很重要:請保證集群中的數據庫表都存在主鍵，不然集群會掛掉；

一.檢查cluster各個節點是否可用

[cluster@node-1 ~]$ mysqlsh

mysql-js> dba.checkInstanceConfiguration("root@node-1:3305");

#在各節點配置之后, 創建cluster集群之前,會顯示如下內容：
Please provide the password for "root@node-1:3305": 
Validating instance...
 
The instance 'node-1:3305' is valid for Cluster usage
{
    "status": "ok"
}

# 如果集群已經創建，會返回
Dba.checkInstanceConfiguration: The instance 'root@node-1:3305' is already part of an InnoDB Cluster (RuntimeError)

二.查看集群狀態（主節點才能查看）

1.連接集群主節點

# mysqlsh

mysql-js> shell.connect("root@node-1:3305");
Please provide the password for 'root@node-1:3305': 
Creating a Session to 'root@node-1:3305'
Your MySQL connection id is 2567660
No default schema selected; type \use <schema> to set one.

#如果從遠程登陸
[root@db-node03 ~]# mysqlsh --uri root@node-1:3305

2.獲取集群實例

mysql-js> cluster=dba.getCluster();
<Cluster:myCluster>

3.查看集群狀態

mysql-js> cluster.status();
{
    "clusterName": "myCluster", 
    "defaultReplicaSet": {
        "name": "default", 
        "primary": "node-1:3305", 
        "status": "OK", 
        "statusText": "Cluster is ONLINE and can tolerate up to ONE failure.", 
        "topology": {
            "node-1:3305": {
                "address": "node-1:3305", 
                "mode": "R/W", 
                "readReplicas": {}, 
                "role": "HA", 
                "status": "ONLINE"
            }, 
            "node-2:3305": {
                "address": "node-2:3305", 
                "mode": "R/O", 
                "readReplicas": {}, 
                "role": "HA", 
                "status": "ONLINE"
            }, 
            "node-3:3305": {
                "address": "node-3:3305", 
                "mode": "R/O", 
                "readReplicas": {}, 
                "role": "HA", 
                "status": "ONLINE"
            }
        }
    }
}

三.集群節點狀態

- ONLINE       - 節點狀態正常。
- OFFLINE      - 實例在運行，但沒有加入任何Cluster。
- RECOVERING   - 實例已加入Cluster，正在同步數據。
- ERROR        - 同步數據發生異常。
- UNREACHABLE  - 與其他節點通訊中斷，可能是網絡問題，可能是節點crash。
- MISSING      - 節點已加入集群，但未啟動group replication

四.InnoDB Cluster集群維護的命令幫助

#會列出集群維護的指令
mysql-js> dba.help();
#列出詳細指令的用法
mysql-js> dba.help('deploySandboxInstance')

五.日常使用的幾個重要命令 (mysqlsh的JS語法)

dba.checkInstanceConfiguration("root@hostname:3306")     #檢查節點配置實例，用于加入cluster之前
 
dba.rebootClusterFromCompleteOutage('myCluster');        #重啟 
 
dba.dropMetadataSchema();                                #刪除schema
 
var cluster = dba.getCluster('myCluster')                #獲取當前集群
 
cluster.checkInstanceState("root@hostname:3306")         #檢查cluster里節點狀態
 
cluster.rejoinInstance("root@hostname:3306")             #重新加入節點，我本地測試的時候發現rejoin一直無效，每次是delete后
 
addcluster.dissolve({force：true})                       #刪除集群
 
cluster.addInstance("root@hostname:3306")                #增加節點
 
cluster.removeInstance("root@hostname:3306")             #刪除節點
 
cluster.removeInstance('root@host:3306',{force:true})    #強制刪除節點
 
cluster.dissolve({force:true})                           #解散集群
 
cluster.describe();                                      #集群描述

六.節點服務器重啟后未加入集群（重新加入集群）（多出現主節點）

#如果查詢節點狀態為：
 "status": "(MISSING)"
