Rechercher dans le manuel MySQL
21.6.2 Deploying InnoDB ReplicaSet
You deploy InnoDB ReplicaSet in a similar way to
InnoDB cluster. First you configure some MySQL server
instances, the minimum is two instances. One functions as the
primary, in this tutorial rs-1
; the other
instance functions as the secondary, in this tutorial
rs-2
; which replicates the transactions
applied by the primary. This is the equivalent of the master and
slave known from asynchronous MySQL replication. Then you
connect to one of the instances using MySQL Shell, and create a
replica set. Once the replica set has been created, you can add
instances to it.
InnoDB ReplicaSet is compatible with sandbox instances, which you can use to deploy locally, for example for testing purposes. See Deploying Sandbox Instances for instructions. However, this tutorial assumes you are deploying a production InnoDB ReplicaSet, where each instance is running on a different host.
InnoDB ReplicaSet Prerequisites
To use InnoDB ReplicaSet you should be aware of the following prerequisites:
Only instances running MySQL version 8.0 and later are supported
GTID-based replication is only supported, binary log file position replication is not compatible with InnoDB ReplicaSet
Only Row Based Replication (RBR) is supported, Statement Based Replication (SBR) is unsupported
Replication filters are not supported
Unmanaged replication channels are not allowed in any instance
A replica set consists of maximum one primary instance, and one or multiple secondaries are supported. Although there is no limit to the number of secondaries you can add to a replica set, each MySQL Router connected to a replica set monitors each instance. Therefore, the more instances that are added to a replica set, the more monitoring has to be done.
The replica set must be entirely managed by MySQL Shell. For example, the replication account is created and managed by MySQL Shell. Making configuration changes to the instance outside of MySQL Shell, for example using SQL statements directly to change the primary, is not supported. Always use MySQL Shell to work with InnoDB ReplicaSet.
AdminAPI and InnoDB ReplicaSet enable you to work with MySQL replication without a deep understanding of the underlying concepts. However, for background information see Chapter 17, Replication.
Use
dba.configureReplicaSetInstance(
to configure each instance you want to use in your replica
set. MySQL Shell can either connect to an instance and then
configure it, or you can pass in instance
)instance
to configure a specific remote instance. How you proceed
depends on whether the instance supports persisting settings,
see
Persisting Settings.
For example, on an instance which does not support persisting
settings, connect with a user with suitable privileges to
configure the instance:
mysql-js> \connect root@example1.com:3306
The dba.configureReplicaSetInstance()
function can optionally create an administrator account, if
the clusterAdmin
option is provided. The
account is created with the correct set of privileges required
to manage InnoDB cluster and InnoDB ReplicaSet. The
preferred method to create users to administer a replica set
is using the clusterAdmin
option.
The administrator account must have the same user name and password across all instances of the same cluster or replica set.
To configure the instance at rs-1:3306
,
with a cluster administrator named rsadmin
issue:
mysql-js> dba.configureReplicaSetInstance('root@rs-1:3306', \
{clusterAdmin: "'rsadmin'@'rs-1%'"});
The interactive prompt requests the password required by the specified user. To configure the instance MySQL Shell is currently connected to, you can specify a null instance definition. For example issue:
mysql-js> dba.configureReplicaSetInstance('', {clusterAdmin: "'rsadmin'@'rs-1%'"});
The interactive prompt requests the password required by the specified user. This checks the instance which MySQL Shell is currently connected to is valid for use in a InnoDB ReplicaSet. Settings which are not compatible with InnoDB ReplicaSet are configured if possible. The cluster administrator account is created with the privileges required for InnoDB ReplicaSet.
Once you have configured your instances, connect to an
instance and use dba.createReplicaSet()
to
create a managed replica set that uses MySQL asynchronous
replication, as opposed to MySQL Group Replication used by
InnoDB cluster. The MySQL instance which MySQL Shell is
currently connected to is used as the initial primary of the
replica set. Only TCP/IP connections are supported for this
operation.
The dba.createReplicaSet()
operation
performs several checks to ensure that the instance state and
configuration are compatible with a managed replica set and if
so, a metadata schema is initialized on the instance. If you
want to check the operation but not actually make any changes
to the instances, use the dryRun
option.
This shows what actions the MySQL Shell would take to create
the replica set. If the replica set is created successfully, a
ReplicaSet
object is returned. Therefore it
is best practice to assign the returned
ReplicaSet
to a variable. This enables you
to work with the replica set, for example by calling the
operation. To create a replica set named
ReplicaSet
.status()example
on instance
rs-1
and assign it to the
rs
variable, issue:
mysql-js> \connect root@rs-1:3306
...
mysql-js> var rs = dba.createReplicaSet("example")
A new replicaset with instance 'rs-1:3306' will be created.
* Checking MySQL instance at rs-1:3306
This instance reports its own address as rs-1:3306
rs-1:3306: Instance configuration is suitable.
* Updating metadata...
ReplicaSet object successfully created for rs-1:3306.
Use rs.add_instance() to add more asynchronously replicated instances to this replicaset
and rs.status() to check its status.
To verify that the operation was successful, you work with the
returned ReplicaSet
object. For example
this provides the
operation, which displays information about the replica set.
We already assigned the returned ReplicaSet
.status()ReplicaSet
to the variable rs
, so issue:
mysql-js> rs.status()
{
"replicaSet": {
"name": "example",
"primary": "rs-1:3306",
"status": "AVAILABLE",
"statusText": "All instances available.",
"topology": {
"rs-1:3306": {
"address": "rs-1:3306",
"instanceRole": "PRIMARY",
"mode": "R/W",
"status": "ONLINE"
}
},
"type": "ASYNC"
}
}
This output shows that the replica set named
example
has been created, and that the
primary is rs-1
. Currently there is only
one instance, and the next task is to add more instances to
the replica set.
Deutsche Übersetzung
Sie haben gebeten, diese Seite auf Deutsch zu besuchen. Momentan ist nur die Oberfläche übersetzt, aber noch nicht der gesamte Inhalt.Wenn Sie mir bei Übersetzungen helfen wollen, ist Ihr Beitrag willkommen. Alles, was Sie tun müssen, ist, sich auf der Website zu registrieren und mir eine Nachricht zu schicken, in der Sie gebeten werden, Sie der Gruppe der Übersetzer hinzuzufügen, die Ihnen die Möglichkeit gibt, die gewünschten Seiten zu übersetzen. Ein Link am Ende jeder übersetzten Seite zeigt an, dass Sie der Übersetzer sind und einen Link zu Ihrem Profil haben.
Vielen Dank im Voraus.
Dokument erstellt 26/06/2006, zuletzt geändert 26/10/2018
Quelle des gedruckten Dokuments:https://www.gaudry.be/de/mysql-rf-deploying-innodb-replicasets.html
Die Infobro ist eine persönliche Seite, deren Inhalt in meiner alleinigen Verantwortung liegt. Der Text ist unter der CreativeCommons-Lizenz (BY-NC-SA) verfügbar. Weitere Informationen auf die Nutzungsbedingungen und dem Autor.
Referenzen
Diese Verweise und Links verweisen auf Dokumente, die während des Schreibens dieser Seite konsultiert wurden, oder die zusätzliche Informationen liefern können, aber die Autoren dieser Quellen können nicht für den Inhalt dieser Seite verantwortlich gemacht werden.
Der Autor Diese Website ist allein dafür verantwortlich, wie die verschiedenen Konzepte und Freiheiten, die mit den Nachschlagewerken gemacht werden, hier dargestellt werden. Denken Sie daran, dass Sie mehrere Quellinformationen austauschen müssen, um das Risiko von Fehlern zu reduzieren.