web-dev-qa-db-ja.com

MariaDB Galera Cluster Nodeダウンした後、開始できません

私の環境：

  • 2つのノード-CentOS 6.4 x86_64

    ノード1：10.10.201.3

    ノード2：10.10.201.4

  • MariaDB-server-10.2.0-1.el6.x86_64

両方のノードは正常に実行されていますが、Node1でmysqlを再起動した後、Node2のmysqlが問題なく実行されている間は、再起動できません。

Node1の構成：

#/etc/my.cnf.d/server.cnf

node1
bind-address=10.10.201.3
datadir=/opt/mysql
socket=/opt/mysql/mysql.sock
handlersocket_address="10.10.201.3"
handlersocket_port="9998"
handlersocket_port_wr="9999"
open_files_limit = 25600
log-error=/opt/mysql/log/mysqld.log
[galera]
# Mandatory settings
wsrep_on=ON
wsrep_provider=/usr/lib64/galera/libgalera_smm.so
wsrep_cluster_address="gcomm://10.10.201.4,10.10.201.3"
wsrep_cluster_name='galera_cluster_www'
wsrep_node_address='10.10.201.3'
wsrep_node_name='www-node1'
wsrep_sst_method=rsync
wsrep_sst_auth=sst_user:password
wsrep-slave-threads=16
binlog_format=ROW
default_storage_engine=InnoDB
innodb_autoinc_lock_mode=2
wsrep_log_conflicts=ON
wsrep_provider_options="cert.log_conflicts=ON"
wsrep_debug=ON
wsrep_max_ws_size = 2G
binlog_row_image = minimal

Node2の構成：

#/etc/my.cnf.d/server.cnf

node2
bind-address=10.10.201.4
datadir=/opt/mysql
socket=/opt/mysql/mysql.sock
handlersocket_address="10.10.201.4"
handlersocket_port="9998"
handlersocket_port_wr="9999"
open_files_limit = 25600
[galera]
# Mandatory settings
wsrep_on=ON
wsrep_provider=/usr/lib64/galera/libgalera_smm.so
wsrep_cluster_address="gcomm://10.10.201.3,10.10.201.4"
wsrep_cluster_name='galera_cluster_www'
wsrep_node_address='10.10.201.4'
wsrep_node_name='www-node2'
wsrep_sst_method=rsync
wsrep_sst_auth=sst_user:password
wsrep-slave-threads=16
binlog_format=ROW
default_storage_engine=InnoDB
innodb_autoinc_lock_mode=2
wsrep_log_conflicts=ON
wsrep_provider_options="cert.log_conflicts=ON"
wsrep_debug=ON
wsrep_max_ws_size = 2G
binlog_row_image = minimal

そして最後に、最初のノード（Node1）でmysqlが失敗した後のNode2のクラスター情報：

MariaDB [(none)]> show status like 'wsrep%';