#重新加入命令
shell.connect("root@node-1:3305");
cluster=dba.getCluster();
cluster.rejoinInstance("root@node-2:3305")
#如果rejoinInstance失敗，提示remove重新添加如下：
cluster.removeInstance('root@node-1:3305');
cluster.addInstance('root@node-1:3305');

七.集群中所有服務器重啟，所有節點都offline，直接獲取集群信息失敗

查詢數據庫SELECT * FROM performance_schema.replication_group_members;
僅顯示單機 'MEMBER_STATE' = 'offline'

使用SELECT clusters.cluster_id,clusters.cluster_name from mysql_innodb_cluster_metadata.clusters；
查找集群名稱
執行rebootClusterFromCompleteOutage命令，恢復集群
+------------+--------------+
| cluster_id | cluster_name |
+------------+--------------+
|          1 | myCluster    |
+------------+--------------+

#指令如下：
shell.connect("root@node-1:3305");
dba.rebootClusterFromCompleteOutage('myCluster');

八.RESET MASTER 和RESET SLAVE 命令的使用方法 注意事項

RESET MASTER 
刪除所有index file 中記錄的所有binlog 文件，將日志索引文件清空，創建一個新的日志文件，這個命令通常僅僅用于第一次用于搭建主從關系的時的主庫，
注意
  reset master 不同于purge binary log的兩處地方
1 reset master 將刪除日志索引文件中記錄的所有binlog文件，創建一個新的日志文件 起始值從000001 開始，然而purge binary log 命令并不會修改記錄binlog的順序的數值
2 reset master 不能用于有任何slave 正在運行的主從關系的主庫。因為在slave 運行時刻 reset master 命令不被支持，resetmaster 將master 的binlog從000001 開始記錄,slave 記錄的master log 則是reset master 時主庫的最新的binlog,從庫會報錯無法找的指定的binlog文件。

In MySQL 5.6.5 and later, RESET MASTER also clears the values of the gtid_purged system variable (known as gtid_lost in MySQL 5.6.8 and earlier) as well as the global value of the gtid_executed (gtid_done, prior to MySQL 5.6.9) system variable (but not its session value); that is, executing this statement sets each of these values to an empty string ('')

RESET SLAVE 
reset slave 將使slave 忘記主從復制關系的位置信息。該語句將被用于干凈的啟動, 它刪除master.info文件和relay-log.info 文件以及所有的relay log 文件并重新啟用一個新的relaylog文件。
使用reset slave之前必須使用stop slave 命令將復制進程停止。

注 所有的relay log將被刪除不管他們是否被SQL thread進程完全應用(這種情況發生于備庫延遲以及在備庫執行了stop slave 命令),存儲復制鏈接信息的master.info文件將被立即清除,如果SQL thread 正在復制臨時表的過程中，執行了stop slave ，并且執行了reset slave，這些被復制的臨時表將被刪除。

RESET SLAVE ALL
在 5.6 版本中 reset slave 并不會清理存儲于內存中的復制信息比如 master host, master port, master user, or master password,也就是說如果沒有使用change master 命令做重新定向，執行start slave 還是會指向舊的master 上面。
當從庫執行reset slave之后,將mysqld shutdown 復制參數將被重置。
在5.6.3 版本以及以后 使用使用 RESET SLAVE ALL 來完全的清理復制連接參數信息。(Bug #11809016)
RESET SLAVE ALL does not clear the IGNORE_SERVER_IDS list set by CHANGE MASTER TO. This issue is fixed in MySQL 5.7. (Bug #18816897)
In MySQL 5.6.7 and later, RESET SLAVE causes an implicit commit of an ongoing transaction. See Section 13.3.3, “Statements That Cause an Implicit Commit”.

九.停止集群

mysql-js> shell.connect("root@node-1:3305");
mysql-js> \sql
#停止集群
mysql-sql> stop group_replication;

十.故障節點修復后，重新加入集群

• 1.初始化故障節點
• 2.導出正常節點的數據庫，并傳到故障節點
• 3.故障節點導入數據庫
• 4.重啟故障節點 MySQL
• 5.將故障節點重新加入集群