MariaDB Galera 클러스터 설정 문제

MariaDB Galera 클러스터 설정 문제

mariadb 클러스터를 가동시키려 하고 있지만 잘 되지 않습니다.현재 64비트 레드햇 ES6 머신에서 MariaDB Galera 5.5.36을 사용하고 있습니다.아래 repo를 통해 mariadb를 설치했습니다.

[mariadb]
name = MariaDB
baseurl = http://yum.mariadb.org/5.5-galera/rhel6-amd64/
gpgkey=https://yum.mariadb.org/RPM-GPG-KEY-MariaDB
gpgcheck=1

server.conf의 서버 1에는 다음이 있습니다.

[mariadb]
log_error=/var/log/mariadb.log
query_cache_size=0
query_cache_type=0
binlog_format=ROW
default_storage_engine=innodb
innodb_autoinc_lock_mode=2
wsrep_provider=/usr/lib64/galera/libgalera_smm.so
wsrep_cluster_address=gcomm://192.168.211.133
wsrep_cluster_name='cluster'
wsrep_node_address='192.168.211.132'
wsrep_node_name='cluster1'
wsrep_sst_method=rsync

서버 2에는

[mariadb]
log_error=/var/log/mariadb.log
query_cache_size=0
query_cache_type=0
binlog_format=ROW
default_storage_engine=innodb
innodb_autoinc_lock_mode=2
wsrep_provider=/usr/lib64/galera/libgalera_smm.so
wsrep_cluster_address=gcomm://192.168.211.132
wsrep_cluster_name='cluster'
wsrep_node_address='192.168.211.133'
wsrep_node_name='cluster2'
wsrep_sst_method=rsync

sudo service mysql start --wsrep-new-cluster 명령어를 사용하여 서버1을 기동하면 정상적으로 기동합니다.mysql을 열고 wsrep의 상태를 확인하면 모든 것이 정상이라고 표시됩니다.그러나 sudo service mysql을 두 번째 서버에서 기동하려고 하면 오류 로그에 다음과 같이 표시됩니다.

