Replication Master Configuration

Replication has several different configuration options.  On the main replication page, we describe daisy chain replication.  This page describes a totally different replication configuration.  This is not a current feature and only describes an idea for a possible new feature.

The advantage of this configuration is that there is only one master database, so if replication fails for some reason, there is no synchronization that needs to be done.  Instead, the master is simply recopied to the slave, and replication is restarted for that slave.

The master database would sit at the center of a star topology, surrounded by a number of slave databases.  The slave databases would be read/write, while the master database would be used only for writing.

Or if using the more secure Middle Tier:

Before anyone can start using the topology shown above, we would need to add a few new features and also review every single query in the entire program.

Technical Issues for Master Configuration

A disadvantage of this configuration is that it does not allow writes when there is no internet connection, but that's a good tradeoff if corruption is less likely.

If a write to the master fails, the write to the local server should also fail.  This ensures that all databases stay synched.

If the master is unavailable, the local servers should be available for read and should not show error messages regarding unimportant writes.

If a slave goes down, the user should be able to manually connect to the master.

Information about how to connect to the master should be in the database itself, and only alterable on the master.

Random primary keys must be turned on so that every INSERT will already contain a key.  There can be a single range instead of the usual multiple ranges.

It is much higher priority that direct connections be implemented; middle tier can come later.

Replication must be monitored and must not have a significant delay, hopefully less than one second.  If replication fails, the slave must be forced to stop accepting queries.

The process of restarting a failed slave that's been down for more than a few minutes should include copying a fresh database from the master rather than trying to patch the slave.