Before I started at my current company, they had a contractor who started up our system. I've recently been going back through their work and cleaning up messes they left behind.
The specific employee who did the work is no longer with the contracting company.
The gateway has multiple DB connections to the same mySQL database. I was curious if anyone had an insight into why the contractor set up the database connections this way. I've asked the contracting company and they told me they aren't sure why.
I'm going to be adding pruning of old data to the mySQL instance and am nervous due to the multiple connections to the same DB.
Are they pointing to different schemas?
1 Like
Did the contractor divide usage up by purpose? I can see using one DB connection for writes while another connection is for bulk trends and data analysis.
@JordanCClark :
They all have the exact same configuration.
@pturmel :
I suspect it may be an attempt at this. There are 4 connections, and the tags are split up amongst the 4.
I might do some testing and see if we get better load times on our trends if I make a connection just for trends. I might even put all the writes in one connection if it simplifies things without to much of a load change.
Thanks for the input.
Yes, one connection dedicated to writes and one connection for everything else would make the most sense. Unfortunately, the tag historian isn't really designed to do this. So a third connection just for the tag historian might make sense.
Anyways, pool size on the writing connection should be large enough to not have any write operation waiting for a turn. Pool size on the reading connection should not be so large that it interferes with the writing connections.
Tweaks that put some critical reads on the priority connection aren't the end of the world.
Splitting tags up among four connections isn't really going to be any different than using one connection with a pool as big as the four separate ones combined.
1 Like