Rechercher dans le manuel MySQL

17.4.1.34 Replication and Transaction Inconsistencies

Table des matières

Inconsistencies in the sequence of transactions that have been executed from the relay log can occur depending on your replication configuration. This section explains how to avoid inconsistencies and solve any problems they cause.

The following types of inconsistencies can exist:

  • Half-applied transactions. A transaction which updates non-transactional tables has applied some but not all of its changes.

  • Gaps. A gap is a transaction that has not been (fully) applied, even though some later transaction has been applied. Gaps can only appear when using a multithreaded slave. To avoid gaps occurring, set slave_preserve_commit_order=1, which requires slave_parallel_type=LOGICAL_CLOCK, and that binary logging (the log_bin system variable) and slave update logging (the --log-slave-updates) are also enabled.

  • Gap-free low-watermark position. Even in the absence of gaps, it is possible that transactions after Exec_master_log_pos have been applied. That is, all transactions up to point N have been applied, and no transactions after N have been applied, but Exec_master_log_pos has a value smaller than N. This can only happen on multithreaded slaves. Enabling slave_preserve_commit_order does not prevent gap-free low-watermark positions.

The following scenarios are relevant to the existence of half-applied transactions, gaps, and gap-free low-watermark position inconsistencies:

  1. While slave threads are running, there may be gaps and half-applied transactions.

  2. mysqld shuts down. Both clean and unclean shutdown abort ongoing transactions and may leave gaps and half-applied transactions.

  3. KILL of replication threads (the SQL thread when using a single-threaded slave, the coordinator thread when using a multithreaded slave). This aborts ongoing transactions and may leave gaps and half-applied transactions.

  4. Error in applier threads. This may leave gaps. If the error is in a mixed transaction, that transaction is half-applied. When using a multithreaded slave, workers which have not received an error complete their queues, so it may take time to stop all threads.

  5. STOP SLAVE when using a multithreaded slave. After issuing STOP SLAVE, the slave waits for any gaps to be filled and then updates Exec_master_log_pos. This ensures it never leaves gaps or gap-free low-watermark positions, unless any of the cases above applies (in other words, before STOP SLAVE completes, either an error happens, or another thread issues KILL, or the server restarts. In these cases, STOP SLAVE returns successfully.)

  6. If the last transaction in the relay log is only half-received and the multithreaded slave coordinator has started to schedule the transaction to a worker, then STOP SLAVE waits up to 60 seconds for the transaction to be received. After this timeout, the coordinator gives up and aborts the transaction. If the transaction is mixed, it may be left half-completed.

  7. STOP SLAVE when using a single-threaded slave. If the ongoing transaction only updates transactional tables, it is rolled back and STOP SLAVE stops immediately. If the ongoing transaction is mixed, STOP SLAVE waits up to 60 seconds for the transaction to complete. After this timeout, it aborts the transaction, so it may be left half-completed.

The global variable rpl_stop_slave_timeout is unrelated to the process of stopping the replication threads. It only makes the client that issues STOP SLAVE return to the client, but the replication threads continue to try to stop.

If a replication channel has gaps, it has the following consequences:

  1. The slave database is in a state that may never have existed on the master.

  2. The field Exec_master_log_pos in SHOW SLAVE STATUS is only a "low-watermark". In other words, transactions appearing before the position are guaranteed to have committed, but transactions after the position may have committed or not.

  3. CHANGE MASTER TO statements for that channel fail with an error, unless the applier threads are running and the CHANGE MASTER TO statement only sets receiver options.

  4. If mysqld is started with --relay-log-recovery, no recovery is done for that channel, and a warning is printed.

  5. If mysqldump is used with --dump-slave, it does not record the existence of gaps; thus it prints CHANGE MASTER TO with RELAY_LOG_POS set to the low-watermark position in Exec_master_log_pos.

    After applying the dump on another server, and starting the replication threads, transactions appearing after the position are replicated again. Note that this is harmless if GTIDs are enabled (however, in that case it is not recommended to use --dump-slave).

If a replication channel has a gap-free low-watermark position, cases 2 to 5 above apply, but case 1 does not.

The gap-free low-watermark position information is persisted in binary format in the internal table mysql.slave_worker_info. START SLAVE [SQL_THREAD] always consults this information so that it applies only the correct transactions. This remains true even if slave_parallel_workers has been changed to 0 before START SLAVE, and even if START SLAVE is used with UNTIL clauses. START SLAVE UNTIL SQL_AFTER_MTS_GAPS only applies as many transactions as needed in order to fill in the gaps. If START SLAVE is used with UNTIL clauses that tell it to stop before it has consumed all the gaps, then it leaves remaining gaps.

Warning

RESET SLAVE removes the relay logs and resets the replication position. Thus issuing RESET SLAVE on a slave with gaps means the slave loses any information about the gaps, without correcting the gaps.

slave-preserve-commit-order ensures that there are no gaps. However, it is still possible that Exec_master_log_pos is just a gap-free low-watermark position in scenarios 1 to 4 above. That is, there may be transactions after Exec_master_log_pos which have been applied. Therefore the cases numbered 2 to 5 above (but not case 1) apply, even when slave-preserve-commit-order is enabled.


Rechercher dans le manuel MySQL

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

  1. Consulter le document html Langue du document :en Manuel MySQL : https://dev.mysql.com/

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.

Table des matières Haut