Home User Manual Discussion Forum Search

Replication 

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.

WARNING

  • 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.

One-Way 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 replication.

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.

Other Strategies
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 Locations.

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. 

 

Open Dental Software 1-503-363-5432