Mariadb 10.1 - 노드 3개 중 1개는 다시 시작되지 않습니다.

2024-6-22 • tag-icon

Mariadb 10.1 - 노드 3개 중 1개는 다시 시작되지 않습니다.

다음은 3노드 클러스터에서 Mariadb에 대한 구성을 변경해야 하는 시나리오입니다. 구성 파일을 편집하고 다음을 사용하여 노드를 종료했습니다.

# service mysqld stop

다른 2개의 노드를 변경하고 동일한 작업을 수행했습니다. 내가 가장 발전된 노드를 시작했을 때

# galera_new_cluster

시작됨 OK

넷 노드에서 시작되었고 정상적으로 시작되었습니다. 마지막 노드는 변경한 첫 번째 노드입니다.

이 노드는 시작되지 않습니다. 서비스 시작 시간 초과에 도달하고 그냥 종료됩니다. 실패한 노드나 기본 노드에서 오류를 찾을 수 없습니다. 시간 제한을 기본값인 90초에서 2시간으로 조정했는데, 이번에도 시간 초과가 발생했습니다.

무슨 일이 일어나고 있는지에 대한 단서를 찾고 있습니다.

현재 galera 구성에 실패했습니다.

[galera]
# Mandatory settings
binlog_format=ROW
default-storage-engine=innodb
innodb_autoinc_lock_mode=2
bind-address=192.168.10.238
wsrep_on=ON
wsrep_provider=/usr/lib64/galera/libgalera_smm.so
wsrep_cluster_address="gcomm://192.168.10.200,192.168.10.201"
## Galera Cluster Configuration
wsrep_cluster_name="Cluster1"
## Galera Synchronization Configuration
wsrep_sst_method=rsync
## Galera Node Configuration
wsrep_node_address="192.168.10.238"
wsrep_node_name="db3"

시작 시간 초과 메시지:

# service mysql start
Starting mysql (via systemctl):  Job for mariadb.service failed because a timeout was exceeded. See "systemctl status mariadb.service" and "journalctl -xe" for details.
                                                           [FAILED]

기본 노드에서 마지막 노드가 클러스터에 성공적으로 참여하는 것을 볼 수 있습니다.

2018-03-13  9:08:36 140261636175616 [Note] WSREP: (050b87ee, 'tcp://0.0.0.0:4567') connection established to ce802915 tcp://192.168.10.238:4567
2018-03-13  9:08:36 140261636175616 [Note] WSREP: (050b87ee, 'tcp://0.0.0.0:4567') turning message relay requesting on, nonlive peers: 
2018-03-13  9:08:36 140261636175616 [Note] WSREP: declaring 8ee7874f at tcp://192.168.10.201:4567 stable
2018-03-13  9:08:36 140261636175616 [Note] WSREP: declaring ce802915 at tcp://192.168.10.238:4567 stable
2018-03-13  9:08:36 140261636175616 [Note] WSREP: Node 050b87ee state prim
2018-03-13  9:08:36 140261636175616 [Note] WSREP: view(view_id(PRIM,050b87ee,87) memb {
        050b87ee,0
        8ee7874f,0
        ce802915,0
} joined {
} left {
} partitioned {
})
2018-03-13  9:08:36 140261636175616 [Note] WSREP: save pc into disk
2018-03-13  9:08:36 140261627782912 [Note] WSREP: New COMPONENT: primary = yes, bootstrap = no, my_idx = 0, memb_num = 3
2018-03-13  9:08:36 140261627782912 [Note] WSREP: STATE_EXCHANGE: sent state UUID: a3fa8cd5-26bf-11e8-8f00-a686a9b10fbd
2018-03-13  9:08:36 140261627782912 [Note] WSREP: STATE EXCHANGE: sent state msg: a3fa8cd5-26bf-11e8-8f00-a686a9b10fbd
2018-03-13  9:08:36 140261627782912 [Note] WSREP: STATE EXCHANGE: got state msg: a3fa8cd5-26bf-11e8-8f00-a686a9b10fbd from 0 (b1)
2018-03-13  9:08:36 140261627782912 [Note] WSREP: STATE EXCHANGE: got state msg: a3fa8cd5-26bf-11e8-8f00-a686a9b10fbd from 1 (db2)
2018-03-13  9:08:36 140261627782912 [Note] WSREP: STATE EXCHANGE: got state msg: a3fa8cd5-26bf-11e8-8f00-a686a9b10fbd from 2 (db3)
2018-03-13  9:08:36 140261627782912 [Note] WSREP: Quorum results:
        version    = 4,
        component  = PRIMARY,
        conf_id    = 20,
        members    = 2/3 (joined/total),
        act_id     = 3166274,
        last_appl. = 3166245,
        protocols  = 0/7/3 (gcs/repl/appl),
        group UUID = 4687a061-0310-11e8-a49f-534404044853
