Cloneプラグイン自体の記事はいろいろ乗っていたので、MySQL SHELLの新機能を試してみた(運用がかなり楽になりそう)
詳しくは↓のブログを見た方がいいが、
https://mysqlserverteam.com/mysql-innodb-cluster-whats-new-in-shell-adminapi-8-0-17-release/
とりあえず試してみると。
member削除、追加した場合
- member削除
MySQL 172.22.246.60:3306 ssl JS > cluster.removeInstance("testuser@172.22.246.64")
The instance will be removed from the InnoDB cluster. Depending on the instance
being the Seed or not, the Metadata session might become invalid. If so, please
start a new session to the Metadata Storage R/W instance.
Instance '172.22.246.64:3306' is attempting to leave the cluster...
The instance '172.22.246.64:3306' was successfully removed from the cluster.
- member追加
MySQL 172.22.246.60:3306 ssl JS > cluster.addInstance("testuser@172.22.246.64:3306")
The safest and most convenient way to provision a new instance is through
automatic clone provisioning, which will completely overwrite the state of
'172.22.246.64:3306' with a physical snapshot from an existing cluster member.
To use this method by default, set the 'recoveryMethod' option to 'clone'.
The incremental distributed 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'.
Incremental distributed state recovery was selected because it seems to be safely usable. ←Cloneではなく差分同期でリカバリ可能と判断
Validating instance at 172.22.246.64:3306...
This instance reports its own address as 172.22.246.64:3306
Instance configuration is suitable.
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.
Incremental distributed state recovery is now in progress.
* Waiting for distributed recovery to finish...
NOTE: '172.22.246.64:3306' is being recovered from '172.22.246.78:3306'
* Distributed recovery has finished
The instance '172.22.246.64:3306' was successfully added to the cluster.
member削除、Conflict起こして、追加した場合（高速書き込みをし続けている状態）
- member削除
MySQL 172.22.246.60:3306 ssl JS > cluster.removeInstance("testuser@172.22.246.64:3306")
The instance will be removed from the InnoDB cluster. Depending on the instance
being the Seed or not, the Metadata session might become invalid. If so, please
start a new session to the Metadata Storage R/W instance.
Instance '172.22.246.64:3306' is attempting to leave the cluster...
The instance '172.22.246.64:3306' was successfully removed from the cluster.
- 削除したmemberで更新
create database test2;
- member追加
MySQL 172.22.246.60:3306 ssl JS > cluster.addInstance("testuser@172.22.246.64:3306")
WARNING: A GTID set check of the MySQL instance at '172.22.246.64:3306' determined that
it contains transactions that do not originate from the cluster, which must be
discarded before it can join the cluster.
172.22.246.64:3306 has the following errant GTIDs that do not exist in the cluster: ←知らないGTIDと検知
647bef0f-aea9-11e9-abf8-fa163e02b29c:1
WARNING: Discarding these extra GTID events can either be done manually or by completely
overwriting the state of 172.22.246.64:3306 with a physical snapshot from an
existing cluster member. To use this method by default, set the
'recoveryMethod' option to 'clone'.
Having extra GTID events is not expected, and it is recommended to investigate
this further and ensure that the data can be removed prior to choosing the
clone recovery method.
Please select a recovery method [C]lone/[A]bort (default Abort): C ←Cloneするに選択。完全同期が走る
Validating instance at 172.22.246.64:3306...
This instance reports its own address as 172.22.246.64:3306
Instance configuration is suitable.
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: 172.22.246.64:3306 is being cloned from 172.22.246.60:3306
** Stage DROP DATA: Completed
** Clone Transfer
FILE COPY ############################################################ 100% Completed
PAGE COPY ############################################################ 100% Completed
REDO COPY ############################################################ 100% Completed
** Stage RECOVERY: |
NOTE: 172.22.246.64:3306 is shutting down...
* Waiting for server restart... ready
* 172.22.246.64:3306 has restarted, waiting for clone to finish...
* Clone process has finished: 115.01 MB transferred in about 1 second (~115.01 MB/s) ←Cloneスピード
Incremental distributed state recovery is now in progress. ←Cloneする間に更新されたものはIncrementalで同期する
* Waiting for distributed recovery to finish...
NOTE: '172.22.246.64:3306' is being recovered from '172.22.246.78:3306'
* Distributed recovery has finished
The instance '172.22.246.64:3306' was successfully added to the cluster.
MySQL 172.22.246.60:3306 ssl JS >