Redundancy Historian data

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.

1 Like

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.

1 Like

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 @PGriffith 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.

1 Like

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.

And thank you too @PGriffith.

This is a great article to get you started:

1 Like