2018-03-13  9:08:36 140261627782912 [Note] WSREP: Flow-control interval: [28, 28]
2018-03-13  9:08:36 140261627782912 [Note] WSREP: Trying to continue unpaused monitor
2018-03-13  9:08:36 140261931068160 [Note] WSREP: New cluster view: global state: 4687a061-0310-11e8-a49f-534404044853:3166274, view# 21: Primary, number of nodes: 3, my index: 0, protocol version 3
2018-03-13  9:08:36 140261931068160 [Note] WSREP: wsrep_notify_cmd is not defined, skipping notification.
2018-03-13  9:08:36 140261931068160 [Note] WSREP: REPL Protocols: 7 (3, 2)
2018-03-13  9:08:36 140261931068160 [Note] WSREP: Assign initial position for certification: 3166274, protocol version: 3
2018-03-13  9:08:36 140261686085376 [Note] WSREP: Service thread queue flushed.
2018-03-13  9:08:39 140261636175616 [Note] WSREP: (050b87ee, 'tcp://0.0.0.0:4567') turning message relay requesting off

Mariadb가 실패한 호스트에서 시작을 시도할 때 오류가 표시되지 않습니다.

Mar 13 09:11:43 pn09 systemd: Starting MariaDB 10.1.30 database server...
Mar 13 09:11:49 pn09 sh: WSREP: Recovered position 4687a061-0310-11e8-a49f-534404044853:2564462
Mar 13 09:11:49 pn09 mysqld: 2018-03-13  9:11:49 122545243265280 [Note] /usr/sbin/mysqld (mysqld 10.1.30-MariaDB) starting as process 7558 ...
Mar 13 09:11:50 pn09 rsyncd[7667]: rsyncd version 3.0.9 starting, listening on port 4444

나는 이것에 대해 약간의 손실을 입었고 어떤 방향이라도 감사하게 생각합니다. 이와 같은 단일 노드에서 서비스를 중지했다가 시작하는 데 문제가 있는 이유가 확실하지 않습니다. 나머지 2개는 문제 없이 깔끔하게 올리고 내릴 수 있어요.

한 가지 주목할 점은, 이것을 조사하는 동안 grastate.dat 파일에서 3개 노드 모두 SEQNO가 -1로 설정되어 있음을 발견했습니다. 왜 그런 일이 일어날지, 그것이 중요한 문제인지, 무엇인지 잘 모르겠습니다.

다른 관심 사항 - 서비스 시작이 실패한 후에도 일부 백그라운드 프로세스가 계속 실행됩니다.

# ps aux |grep mysql
mysql     7558  0.2  0.3 349912 57920 ?        Ssl  09:11   0:00 /usr/sbin/mysqld --wsrep_start_position=4687a061-0310-11e8-a49f-534404044853:2564462
mysql     7567  1.2  0.0 113388  1796 ?        S    09:11   0:03 /bin/bash -ue /usr//bin/wsrep_sst_rsync --role joiner --address 192.168.10.238 --datadir /var/lib/mysql/ --parent 7558
mysql     7667  0.0  0.0 114652  1068 ?        S    09:11   0:00 rsync --daemon --no-detach --port 4444 --config /var/lib/mysql//rsync_sst.conf

관련 정보