Replication is a technology built into MySQL that continuously keeps a slave database synchronized with its master. To learn more, read chapter 16 in the MySQL 5.1 Manual regarding replication configuration.
Other Helpful Links
Open Dental no longer charges extra for replication support. For customers on normal support, our replication support services are limited to general advice, startup assistance, and troubleshooting the cause of replication failure when asked.
TimeStamp columns, such as procedurelog.DateTStamp, will have different values in each database because of the inherent lag with replication. When looking at the columns in the database, be aware that this is normal and expected.
- We don't support any database access outside of Open Dental.
- Within Open Dental, (Query window) CREATE and DROP commands can only be run from 'report' servers because they have been known to break replication. See Random Primary Keys.
- You cannot run Daisy Chain Replication on live databases without a Replication - Slave Monitor that immediately notifies all users and IT staff at the exact moment that replication crashes. We cannot stress this enough. We are not responsible for the damage done when databases continue to be used after an error crashes replication.
- If running Database Maintenance, make certain all servers are connected prior to running (e.g. if mobile units). We also recommend making a backup of the database first, then running it after hours. You will need to 'Force Synchronization' after running, then check that replication is still running properly. You want to avoid a scenario where you run database maintenance at one location, then run at a second location while the first one is running.
The simplest configuration is One-Way Replication. Anyone considering replication is encouraged to run this configuration for a number of months to get very familiar with the administration.
Daisy Chain Replication
In a more complex configuration, the replication can form a ring. This is called Daisy Chain Replication. All the databases together are referred to as a single virtual database. In this configuration, each location can continue to function normally even if the internet connection is lost. The data from the other locations will not be fresh, but an office typically doesn't care as much about that data. Once the internet connection is restored, the replication quickly updates the database with current data. This kind of replication is supported very well by Open Dental.
This also works well for mobile vans that service children or nursing homes.
You want all patients in one database, but your network connection
may be slow and intermittent, or you might only be able to connect to
the network when you return from the field. So instead of the usual
single server, you would have multiple servers, one for each mobile
van. If you take laptops to nursing homes, then each laptop would
be a standalone server. The servers
at each location have identical data and they stay in synch using
There are, of course, limitations to this solution. It takes a very skilled database administrator to keep
the synchronization running smoothly and to properly handle
a downed network. Setting up the servers is time consuming
and requires expertise that we might not be able to provide. Replication also requires that proper safeguards be put in place to monitor and repair any replication problems. We have found that many offices tend to jump right into replication without having any recovery skills and without a monitoring process in place.
You cannot run daisy chain replication on live databases without a monitor that immediately notifies all users and IT staff at the exact moment that replication crashes. We cannot stress this enough. We are not responsible for the damage done when databases continue to be used after an error crashes replication. 2/8/2012 Version 12.1 has new features to prevent usage of a database where replication has failed. See Replication - Slave Monitor.
If you are just taking your laptop home at night or want access from
home, do not use replication. Instead, consider a
different Remote access strategy. Also,
before using replication, understand the alternative strategies explained on Multiple
Features that won't work
The following features will not work when using Random Primary Keys and replication. There are no immediate plans to add support.
- The Anesthesia feature was written by an outside developer and is not used by most dental offices.
- Language Translation. It uses strings for primary key instead of int. And because English phrases are added automatically and frequently, it would be hard (but not impossible) to adapt it for use with replication. As long as each computer is set in the Control Panel for English-US, this will not be a problem.
- The eCW bridge might not work. It assumes that various parameters are int32.
- The Public Health School table and County
table use strings instead of ints for primary keys. May end up with a few duplicates if not synching in real-time. Unsure what consequences would be. Probably more annoying than critical.
Storing Images in Database: We do not recommend using replication with Images Stored in Database, except for distributions where the Images module is not used.
EHR users: There are no known issues for using replication with EHR features. If you are an EHR user who uses replication, please let us know so we can monitor and track your success. If you have any issues, please notify us immediately.