Rechercher dans le manuel MySQL
17.3.3.3 Recovering From Failed Replication Privilege Checks
If a privilege check against the
PRIVILEGE_CHECKS_USER
account fails, the
transaction is not executed and replication stops for the
channel. Details of the error and the last applied transaction
are recorded in the Performance Schema
replication_applier_status_by_worker
table. Follow this procedure to recover from the error:
Identify the replicated event that caused the error and verify whether or not the event is expected and from a trusted source. You can use mysqlbinlog to retrieve and display the events that were logged around the time of the error. For instructions to do this, see Section 7.5, “Point-in-Time (Incremental) Recovery Using the Binary Log”.
If the replicated event is not expected or is not from a known and trusted source, investigate the cause. If you can identify why the event took place and there are no security considerations, proceed to fix the error as described below.
If the
PRIVILEGE_CHECKS_USER
account should have been permitted to execute the transaction, but has been misconfigured, grant the missing privileges to the account and restart replication for the channel.If the transaction needs to be executed and you have verified that it is trusted, but the
PRIVILEGE_CHECKS_USER
account should not have this privilege normally, you can grant the required privilege to thePRIVILEGE_CHECKS_USER
account temporarily. After the replicated event has been applied, remove the privilege from the account, and take any necessary steps to ensure the event does not recur if it is avoidable.If the transaction is an administrative action that should only have taken place on the master and not on the slave, or should only have taken place on a single replication group member, skip the transaction on the server or servers where it stopped replication, then issue
START SLAVE
to restart replication on the channel. To avoid the situation in future, you could issue such administrative statements withSET sql_log_bin = 0
before them andSET sql_log_bin = 1
after them, so that they are not logged on the master.If the transaction is a DDL or DML statement that should not have taken place on either the master or the slave, skip the transaction on the server or servers where it stopped replication, undo the transaction manually on the server where it originally took place, then issue
START SLAVE
to restart replication.
To skip a transaction, if GTIDs are in use, commit an empty transaction that has the GTID of the failing transaction, for example:
If GTIDs are not in use, issue a SET GLOBAL
sql_slave_skip_counter
statement to skip the event, as
described in
Section 13.4.2.5, “SET GLOBAL sql_slave_skip_counter Statement”.
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-privilege-checks-recover.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.