Random Primary Keys / Slave Monitor
Random primary keys are unique key ranges used by each server on Replication (both One-Way Replication and Daisy Chain Replication). They ensure there will be no conflicts when data is merged. A Slave Monitor is required for daisy chain replication only.
Note: For one-way replication, random primary keys are required because Open Dental inserts data even if a user doesn't. For example, if an appointment is opened, no changes are made, then OK is clicked, Open Dental creates an audit trail entry. There are also continuous records added for signals (the heart beat of the application).
Slave Monitor: If running daisy chain replication, one computer must be designated as the Slave Monitor, and each server must have the slave monitor specified in the Slave Monitor field. The slave monitor computer will constantly monitor the health of the replication process and should stay on and logged on to Open Dental at all times. The slave monitor does not need to be the replication server; it can be the name of any workstation on the network. Typically, users specify the replication server as its own monitor because Open Dental must be running and a user must be logged on for the monitor to work. It should at least be a computer that is on the same network as the replication server so it will continue to function normally if the internet goes down.
Example: There are two replications servers (A and B) at two different offices. In server A's office, the replication monitor could be any computer on network A. It would not be a computer on network B, because if the internet went down, the monitor would quit working.
Turn on Random Primary Keys / Specify the Slave Monitor
Once you start using random primary keys, you can never turn the feature off, though you can freely edit the ranges.
- In the Main Menu, click Setup, Advanced Setup, Replication.
- Check the Use Random Primary Keys box at the top to turn on random primary keys. From now on,
all of primary keys in all tables will be longer, making
them not as user-friendly if we need to do troubleshooting.
Synch: If clicked, Open Dental will use the text in the server Description as the computer name for each replication server. The synch will fail if the description is not a valid replication server computer name.
- Click Add to add a server, or double click a server to edit.
- Enter the server information:
Server Description: Server name. Not actually linked to the Clinic table yet. This field should exactly match your server name or IP address. We recommend using IP address to reduce possible DNS issues.
server_id: The database admin adds a server_id command to the my.ini file on each server. See instructions further down for editing the my.ini file. Each workstation can then use a query to identify which server it is connected to. The interface above allows setting a key range for each server_id.
Range Start/End: The allowed range is extremely large.
A to Z folders: Each server can be assigned separate A to Z folders. This allows the use of a folder in the local area network rather than one that's accessed across a VPN. This path will also show in the Data Path window. Keeping the A to Z folders synchronized between locations is up to the customer and will require additional software and expertise. If using different A to Z folders, when doing an update from the main office use a script to copy the contents of the Update Files folder to the other A to Z folders. Microsoft has a free applications like SyncToy 2.1 and DFS File Synchronization. See Online Backups.
Update Blocked: If checked, then no workstation connected to that server will be allowed to initiate an update. This is typically done for servers that are considered slave or peripheral. Use this option carefully. It really will block the ability of the server to update database versions, and it's possible that this could prevent startup of the program in certain situations.
Report Server: Flag the server as a 'report' replication server so it can run dangerous Queries such as those with CREATE TABLE or DROP TABLE syntax. These queries can cause replication failure so should only be run on 'report' servers. More than one computer can be a 'report' server.
Slave Monitor (Daisy Chain Replication only): Specify the computer that will monitor the status of the replication process. If replication fails, this computer will be responsible for disabling access to Open Dental from all computers on this server until replication has been restored.
Slave Monitor Triggers and Technical Details
To detect replication failure, Open Dental must be running on the designated slave monitor
How replication failure is detected.
- The monitor polls the slave status every 10 seconds with the following query: SHOW SLAVE STATUS \G;
- If the Slave_SQL_Running column does not equal "Yes", then the slave updates the database to trigger that replication has failed.
For example if server ID is 3:
UPDATE preference SET ValueString = '3' WHERE PrefName = 'ReplicationFailureAtServer_id';
- All users are kicked out of Open Dental on all servers.
- When users try to use Open Dental on the failed slave, they are told, "This database is temporarily unavailable. Please connect instead to your alternate database at the other location."
It is up to the administrators of the replication service to ensure that training is in place to make sure users know what to do when they see this message.
The slave monitor will detect failure if replication stops or fails on any server, for any reason. So do not stop replication unless Open Dental is shut down on the monitor. The slave monitor will not react to loss of internet connection; MySQL will gracefully continue replication where it left off when reconnected. Stopping the MySQL service will cause other error messages in Open Dental, but will not trigger a reaction by the slave monitor.
See also Troubleshooting Replication.