새로운 Percona XtraDB 노드가 클러스터에 참여할 수 없음

새로운 Percona XtraDB 노드가 클러스터에 참여할 수 없음

4개 노드 Percona XtraDB 클러스터가 있습니다. 매일 밤 백업을 위해 노드 하나가 종료된 후 클러스터에 다시 합류합니다. 이것은 꽤 오랫동안 잘 작동했습니다.

어젯밤 백업 노드가 클러스터 재결합을 거부했습니다. 다른 세 개의 노드는 잘 작동하지만 실패한 노드에 합류하려는 시도는 실패합니다.

운 좋게도 우리는 Ansible을 사용하여 모든 노드를 프로비저닝하므로 실패한 노드를 제거하고 처음부터 완전히 새로운 데이터베이스 노드로 교체하기 위한 반복 가능한 방법을 얻었습니다.

유엔다행히도 새 노드도 실패합니다. 최근 Ansible 스크립트에 대한 변경 사항이 없으며 이후 인스턴스를 성공적으로 시작했습니다. 차이가 있다면 이는 모두 Amazon AWS의 2개 AZ VPC에서 실행됩니다.

새 서버의 MySQL 로그는 다음과 같이 말합니다.

131226 04:44:50 mysqld_safe Starting mysqld daemon with databases from /data/mysql
131226 04:44:50 mysqld_safe Skipping wsrep-recover for empty datadir: /data/mysql
131226 04:44:50 mysqld_safe Assigning 00000000-0000-0000-0000-000000000000:-1 to wsrep_start_position
131226  4:44:50 [Note] WSREP: wsrep_start_position var submitted: '00000000-0000-0000-0000-000000000000:-1'
131226  4:44:50 [Note] WSREP: Read nil XID from storage engines, skipping position init
131226  4:44:50 [Note] WSREP: wsrep_load(): loading provider library '/usr/lib64/libgalera_smm.so'
131226  4:44:50 [Note] WSREP: wsrep_load(): Galera 3.2(r170) by Codership Oy <[email protected]> loaded successfully.
131226  4:44:50 [Note] WSREP: CRC-32C: using hardware acceleration.
131226  4:44:50 [Warning] WSREP: Could not open saved state file for reading: /data/mysql//grastate.dat
131226  4:44:50 [Note] WSREP: Found saved state: 00000000-0000-0000-0000-000000000000:-1
131226  4:44:50 [Note] WSREP: Passing config to GCS: base_host = 10.0.1.226; base_port = 4567; cert.log_conflicts = no; gcache.dir = /data/mysql/; gcache.keep_pages_size = 0; gcache.mem_size = 0; gcache.name = /data/mysql//galera.cache; gcache.page_size = 128M; gcache.size = 128M; gcs.fc_debug = 0; gcs.fc_factor = 1; gcs.fc_limit = 16; gcs.fc_master_slave = NO; gcs.max_packet_size = 64500; gcs.max_throttle = 0.25; gcs.recv_q_hard_limit = 9223372036854775807; gcs.recv_q_soft_limit = 0.25; gcs.sync_donor = NO; repl.causal_read_timeout = PT30S; repl.commit_order = 3; repl.key_format = FLAT8; repl.proto_max = 5
131226  4:44:50 [Note] WSREP: Assign initial position for certification: -1, protocol version: -1
131226  4:44:50 [Note] WSREP: wsrep_sst_grab()
131226  4:44:50 [Note] WSREP: Start replication
131226  4:44:50 [Note] WSREP: Setting initial position to 00000000-0000-0000-0000-000000000000:-1
131226  4:44:50 [Note] WSREP: protonet asio version 0
131226  4:44:50 [Note] WSREP: Using CRC-32C (optimized) for message checksums.
131226  4:44:50 [Note] WSREP: backend: asio
131226  4:44:50 [Note] WSREP: GMCast version 0
131226  4:44:50 [Note] WSREP: (7497477a-6de8-11e3-9a71-7af4d47d85be, 'tcp://0.0.0.0:4567') listening at tcp://0.0.0.0:4567
131226  4:44:50 [Note] WSREP: (7497477a-6de8-11e3-9a71-7af4d47d85be, 'tcp://0.0.0.0:4567') multicast: , ttl: 1
131226  4:44:50 [Note] WSREP: EVS version 0
131226  4:44:50 [Note] WSREP: PC version 0
131226  4:44:50 [Note] WSREP: gcomm: connecting to group 'my_wsrep_cluster', peer '10.0.2.180:,10.0.1.226:,10.0.1.21:,10.0.2.236:'
131226  4:44:50 [Warning] WSREP: (7497477a-6de8-11e3-9a71-7af4d47d85be, 'tcp://0.0.0.0:4567') address 'tcp://10.0.1.226:4567' points to own listening address, blacklisting
131226  4:44:53 [Warning] WSREP: no nodes coming from prim view, prim not possible
131226  4:44:53 [Note] WSREP: view(view_id(NON_PRIM,7497477a-6de8-11e3-9a71-7af4d47d85be,1) memb {
    7497477a-6de8-11e3-9a71-7af4d47d85be,0
} joined {
} left {
} partitioned {
})
131226  4:44:54 [Warning] WSREP: last inactive check more than PT1.5S ago (PT3.5049S), skipping check
131226  4:45:23 [Note] WSREP: view((empty))
131226  4:45:23 [ERROR] WSREP: failed to open gcomm backend connection: 110: failed to reach primary view: 110 (Connection timed out)
     at gcomm/src/pc.cpp:connect():141