+------------------------------+--------------------------------------+
| Variable_name                | Value                                |
+------------------------------+--------------------------------------+
| wsrep_apply_oooe             | 0.017353                             |
| wsrep_apply_oool             | 0.000050                             |
| wsrep_apply_window           | 1.021550                             |
| wsrep_causal_reads           | 0                                    |
| wsrep_cert_deps_distance     | 24.564685                            |
| wsrep_cert_index_size        | 48                                   |
| wsrep_cert_interval          | 0.021750                             |
| wsrep_cluster_conf_id        | 69                                   |
| wsrep_cluster_size           | 1                                    |
| wsrep_cluster_state_uuid     | c07f825f-132f-11e6-b219-d7e841605104 |
| wsrep_cluster_status         | Primary                              |
| wsrep_commit_oooe            | 0.000000                             |
| wsrep_commit_oool            | 0.000034                             |
| wsrep_commit_window          | 1.005403                             |
| wsrep_connected              | ON                                   |
| wsrep_evs_delayed            |                                      |
| wsrep_evs_evict_list         |                                      |
| wsrep_evs_repl_latency       | 0/0/0/0/0                            |
| wsrep_evs_state              | OPERATIONAL                          |
| wsrep_flow_control_paused    | 0.000000                             |
| wsrep_flow_control_paused_ns | 0                                    |
| wsrep_flow_control_recv      | 0                                    |
| wsrep_flow_control_sent      | 0                                    |
| wsrep_gcomm_uuid             | 401f6755-71da-11e6-8244-9e88079ed6c4 |
| wsrep_incoming_addresses     | 10.10.201.4:3306                     |
| wsrep_last_committed         | 2364263                              |
| wsrep_local_bf_aborts        | 116                                  |
| wsrep_local_cached_downto    | 2221069                              |
| wsrep_local_cert_failures    | 23                                   |
| wsrep_local_commits          | 729390                               |
| wsrep_local_index            | 0                                    |
| wsrep_local_recv_queue       | 0                                    |
| wsrep_local_recv_queue_avg   | 0.004725                             |
| wsrep_local_recv_queue_max   | 6                                    |
| wsrep_local_recv_queue_min   | 0                                    |
| wsrep_local_replays          | 112                                  |
| wsrep_local_send_queue       | 0                                    |
| wsrep_local_send_queue_avg   | 0.000335                             |
| wsrep_local_send_queue_max   | 2                                    |
| wsrep_local_send_queue_min   | 0                                    |
| wsrep_local_state            | 4                                    |
| wsrep_local_state_comment    | Synced                               |
| wsrep_local_state_uuid       | c07f825f-132f-11e6-b219-d7e841605104 |
| wsrep_protocol_version       | 7                                    |
| wsrep_provider_name          | Galera                               |
| wsrep_provider_vendor        | Codership Oy <[email protected]>    |
| wsrep_provider_version       | 25.3.15(r3578)                       |
| wsrep_ready                  | ON                                   |
| wsrep_received               | 1376816                              |
| wsrep_received_bytes         | 630752657                            |
| wsrep_repl_data_bytes        | 303429595                            |
| wsrep_repl_keys              | 3039261                              |
| wsrep_repl_keys_bytes        | 41097380                             |
| wsrep_repl_other_bytes       | 0                                    |
| wsrep_replicated             | 729452                               |
| wsrep_replicated_bytes       | 391211903                            |
| wsrep_thread_count           | 17                                   |
+------------------------------+--------------------------------------+
clustermariadbgalera
2
user36814

私は同じ問題を抱えていて、最後に問題を修正した後（onCentOS 7-MariaDB-server-10.2 .0-1）、私はそれを正しく設定する方法についてのドキュメントを書いており、それがあなたの問題も修正することを願っています。以下の指示に従って、Galeraノードをゼロから構築してみてください。必須の設定を使用します。後で設定を追加できます。5番目のステップに失敗したか、正しく実行しなかったと思います。とにかく、すべてのステップを記述します他の誰でも簡単にフォローできます。

この問題は、マスターノードでgalera_new_clusterコマンドを使用せず、wsrep_cluster_address-gcommに適切なアドレスを使用しない場合に発生します。したがって、マスターに障害が発生すると、他のノードはピアに戻ることができません。 （マスターでもクラスターに戻ることはできません）

GLR{1,2,3}という名前の3つのサーバーを検討し、それぞれにGalera Clusterをセットアップします。・7段目で2ノードクラスタの障害を回避する方法を説明します。

ステップ1

インストールの場合：

お好みのエディターで/etc/yum.repos.d/mariadb.repoを開き、それに次の行を追加します。

[mariadb]
name = MariaDB
baseurl = http://yum.mariadb.org/10.0/centos6-AMD64
gpgkey=https://yum.mariadb.org/RPM-GPG-KEY-MariaDB
gpgcheck=1

ステップ2

SELinuxを管理/設定する方法がわからない場合は、SELinuxをpermissiveモードに設定し、インストールの完了後にログファイルをチェックして、必要な管理手順を実行してください。 SELinuxログをより深く理解するために、setroubleshoot-serverおよびsetools-consoleパッケージをインストールする必要がある場合もあります。

ただし、SELinuxを有効にしていて、permissiveモードに設定したくない場合は、mysqldが必要な操作を実行するのをブロックする可能性があることに注意してください。したがって、mysqldが非特権ポートで外部プログラムを実行してリスンソケットを開くことができるように、つまり、非特権ユーザーが実行できることを構成する必要があります。

SELinuxの管理方法を教えることはこの回答の範囲を超えていますが、次のコマンドを実行することで、mysqlリクエストに対してのみ許可モードで設定できます。

semanage permissive -a mysql_t

ステップ3

