前提
innodb_cluster前提で、mysqlshでクラスタを構築しました。
dba.configureInstance("instance1")
以下を設定してくれるっぽい。
server_id=1
gtid_mode=ON
enforce_gtid_consistency=ON
binlog_checksum=NONE
dba.createCluster("mycluster")
cluster.addInstance("instance2")
以下を設定してくれるっぽい。
transaction_write_set_extraction=XXHASH64
group_replication_group_name="aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa"
group_replication_start_on_boot=off
group_replication_local_address= "127.0.0.1:24901"
group_replication_group_seeds= "127.0.0.1:24901,127.0.0.1:24902,127.0.0.1:24903"
group_replication_bootstrap_group=off
物理バックアップ前提で、xtrabackup8.0でバックアップ・リストア
とりあえずマニュアル通りでやって見ると
# xtrabackup --backup --target-dir=$bk_dir
# xtrabackup --prepare --target-dir=$bk_dir
# rm -rf $data_dir
# xtrabackup --copy-back --target-dir=$bk_dir
# chown -R mysql. $data_dir
# systemctl start mysqld
mysql> reset master;
mysql> set global gtid_purged=xxxxxxxxxxxxxx;
Groupreplication起動して見ます
mysql> set global group_replication_bootstrap_group=ON;
mysql> start group_replication;
mysql> set global group_replication_bootstrap_group=OFF;
group name知らないよと怒られます
2019-06-19T10:49:52.008040Z 0 [ERROR] [MY-011685] [Repl] Plugin group_replication reported: 'The group name option is mandatory'
2019-06-19T10:49:52.008054Z 0 [ERROR] [MY-011660] [Repl] Plugin group_replication reported: 'Unable to start Group Replication on boot'
WHY?
私の場合はmysqlshで設定したため、$data_dir/mysqld-auto.cnfに設定情報が保存されています。(set persistで設定した場合もこちらに保存されます)
xtrabackupは該当ファイルをBKしてくれないので、rmでGroupreplicationの設定がすべて飛んでしまったわけです。
もう一つ気付いたのは$data_dir/auto.cnfも飛んでしまいました。
こちらはサービス起動時に、なければ自動生成してくれますが、
mysql_innodb_cluster_metadata.instancesに古いuuidが残っている。新しいreplica setなので問題ないとか？
mysql> select * from mysql_innodb_cluster_metadata.instances\G
*************************** 1. row ***************************
instance_id: 1
host_id: 1
replicaset_id: 1
mysql_server_uuid: e4ca1264-927e-11e9-81ea-fa163e024c6f ←古いまま
略
例えばsecondaryでリストアした場合、server_uuidが変わってしまうと知らないものと判断されるのでclusterにrejoinできなくなります。
マニュアルによれば、auto.cnfは再生成させて、cluster.removeしてcluster.rescanしてcluster.addInstanceしてとのことです。
If you are rejoining an instance which has changed in some way then you might have to modify the instance to make the rejoin process work correctly. For example, when you restore a MySQL Enterprise Backup backup, the server_uuid changes. Attempting to rejoin such an instance fails because InnoDB cluster instances are identified by the server_uuid variable. In such a situation, information about the instance's old server_uuid must be removed from the InnoDB cluster metadata and then a Cluster.rescan() must be executed to add the instance to the metadata using it's new server_uuid. For example:
でもprimaryの場合はどうすればいいでしょう？innodb_clusterの考えは既存クラスタを捨てて再度作るとのこと？
一応auto.cnfとmysqld-auto.cnfを別途バックアップ取ってリカバリしたらうまく行けそうでしたが、まだまだ情報少ない。。。
そもそもリストアのやり方が間違っていたら教えてください。
2019/07/09追記
試行錯誤の結果、auto.cnfとmysqld-auto.cnfはリストア直前(mysqld-auto.cnfにはpersistなどで動的に更新されるため)に退避し、リストア後に戻す方法にしました。
(今のところ安定して問題もなし)
cluster.remove ⇒cluster.rejoinメタデータまで更新されましたが、残念ながらmember追加するたびに作成されるユーザmysql_innodb_cluster_xxxxxxxxは残ってしまいました。
リストア前のサービス停止とリストア後のサービス起動はこちらを参照。
まとめ
mysqlsh超便利ですが、運用を考えるとまだまだ考えることいっぱいですね。。