Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Synergetic have a standard database restore script/procedure that should be used to ensure the initial defaults are set correctly for any system, regardless of if SQL AGs are implemented or not. When SQL AGs are implemented, some of the above settings need to be set on each node, for example the is_trustworthy_on property will need to be enabled on each node and it can only be changed when the node is active. Please refer to the SQL Agent Job - Synergetic DB Health Check.sql listed under Useful Scripts below.


Failover Support

SQL AG Failover mode can be set to automatic or manual and it is recommended to review this Microsoft Knowledge Base article for the required configuration and conditions that will trigger a failover.

On a failover event the Synergetic Windows client and Arrival/Departure Terminal do not support automatic resume however prompts are displayed to the user when the software detects the session has failed, asking the user if they would like to re-connect to SQL Server. This is because the Windows client requires a persistent session (and in many cases multiple sessions) to SQL Server. The web applications do not keep persistent sessions open to SQL Server so failover occurs more seamlessly for the user. To cleanly re-establish the sessions it is recommended to restart the application if the connection ever drops from a failover event.

The window below is displayed in Synmain when the SQL session drops:

Image Added

Click 'Yes' then the warning below is then displayed (as stated above it is best to restart the application if the error above appears):

Image Added

If the session can re-connect the message below is displayed then the application can still generally be used without restarting:

Image Added


Other Considerations

Nodes should share the same hardware configuration, notably drive assignment. If synchronous commit is utilised then the server should have identical hardware for performance. Also need to consider network latency between cluster nodes and failover behaviour, in particular if setting synchronous commit with auto failover.

...