Daisy Chain Replication 

If you are just taking your laptop home at night or want access from home, do not use daisy chain replication.  Instead, consider a different Remote access strategy. Also, before using Daisy Chain Replication, see the Multiple Locations page, and make sure you understand all the alternative strategies listed there.

You can creating a powerful multi-location database which can also tolerate intermittent lost connections.  Multiple servers are set up, and each one has an identical database.  All the servers are then replicated to each other in a big daisy chain circle that includes all servers.  As few as two servers may be included in the loop.  One of the servers may be temporarily disconnected from the internet for a time, and will continue to function normally.  When it's reconnected to the loop, it gets properly synchronized.

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 a laptops to a nursing homes, then each laptop would be a standalone server.  The servers at each location have identical data and they stay in synch using MySQL replication.

There are, of course, limitations to this solution. It does not scale up well.  Every time a server looses connection to the internet, the replication stops.  One broken link in the chain stops replication for all servers.  The individual servers still function, but they are at risk of getting out of synch. It takes a skilled database administrator to keep the MySQL 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. Also, all of your primary keys in all your tables will be longer, making them not user friendly if we need to do troubleshooting. Once you switch to random primary keys which are needed for muliple server merging, you can never go back.  Using random primary keys is not a huge consideration, but it's just something to be aware of.

Step one: Setup each individual server and make sure it works properly.

Step two: Setup a replication daisy chain. Each server is both a slave to the server behind it and a master to the server in front of it.  This causes data entered on one server to be duplicated to all the other servers whenever a connection becomes available.  See the MySQL website for information on setting up replication.  Also, read this multipage article: http://www.onlamp.com/pub/a/onlamp/2006/04/20/advanced-mysql-replication.html

adjustment
appointment
carrier
claim
claimpayment
claimproc
clockevent
commlog
computer
contact
covpat
docattach
document
emailmessage
emailtemplate
employer
insplan
instructor
letter
lettermergefield
lettermerge
medication
medicationpat
patient
patientnote
payment
payplan
paysplit
perioexam
periomeasure
printer
procedurelog
quickpastecat
quickpastenote
recall
referral
rxpat
schoolclass
schoolcourse
screen
screengroup
securitylog
task
tasklist
zipcode

You should designate one server to handle administrative funtions including:
Appointment Views
Autocodes
Claim Form editing
Clearinghouses
Clinics
Counties
Insurance Categories
Definitions
Employees
Fees
Language translation
Security Admin
Procedure Buttons
Procedure Codes
Program Links
Providers
Rx Setup
Schedules, including provider and blockout
Schools

Eventually, all tables will appropriately handle random primary keys, even adminstrative tables.

Step four: In the Main Menu, go to Tools | Merge Replicating Databases.  Learn how to use this tool.

You will see a list of all Computers that have logged in from a client workstation. Manually select all computers in the list that are part of the replication loop.  When you click OK, it will communicate with all of the servers on each computer and force replication to synchronize.  This is useful sometimes if you need to ensure that you have the most recent data on all servers.

MySQL also provides an enterprise monitor software that will graphically show your replication loop and will let you monitor the status of each server and how many seconds each one is behind its master.  Learn how to use the monitor tool.