マネジメント

updated: 2018-09-21 07:55

マネジメント

OpenStack のデータベースをインストールして設定するとき、Galera Cluster を初期化できます。

前提条件

  • Galera Cluster をインストールしたデータベースホスト
  • 最小 3 ノード
  • ホスト間のファイアウォールなし
  • mysqld へのアクセス許可を設定した SELinux や AppArmor
  • wsrep_provider パラメーターに指定された libgalera_smm.so への適切なパス

クラスターの初期化

Galera Cluster では、Primary Component が、お互いにレプリケーションするデータベースサーバーのクラスターです。クラスターノードが Primary Component との接続性を失った場合、不整合なデータの作成や処理を避けるために、デフォルトで非稼働状態になります。

クラスターノードは、デフォルトで Primary Component の一部として起動しません。Primary Component において、レプリケーションと状態転送により、すべてのデータベースが同じ状態になります。

以下の手順を実行して、クラスターを起動します。

  1. 1 つのクラスターノードにおいて Primary Component を初期化します。init を使用するサーバーの場合、以下のコマンドを実行します。

    # service mysql start --wsrep-new-cluster

    systemd を使用するサーバーの場合、以下のコマンドを実行します。

    # systemctl start mariadb --wsrep-new-cluster

  2. データベースサーバーが起動すると、wsrep_cluster_size 状態変数を使用して、クラスター状態を確認します。データベースクライアントから、以下のコマンドを実行します。

    SHOW STATUS LIKE 'wsrep_cluster_size';

+--------------------+-------+
| Variable_name      | Value |
+--------------------+-------+
| wsrep_cluster_size | 1     |
+--------------------+-------+

  3. すべての他のクラスターノードにおいてデータベースサーバーを起動します。init を使用するサーバーに対して、以下のコマンドを実行します。

    # service mysql start

    systemd を使用するサーバーの場合、以下のコマンドを実行します。

    # systemctl start mariadb

  4. クラスターノードをどれか起動したとき、どれか 1 つにデータベースクライアントからログインして、wsrep_cluster_size 状態変数を再び確認します。

    SHOW STATUS LIKE 'wsrep_cluster_size';

+--------------------+-------+
| Variable_name      | Value |
+--------------------+-------+
| wsrep_cluster_size | 3     |
+--------------------+-------+

各クラスターノードが起動したとき、wsrep_cluster_address パラメーターに指定された IP アドレスを確認して、それで動作しているデータベースサーバーへのネットワーク接続性を確立しようとします。接続が確立されると、クラスターを同期するために必要となる状態転送を要求する、Primary Component に参加しようとします。

注釈

クラスターノードをどれか再起動する必要がある場合、実行できます。データベースサーバーが戻ってきたとき、Primary Component との接続を確立して、停止中に失った変更をすべて自身に適用します。

クラスターの再起動

各クラスターノードは、問題なく停止したり再起動したりできます。データベースが接続を失ったり、再起動したりしたとき、Primary Component と再接続されると、Galera Cluster は同期状態に戻ります。クラスター全体を再起動する必要があるとき、最も高度なクラスターノードを識別し、そのノードの Primary Component を初期化します。

最も高度なクラスターノードを見つけるために、各ノードの最新コミットのトランザクションにある seqnos を確認する必要があります。データベースディレクトリーにある grastate.dat ファイルを表示すると、これを見つけられます。

$ cat /path/to/datadir/grastate.dat

# Galera saved state
version: 3.8
uuid:    5ee99582-bb8d-11e2-b8e3-23de375c1d30
seqno:   8204503945773

代わりに、データベースサーバーが動作している場合、 wsrep_last_committed 状態変数を使用します。

SHOW STATUS LIKE 'wsrep_last_committed';

+----------------------+--------+
| Variable_name        | Value  |
+----------------------+--------+
| wsrep_last_committed | 409745 |
+----------------------+--------+

この値は各トランザクションによりインクリメントされます。ほとんどの高度なノードは、最大のシーケンス番号を持つため、ほとんど最新です。

設定のヒント

デプロイ戦略

Galera は、以下の方法のどれかにより設定できます。

  • 各インスタンスは、自身の IP アドレスを持ちます。

    OpenStack サービスは、利用できるものから 1 つを選択できるよう、これらの IP アドレスの一覧を用いて設定されます。

  • Galera は HAProxy の後ろで動作します。

    HAProxy は、受信リクエストを負荷分散して、すべてのクライアントに 1 つの IP アドレスを公開します。

    Galera の同期レプリケーションは、スレーブのラグがないことを保証します。フェイルオーバー手順は、アクティブなバックエンドがダウンしたことを HAProxy が検知すると、バックアップに切り替え、UP 状態になります。バックエンドが UP にならない場合、Galera クラスターが再び正常に再構成された場合のみ、フェイルオーバー手順が完了します。SLA は、通常 5 分以内です。

  • MySQL/Galera をアクティブ/パッシブモードで使用して、 SELECT ... FOR UPDATE のような形式のクエリーにおけるデッドロックを避けます (例えば、nova や neutron により使用されます)。この問題は、以下で議論されています。

HAProxy の設定

HAProxy に記載されているとおり、Galera Cluster へのクライアントアクセスを負荷分散するために、HAProxy を使用している場合、 clustercheck ユーティリティーを使用して、より良くヘルスチェックできます。

  1. clustercheck の設定ファイルを /etc/sysconfig/clustercheck に作成します。

    MYSQL_USERNAME="clustercheck_user"
MYSQL_PASSWORD="my_clustercheck_password"
MYSQL_HOST="localhost"
MYSQL_PORT="3306"

注釈

Ubuntu 16.04.1 の場合: clustercheck の設定ファイルを /etc/default/clustercheck に作成します。

  1. データベースクライアントにログインして、clustercheck ユーザーに PROCESS 権限を与えます。

    GRANT PROCESS ON *.* TO 'clustercheck_user'@'localhost'
IDENTIFIED BY 'my_clustercheck_password';

FLUSH PRIVILEGES;

    どれか 1 つのクラスターノードにおいてのみ実行する必要があります。Galera Cluster が、他のすべてのノードにユーザーを複製します。

  2. HAProxy モニターサービスの設定ファイルを /etc/xinetd.d/galera-monitor に作成します。

    service galera-monitor
{
   port = 9200
   disable = no
   socket_type = stream
   protocol = tcp
   wait = no
   user = root
   group = root
   groups = yes
   server = /usr/bin/clustercheck
   type = UNLISTED
   per_source = UNLIMITED
   log_on_success =
   log_on_failure = HOST
   flags = REUSE
}

  3. clustercheck の xinetd デーモンを起動します。 init を使用するサーバーの場合、以下のコマンドを実行します。

    # service xinetd enable
# service xinetd start

    systemd を使用するサーバーの場合、以下のコマンドを実行します。

    # systemctl daemon-reload
# systemctl enable xinetd
# systemctl start xinetd
updated: 2018-09-21 07:55
Creative Commons Attribution 3.0 License

Except where otherwise noted, this document is licensed under Creative Commons Attribution 3.0 License. See all OpenStack Legal Documents.

found an error? report a bug questions?