Random Primary Keys
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.
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.
Once you start using random primary keys, you can never turn the feature off, though you can freely edit the ranges.
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 sync 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_idcommand 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.
A to Z folders: Each server can be assigned separate A to Z Folder. 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 (Paths). 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.
To detect replication failure, Open Dental must be running on the designated slave monitor computer.
How replication failure is detected.
For example if server ID is 3: UPDATE preference SET ValueString = '3' WHERE PrefName = 'ReplicationFailureAtServer_id';
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.