|
hmmm... I'm not sure what you mean, replication can be restarted easily:
slave start. That is, after you fix the error, which is usually just a
mysqlcheck on the table. You shouldn't have to take the master down at all.
And if you use a replication check in LVS, LVS will take the db server out
of rotation if it's not replicating, so it shouldn't even be noticed until
you can get around to fixing it. Nagios is also recommended to let you know
when a slave is no longer replicating.
The latency is on the order of a couple seconds and it's easy to take care
of in the app. In fact, it's only a problem if you cache db results for
hours or days (we use memcached). So it's not much of a problem in reality
if you account for it.
NDB violates my simplicity+commodity ideals... it's complicated and requires
very expensive (lots of RAM) servers. And, I think it *requires* SCSI drives
for some reason (I thought it was memory-based)! Doesn't Yahoo use MySQL
replication? If it's good enough for Yahoo, it's good enough for most
people. :-)
On 10/25/05, mike <mike503@xxxxxxxxx> wrote:
>
> this is exactly how i was doing it.
>
> the problem was that i expected the data on the slaves to be realtime
> - and the replication moved too slow. not to mention it broke a lot
> (not sure why) - anytime there was a query that failed it halted
> replication.
>
> in which case, i had to either take the master down, or put it in
> read-only mode, so i could copy the database over, and re-initialize
> replication.
>
> of course, this was on sub-par equipment, and maybe nowadays it runs
> better. i'm thinking that the NDBcluster solution might be better
> since it's designed for this more - replication still (afaik) sucks
> because when you need to re-sync it requires the server to be down or
> put in read-only, which is essentially downtime.
>
> On 10/25/05, Troy Hakala <troy@xxxxxxxxxxxxxx> wrote:
> > We're using master/slave replication. The LVS balances the reads from
> the
> > slaves and the master isn't in the load-balancing pool at all. The app
> knows
> > that writes go to the master and reads go the VIP for the slaves. Aside
> from
> > replication latency, this works very reliably.
> >
> _______________________________________________
> LinuxVirtualServer.org mailing list - lvs-users@xxxxxxxxxxxxxxxxxxxxxx
> Send requests to lvs-users-request@xxxxxxxxxxxxxxxxxxxxxx
> or go to http://www.in-addr.de/mailman/listinfo/lvs-users
>
|
