slony and database replication (info from LinuxWorld) (continued)
Python
python at venix.com
Tue Apr 11 18:57:00 EDT 2006
(my editor's hot-key for open new line below (vi's lower-case o)
is the same as my email's send-it-now key)
My two main reasons for using MySQL are:
easy administration
replication
The MySQL replication process works by serving the Master's log out to
the replicating slaves over the network. The connection is very loose.
So long as the log files have not been deleted, a slave can resume
processing even after losing contact for several months. The slaves
track their own progress through the log files. The log file includes
time stamp info from the original server along with server ID numbers so
that (master, replicator) sets can be daisy chained or even closed into
a circle.
I asked about replication for postgresql and was pointed to Slony.
However, reading the website info, Slony appears to be designed for
tightly coupled on-line cluster style operations. If any one has
experience to contradict that, please let me know.
If anyone cares, the rules for MySQL replication are:
unique ID for each server
only one master (source) into each server
many replicators from a server
a loop can be as short as two servers replicating each other
It is possible to short-circuit a large logical loop and directly
combine logs into a "common collector".
--
Lloyd Kvam
Venix Corp
More information about the gnhlug-discuss
mailing list