LiRul wrote:
Hello!
Az a terv, hogy MySQL5-tel csinalunk egy master-slave felallast, 15-20 db
tablat szinkronizalva. Mind a ket gepen futna egy-egy httpd php-vel,
amig megy a master sql, addig a slave-en futo php is a master-hez
fordul (legalabbis a select-en kivuli keresekkel); ha elerhetetlen a
master, akkor a sajat magan futo slave sql-hez.
Ez idaig tiszta s nem is okoz gondot. (Programozok megcsinaljak a
csatlakozasi dontest.) A problema ott kezdodik, hogy mi tortenjen akkor,
ha a master visszajon az elok soraba? Amig ugye away volt, a slave-re
tortentek az irasok is, kerdes, hogy ez vissza tud-e szinkronizalodni
(szep magyarul) a masterre valahogy?
http://mysql.com/doc/refman/5.0/en/replication-faq.html
Q: How can I use replication to provide redundancy or high availability?
A: With the currently available features, you would have to set up a
master and a slave (or several slaves), and to write a script that
monitors the master to check whether it is up. Then instruct your
applications and the slaves to change master in case of failure. Some
suggestions:
*
To tell a slave to change its master, use the CHANGE MASTER TO
statement.
*
A good way to keep your applications informed as to the location
of the master is by having a dynamic DNS entry for the master. With bind
you can use nsupdate to dynamically update your DNS.
*
Run your slaves with the --log-bin option and without
--log-slave-updates. In this way, the slave is ready to become a master
as soon as you issue STOP SLAVE; RESET MASTER, and CHANGE MASTER TO
statement on the other slaves. For example, assume that you have the
following setup:
WC
\
v
WC----> M
/ | \
/ | \
v v v
S1 S2 S3
In this diagram, M means the master, S the slaves, WC the clients
issuing database writes and reads; clients that issue only database
reads are not represented, because they need not switch. S1, S2, and S3
are slaves running with --log-bin and without --log-slave-updates.
Because updates received by a slave from the master are not logged in
the binary log unless --log-slave-updates is specified, the binary log
on each slave is empty initially. If for some reason M becomes
unavailable, you can pick one of the slaves to become the new master.
For example, if you pick S1, all WC should be redirected to S1, which
will log updates to its binary log. S2 and S3 should then replicate from S1.
The reason for running the slave without --log-slave-updates is to
prevent slaves from receiving updates twice in case you cause one of the
slaves to become the new master. Suppose that S1 has --log-slave-updates
enabled. Then it will write updates that it receives from M to its own
binary log. When S2 changes from M to S1 as its master, it may receive
updates from S1 that it has already received from M
Make sure that all slaves have processed any statements in their
relay log. On each slave, issue STOP SLAVE IO_THREAD, then check the
output of SHOW PROCESSLIST until you see Has read all relay log. When
this is true for all slaves, they can be reconfigured to the new setup.
On the slave S1 being promoted to become the master, issue STOP SLAVE
and RESET MASTER.
On the other slaves S2 and S3, use STOP SLAVE and CHANGE MASTER TO
MASTER_HOST='S1' (where 'S1' represents the real hostname of S1). To
CHANGE MASTER, add all information about how to connect to S1 from S2 or
S3 (user, password, port). In CHANGE MASTER, there is no need to specify
the name of S1's binary log or binary log position to read from: We know
it is the first binary log and position 4, which are the defaults for
CHANGE MASTER. Finally, use START SLAVE on S2 and S3.
Then instruct all WC to direct their statements to S1. From that
point on, all updates statements sent by WC to S1 are written to the
binary log of S1, which then contains every update statement sent to S1
since M died.
The result is this configuration:
WC
/
|
WC | M(unavailable)
\ |
\ |
v v
S1<--S2 S3
^ |
+-------+
When M is up again, you must issue on it the same CHANGE MASTER as
that issued on S2 and S3, so that M becomes a slave of S1 and picks up
all the WC writes that it missed while it was down. To make M a master
again (because it is the most powerful machine, for example), use the
preceding procedure as if S1 was unavailable and M was to be the new
master. During this procedure, do not forget to run RESET MASTER on M
before making S1, S2, and S3 slaves of M. Otherwise, they may pick up
old WC writes from before the point at which M became unavailable.
Note that there is no synchronization between the different slaves
to a master. Some slaves might be ahead of others. This means that the
concept outlined in the previous example might not work. In practice,
however, the relay logs of different slaves will most likely not be far
behind the master, so it would work, anyway (but there is no guarantee).
_________________________________________________
linux lista - [email protected]
http://mlf2.linux.rulez.org/mailman/listinfo/linux
