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

一.檢查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.將故障節點重新加入叢集