Database Reference
In-Depth Information
Replication best practices
Some general best practices for running replication systems are described in this chapter.
How to do it...
F Use similar hardware and OS on all systems: Replication allows nodes to switch
roles. If we switchover or failover to different hardware, we may get performance
issues and it will be hard to maintain a smoothly running application.
F Configure all systems identically, as far as possible: Use the same mount points,
same directory names, same users; keep everything possible the same. Don't be
tempted to make one system more important than the others in some way. It's just a
single point of failure and gets confusing.
F Give systems good names to reduce confusion: Never, ever call one of your systems
"Master" and the other one "Slave". When you do a switchover, you will get very
confused. Try to pick system names that have nothing whatsoever to do with their
role. Replication roles will inevitably change. System names should not. If one system
fails, and you add a new system, never reuse the name of the old system: pick
another one. It will be too confusing. Don't pick names that relate to something in the
business. Colors are a bad choice, because if you have two servers named yellow and
red , you then end up saying things like "there is a red alert on server yellow" which
can easily be confusing. Don't pick place names, otherwise you'll be confused trying
to remember that London is in Edinburgh and Paris is in Rome.
F Keep the system clocks synchronized: This helps you to keep sane when looking
at log files produced by multiple servers. You can either use ntp or manually resync
them on a regular basis.
F Use a single, unambiguous timezone: Use UTC (Coordinated Universal Time) or
similar. Don't pick a timezone that has Daylight Savings Time , especially in regions
that have complex DST rules. This just leads to (human) confusion with replication, as
servers are often in different countries, and timezone differences vary throughout the
year. Do this even if you start with all servers in one country, because over the lifetime
of the application, you may add new servers in different locations. Think ahead.
F Monitor each of the database servers: If you want high availability, then you'll need
to regularly check that your servers are operational. I speak to many people who
would like to regard replication as a one-shot deal. Think of it more as a marriage,
and plan for it to be a happy one.
F Monitor the replication delay between servers: All forms of replication are only
useful if the data is flowing correctly between the servers. Monitoring the time it
takes data to go from one server to another is essential to understanding whether
replication is working for you, or not. Replication can be bursty, so you'll need to
watch to make sure it keeps within sensible limits. You may be able to set tuning
parameters to keep things low, or you may need to look at other factors.
 
Search WWH ::




Custom Search