Rechercher dans le manuel MySQL
18.4.3 Distributed Recovery
[+/-]
Whenever a member joins a replication group, it connects to an existing member to carry out state transfer. The joining member transfers all the transactions that took place in the group before it joined, which are provided by the existing member (called the donor). Next, the joining member applies the transactions that took place in the group while this state transfer was in progress. When the joining member has caught up with the remaining servers in the group, it begins to participate normally in the group. This process is called distributed recovery.
Group Replication uses a combination of these methods for state transfer during distributed recovery:
A remote cloning operation using the clone plugin's function, which is available from MySQL 8.0.17. To enable this method of state transfer, you must install the clone plugin on the group members and the joining member. Group Replication automatically configures the required clone plugin settings and manages the remote cloning operation.
Replicating from a donor's binary log and applying the transactions on the joining member. This method uses a standard asynchronous replication channel named
group_replication_recoverythat is established between the donor and the joining member.
Group Replication automatically selects the best combination of
these methods for state transfer after you issue
START GROUP_REPLICATION on the
joining member. To do this, Group Replication checks which
existing members are suitable as donors, how many transactions the
joining member needs from a donor, and whether any required
transactions are no longer present in the binary log files on any
group member. If the transaction gap between the joining member
and a suitable donor is large, or if some required transactions
are not in any donor's binary log files, Group Replication begins
distributed recovery with a remote cloning operation. If there is
not a large transaction gap, or if the clone plugin is not
installed, Group Replication proceeds directly to state transfer
from a donor's binary log.
During a remote cloning operation, the existing data on the joining member is removed, and replaced with a copy of the donor's data. When the remote cloning operation is complete and the joining member has restarted, state transfer from a donor's binary log is carried out to get the transactions that the group applied while the remote cloning operation was in progress.
During state transfer from a donor's binary log, the joining member replicates and applies the required transactions from the donor's binary log, applying the transactions as they are received, up to the point where the binary log records that the joining member joined the group (a view change event). While this is in progress, the joining member buffers the new transactions that the group applies. When state transfer from the binary log is complete, the joining member applies the buffered transactions.
When the joining member is up to date with all the group's transactions, it is declared online and can participate in the group as a normal member, and distributed recovery is complete.
Document created the 26/06/2006, last modified the 26/10/2018
Source of the printed document:https://www.gaudry.be/en/mysql-rf-group-replication-distributed-recovery.html
The infobrol is a personal site whose content is my sole responsibility. The text is available under CreativeCommons license (BY-NC-SA). More info on the terms of use and the author.
References
These references and links indicate documents consulted during the writing of this page, or which may provide additional information, but the authors of these sources can not be held responsible for the content of this page.
The author This site is solely responsible for the way in which the various concepts, and the freedoms that are taken with the reference works, are presented here. Remember that you must cross multiple source information to reduce the risk of errors.
