Galeraレプリケーションに Primary Key が必要な理由

この記事は最終更新から6年以上経過しています。内容が古くなっている可能性があります。

はじめに

Galera Cluster(およびそのブランチ)には、「全テーブルにPrimary Keyが設定されている必要がある」という制約事項があります。これは以下のように公式リファレンスマニュアルでも明言されています。

DIFFERENCES FROM A STANDALONE MYSQL SERVER

Do not use tables without a primary key.

MariaDB Galera Cluster – Known Limitations

All tables should have a primary key (multi-column primary keys are supported).

特に Percona XtraDB Cluster(以下、PXC)の場合、PXC5.7で「PXC Strict Mode」という機能を実装し、PKがないテーブルが作られないよう厳密にチェックを行っています。

PXC Strict Mode

At runtime, any undesirable operation performed on a table without an explicit primary key is denied and an error is logged.

では、なぜGaleraでは必ずPKを付けなければいけないのでしょうか?本記事では、その理由について調べてみたいと思います。

マニュアルを参照

実は上記の疑問の答えは同じマニュアルの中にしっかりと書かれています。
以下がその答えとなりますが、後の章で解説いたします。

DIFFERENCES FROM A STANDALONE MYSQL SERVER

When tables lack a primary key, rows can appear in different order on different nodes in your cluster. As such, queries like SELECT…LIMIT… can return different results. Additionally, on such tables the DELETE statement is unsupported.

MariaDB Galera Cluster – Known Limitations

DELETE operations are unsupported on tables without a primary key. Also, rows in tables without a primary key may appear in a different order on different nodes.

結論

「Galera ClusterではPKが必須」という制限は、「Galera Clusterではbinlog_format = ROW の設定が必須」というもう一つの制限事項とセットになっています。
Galera Clusterに限らず、MySQLでも「ROW-based replication では、PKの設定が推奨される」というのは一般的に語られており、そのルールがGaleraレプリケーションにおいては明文化されているに過ぎないのです。

それでは、PK無し + ROW-based な環境だとどのような問題が発生するのでしょうか?それは、以下に述べるような事象です。

  • レコードの順番が、各ノード間で異なってしまう
  • レプリケーションされたイベントで不要なテーブルスキャンが実行され、大幅なレプリケーション遅延が発生することがある

検証

上に挙げた問題について、以前作成したPXC検証環境で確認してみましょう。

目次

【検証1】レコード順の相違について

1. Node1にログインして、検証用のテーブル・データを作成します

2. Node1 → Node2 の順番でトランザクションを開始します

3. Node2 → Node1 の順番でCOMMITします

4. PKテーブルでは Node1/Node2 のレコード順が同じになります

5. 非PKテーブルでは Node1/Node2 のレコード順が異なります

コミットのタイミングでレコード順が異なってしまうため、 ノード間でデータの整合性が保てなくなってしまいます。

【検証2】不要なテーブルスキャンについて

1. Node1でテストデータを作成します

2. 非PKテーブルを作成し、データをコピーします

3. Node1のPKテーブルを更新しNode2にいつ反映されるか確認する

4. 非PKテーブルでも同じことを行う

t1_PKの場合に比べ、t1_no_PKの方は中々更新が反映されないことが確認できます

補足

ちなみに、Galera Cluster において binlog_format = ROW は必須ですが、log_bin(バイナリログ)の有効化は必須ではありません。つまり、Galera Cluster は Write-Set にROW形式のイベントを直接出力しており、それは内部的処理なので詳細は確認できません。

しかし、バイナリログは必須ではないものの、以下の記事で述べた通り基本的に有効にすることを推奨します。

Galera Clusterでバイナリログは有効にすべきか

Let’s Enjoy Galera Life !!


Percona

 

スマートスタイルTECHブログについて

スマートスタイルTECHブログでは、日頃オープンソースデータベースのサポート業務に従事している有資格者で構成された技術サポートチームがPerconaに関する技術情報を発信しています。データベースのお困りごとはお気軽にご相談下さい。

よかったらシェアしてね!
  • URLをコピーしました!
目次