131226  4:45:23 [ERROR] WSREP: gcs/src/gcs_core.c:gcs_core_open():196: Failed to open backend connection: -110 (Connection timed out)
131226  4:45:23 [ERROR] WSREP: gcs/src/gcs.c:gcs_open():1291: Failed to open channel 'my_wsrep_cluster' at 'gcomm://10.0.2.180,10.0.1.226,10.0.1.21,10.0.2.236': -110 (Connection timed out)
131226  4:45:23 [ERROR] WSREP: gcs connect failed: Connection timed out
131226  4:45:23 [ERROR] WSREP: wsrep::connect() failed: 7
131226  4:45:23 [ERROR] Aborting

131226  4:45:23 [Note] WSREP: Service disconnected.
131226  4:45:24 [Note] WSREP: Some threads may fail to exit.
131226  4:45:24 [Note] /usr/sbin/mysqld: Shutdown complete

131226 04:45:24 mysqld_safe mysqld from pid file /data/mysql/mysql.pid ended

클러스터의 기존 노드는 새 노드가 가입을 시도할 때마다 다음을 내보냅니다.

131226  4:45:23 [Warning] WSREP: unserialize error invalid flags 2: 71 (Protocol error)
 at gcomm/src/gcomm/datagram.hpp:unserialize():101

이런 일이 발생한 사람이 있습니까? 인터넷 검색에서는 거의 공개되지 않으며 반복 가능한 서버 구성이 현재 반복 가능하지 않다는 사실이 걱정스럽습니다.

답변1

이것드러내다Galera 2.x -> 3.x 스위치의 부작용입니다.

새 서버에는 최신 Galera 3.x 패키지가 포함되었습니다. 혼합 클러스터에는 다음이 필요합니다.

wsrep_provider_options = 'socket.checksum = 1;'

/etc/my.cnf3.x 노드에 연결 하여 2.x 노드와 통신할 수 있도록 합니다.

Launchpad를 이용해 주신 Alex Yurchenko(ayurchen)에게 많은 감사를 드립니다.

답변2

인터넷에서 이 특정 오류가 참조되는 유일한 다른 곳은 다음의 주석 9입니다.버그 1153727, 고정됨으로 표시됩니다. "작동하는" 노드를 사용 가능한 최신 버전의 Percona XtraDB Cluster로 업그레이드하는 것이 좋습니다. 그러면 최신 버전의 새 노드에 가입할 수 있습니다.

관련 정보