Replication is a technology built into MySQL that continuously keeps a slave database synchronized with its master. If you are interested in replication, contact technical support for general startup information. To learn more about replication, read chapter 17 in the MySQL 5.5 Manual regarding replication configuration.
Support: We charge an additional $100 per hour for replication support. We will provide 15 minutes of free diagnostic support, but anything in excess will be charged at the replication support rate. Services are limited to general advice, startup assistance, and troubleshooting the cause of replication failure when asked.
Features that won't work with replication:
There are no immediate plans to add support.
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.
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.
One Way Replication: See One-Way Replication Setup.
This configuration is useful for offices that have many workstations or who experience slowness on the main server when running custom reports or complex backup scripts. Anyone considering replication is encouraged to run this configuration for a number of months to get very familiar with the administration.
The Slave pulls data from the Master. No changes are ever made directly to the Slave database. Any users of Open Dental connecting to the slave database should be trained to only run reports or make backups, not to do any data entry. Data is never sent from the Slave to the Master because there is no replication process in that direction. If the Slave becomes corrupt, simply wipe it clean and start again.
Daisy Chain Replication: Daisy Chain Replication Setup.
This configuration is very complex and should only be attempted by users who are experienced with replication. The replication forms a ring. All the databases together are referred to as a single virtual database. 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 configuration 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 sync 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 recovery skills and without a monitoring process in place.
Other Strategies: If you are just taking your laptop home at night or want access from home, do not use replication. Instead, consider other options. See Remote Access.