利用MySQL?Shell安裝部署MGR集群的詳細過程
本文介紹如何利用MySQL Shell + GreatSQL 8.0.25構建一個三節(jié)點的MGR集群。
MySQL Shell是一個客戶端工具,可用于方便管理和操作MySQL,支持SQL、JavaScript、Python等多種語言,也包括完善的API。MySQL Shell支持文檔型和關系型數據庫模式,通過X DevAPI可以管理文檔型數據,通過AdminAPI可以管理InnoDB Cluster、InnoDB ClusterSet及InnoDB ReplicaSet等。
1. 安裝準備
準備好下面三臺服務器:
| IP | 端口 | 角色 |
|---|---|---|
| 172.16.16.10 | 3306 | mgr1 |
| 172.16.16.11 | 3306 | mgr2 |
| 172.16.16.12 | 3306 | mgr3 |
確保三個節(jié)點間的網絡是可以互通的,并且沒有針對3306和33061端口的防火墻攔截規(guī)則。
利用yum安裝MySQL Shell,版本選擇和GreatSQL相同的8.0.25:
$ yum install mysql-shell-8.0.25
假定已經參考前文 3. 安裝部署MGR集群 做好MySQL Server的初始化并啟動三個實例。
接下來直接利用MySQL Shell部署MGR。
2. 利用MySQL Shell構建MGR集群
利用MySQL Shell構建MGR集群比較簡單,主要有幾個步驟:
- 檢查實例是否滿足條件。
- 創(chuàng)建并初始化一個集群。
- 逐個添加實例。
首先,用管理員賬號 root 連接到第一個節(jié)點:
#在本地通過socket方式登入 $ mysqlsh -Spath/mysql.sock root@localhost Please provide the password for 'root@.%2Fmysql.sock': ******** Save password for 'root@.%2Fmysql.sock'? [Y]es/[N]o/Ne[v]er (default No): yes MySQL Shell 8.0.25 ...
執(zhí)行命令 \status 查看當前節(jié)點的狀態(tài),確認連接正??捎?。
執(zhí)行 dba.configureInstance() 命令開始檢查當前實例是否滿足安裝MGR集群的條件,如果不滿足可以直接配置成為MGR集群的一個節(jié)點:
MySQL localhost JS > dba.configureInstance()
Configuring local MySQL instance listening at port 3306 for use in an InnoDB cluster...This instance reports its own address as 172.16.16.10:3306
#提示當前的用戶是管理員,不能直接用于MGR集群,需要新建一個賬號
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
Please select an option [1]: 2 <-- 這里我們選擇方案2,即創(chuàng)建一個最小權限賬號
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: GreatSQL
Password for new account: ********
Confirm password: ********
applierWorkerThreads will be set to the default value of 4.
The instance '172.16.16.10:3306' is valid to be used in an InnoDB cluster.
Cluster admin user 'GreatSQL'@'%' created.
The instance '172.16.16.10:3306' is already ready to be used in an InnoDB cluster.
Successfully enabled parallel appliers.
完成檢查并創(chuàng)建完新用戶后,退出當前的管理員賬戶,并用新創(chuàng)建的MGR專用賬戶登入,準備初始化創(chuàng)建一個新集群:
$ mysqlsh --uri GreatSQL@172.16.16.10:3306
Please provide the password for 'GreatSQL@172.16.16.10:3306': ********
Save password for 'GreatSQL@172.16.16.10:3306'? [Y]es/[N]o/Ne[v]er (default No): yes
MySQL Shell 8.0.25
...
#定義一個變量名c,方便下面引用
MySQL 172.16.16.10:3306 ssl JS > var c = dba.createCluster('MGR1');
A new InnoDB cluster will be created on instance '172.16.16.10:3306'.
Validating instance configuration at 172.16.16.10:3306...
This instance reports its own address as 172.16.16.10:3306
Instance configuration is suitable.
NOTE: Group Replication will communicate with other members using '172.16.16.10:33061'. Use the localAddress option to override.
Creating InnoDB cluster 'MGR1' on '172.16.16.10: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.
MySQL 172.16.16.10:3306 ssl JS >這就完成了MGR集群的初始化并加入第一個節(jié)點(引導節(jié)點)。
接下來,用同樣方法先用 root 賬號分別登入到另外兩個節(jié)點,完成節(jié)點的檢查并創(chuàng)建最小權限級別用戶(此過程略過。。。注意各節(jié)點上創(chuàng)建的用戶名、密碼都要一致),之后回到第一個節(jié)點,執(zhí)行 addInstance() 添加另外兩個節(jié)點。
MySQL 172.16.16.10:3306 ssl JS > c.addInstance('GreatSQL@172.16.16.11:3306'); <-- 這里要指定MGR專用賬號
WARNING: A GTID set check of the MySQL instance at '172.16.16.11:3306' determined that it contains transactions that do not originate from the cluster, which must be discarded before it can join the cluster.
172.16.16.11:3306 has the following errant GTIDs that do not exist in the cluster:
b05c0838-6850-11ec-a06b-00155d064000:1
WARNING: Discarding these extra GTID events can either be done manually or by completely overwriting the state of 172.16.16.11: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): Clone <-- 選擇用Clone方式從第一個節(jié)點全量復制數據
Validating instance configuration at 172.16.16.11:3306...
This instance reports its own address as 172.16.16.11:3306
Instance configuration is suitable.
NOTE: Group Replication will communicate with other members using '172.16.16.11:33061'. 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: 172.16.16.11:3306 is being cloned from 172.16.16.10:3306
** Stage DROP DATA: Completed
** Clone Transfer
FILE COPY ############################################################ 100% Completed
PAGE COPY ############################################################ 100% Completed
REDO COPY ############################################################ 100% Completed
NOTE: 172.16.16.11:3306 is shutting down... <-- 數據Clone完成,準備重啟實例。如果該實例無法完成自動重啟,則需要手動啟動
* Waiting for server restart... ready
* 172.16.16.11:3306 has restarted, waiting for clone to finish...
** Stage RESTART: Completed
* Clone process has finished: 72.43 MB transferred in about 1 second (~72.43 MB/s)
State recovery already finished for '172.16.16.11:3306'
The instance '172.16.16.11:3306' was successfully added to the cluster. <-- 新實例加入成功
MySQL 172.16.16.10:3306 ssl JS >
用同樣的方法,將 172.16.16.12:3306 實例也加入到集群中。
現在,一個有這三節(jié)點的MGR集群已經部署完畢,來確認下:
MySQL 172.16.16.10:3306 ssl JS > c.describe()
{
"clusterName": "MGR1",
"defaultReplicaSet": {
"name": "default",
"topology": [
{
"address": "172.16.16.10:3306",
"label": "172.16.16.10:3306",
"role": "HA"
},
"address": "172.16.16.11:3306",
"label": "172.16.16.11:3306",
"address": "172.16.16.12:3306",
"label": "172.16.16.12:3306",
}
],
"topologyMode": "Single-Primary"
}
} 或者執(zhí)行 c.status() 可以打印出集群更多的信息。
至此,利用MySQL Shell構建一個三節(jié)點的MGR集群做好了,可以嘗試向 Primary 節(jié)點寫入數據觀察測試。
3. MySQL Shell接管現存的MGR集群
對于已經在運行中的MGR集群,也是可以用MySQL Shell接管的。只需要在調用 createCluster() 函數時,加上 adoptFromGR:true 選項即可。實際上不加這個選項的話,MySQL Shell也會自動檢測到該MGR集群已存在,并詢問是否要接管。
在這里簡單演示下:
#不加上 adoptFromGr:true 選項
MySQL 172.16.16.10:3306 ssl JS > var c=dba.createCluster('MGR1');
A new InnoDB cluster will be created on instance '172.16.16.10:3306'.You are connected to an instance that belongs to an unmanaged replication group.
Do you want to setup an InnoDB cluster based on this replication group? [Y/n]:
可以看到,會有提示信息詢問是否要接管。
如果加上 adoptFromGr:true 選項,則會直接創(chuàng)建集群,不再詢問:
var c=dba.createCluster('MGR1', {adoptFromGr:true});
A new InnoDB cluster will be created based on the existing replication group on instance '172.16.16.10:3306'.Creating InnoDB cluster 'MGR1' on '172.16.16.10:3306'...
Adding Seed Instance...
Adding Instance '172.16.16.10:3306'...
Adding Instance '172.16.16.11:3306'...
Adding Instance '172.16.16.12:3306'...
...
如果是MGR集群的metadata發(fā)生變化,這時候無論調用 dba.getCluster() 還是 dba.createCluster 都可能會報告類似下面的錯誤:
Dba.getCluster: Unable to get an InnoDB cluster handle. The instance '192.168.6.27:3306' may belong to a different cluster from the one registered in the Metadata since the value of 'group_replication_group_name' does not match the one registered in the Metadata: possible split-brain scenario. Please retry while connected to another member of the cluster. (RuntimeError)
這種情況下,可以調用 dba.dropMetadataSchema() 函數刪除元數據,再調用 dba.createCluster() 接管集群:
#確保不影響正常業(yè)務的話,刪除無用MGR元數據
MySQL 172.16.16.10:3306 ssl JS > dba.dropMetadataSchema()
Are you sure you want to remove the Metadata? [y/N]: y
Metadata Schema successfully removed.
#接管現有集群
MySQL 172.16.16.10:3306 ssl JS > var c=dba.createCluster('MGR1', {adoptFromGr:true})
...這樣就可以了接管了。
4. 小結
本文主要介紹了如何利用MySQL Shell構建一個三節(jié)點的MGR集群,以及如何用MySQL Shell接管現有集群,處理元數據沖突的問題。相對于手工方式搭建MGR集群,用MySQL Shell操作會方便很多,推薦使用。
參考資料、文檔
免責聲明
因個人水平有限,專欄中難免存在錯漏之處,請勿直接復制文檔中的命令、方法直接應用于線上生產環(huán)境。請讀者們務必先充分理解并在測試環(huán)境驗證通過后方可正式實施,避免造成生產環(huán)境的破壞或損害。
到此這篇關于利用MySQL Shell安裝部署MGR集群 | 深入淺出MGR的文章就介紹到這了,更多相關MySQL Shell MGR集群內容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關文章希望大家以后多多支持腳本之家!
相關文章
MySQL中DATE_FORMAT()函數將Date轉為字符串
時間、字符串、時間戳之間的互相轉換很常用,下面這篇文章主要給大家介紹了關于MySQL中DATE_FORMAT()函數將Date轉為字符串的相關資料,文中通過圖文介紹的非常詳細,需要的朋友可以參考下2022-09-09
MySQL 客戶端不輸入用戶名和密碼直接連接數據庫的2個方法
MySQL 客戶端不輸入用戶名和密碼直接連接數據庫的2個方法,大家可以測試下。2009-07-07
Mysql性能調優(yōu)之max_allowed_packet使用及說明
這篇文章主要介紹了Mysql性能調優(yōu)之max_allowed_packet使用及說明,具有很好的參考價值,希望對大家有所幫助。如有錯誤或未考慮完全的地方,望不吝賜教2022-11-11

