RE: Here"s an Idea for Re-Syncing Master and Slave During Production Hours without Interrupting Use

RE: Here"s an Idea for Re-Syncing Master and Slave During Production Hours without Interrupting Use

am 04.12.2009 22:24:12 von Eric.Robinson

> I would say that it's very important to know why data=20
> is getting out of sync between your master and slave.=20

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 the replication is solid
enough to use the slave server for backup purposes. (Which, by the way,
is the real reason I'm doing this. In the middle of the night, when
there are few users on the system, I want to backup the slave, but first
I want to make sure I have a 100% reliable copy of the data.)

> There are ways to resync data that don't involve all=20
> 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.=20

--
Eric Robinson=20



Disclaimer - December 4, 2009=20
This email and any files transmitted with it are confidential and =
intended solely for Gavin Towey,Tom Worster,mysql@lists.mysql.com. If =
you are not the named addressee you should not disseminate, distribute, =
copy or alter this email. Any views or opinions presented in this email =
are solely those of the author and might not represent those of . =
Warning: Although has taken reasonable precautions to ensure no viruses =
are present in this email, the company cannot accept responsibility for =
any loss or damage arising from the use of this email or attachments.=20
This disclaimer was added by Policy Patrol: http://www.policypatrol.com/

--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/mysql?unsub=3Dgcdmg-mysql-2@m.gmane.o rg

RE: Here"s an Idea for Re-Syncing Master and Slave DuringProduction Hours without Interrupting User

am 04.12.2009 22:33:28 von Gavin Towey

> 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 snapsh=
ots is that it allows you to take a backup from the master relatively painl=
essly.

-----Original Message-----
From: Robinson, Eric [mailto:eric.robinson@psmnv.com]
Sent: Friday, December 04, 2009 1:24 PM
To: Gavin Towey; Tom Worster; mysql@lists.mysql.com
Subject: RE: Here's an Idea for Re-Syncing Master and Slave During Producti=
on Hours without Interrupting Users (Much)

> 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 the replication is solid
enough to use the slave server for backup purposes. (Which, by the way,
is the real reason I'm doing this. In the middle of the night, when
there are few users on the system, I want to backup the slave, but first
I want to make sure I have a 100% reliable copy of the data.)

> 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.

--
Eric Robinson



Disclaimer - December 4, 2009
This email and any files transmitted with it are confidential and intended =
solely for Gavin Towey,Tom Worster,mysql@lists.mysql.com. If you are not th=
e named addressee you should not disseminate, distribute, copy or alter thi=
s email. Any views or opinions presented in this email are solely those of =
the author and might not represent those of . Warning: Although has taken =
reasonable precautions to ensure no viruses are present in this email, the =
company cannot accept responsibility for any loss or damage arising from th=
e use of this email or attachments.
This disclaimer was added by Policy Patrol: http://www.policypatrol.com/

This message contains confidential information and is intended only for the=
individual named. If you are not the named addressee, you are notified th=
at reviewing, disseminating, disclosing, copying or distributing this e-mai=
l is strictly prohibited. Please notify the sender immediately by e-mail i=
f you have received this e-mail by mistake and delete this e-mail from your=
system. E-mail transmission cannot be guaranteed to be secure or error-fre=
e as information could be intercepted, corrupted, lost, destroyed, arrive l=
ate or incomplete, or contain viruses. The sender therefore does not accept=
liability for any loss or damage caused by viruses or errors or omissions =
in the contents of this message, which arise as a result of e-mail transmis=
sion. [FriendFinder Networks, Inc., 220 Humbolt court, Sunnyvale, CA 94089,=
USA, FriendFinder.com

--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/mysql?unsub=3Dgcdmg-mysql-2@m.gmane.o rg

Re: Here"s an Idea for Re-Syncing Master and Slave During Production

am 08.12.2009 23:05:44 von Baron Schwartz

Eric,

>> There are ways to resync data that don't involve all
>> this as well: =A0Maatkit 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 Maatkit. 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. 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.

I think Maatkit is by far the best solution for live master-slave sync
in most real-world situations.

- Baron

--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/mysql?unsub=3Dgcdmg-mysql-2@m.gmane.o rg