I'm not going to argue against the importance of backups but in addition, MySQL 5.6 added
an additional option in delayed replication
- note that though the blog post is looking at the 5.6 DMR, it did make it into MySQL 5.6
GA). Configure one of you slaves to delay applying replication events from its relay log
and this gives you a configurable window to identify a problem with your master's data
and stop it being applied to that slave.
> -----Original Message-----
> From: Johan De Meersman [mailto:vegivamp@stripped]
> Sent: 13 September 2013 07:30
> To: Kaushal Shriyan
> Cc: replication@stripped
> Subject: Re: MySQL Master and Slave Replication
> ----- Original Message -----
> > From: "Kaushal Shriyan" <kaushalshriyan@stripped>
> > Subject: MySQL Master and Slave Replication
> > I have a question regarding MySQL replication master slave setup. One
> > question is of concern "If data is corrupted, lost or deleted in the
> > master that will be synced to the slave. Restoring the slave to the
> > master does not get the data back."? Please suggest.
> Repeat after me: Replication is not backup. RAID is not backup. Only backup
> is backup.
> The point of replication is load distribution, running heavy reporting, etc,
> and/or quick failover in case of *hardware* failure on the master.
> To protect against data corruption, you need to take regular backups of your
> data, using MySQLdump, Xtrabackup, or any of the myriad alternatives; and -
> most importantly - save those backups somewhere else than on the server
> you take them from, ideally even outside of the same datacenter.
> Unhappiness is discouraged and will be corrected with kitten pictures.
> MySQL Replication Mailing List
> For list archives: http://lists.mysql.com/replication
> To unsubscribe: http://lists.mysql.com/replication