|
On 10/25/05, Troy Hakala <troy@xxxxxxxxxxxxxx> wrote:
> 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.
>
perhaps it changed from when i used it - anytime a slave died, it
would not start replicating (or you wouldn't want to) unless it caught
up to the master since it died. but to grab a snapshot of the master
data, you would have to take the master down or flush tables with a
read lock until it was done getting the data synced. then you could
restart it...
> 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.
how is it easy to take care of?
for example, i was using this on a forum - when someone posts a message:
webserver inserts data into master
master replicates to slave
webserver reads from slave
if that doesn't happen within milliseconds, the user is taken to a
page that doesn't have their post show up yet.
now we can say "okay, all you need is gigE and nice processors and
latency is low" - but you can't guarantee that over the lifetime of
the application, so it wouldn't be smart to design for it that way,
right?
to me, mysql replication is only useful if you can access data that
isn't changing near-realtime. otherwise to be safe you always have to
ask the master for the data back, because you can't guarantee the
slave is within milliseconds of the master...
|
