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.
- We don't support any database access outside of Open Dental. Within Open Dental, (Query window) we don't support replication endangering commands: most DDL, INSERT, CREATE, GRANT, ALTER. They have been known to break replication. If you need to do these for any reason, contact Open Dental.
- 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.
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.
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.