yumを使用してインストールした後、以下の行を/etc/my.cnf.d/server.cnfの末尾に、各GLRサーバーでそれぞれ以下のように追加します。

[GLR1]↴

$ vim /etc/my.cnf.d/server.cnf
[galera]
# Mandatory settings
wsrep_on=ON
wsrep_provider=/usr/lib64/galera/libgalera_smm.so
wsrep_cluster_address='gcomm://{GLR1 IP},{GLR2 IP},{GLR3 IP}'
wsrep_cluster_name='galera'
wsrep_node_address='{GLR1 IP}
wsrep_node_name='GLR1'
wsrep_sst_method=rsync
binlog_format=row
default_storage_engine=InnoDB
innodb_autoinc_lock_mode=2
bind-address=0.0.0.0

[GLR2]↴

$ vim /etc/my.cnf.d/server.cnf
[galera]
# Mandatory settings
wsrep_on=ON
wsrep_provider=/usr/lib64/galera/libgalera_smm.so
wsrep_cluster_address='gcomm://{GLR1 IP},{GLR2 IP},{GLR3 IP}'
wsrep_cluster_name='galera'
wsrep_node_address='{GLR2 IP}
wsrep_node_name='GLR2'
wsrep_sst_method=rsync
binlog_format=row
default_storage_engine=InnoDB
innodb_autoinc_lock_mode=2
bind-address=0.0.0.0

[GLR3]↴

$ vim /etc/my.cnf.d/server.cnf
[galera]
# Mandatory settings
wsrep_on=ON
wsrep_provider=/usr/lib64/galera/libgalera_smm.so
wsrep_cluster_address='gcomm://{GLR1 IP},{GLR2 IP},{GLR3 IP}'
wsrep_cluster_name='galera'
wsrep_node_address='{GLR3 IP}
wsrep_node_name='GLR3'
wsrep_sst_method=rsync
binlog_format=row
default_storage_engine=InnoDB
innodb_autoinc_lock_mode=2
bind-address=0.0.0.0

ステップ4

すべてのサーバーを再起動します。

ステップ5

GLR1でのみ次のコマンドを使用し、GLR2とGLR3でmariadb.serviceを再起動します。

$ galera_new_cluster
$ sevice mysql start

ステップ6

質問で気付いたように、次のコマンドを使用してサーバー間の接続をテストできます。

$ mysql -u root -p -e "SHOW STATUS LIKE 'wsrep%'"

または、クラスタサイズを確認します。

$ mysql -u root -p -e "SHOW GLOBAL STATUS LIKE 'wsrep_cluster_size';"

ステップ7

一方、上記のすべての手順を完了した後、これを使用できます Article 単一ノードの障害が2つを使用したい場合に他のノードが機能しなくなる原因を回避する方法についてgaleracluster Webサイトから提供されます-NODEクラスター。

利用できる2つのソリューションがあります。

  • bootstrappc.boostrapwsrep Provider option）を使用して、生き残ったノードで新しいプライマリコンポーネントを形成できます。これを行うには、データベースクライアントで次のコマンドを実行します。

    SET GLOBAL wsrep_provider_options='pc.bootstrap=YES';

    これにより、残っているノードが新しいプライマリコンポーネントとしてブートストラップされます。他のノードがオンラインに戻るか、このノードとのネットワーク接続を回復すると、状態の転送が開始され、このノードに追いつきます。

  • ノードを引き続き動作させたい場合は、pc.ignore_sbwsrep Providerオプションを使用できます。これを行うには、データベースクライアントにログインし、次のコマンドを実行します。

    SET GLOBAL wsrep_provider_options='pc.ignore_sb=TRUE';

    ノードは更新の処理を再開し、スプリットブレインの状況が疑われる場合でも継続します。

注警告：マルチマスターセットアップでは、前述のスプリットブレイン状況のリスクがあるため、pc.ignore_sbを有効にするのは危険です。ただし、マスター/スレーブクラスターでの処理は単純化されます（特に2つのノードのみを使用する場合）。

上記のソリューションに加えて、Galera Arbitratorを使用することで状況を完全に回避できます。 Galera Arbitratorは、クォーラム計算で奇数ノードとして機能します。つまり、2ノードクラスタの1つのノードでGalera Arbitratorを有効にすると、他のノードで障害が発生したりネットワーク接続が失われたりしても、そのノードはプライマリコンポーネントのままになります。

4
FarazX