We are running FactorySQL 4.2.12 on three servers. Two of the servers run a redundant project. The third server is running a standalone project. Data caching is enable on all three servers. Both of the projects log data to the same separate database server, but each logs to a different database on that server. Last night we experienced a network hardware failure on the database server. The standalone project cached the data until the problem was resolved. The redundant system did not cache any data. Is there a known problem with caching and redundant projects?
A fourth FactorySQL server running version 4.1.5 also has a standalone project. It did not cache the data either even though caching is enabled.
The redundant servers should have both cached data, and then the server that ultimately became master should have written the cache.
I would look at the logs for both servers, as well as the “redundancy” and “data cache” sections under the system status window. You should see that at some point the systems both become “provisional masters” - this means that they can’t determine who’s master and will both partially run- the historical data will be cached.
Around the time that one of them becomes full master and the other primary backup, you should see some messages about the data cache.
Also, go to the install directories and take a look at the data_cache_db.fdb files. How big are they? Anything over 100k or so might indicate that there is data that needs to be written.
Regards,
I think I know why the data may not have been cached. I believe the groups that weren’t cached had SQL Query action items. When FSQL lost the connection to the database server, it wasn’t able to evaluate all the items and therefore didn’t cache any data.
So it’s by design that FactorySQL Groups with SQL Query action items will not be cached when the database connection is lost? A better solution would be to allow the caching function to work but use a null value for the items that cannot be evaluated. Has this issue been addressed in Ignition?
Yes it’s true that the group with SQL queries will fail and thus not execute. You’re right that we possibly could just ignore this and log null values, but for most situations where these are used, it probably wouldn’t be desirable. To put it a different way, groups have always worked more or less under the assumption that everything should completely successfully or not, and the general thought is that we don’t know how important that value is going to be.
Of course, the easy solution would just be to make an item level option that says “abort group execution on error”, so if it were set to false, it would just affect the item and not the group. This idea has been brought up before, but has not yet made its way into Ignition.
Regards,