問題
這個(gè)問題潮尝，在線上環(huán)境偶爾遇到如下錯(cuò)誤榕吼，甚至偶爾連主節(jié)點(diǎn)的bootstrap都不行，報(bào)錯(cuò)大概就是如下勉失，
2024-05-22T11:53:07.919600+08:00 0 [ERROR] [MY-013780] [Repl] Plugin group_replication reported: 'Failed to establish MySQL client connection in Group Replication. Error establishing connection. Please refer to the manual to make sure that you configured Group Replication properly to work with MySQL Protocol connections.'
2024-05-22T11:53:07.919780+08:00 0 [ERROR] [MY-011735] [Repl] Plugin group_replication reported: '[GCS] The group communication engine failed to test connectivity to the local group communication engine on 192.168.1.86:3320. This may be due to one or more invalid configuration settings. Double-check your group replication
local address, firewall, SE Linux and TLS configurations and try restarting Group Replication on this server.'
這個(gè)報(bào)錯(cuò)其實(shí)不太明顯友题，我們檢查所有的防火墻，SE Linux 和 SSL配置等都沒有問題戴质。而我自己模擬的時(shí)候度宦，只能關(guān)閉掉數(shù)據(jù)庫的SSL支持，然后MGR 使用SSL連接告匠，這個(gè)肯定報(bào)錯(cuò)戈抄，如下，
first,skip ssl ,add tls_version='' in my.cnf to disable ssl .
| have_openssl | DISABLED |
| have_ssl | DISABLED |
use mysql
| group_replication_recovery_use_ssl | ON |
| group_replication_ssl_mode | REQUIRED |
| group_replication_communication_stack | MYSQL |
| group_replication_group_seeds | 192.168.1.84:3320,192.168.1.85:3320 |
| group_replication_local_address | 192.168.1.86:3320 |
boot first node
set global group_replication_bootstrap_group=on;
start group_replication;
這樣就會(huì)有類似的報(bào)錯(cuò)后专，但是報(bào)錯(cuò)視乎不太明顯划鸽，當(dāng)我們使用xcom協(xié)議的時(shí)候，報(bào)錯(cuò)變得很清晰戚哎，
2024-05-23T21:30:06.935157+08:00 0 [ERROR] [MY-011735] [Repl] Plugin group_replication reported: '[GCS] TLS version is invalid: '
2024-05-23T21:30:06.935239+08:00 0 [Note] [MY-011735] [Repl] Plugin group_replication reported: '[GCS] Error initializing SSL'
2024-05-23T21:30:06.935355+08:00 9 [ERROR] [MY-011735] [Repl] Plugin group_replication reported: '[GCS] Error starting SSL in the group communication engine.'
2024-05-23T21:30:06.956616+08:00 9 [ERROR] [MY-011735] [Repl] Plugin group_replication reported: '[GCS] Error initializing the group communication engine.'
2024-05-23T21:30:06.977953+08:00 9 [ERROR] [MY-011674] [Repl] Plugin group_replication reported: 'Unable to initialize the group communication engine'
2024-05-23T21:30:06.977998+08:00 9 [ERROR] [MY-011637] [Repl] Plugin group_replication reported: 'Error on group communication engine initialization'
2024-05-23T21:30:06.978025+08:00 9 [Note] [MY-011649] [Repl] Plugin group_replication reported: 'Requesting to leave the group despite of not being a member'
相關(guān)原理
實(shí)際上MGR在傳遞消息給底層XCOM的時(shí)候裸诽，首先會(huì)通過mysql的gcs層將消息打包好，然后傳送給本地的XCOM型凳，因?yàn)槭潜镜貍鬏斦啥虼讼⒅恍枰湃腙?duì)列就好了，然后通過pipe傳遞一個(gè)消息甘畅，然后XCOM收到這些消息后會(huì)走paxos協(xié)議傳遞到遠(yuǎn)端的各個(gè)節(jié)點(diǎn)埂蕊，這個(gè)地方是需要走網(wǎng)絡(luò)socket的往弓，而scoket到底走不走ssl協(xié)議則是參數(shù)group_replication_ssl_mode和group_replication_recovery_use_ssl控制的，如果我們不想MGR連接使用SSL協(xié)議可以考慮設(shè)置這兩個(gè)參數(shù)為蓄氧，
- set persist group_replication_recovery_use_ssl=off;
- set persist group_replication_ssl_mode=disable;
這是老的方式函似，叫做XCOM協(xié)議。而到了8027喉童，新增了一個(gè)參數(shù)group_replication_communication_stack(參數(shù)默認(rèn)還是XCOM協(xié)議)撇寞，其可以設(shè)置為XCOM何MYSQL，新的MYSQL協(xié)議實(shí)際上就是在我們上面說的底層XCOM互聯(lián)的時(shí)候使用mysql自己的協(xié)議來連接堂氯，傳輸?shù)臄?shù)據(jù)都需要額外封裝一層mysql協(xié)議蔑担，我們可以看看下面的圖，發(fā)現(xiàn)XCOM的sender_task在連接初始化連接的時(shí)候帶了mysql的協(xié)議祖灰，包含了用戶名和密碼钟沛，用的是我們的recovery通道的用戶，
而到了shell的8031左右局扶，搭建cluster group_replication_communication_stack參數(shù)更是會(huì)被默認(rèn)的設(shè)置為MYSQL協(xié)議恨统，也就是說如果使用cluster在不注意的情況下group_replication_communication_stack已經(jīng)變成了MYSQL協(xié)議，而不是我們傳統(tǒng)的XCOM協(xié)議三妈，XCOM協(xié)議我們已經(jīng)用了很久了畜埋，貌似更穩(wěn)定一些。
當(dāng)然MGR在初始化的時(shí)候就會(huì)進(jìn)行連接的探測畴蒲，如果報(bào)錯(cuò)提前報(bào)錯(cuò)出來悠鞍，不至于到了XCOM進(jìn)行連接發(fā)送消息的時(shí)候才報(bào)錯(cuò)，而且會(huì)探測所有的本地節(jié)點(diǎn)和遠(yuǎn)端節(jié)點(diǎn)模燥，只要不能連接就會(huì)報(bào)錯(cuò)咖祭，大概在這個(gè)地方，
而我們看到XCOM協(xié)議報(bào)錯(cuò)是比較明顯的蔫骂，而MYSQL協(xié)議報(bào)錯(cuò)報(bào)得不明不白么翰，同時(shí)我們考慮使用XCOM協(xié)議的時(shí)候沒有類似問題，因此感覺大概率為封裝xcom消息封裝MySQL協(xié)議后出現(xiàn)的問題辽旋。
MySQL協(xié)議的握手信息溢出情況
這個(gè)問題就是在對(duì)上面問題進(jìn)行debug的時(shí)候發(fā)現(xiàn)的浩嫌，大概如下，
Old value = 63487
New value = 18446744072098936831
csm_parse_handshake (ctx=0x7fff027f2ff0) at /pxc/mysql-8.0.36/sql-common/client.cc:6858
code,
mysql->server_capabilities |= uint2korr((uchar *)end + 5) << 16;
這里有一個(gè)明顯的溢出补胚，這里就是進(jìn)行MySQL協(xié)議握手的時(shí)候客戶端接收到服務(wù)端的握手信息后解包得到服務(wù)端的信息的時(shí)候码耐，其中包含了服務(wù)端是否支持SSL連接。
如何解決
這個(gè)問題我們可以考慮切換為老的XCOM協(xié)議看看是否問題還存在溶其，如下
set persist group_replication_communication_stack='xcom';
set persist group_replication_group_seeds='192.168.1.85:33201,192.168.1.84:33201,192.168.1.86:33201';
set persist group_replication_local_address='192.168.1.86:33201';
同時(shí)搭建cluster的時(shí)候可以指定一下使用XCOM協(xié)議骚腥。
BUG
最后將一些信息提交給了官方如下，
https://bugs.mysql.com/bug.php?id=115087&thanks=4
當(dāng)然如果有能穩(wěn)定重現(xiàn)的方式握联，也可以告知一下桦沉。
