MySQL Forums
Forum List  »  Replication

Re: [suggestion]Is writing relay log necessary in slave?
Posted by: feng guo
Date: December 22, 2014 12:53AM

Rick James Wrote:
-------------------------------------------------------
> There are potentially two replication-related logs
> on a Slave:
>
> * The "relay_log(s)" are absolutely required --
> they hold the stuff sent from the Master's
> "binlog(s)". Yes, it is a staging area, but
> usually it involves nearly zero overhead. If
> replication gets behind, then it becomes a safety
> measure -- things can be sent from the Master to
> the relay_log rapidly even if they cannot be
> executed immediately. That way, if the Master
> dies, there is less risk of any loss on the Slave.
> ("Semi-Sync" adds safety to this.)
>
> * The binlog (on a Slave) is optional. It is the
> same concept as the Master's binlog -- namely it
> holds the writes. It is useful for
> ** Various backup things; incremental backups;
> etc
> ** Having a Slave hanging of this Slave -- a more
> complex topology of servers.
> ** Dual-Master -- two servers, each being both a
> Master and a Slave to each other.
>
> Your comments/suggestions are focused on the
> Slave; the relay_log is focused on keeping the
> Master going.
>
> > master's binlog file name and position to an
> transaction safe table
>
> This, and similar things that are currently kept
> in files, may be coming soon in version 5.7. The
> design is a tricky problem of chicken-and-egg
> and/or runaway allocation and/or "transaction
> safe".
>
> > avoid slave disk's relay log writing load
>
> Check it out -- I rarely see more than 2GB of data
> going into a relay_log per _day_. How much do you
> have? 2GB/day is not much burden on a disk
> system. The LAN/WAN will probably be overloaded
> before the disk.

Thx,relay log is really necessary~

Options: ReplyQuote


Subject
Views
Written By
Posted
Re: [suggestion]Is writing relay log necessary in slave?
968
December 22, 2014 12:53AM


Sorry, you can't reply to this topic. It has been closed.

Content reproduced on this site is the property of the respective copyright holders. It is not reviewed in advance by Oracle and does not necessarily represent the opinion of Oracle or any other party.