140609 14:47:55 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
140609 14:47:56 mysqld_safe WSREP: Running position recovery with --log_error='/var/lib/mysql/wsrep_recovery.i5qfm2' --pid-file='/var/lib/mysql/localhost.localdomain-recover.pid'
140609 14:47:57 mysqld_safe WSREP: Recovered position 85448d73-ebe8-11e3-9c20-fbc1995fee11:0
140609 14:47:57 [Note] WSREP: wsrep_start_position var submitted: '85448d73-ebe8-11e3-9c20-fbc1995fee11:0'
140609 14:47:57 [Note] WSREP: Read nil XID from storage engines, skipping position init
140609 14:47:57 [Note] WSREP: wsrep_load(): loading provider library '/usr/lib64/galera/libgalera_smm.so'
140609 14:47:57 [Note] WSREP: wsrep_load(): Galera 25.3.2(r170) by Codership Oy <info@codership.com> loaded successfully.
140609 14:47:57 [Note] WSREP: CRC-32C: using hardware acceleration.
140609 14:47:57 [Note] WSREP: Found saved state: 85448d73-ebe8-11e3-9c20-fbc1995fee11:-1
140609 14:47:57 [Note] WSREP: Passing config to GCS: base_host = 192.168.211.133; base_port = 4567; cert.log_conflicts = no; gcache.dir = /var/lib/mysql/; gcache.keep_pages_size = 0; gcache.mem_size = 0; gcache.name = /var/lib/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
140609 14:47:57 [Note] WSREP: Assign initial position for certification: 0, protocol version: -1
140609 14:47:57 [Note] WSREP: wsrep_sst_grab()
140609 14:47:57 [Note] WSREP: Start replication
140609 14:47:57 [Note] WSREP: Setting initial position to 85448d73-ebe8-11e3-9c20-fbc1995fee11:0
140609 14:47:57 [Note] WSREP: protonet asio version 0
140609 14:47:57 [Note] WSREP: Using CRC-32C (optimized) for message checksums.
140609 14:47:57 [Note] WSREP: backend: asio
140609 14:47:57 [Note] WSREP: GMCast version 0
140609 14:47:57 [Note] WSREP: (0c085f34-efe5-11e3-9f6b-8bfd1706e2a4, 'tcp://0.0.0.0:4567') listening at tcp://0.0.0.0:4567
140609 14:47:57 [Note] WSREP: (0c085f34-efe5-11e3-9f6b-8bfd1706e2a4, 'tcp://0.0.0.0:4567') multicast: , ttl: 1
140609 14:47:57 [Note] WSREP: EVS version 0
140609 14:47:57 [Note] WSREP: PC version 0
140609 14:47:57 [Note] WSREP: gcomm: connecting to group 'cluster', peer '192.168.211.132:,192.168.211.134:'
140609 14:48:00 [Warning] WSREP: no nodes coming from prim view, prim not possible
140609 14:48:00 [Note] WSREP: view(view_id(NON_PRIM,0c085f34-efe5-11e3-9f6b-8bfd1706e2a4,1) memb {
        0c085f34-efe5-11e3-9f6b-8bfd1706e2a4,0
} joined {
} left {
} partitioned {
})
140609 14:48:01 [Warning] WSREP: last inactive check more than PT1.5S ago (PT3.50775S), skipping check
140609 14:48:31 [Note] WSREP: view((empty))
140609 14:48:31 [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
140609 14:48:31 [ERROR] WSREP: gcs/src/gcs_core.c:gcs_core_open():196: Failed to open backend connection: -110 (Connection timed out)
140609 14:48:31 [ERROR] WSREP: gcs/src/gcs.c:gcs_open():1291: Failed to open channel 'cluster' at 'gcomm://192.168.211.132,192.168.211.134': -110 (Connection timed out)
140609 14:48:31 [ERROR] WSREP: gcs connect failed: Connection timed out
140609 14:48:31 [ERROR] WSREP: wsrep::connect() failed: 7
140609 14:48:31 [ERROR] Aborting

140609 14:48:31 [Note] WSREP: Service disconnected.
140609 14:48:32 [Note] WSREP: Some threads may fail to exit.
140609 14:48:32 [Note] /usr/sbin/mysqld: Shutdown complete

140609 14:48:32 mysqld_safe mysqld from pid file /var/lib/mysql/localhost.localdomain.pid ended

클러스터가 가동되고 있는 것을 세컨더리 서버가 검출할 수 없는 이유를 알 수 없습니다.이들 머신은 서로 정상적으로 통신할 수 있으며 서로 SSH할 수 있으며 서로 ping할 수 있습니다.galera 캐시 삭제, mariadb galera 버전 다운그레이드, SELinux 비활성화, mysql 서비스 실행, 올바른 포트가 열려 있는지 확인, IP 주소가 다른 컴퓨터 상의 2개의 VM에서 실행 등을 시도했습니다.제가 이것을 고치려고 3일 동안 찾아봤지만 아무런 해결책이 없는 것 같아서 여기서 무슨 일이 일어나고 있는지 아는 사람 있나요?

유사한 문제를 해결한 방법은 다음과 같습니다.

CentOS 7 (MariaDB Galera 10.1 탑재)

Node2 나는 이것을 보았다.

016-12-27 15:40:38 140703512762624 [Warning] WSREP: no nodes coming from prim view, prim not possible

읽어본 후 node1에서 실행해 보았습니다.

service mysql start --wsrep-new-cluster

하지만 실패했고, 로그에서 이걸 발견...

2016-12-27 15:44:08 140438853814528 [ERROR] WSREP: It may not be safe to bootstrap the cluster from this node. It was not the last one to leave the cluster and may not contain all the updates. To force cluster bootstrap with this node, edit the grastate.dat file manually and set safe_to_bootstrap to 1 .

그래서 나는 파일을 편집했다./var/lib/mysql/grastate.dat,변화하는safe_to_bootstrap로.1.

그 후 다음을 사용하여 프라이머리 노드를 시작할 수 있었습니다.

service mysql start --wsrep-new-cluster

그리고 다른 쪽에서는 그냥...

service mysql start

주의: 이것은, 실가동전의 데모 환경에서 행해지고 있습니다.모든 서버를 동시에 reboot하여 모든 것을 실행한 후 즉시 고장났습니다.P. 그러나 쓰기가 없고 DB가 동기화되어 있다는 것을 알았습니다.운영 환경에서 이러한 상황이 발생하면 다음을 사용하여 "새로운 클러스터"를 실행할 노드를 결정할 수 있습니다. 즉, 나를 프라이머리로 만드는 것과 비슷합니다.

mysqld_safe --wsrep-recover

이것이 실제 가동상의 문제라면 고장난 클라이언트에 명령어를 던지기 전에 이 문서를 읽고 CloneZilla를 사용하여 백업을 하는 것이 좋습니다.

https://www.percona.com/blog/2014/09/01/galera-replication-how-to-recover-a-pxc-cluster/

클러스터는 프라이머리 노드에서 다음 명령으로 시작해야 합니다.

galera_new_cluster

첫 번째 노드를 시작한 후 클러스터의 다른 노드를 성공적으로 시작할 수 있습니다.

모든 IP를 wsrep_cluster_address 파라미터에 표시해야 합니다.

wsrep_cluster_address=gcomm://192.168.211.199,192.168.211.199

이 작업은 양쪽 호스트에서 수행해야 합니다.그나저나 당신은 분할된 뇌 시나리오를 피하기 위해 두 개의 노드가 아닌 세 개의 노드를 원할 것입니다.

언급URL : https://stackoverflow.com/questions/24127115/mariadb-galera-cluster-set-up-problems