MariaDB Galera Cluster einrichten Probleme
Ich versuche, ein mariadb-cluster und läuft, aber es ist nicht für mich. Jetzt bin ich mit MariaDB Galera 5.5.36 auf einem 64-bit red hat ES6 Maschine. Ich mariadb installiert über das repo hier:
[mariadb]
name = MariaDB
baseurl = http://yum.mariadb.org/5.5-galera/rhel6-amd64/
gpgkey=https://yum.mariadb.org/RPM-GPG-KEY-MariaDB
gpgcheck=1
In den server.conf habe ich Folgendes in der server-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
und auf server 2 habe ich
[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
Wenn ich start server 1 mit dem folgenden Befehl: sudo service mysql start --wsrep-neue-cluster startet es einfach gut, wenn ich mit mysql und überprüfen Sie den status wsrep es sagt alles ist und läuft ist gut, aber wenn ich versuche, sudo service mysql start auf dem zweiten server bekomme ich Folgendes in die error-logs:
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
Ich bin ratlos, warum der zweite server nicht erkennen kann, dass ein cluster eingerichtet ist und ausgeführt wird. Diese Maschinen können miteinander kommunizieren just fine, kann ich SSH von einem zum anderen und Sie können sich gegenseitig ping. Ich habe versucht, gelöscht, die galera-cache, versuchte Herabstufung meine version von mariadb galera, versucht, das deaktivieren von SELinux, habe versucht mit der mysql-Dienst als ein anderer Benutzer bestätigt hat, dass die richtigen ports geöffnet sind, wird versucht, läuft Sie auf 2 VMs auf unterschiedlichen Computern mit unterschiedlichen IP-Adressen, etc. Hat jemand eine Idee, was hier Los ist, denn ich habe die Suche seit 3 Tagen versucht dieses Problem zu beheben, aber keine Lösung scheint zu funktionieren bei mir.
Du musst angemeldet sein, um einen Kommentar abzugeben.
Muss der cluster starten, indem Sie diesen Befehl auf dem primären Knoten:
nach dem Start der ersten Knoten können Sie andere Knoten im cluster erfolgreich.
Ich glaube, Sie brauchen, um eine Liste mit allen IPs in der wsrep_cluster_address parameter.
wsrep_cluster_address=gcomm://192.168.211.132,192.168.211.133
Sollte dies auf beiden hosts. BTW Sie wollen wahrscheinlich drei Knoten, die nicht zwei, wie zu vermeiden split-brain-Szenarien.
Hier ist, wie ich meine Feste ähnliches Problem.
CentOS 7 w/MariaDB Galera 10.1.
Node2 sah ich dieses:
Nach etwas Lesen, ich habe versucht mit diesem auf node1.
Aber dies ist fehlgeschlagen, und in den logs fand ich dieses...
Also bearbeitete ich die Datei
/var/lib/mysql/grastate.dat
, ändernsafe_to_bootstrap
zu1
.War ich dann in der Lage, starten Sie den Primären Knoten verwenden:
Dann auf die anderen, ich habe gerade verwendet
Hinweis: Diese war in einem demo-pre-production-Umgebung. Ich habe prompt brach es nach dem aufstehen alles, was zur Arbeit von Neustart alle Server zur gleichen Zeit :P, aber ich wusste, dass es nicht schreibt, und dass die DB ist im Einklang waren. Wenn Sie sind in der Herstellung, und dies geschieht, können Sie die folgenden, um herauszufinden, welcher Knoten ausführen "neuer cluster" auf, die ähnlich zu sagen, mich machen primären.
Ist dies ein Produktions-Problem, ich sehr empfehlen Sie diesen Artikel Lesen, und macht ein backup w/CloneZilla bevor er Befehle an die gebrochenen Kunden!
https://www.percona.com/blog/2014/09/01/galera-replication-how-to-recover-a-pxc-cluster/