快速部署 MySQL InnoDB Cluster
文章目录
准备工作
- 三台相同或兼容版本（使用 MySQL Clone 技术还必须相同补丁版本）的 MySQL 服务器实例。至少一台安装有 MySQL Shell 。建议三台都安装，因为它也没多大，否则需要手动在其中的两台上创建 配置账户 。
- InnoDB Cluster 的成员服务器使用三种用户账户，它们的共同特点是每个账户须使用相同的用户名和密码存在于 InnoDB Cluster 的每个成员服务器上：
- 配置账户：用于创建和配置 InnoDB Cluster ，等同于部署账户。仅可创建一个配置账户，且必须在每个成员上单独创建。
- 管理员账户：用于完成配置过程后管理 InnoDB Cluster 。可以创建多个。在把所有实例加入到集群后，使用
cluster.setupAdminAccount()命令创建管理员账户。该命令使用你所指定的用户名和密码创建一个账户，并授予所有必需的权限。使用cluster.setupAdminAccount()命令创建一个账户的事务被写入到二进制日志，并发送到所有集群中的其他服务器实例以在它们上创建该账户。 - MySQL Router 账户：MySQL Router 使用它来连接到 InnoDB Cluster 。可以创建多个。在把所有实例加入到集群后，使用
cluster.setupRouterAccount()命令创建 MySQL Router 账户，其余过程类似于创建管理员账户。
详细信息请参阅 7.3 InnoDB Cluster 的用户账户 。
- 其他预配置可在使用 MySQL Shell 部署时遵循提示信息完成。
- 笔者采用的是 Yum 包安装方式，使用操作系统的 root 账户，部署前并未为 InnoDB Cluster 创建任何账户，因而最初需要使用 MySQL 的 root 账户登录 MySQL Shell 部署。
环境信息
- 操作系统：
[root@ic ~]# uname -a Linux ic-source 3.10.0-1160.59.1.el7.x86_64 #1 SMP Wed Feb 23 16:47:03 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux - MySQL 安装包
其实只需要 common、libs、server、client、mysql-shell 即可，并不是需要以下所有包，因笔者出于其他目的安装了额外的包。[root@ic ~]# rpm -qa|grep mysql mysql-community-client-plugins-8.0.31-1.el7.x86_64 mysql-community-libs-8.0.31-1.el7.x86_64 mysql-community-icu-data-files-8.0.31-1.el7.x86_64 mysql-community-devel-8.0.31-1.el7.x86_64 mysql-shell-8.0.31-1.el7.x86_64 mysql-community-common-8.0.31-1.el7.x86_64 mysql-community-client-8.0.31-1.el7.x86_64 mysql-community-server-8.0.31-1.el7.x86_64 mysql-community-libs-compat-8.0.31-1.el7.x86_64 - 网络情况
[root@datanode3 ~]# cat /etc/hosts 127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4 ::1 localhost localhost.localdomain localhost6 localhost6.localdomain6 192.168.52.3 ic-source 192.168.52.4 ic-replica1 192.168.52.6 ic-replica2 - MySQL 选项文件
笔者的/etc/my.cnf配置如下：
datadir=/var/lib/mysql/data
socket=/var/lib/mysql/mysql.sock
innodb_dedicated_server = 1
log-error=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid
#GR
disabled_storage_engines="MyISAM,BLACKHOLE,FEDERATED,ARCHIVE,MEMORY"
- Python 版本
笔者使用的是 MySQL Shell 默认的 JS（JavaScript） API 处理模式，没有用到 Python ，更习惯使用 Python 的可以使用\py切换到 Python 处理模式，同时要注意操作系统中所安装的 Python 版本兼容性问题。
这里还是列出笔者测试环境的 Python 版本仅供参考：[root@ic ~]# python -V Python 2.7.5 [root@ic ~]# python3 -V Python 3.10.6
部署
为了更好地学习理解使用 MySQL Shell 部署 InnoDB Cluster 的过程和出于安全方面考虑的权限分离，笔者独立使用配置账户 ic_config 和管理员账户 ic_admin ，这与 MySQL 官网示例不同。如果你对这方面没有要求，则和多数情况一样，管理员和配置（部署）账户是同一个。
1. 配置 InnoDB Cluster 实例并创建配置账户
首次部署 直接执行mysqlsh打开 MySQL Shell ，在每台服务器上 执行dba.configureInstance('root@localhost:3306')，而后遵循提示操作：
#这里因为我配置了 MySQL 免登录，可以无需输入密码直接启动
[root@ic ~]# mysqlsh
MySQL Shell 8.0.31
Copyright (c) 2016, 2022, Oracle and/or its affiliates.
Oracle is a registered trademark of Oracle Corporation and/or its affiliates.
Other names may be trademarks of their respective owners.
Type '\help' or '\?' for help; '\quit' to exit.
MySQL JS > dba.configureInstance('root@localhost:3306')
Configuring local MySQL instance listening at port 3306 for use in an InnoDB cluster...
This instance reports its own address as ic-source:3306
Clients and other cluster members will communicate with it through this address by default. If this is not correct, the report_host MySQL system variable should be changed.
#这里报错说 'root' 用户仅可 'localhost' 从连接。必须创建使用符合源地址规范的新账户以允许来自所有实例的远程连接。
ERROR: User 'root' can only connect from 'localhost'. New account(s) with proper source address specification to allow remote connection from all instances must be created to manage the cluster.
1) Create remotely usable account for 'root' with same grants and password
2) Create a new admin account for InnoDB cluster with minimal required grants
3) Ignore and continue
4) Cancel
# 这里选择 2 ，不建议选择 1 ，如果预先手动创建了配置账户，可以选择 3 。
Please select an option [1]: 2
Please provide an account name (e.g: icroot@%) to have it created with the necessary
privileges or leave empty and press Enter to cancel.
#这里指定要创建的配置账户名称和密码（两次，第二次确认）
Account Name: ic_config
Password for new account: ************
Confirm password: ************
applierWorkerThreads will be set to the default value of 4.
#这里提示了需要修复的一些配置
NOTE: Some configuration options need to be fixed:
+----------------------------------------+---------------+----------------+--------------------------------------------------+
| Variable | Current Value | Required Value | Note |
+----------------------------------------+---------------+----------------+--------------------------------------------------+
| binlog_transaction_dependency_tracking | COMMIT_ORDER | WRITESET | Update the server variable |
| enforce_gtid_consistency | OFF | ON | Update read-only variable and restart the server |
| gtid_mode | OFF | ON | Update read-only variable and restart the server |
| server_id | 1 | <unique ID> | Update read-only variable and restart the server |
+----------------------------------------+---------------+----------------+--------------------------------------------------+
Some variables need to be changed, but cannot be done dynamically on the server.
#这里询问你是否想要执行更改所需配置？选 y 。
Do you want to perform the required configuration changes? [y/n]: y
#这里询问你是否想要在配置后重启实例？选 y 。
Do you want to restart the instance after configuring it? [y/n]: y
Cluster admin user 'ic_config'@'%' created.
Configuring instance...
The instance 'ic-source:3306' was configured to be used in an InnoDB cluster.
Restarting MySQL...
NOTE: MySQL server at ic-source:3306 was restarted.
如果你不是 首次部署 ，则建议执行dba.checkInstanceConfiguration(instance)，这是可选的，其中instance表示 MySQL 用户名@IP 或主机名:端口号 。当然，你也可以直接执行dba.configureInstance()。
如果你预先在每台服务器上创建了配置账户，则可以仅在其中一台（建议使用 源服务器（ic-source） ）上使用 MySQL Shell 部署，你甚至可以仅在该台服务器上安装 MySQL Shell 。
2. 创建集群实例
在三台服务器上均执行完第一步的操作后，在 源服务器（ic-source） 上，执行\c ic_config@ic-source:3306使用配置账户登录，并执行var cluster = dba.createCluster('testCluster')创建集群实例。
MySQL JS > \c ic_config@ic-source:3306
Creating a session to 'ic_config@ic-source:3306'
Please provide the password for 'ic_config@ic-source:3306': ************
Save password for 'ic_config@ic-source:3306'? [Y]es/[N]o/Ne[v]er (default No): y
Fetching schema names for auto-completion... Press ^C to stop.
Your MySQL connection id is 9
Server version: 8.0.31 MySQL Community Server - GPL
No default schema selected; type \use <schema> to set one.
MySQL ic-source:3306 ssl JS > var cluster = dba.createCluster('testCluster')
A new InnoDB Cluster will be created on instance 'ic-source:3306'.
Validating instance configuration at ic-source:3306...
This instance reports its own address as ic-source:3306
Instance configuration is suitable.
NOTE: Group Replication will communicate with other members using 'ic-source:3306'. Use the localAddress option to override.
Creating InnoDB Cluster 'testCluster' on 'ic-source:3306'...
Adding Seed Instance...
Cluster successfully created. Use Cluster.addInstance() to add MySQL instances.
At least 3 instances are needed for the cluster to be able to withstand up to
one server failure.
3. 创建管理员账户
在 源服务器（ic-source） 上，执行cluster.setupAdminAccount("ic_admin")创建管理员账户 ic_admin 。
MySQL ic-source:3306 ssl JS > cluster.setupAdminAccount("ic_admin")
Missing the password for new account ic_admin@%. Please provide one.
Password for new account: ***********
Confirm password: ***********
Creating user ic_admin@%.
Account ic_admin@% was successfully created.
然后，执行cluster.status()查看集群状态信息。
MySQL ic-source:3306 ssl JS > cluster.status()
{
"clusterName": "testCluster",
"defaultReplicaSet": {
"name": "default",
"primary": "ic-source:3306",
"ssl": "REQUIRED",
"status": "OK_NO_TOLERANCE",
"statusText": "Cluster is NOT tolerant to any failures.",
"topology": {
"ic-source:3306": {
"address": "ic-source:3306",
"memberRole": "PRIMARY",
"mode": "R/W",
"readReplicas": {},
"replicationLag": "applier_queue_applied",
"role": "HA",
"status": "ONLINE",
"version": "8.0.31"
}
},
"topologyMode": "Single-Primary"
},
"groupInformationSourceMember": "ic-source:3306"
}
4. 添加实例
在 源服务器（ic-source） 上，加入其他两个 副本服务器（ic-replica1、ic-replica2）实例 。
注意
笔者这两台副本服务器实例都是空的，所以不需要检查。如果你的实例不是空的，且与源服务器上的数据不同，则应执行cluster.checkInstanceState(instance)检查该实例上已有数据是否会阻止其加入到集群。有关该操作的详细信息，参阅 检查实例状态
- 先将 ic-replica1 副本实例加入到集群。
MySQL ic-source:3306 ssl JS > cluster.addInstance('ic_config@ic-replica1:3306')
NOTE: The target instance 'ic-replica1:3306' has not been pre-provisioned (GTID set is empty). The Shell is unable to decide whether incremental state recovery can correctly provision it.
The safest and most convenient way to provision a new instance is through automatic clone provisioning, which will completely overwrite the state of 'ic-replica1:3306' with a physical snapshot from an existing cluster member. To use this method by default, set the 'recoveryMethod' option to 'clone'.
The incremental state recovery may be safely used if you are sure all updates ever executed in the cluster were done with GTIDs enabled, there are no purged transactions and the new instance contains the same GTID set as the cluster or a subset of it. To use this method by default, set the 'recoveryMethod' option to 'incremental'.
#这里选择使用远程克隆操作（MySQL Clone），因为是初始化实例。
Please select a recovery method [C]lone/[I]ncremental recovery/[A]bort (default Clone): c
Validating instance configuration at ic-replica1:3306...
This instance reports its own address as ic-replica1:3306
Instance configuration is suitable.
NOTE: Group Replication will communicate with other members using 'ic-replica1:3306'. Use the localAddress option to override.
A new instance will be added to the InnoDB cluster. Depending on the amount of
data on the cluster this might take from a few seconds to several hours.
Adding instance to the cluster...
Monitoring recovery process of the new cluster member. Press ^C to stop monitoring and let it continue in background.
Clone based state recovery is now in progress.
NOTE: A server restart is expected to happen as part of the clone process. If the
server does not support the RESTART command or does not come back after a
while, you may need to manually start it back.
* Waiting for clone to finish...
NOTE: ic-replica1:3306 is being cloned from ic-source:3306
** Stage DROP DATA: Completed
NOTE: ic-replica1:3306 is shutting down...
* Waiting for server restart... ready
* ic-replica1:3306 has restarted, waiting for clone to finish...
** Stage RESTART: Completed
* Clone process has finished: 697.67 MB transferred in 40 sec (17.44 MB/s)
The instance 'ic-replica1:3306' was successfully added to the cluster.
然后，执行cluster.status()查看集群状态信息。
MySQL ic-source:3306 ssl JS > cluster.status()
{
"clusterName": "testCluster",
"defaultReplicaSet": {
"name": "default",
"primary": "ic-source:3306",
"ssl": "REQUIRED",
"status": "OK_NO_TOLERANCE_PARTIAL",
"statusText": "Cluster is NOT tolerant to any failures. 1 member is not active.",
"topology": {
"ic-replica1:3306": {
"address": "ic-replica1:3306",
"instanceErrors": [
"NOTE: group_replication is stopped."
],
"memberRole": "SECONDARY",
"memberState": "OFFLINE",
"mode": "R/O",
"readReplicas": {},
"role": "HA",
"status": "(MISSING)",
"version": "8.0.31"
},
"ic-source:3306": {
"address": "ic-source:3306",
"memberRole": "PRIMARY",
"mode": "R/W",
"readReplicas": {},
"replicationLag": "applier_queue_applied",
"role": "HA",
"status": "ONLINE",
"version": "8.0.31"
}
},
"topologyMode": "Single-Primary"
},
"groupInformationSourceMember": "ic-source:3306"
}
这里刚好看到"instanceErrors": ["NOTE: group_replication is stopped."], ，这个实例加入得有问题，克隆成功了但组复制没有启动。后来发现，里面有一批 datanode1-relay-bin.* 文件，怀疑可能是我以前做过其他实验，手动配置过 MGR 或复制导致的。
- 再以同样的操作将 ic-replica2 副本实例加入到集群。这个问题先放着后面会处理，因为我部署时没注意到，在此强调一下，大家不要像我一样马虎，仔细查看状态信息，并及时处理报错 。
MySQL ic-source:3306 ssl JS > cluster.addInstance('ic_config@ic-replica2:3306')
NOTE: The target instance 'ic-replica2:3306' has not been pre-provisioned (GTID set is empty). The Shell is unable to decide whether incremental state recovery can correctly provision it.
The safest and most convenient way to provision a new instance is through automatic clone provisioning, which will completely overwrite the state of 'ic-replica2:3306' with a physical snapshot from an existing cluster member. To use this method by default, set the 'recoveryMethod' option to 'clone'.
The incremental state recovery may be safely used if you are sure all updates ever executed in the cluster were done with GTIDs enabled, there are no purged transactions and the new instance contains the same GTID set as the cluster or a subset of it. To use this method by default, set the 'recoveryMethod' option to 'incremental'.
Please select a recovery method [C]lone/[I]ncremental recovery/[A]bort (default Clone): c
Validating instance configuration at ic-replica2:3306...
This instance reports its own address as ic-replica2:3306
Instance configuration is suitable.
NOTE: Group Replication will communicate with other members using 'ic-replica2:3306'. Use the localAddress option to override.
A new instance will be added to the InnoDB cluster. Depending on the amount of
data on the cluster this might take from a few seconds to several hours.
Adding instance to the cluster...
Monitoring recovery process of the new cluster member. Press ^C to stop monitoring and let it continue in background.
Clone based state recovery is now in progress.
NOTE: A server restart is expected to happen as part of the clone process. If the
server does not support the RESTART command or does not come back after a
while, you may need to manually start it back.
* Waiting for clone to finish...
NOTE: ic-replica2:3306 is being cloned from ic-source:3306
** Stage DROP DATA: Completed
NOTE: ic-replica2:3306 is shutting down...
* Waiting for server restart... ready
* ic-replica2:3306 has restarted, waiting for clone to finish...
** Stage RESTART: Completed
* Clone process has finished: 697.67 MB transferred in 11 sec (63.42 MB/s)
State recovery already finished for 'ic-replica2:3306'
The instance 'ic-replica2:3306' was successfully added to the cluster.
然后，执行cluster.status()查看集群状态信息。
MySQL ic-source:3306 ssl JS > cluster.status()
{
"clusterName": "testCluster",
"defaultReplicaSet": {
"name": "default",
"primary": "ic-source:3306",
"ssl": "REQUIRED",
"status": "OK_NO_TOLERANCE_PARTIAL",
"statusText": "Cluster is NOT tolerant to any failures. 1 member is not active.",
"topology": {
"ic-replica1:3306": {
"address": "ic-replica1:3306",
"instanceErrors": [
"NOTE: group_replication is stopped."
],
"memberRole": "SECONDARY",
"memberState": "OFFLINE",
"mode": "R/O",
"readReplicas": {},
"role": "HA",
"status": "(MISSING)",
"version": "8.0.31"
},
"ic-replica2:3306": {
"address": "ic-replica2:3306",
"memberRole": "SECONDARY",
"mode": "R/O",
"readReplicas": {},
"replicationLag": "applier_queue_applied",
"role": "HA",
"status": "ONLINE",
"version": "8.0.31"
},
"ic-source:3306": {
"address": "ic-source:3306",
"memberRole": "PRIMARY",
"mode": "R/W",
"readReplicas": {},
"replicationLag": "applier_queue_applied",
"role": "HA",
"status": "ONLINE",
"version": "8.0.31"
}
},
"topologyMode": "Single-Primary"
},
"groupInformationSourceMember": "ic-source:3306"
}
好，现在我来处理刚刚那个报错。我当时没仔细看，也没多想，直接cluster.removeInstance('ic_config@ic-replica1:3306')移除，然后重新加入实例，然后就好了。第一次加入副本实例 ic-replica1 时临时有事需要外出，所以取消了。因为在加入副本实例 ic-replica2 打指令时是复制的 ic-replica1 没有改，相当于加入了两次 ic-replica1 ，日志也过去太长了懒得翻了。
MySQL ic.source:3306 ssl JS > cluster.rejoinInstance('ic_config@ic.replica1:3306)
SyntaxError: Invalid or unexpected token
MySQL ic.source:3306 ssl JS > cluster.rejoinInstance('ic_config@ic.replica1:3306')
Validating instance configuration at ic.replica1:3306...
This instance reports its own address as ic.replica1:3306
Instance configuration is suitable.
Rejoining instance 'ic.replica1:3306' to cluster 'testCluster'...
Re-creating recovery account...
NOTE: User 'mysql_innodb_cluster_1310685405'@'%' already existed at instance 'ic.source:3306'. It will be deleted and created again with a new password.
* Waiting for the Cluster to synchronize with the PRIMARY Cluster...
** Transactions replicated ############################################################ 100%
The instance 'ic.replica1:3306' was successfully rejoined to the cluster.
MySQL ic.source:3306 ssl JS > cluster.status()
{
"clusterName": "testCluster",
"defaultReplicaSet": {
"name": "default",
"primary": "ic.source:3306",
"ssl": "REQUIRED",
"status": "OK",
"statusText": "Cluster is ONLINE and can tolerate up to ONE failure.",
"topology": {
"ic.replica1:3306": {
"address": "ic.replica1:3306",
"memberRole": "SECONDARY",
"mode": "R/O",
"readReplicas": {},
"replicationLag": "applier_queue_applied",
"role": "HA",
"status": "ONLINE",
"version": "8.0.31"
},
"ic.replica2:3306": {
"address": "ic.replica2:3306",
"memberRole": "SECONDARY",
"mode": "R/O",
"readReplicas": {},
"replicationLag": "applier_queue_applied",
"role": "HA",
"status": "ONLINE",
"version": "8.0.31"
},
"ic.source:3306": {
"address": "ic.source:3306",
"memberRole": "PRIMARY",
"mode": "R/W",
"readReplicas": {},
"replicationLag": "applier_queue_applied",
"role": "HA",
"status": "ONLINE",
"version": "8.0.31"
}
},
"topologyMode": "Single-Primary"
},
"groupInformationSourceMember": "ic.source:3306"
}
5. 验证集群状态
部署完成后，执行cluster.status()验证集群状态。
MySQL ic-source:3306 ssl JS > cluster.status()
{
"clusterName": "testCluster",
"defaultReplicaSet": {
"name": "default",
"primary": "ic-source:3306",
"ssl": "REQUIRED",
"status": "OK",
"statusText": "Cluster is ONLINE and can tolerate up to ONE failure.",
"topology": {
"ic-replica1:3306": {
"address": "ic-replica1:3306",
"memberRole": "SECONDARY",
"mode": "R/O",
"readReplicas": {},
"replicationLag": "applier_queue_applied",
"role": "HA",
"status": "ONLINE",
"version": "8.0.31"
},
"ic-replica2:3306": {
"address": "ic-replica2:3306",
"memberRole": "SECONDARY",
"mode": "R/O",
"readReplicas": {},
"replicationLag": "applier_queue_applied",
"role": "HA",
"status": "ONLINE",
"version": "8.0.31"
},
"ic-source:3306": {
"address": "ic-source:3306",
"memberRole": "PRIMARY",
"mode": "R/W",
"readReplicas": {},
"replicationLag": "applier_queue_applied",
"role": "HA",
"status": "ONLINE",
"version": "8.0.31"
}
},
"topologyMode": "Single-Primary"
},
"groupInformationSourceMember": "ic-source:3306"
}
额外的知识
在此次部署 InnoDB Cluster 的过程中，因为上面遇到的问题，和强迫症改主机名（多年前搭的 Hadoop 环境），导致我重新部署了一次。我在此过程中有些意外收获：
- MySQL 的主机名解析机制，或者说主机名命名规范，与 （RedHat）Linux 不同。
MySQL 可以识别 下划线（_） 作为主机名的一部分，而这在 Linux 中是不允许的，后者只允许 英文句号（.）和连字符（-），但 英文句号（.） 往往表示主机名与域名一起使用。这是我之前所忽视的，现在大部分应用里， 下划线（_） 的支持程度远高于 连字符（-） 。
例如，使用如下/etc/hosts配置时，MySQL 可以识别 ic_replica1 作为实例变量或连接串的一部分。
192.168.52.3 namenode ic_source
192.168.52.4 datanode1 ic_replica1
192.168.52.5 datanode2
192.168.52.6 datanode3 ic_replica2
而如果你直接配置成如下形式，则会无法生效：
192.168.52.3 ic_source
192.168.52.4 ic_replica1
192.168.52.6 ic_replica2
且对每条单独执行hostname 主机名时会报错：
[root@ic mysql]# hostname ic_source
hostname: the specified hostname is invalid
- MySQL InnoDB Cluster 自动配置的选项放在 MySQL 服务器（ mysqld） 的自动配置文件 DATADIR\mysqld-auto.cnf 中。该文件是以 JSON 格式存储的，使用
SET PERSIST或SET PERSIST_ONLY持久化的系统变量配置（仅限服务器）。 - DATADIR\mysqld-auto.cnf 中的 server_id 就是普通的 server_id ，可以部署前手动配置为指定数字，而并非 BASEDIR/auto.cnf 中的 server_uuid。
mysql> select @@server_id;
+-------------+
| @@server_id |
+-------------+
| 344590725 |
+-------------+
1 row in set (0.00 sec)
mysql> select @@server_uuid;
+--------------------------------------+
| @@server_uuid |
+--------------------------------------+
| f10abfbf-7c8b-11ea-a226-000c298d6cb9 |
+--------------------------------------+
1 row in set (0.00 sec)
mysql> select conv(hex(uuid_to_bin(@@server_uuid)),16,10);
+---------------------------------------------+
| conv(hex(uuid_to_bin(@@server_uuid)),16,10) |
+---------------------------------------------+
| 18446744073709551615 |
+---------------------------------------------+
1 row in set, 1 warning (0.00 sec)
- InnoDB Cluster 的元数据仓库也是建立在 MySQL 中的数据库。
mysql> show databases;
+-------------------------------+
| Database |
+-------------------------------+
| errant |
| information_schema |
| learn |
| mysql |
| mysql_innodb_cluster_metadata |
| performance_schema |
| sys |
+-------------------------------+
7 rows in set (0.01 sec)
5. 部署过程中 3. 创建管理员账户 和 4. 添加实例 顺序可以互换，但互换后 先添加实例后创建管理员账户 ，新创建的额管理员账户是通过组复制的 二进制日志状态传输 方式进行分布式恢复的，因而会产生新事务，可通过查看二进制日志验证。而 先创建管理员账户后添加实例 ，是通过 远程克隆操作 进行分布式恢复的。
在 MySQL Shell 中执行cluster.setupAdminAccount('ic_admin_1')创建一个新的管理员账户 ic_admin_1 ：
MySQL ic.source:3306 ssl JS > cluster.setupAdminAccount('ic_admin_1')
Missing the password for new account ic_admin_1@%. Please provide one.
Password for new account: ***********
Confirm password: ***********
Creating user ic_admin_1@%.
Account ic_admin_1@% was successfully created.
查看二进制日志，发现只有 ic_admin_1 的日志记录，而没有 ic_admin 的日志记录。证明第一次部署时创建的管理员账户是直接通过 远程克隆操作 复制的，而没有产生二进制日志记录。
[root@ic mysql]# mysqlbinlog binlog.00000*|grep ic_admin
ic-replica1 上的二进制日志
ic-replica2 上的二进制日志
如果你觉得文章写得不错，请动动小手点个赞吧！
317
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
