Random Primary Keys

In the Main Menu, click Setup, Advanced Setup, Replication.

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.

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.

Range Start/End: The allowed range is extremely large. Open Dental uses 64 bit signed int types internally and in the database. The allowed range is from 1 to 9,223,372,036,854,775,807. This key range is so large that this solution can be scaled up without ever running out of keys, no matter how many clinics are connected. We recommend ranges of at least 100,000,000 numbers. If smaller ranges are used, replication may become slow or unresponsive as the number of available primary keys runs out. This range recommendation will result in keys that are a very manageable 9 digits long. Also, JavaScript and other programs have a max int size of 9,007,199,254,740,992 (1000 times smaller), so it makes sense to stay under this value for future flexibility with other software.

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.

Slave Monitor Triggers and Technical Details

To detect replication failure, Open Dental must be running on the designated slave monitor computer.

How replication failure is detected.

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.

Replication Troubleshooting