Database best practice multiple gateways same local network

Ignition
1

For system all on local network and servers running in server cluster as VMs

(redundancy / data protection is outside the scope of this question)

We are planning on 3 ignition gateway IO servers (Backend1-3)
And 1 gateway IO server (Frontend1)

For Database should we have (best practice / better efficiency)

  1. Single Database that everything points to? In the neighborhood of 1-3 million tags. (however only a very small portion of these will change with any significant frequency)
  2. Each IO server has DB on the same virtual machine for tag history and that data is synced to main DB (best way to sync that data so history query only references single DB.
  3. We will have some configuration / data tables (outside of ignition created) + Audit log + history + Alarm log + ignition config (ignition created tables) Is there a reason to split these into different database schema, or keep them all in the same database connection / schema? For example Audit and Alarm log in a different DB Schema/connection then history.

For the purpose of this I am not concerned with programming that writes / deletes from the wrong table in the DB and using different connections to prevent this type of program error.

I think for simplicity sake it would be easier if everything was under 1 database connection, but if we need to for performance reasons we can make multiple DB connections.

1 Like
2

Hi,

I would recommend reviewing our Ignition Server Sizing and Architecture Guide. There are a lot of good pieces of information in there that could answer some of your questions.

3
  1. Yes.
  2. Do not put Ignition gateways and DBs in the same VMs in production. CPU and RAM utilization patterns will pathologically interact. Ignition runs best in a low-latency environment, which typically requires have lightly loaded CPU cores dedicated to the VMs. DBs in the same OS will steal all the CPU time.
  3. Keep them together. Ignition will naturally segregate the data by source gateway.

Consider not splitting up the backends. If you have them run just OPC connections and drivers, I suspect a single one will handle all of your tag needs. Your real load will come in on the front end, especially if serving many Perspective clients.

Consider having the I/O backend drive a master DB, and replicate to a slave DB that is read-only, and point the front ends at that read-only replica. Configure the remote tag providers in the front ends to divert tag history queries to their own connection. That'll keep the master DB write-mostly with low latency.

1 Like
4

We are looking at around 3-10 clients with only a couple of them actually in use (not just on static screen) at any one time. 80-90% of the time none of them will actually be in use.