You can help by commenting or suggesting your edit directly into the transcript. We'll review any changes before posting them. All comments are completely anonymous. For any comments that need a reply, consider emailing firstname.lastname@example.org.
We are experiencing playback issues from our video hosting provider. Please check back shortly.
Learn about what database information you need to think about and consider in order to protect your data when setting up Redundancy in Ignition.
Video recorded using: Ignition 7.9
Transcript(open in window)
[00:00] When we talk about Redundancy in Ignition, we're trying to maximize the uptime of the Ignition Gateway. But Ignition Redundancy only protects the projects and not the data in our database. Protecting your database data is typically done using your database software, but Ignition has some tools that can help protect the data. For example, the tag historian has a tag history splitter provider, which will store history data to two separate databases, but even then we'd only be duplicating our history data and not any data coming from transaction groups or scripts or query bindings that we have elsewhere in the project. The most common way to do this is to set up one or two way replication in your database. One way replication will maximize the uptime of the database at the expense of not having access to the historical data when the master is down. Two way replication is the best option because, in addition to maximizing uptime, it provides a complete duplicate of your data, so that even when the master database is down, you will still have access to all of your data for trends, reporting, or anything else that you are interacting with.