Rechercher dans le manuel MySQL
17.4.1.27 Replication and Master or Slave Shutdowns
It is safe to shut down a master server and restart it later.
When a slave loses its connection to the master, the slave tries
to reconnect immediately and retries periodically if that fails.
The default is to retry every 60 seconds. This may be changed
with the CHANGE MASTER TO
statement. A slave also is able to deal with network
connectivity outages. However, the slave notices the network
outage only after receiving no data from the master for
slave_net_timeout
seconds. If
your outages are short, you may want to decrease
slave_net_timeout
. See
Section 17.3.2, “Handling an Unexpected Halt of a Replication Slave”.
An unclean shutdown (for example, a crash) on the master side
can result in the master binary log having a final position less
than the most recent position read by the slave, due to the
master binary log file not being flushed. This can cause the
slave not to be able to replicate when the master comes back up.
Setting
sync_binlog=1
in the
master my.cnf
file helps to minimize this
problem because it causes the master to flush its binary log
more frequently. For the greatest possible durability and
consistency in a replication setup using
InnoDB
with transactions, you should also set
innodb_flush_log_at_trx_commit=1
.
With this setting, the contents of the InnoDB
redo log buffer are written out to the log file at each
transaction commit and the log file is flushed to disk. Note
that the durability of transactions is still not guaranteed with
this setting, because operating systems or disk hardware may
tell mysqld that the flush-to-disk operation
has taken place, even though it has not.
Shutting down a slave cleanly is safe because it keeps track of where it left off. However, be careful that the slave does not have temporary tables open; see Section 17.4.1.30, “Replication and Temporary Tables”. Unclean shutdowns might produce problems, especially if the disk cache was not flushed to disk before the problem occurred:
For transactions, the slave commits and then updates
relay-log.info
. If a crash occurs between these two operations, relay log processing will have proceeded further than the information file indicates and the slave will re-execute the events from the last transaction in the relay log after it has been restarted.A similar problem can occur if the slave updates
relay-log.info
but the server host crashes before the write has been flushed to disk. To minimize the chance of this occurring, setsync_relay_log_info=1
in the slavemy.cnf
file. Settingsync_relay_log_info
to 0 causes no writes to be forced to disk and the server relies on the operating system to flush the file from time to time.
The fault tolerance of your system for these types of problems is greatly increased if you have a good uninterruptible power supply.
Traduction non disponible
Le manuel MySQL n'est pas encore traduit en français sur l'infobrol. Seule la version anglaise est disponible pour l'instant.
Document créé le 26/06/2006, dernière modification le 26/10/2018
Source du document imprimé : https://www.gaudry.be/mysql-rf-replication-features-shutdowns.html
L'infobrol est un site personnel dont le contenu n'engage que moi. Le texte est mis à disposition sous licence CreativeCommons(BY-NC-SA). Plus d'info sur les conditions d'utilisation et sur l'auteur.
Références
Ces références et liens indiquent des documents consultés lors de la rédaction de cette page, ou qui peuvent apporter un complément d'information, mais les auteurs de ces sources ne peuvent être tenus responsables du contenu de cette page.
L'auteur de ce site est seul responsable de la manière dont sont présentés ici les différents concepts, et des libertés qui sont prises avec les ouvrages de référence. N'oubliez pas que vous devez croiser les informations de sources multiples afin de diminuer les risques d'erreurs.