Hi Eric,
At least with Maatkit, you get transparency. We make a concerted
effort to update the RISKS section of each tool with each release, so
there
is full disclosure.
Fair enough, but I still found the warnings a little too scary. A more
complete explanation of the exact nature of the
Hi Baron,
I'm the primary author of Maatkit.
Awkward... :-)
What can I say -- you could go buy a commercial off-the-shelf tool
and believe the song and dance they feed you about the tool
being perfect.
There's not a single commercial software solution in our toolbox. We're
big fans
Eric,
There are ways to resync data that don't involve all
this as well: Maatkit has some tools
I've looked with great interest at Maatkit, but their tools are replete
with warnings about dangers, bugs, and crashes. They certainly do not
inspire confidence.
I'm the primary author of
Let's face it, sometimes the master and slave get out of sync, even when
'show slave status' and 'show master status' indicate that all is well.
And sometimes it is not feasible to wait until after production hours to
resync them. We've been working on a method to do an emergency
hot-resync
i have two questions. (1) innodb? (2) why delete slave logs when you can
restart the slave with --skip-slave and then use CHANGE MASTER TO?
tom
On 12/4/09 6:34 AM, Robinson, Eric eric.robin...@psmnv.com wrote:
Let's face it, sometimes the master and slave get out of sync, even when
'show
(1) innodb?
It's an off-the-shelf application that uses MyISAM tables. It is
possible to convert to innodb, but I have not been sold on innodb in
terms of its performance characteristics for this particular
application. Maybe I've been reading the wrong stuff. Do you have
general thoughts on
On 12/4/09 11:59 AM, Robinson, Eric eric.robin...@psmnv.com wrote:
(2) why delete slave logs when you can
restart the slave with --skip-slave and
then use CHANGE MASTER TO?
Well... I guess mainly because I didn't know about that option! I
thought I needed to fake out mysql on this, but it
I think he's trying to say that this method wouldn't work for innodb, unless
you copied files from an LVM snapshot, or something similar.
I would say that it's very important to know why data is getting out of sync
between your master and slave. Fixing those root causes would eliminate the
On 12/4/09 3:14 PM, Gavin Towey gto...@ffn.com wrote:
I would say that it's very important to know why data is getting out of sync
between your master and slave. Fixing those root causes would eliminate the
need for this.
i very much agree. the only instances of slaves getting out of whack
I would say that it's very important to know why data
is getting out of sync between your master and slave.
Ultimately, I agree. But since it's a canned application, getting to
that point might be hard, and once it is resolved, new issues might
arise. I would never have any confidence that
I would never have any confidence that the replication is solid
enough to use the slave server for backup purposes.
I agree completely there. That's the other reason I like filesystem snapshots
is that it allows you to take a backup from the master relatively painlessly.
-Original
I would never have any confidence that the replication
is solid enough to use the slave server for backup purposes.
I agree completely there. That's the other reason I like filesystem
snapshots is that it allows you to take a backup from
the master relatively painlessly.
I've thought of
12 matches
Mail list logo
