Good day.
When the connection is lost, data synchronization ends with an error. If it synchronizes for several days some trezor and there is a connection failure lasting about 5 minutes before the end, the rest of the archive objects will not be completed. Would it be possible to add a parameter to ARCSYNCHRO, which would say that it should try to connection to both databases and continue only after the connection is recover?
Well thank you.
Thank you for your suggestion.
I asked my colleagues to add this property to the property list for other versions (so-called wishlist).
D2000 currently has various mechanisms for increasing the level of availability and reliability (redundancy of application servers, redundancy of processes, redundancy of archives, redundancy of communication routes in selected communication protocols).
Of course, we have not caught “everything”. The availability of a database (configuration / monitoring) for the Kernel is necessary condition. If it is not met, the kernel loses end when connectivity is lost.
It is similar for the archive. It has no database - it does not try to reconnect or otherwise mask the outage. The end. Similarly, the cfgsynchro tool (synchronization of configuration databases in redundancy). Loss of connectivity will cause an error and end.
Also DbManager e.g. actively try to reconnection a broken connection. But if it was a transaction, all operations within the current transaction will end in failure. Only then (after the transaction is completed) can the connection be recycled to something else. So we don’t mask anything here, the application knows that something is wrong.
If we wanted to implement connection reconnection in Archive, there would be other complications, for example:
• if the archive is active, after losing the connection to the DB, it tries to restore it, but if it fails for a long time, requests are accumulate in queues
• so e.g. they do not change the values of archive objects, they do not count statistics - there are many applications where it will matter (and in redundancy they would prefer crash of archive and automatic switching of the active instance to the second archive)
• if the connection cannot be reconnection for a long time, the memory queue grows, can it cause exhaust memory, crash of archive … good or bad?
Besides that to supplying D2000 technology to our partners, we have several large systems deployed and supported, most with redundant archives. In a standard corporate environment (whether servers supplied by us or our customers, or physically or virtualized), I have not experienced network / archive / arcsynchro problems over 16 years (since arcsynchro exists) that would require the implementation of reconnect. If there were crashes or problems with the archive DB, then the stability of the DB server was solved (eg for Oracle 11c).