Geen cache-versie.
Caching uitgeschakeld. Standaardinstelling voor deze pagina:ingeschakeld (code DEF204)
Als het scherm te langzaam is, kunt u de gebruikersmodus uitschakelen om de cacheversie te bekijken.
Rechercher dans le manuel MySQL
17.4.1.31 Replication Retries and Timeouts
The global system variable
slave_transaction_retries sets
the maximum number of times for applier threads on a
single-threaded or multithreaded replication slave to
automatically retry failed transactions before stopping.
Transactions are automatically retried when the SQL thread fails
to execute them because of an InnoDB
deadlock, or when the transaction's execution time exceeds the
InnoDB
innodb_lock_wait_timeout value.
If a transaction has a non-temporary error that will prevent it
from ever succeeding, it is not retried.
The default setting for
slave_transaction_retries is
10, meaning that a failing transaction with an apparently
temporary error is retried 10 times before the applier thread
stops. Setting the variable to 0 disables automatic retrying of
transactions. On a multithreaded slave, the specified number of
transaction retries can take place on all applier threads of all
channels. The Performance Schema table
replication_applier_status shows
the total number of transaction retries that took place on each
replication channel, in the
COUNT_TRANSACTIONS_RETRIES column.
The process of retrying transactions can cause lag on a
replication slave or on a Group Replication group member, which
can be configured as a single-threaded or multithreaded slave.
The Performance Schema table
replication_applier_status_by_worker
shows detailed information on transaction retries by the applier
threads on a single-threaded or multithreaded slave. This data
includes timestamps showing how long it took the applier thread
to apply the last transaction from start to finish (and when the
transaction currently in progress was started), and how long
this was after the commit on the original master and the
immediate master. The data also shows the number of retries for
the last transaction and the transaction currently in progress,
and enables you to identify the transient errors that caused the
transactions to be retried. You can use this information to see
whether transaction retries are the cause of replication lag,
and investigate the root cause of the failures that led to the
retries.
Nederlandse vertaling
U hebt gevraagd om deze site in het Nederlands te bezoeken. Voor nu wordt alleen de interface vertaald, maar nog niet alle inhoud.Als je me wilt helpen met vertalingen, is je bijdrage welkom. Het enige dat u hoeft te doen, is u op de site registreren en mij een bericht sturen waarin u wordt gevraagd om u toe te voegen aan de groep vertalers, zodat u de gewenste pagina's kunt vertalen. Een link onderaan elke vertaalde pagina geeft aan dat u de vertaler bent en heeft een link naar uw profiel.
Bij voorbaat dank.
Document heeft de 26/06/2006 gemaakt, de laatste keer de 26/10/2018 gewijzigd
Bron van het afgedrukte document:https://www.gaudry.be/nl/mysql-rf-replication-features-timeout.html
De infobrol is een persoonlijke site waarvan de inhoud uitsluitend mijn verantwoordelijkheid is. De tekst is beschikbaar onder CreativeCommons-licentie (BY-NC-SA). Meer info op de gebruiksvoorwaarden en de auteur.
Referenties
Deze verwijzingen en links verwijzen naar documenten die geraadpleegd zijn tijdens het schrijven van deze pagina, of die aanvullende informatie kunnen geven, maar de auteurs van deze bronnen kunnen niet verantwoordelijk worden gehouden voor de inhoud van deze pagina.
De auteur Deze site is als enige verantwoordelijk voor de manier waarop de verschillende concepten, en de vrijheden die met de referentiewerken worden genomen, hier worden gepresenteerd. Vergeet niet dat u meerdere broninformatie moet doorgeven om het risico op fouten te verkleinen.
