My first project setting up a redundant server:
-2 PC’s each with
– Ignition 8.0.0.10 (testing right now) Logging to Historian Spliter (pointed at each SQL express)
– MS SQL Express
Both DB’s get the same data, looks good.
when Backup reboots, Data looks good after recovery.
when Server reboots…
-any data collected in the backup SQL instance stays on the backup and is not available to charts after the master is back on-line.
Question: is there a way to make those rows show up in the SQL instance on the master?
Don’t use the historian splitter for this. Use your database’s replication/master-backup/etc system. For MSSQL, I believe this usually gives you a “virtual” IP, that will seamlessly fail over to the ‘master’ or ‘backup’ database instances, in a way that’s totally invisible to whatever application is connecting to the database.
Also, you probably don’t want to run your database on the same VM/hardware/etc as Ignition; both databases and Ignition like to consume RAM. Frequently, even if you have plenty of hardware overhead to start with, in a few years you’ll have to deal with a painful divorce once one or both services overruns what it can use on your hardware. Which is not to say you can’t run the two services on the same hardware…just that there’s plenty of tales (on this forum and elsewhere) of eventual fallout from early design decisions.
Thanks for the quick reply! This is for a small tank farm. 2 PLC’s - only keeping a year of tag data. Probably only going to look at a month of data. No off site use. We are replacing the current IFix system. Using IFix system as a template to design the system. Been in place for about 10 years. No need to add server farm.
Looking for a way of pushing collected data on backup system to master when master returns on-line… Without the 5 figure cost. That is to say - programmatically.
Are you totally committed to MSSQL? MySQL has good replication features and the community edition is free. We have used this product with Ignition on 10,000 tag systems.
EDIT: While @paul-griffith does have a point with separating the services, I have found it is just plain easier to have them under the same machine. Mostly to avoid having to manage a “virtual” IP. If it is on the same machine. The IP address can be localhost. Just something to consider.
I have not used MySQL professionally. When I was studying SQL I had a Fedora server setup, Apache, & PHP. Thanks for the input. I’ll look into it. @brandon1.
I have used Master-Master replication in both MySQL and Maria on almost all of our deployments. It is our default standard. I do want to explore using the core historian when it has added the redundancy feature. It seems like GTID replication makes the system less prone to conflicts that fault the replication but that is something that has to be dealt with when using this. It is worth the extra management to guarantee that a single database failure does not take down history on the system.
When the master gateway goes down, the backup gateway takes over and begins writing historian data to its own local com.inductiveautomation.historian directory. When the master gateway comes back online and resumes operation, it continues writing to its own historian directory.
This results in a gap in historical trends on the master, corresponding to the period when the backup gateway was active.
Our question is:
Is there a supported way to merge the historian data directories (com.inductiveautomation.historian) from the backup gateway into the master gateway so that the missing historical data is restored and the trend gap is eliminated?
If direct merging of the directories is not supported, what is the recommended method for consolidating historian data between redundant gateways when failover occurs?
Any guidance or recommended best practice for handling this scenario with Core Historian would be greatly appreciated.
Is it possible to merge “C:\Program Files\Inductive Automation\Ignition\data\var\com.inductiveautomation.historian” from backup-server with “C:\Program Files\Inductive Automation\Ignition\data\var\com.inductiveautomation.historian” in master-server while waiting for redundant functionality?
Maybe via the PostgreSQL-compatible aux port for the QuestDB. Likely not trivial.
I would set up an external DB for history, and run scripts to query from the core historian then system.tag.storeTagHistory() to store to the proper external DB. Fail over to backup and run there too (probably need a tag event to trigger on the backup).
Or open a support ticket to get help.
Bottom line is to not use the core historian with redundancy until official support arrives.