Percona XtraDB Cluster 5.7 のバグたち(修正済)
私はRDBで一番大事なのは、durability (永続性、整合性) だと思っている。
データの整合性は、気づくことが難しい。整合性を疑って、正しいデータと比較して初めて気づける。
気づいたときには影響が広くなっており、すでに取り戻せないデータが発生している・・・ということも有り得る。
Availability (可用性) や Performance (性能) は、問題が出たとしても、いろいろな手段でカバー可能であることは多い。
ということで、踏み抜いておいた(踏み抜いてしまった)PXCのdurabilityに関わるバグたちを紹介。
Wrong count if LOAD DATA used with GTIDs
https://jira.percona.com/browse/PXC-879
GTID を有効にしている状態で、かつ、LDI中にバイナリログのローテが入ると発動。
PXCにはパフォーマンスをあげるため、LDI時にデータを1万件ごとに小分けにしてコミットする機能が入っている。この機能にバグが潜んでいたようだ。
このバグを踏むと、例えば、31000件ロードしたら、LDIを実行したノードには31000件、正しく書き込まれる、
しかし、その他のノードでは1000件が失われ30000件だけ書き込まれる。
このバグは 5.7.20-29.24 で修正されている。
Node consistency compromized for simple INSERT INTO ... ON DUPLICATE KEY UPDATE workload
https://jira.percona.com/browse/PXC-2039
複数ノードに同時並列でINSERT INTO ~ ON DUPLICATE KEY UPDATEを行うとノード間データ不整合が発生。
このバグはパッチは出ているものの、まだパッケージとしてはリリースされていない。
次のリリースに取り込まれるであろう。
Transaction lost after recovery
https://jira.percona.com/browse/PXC-895
前提として、いわゆる durable (以下)なパラメータでPXCを運用している人のみが気にすべきバグである。
コピーする(SST)ため、crash recovery が必要なことは基本的にない。
Crash recovery が必要になるのは、全ノードがダウンした際だけである。
durable なパラメータで運用していない場合、全ノード ダウン時、少々データがロストするのはそもそも「仕様」である。
自分は durable で運用している。
複数のサーバが同時に死ぬことは、ほとんどありえないが、「ドミノ倒し」になることは有り得るからだ。
負荷やバグでノードが次々と死んでいくケースである。
実際、上記の1,2 のバグを踏んだ結果、残り1ノードになってしまうケースがある。
PXCではデータ不整合を検知すると、そのノードは自発的にシャットダウンする。
これ自体はデータ不整合が新たな不整合を生まないための仕組みで、望ましい挙動である。
しかし、結果として、1ノードになってしまうのだ。
このような状態でさらに想定外の事態が起きても、データロストしないよう durableな設定 で保険をかけているのだが、その保険が有効に機能してなかったという・・・
このバグも 5.7.20-29.24 で修正されている。
いずれも報告からすぐ修正がなされており、PXCのサポート体制は評価できる。
PXC5.7を利用している人は、最新バージョンに今すぐバージョンアップしよう。
(2のバグFIXはまだリリースされてないけど・・・)
データの整合性は、気づくことが難しい。整合性を疑って、正しいデータと比較して初めて気づける。
気づいたときには影響が広くなっており、すでに取り戻せないデータが発生している・・・ということも有り得る。
Availability (可用性) や Performance (性能) は、問題が出たとしても、いろいろな手段でカバー可能であることは多い。
ということで、踏み抜いておいた(踏み抜いてしまった)PXCのdurabilityに関わるバグたちを紹介。
1. LOAD DATA INFILE 利用時にノード間不整合
Wrong count if LOAD DATA used with GTIDs
https://jira.percona.com/browse/PXC-879
GTID を有効にしている状態で、かつ、LDI中にバイナリログのローテが入ると発動。
PXCにはパフォーマンスをあげるため、LDI時にデータを1万件ごとに小分けにしてコミットする機能が入っている。この機能にバグが潜んでいたようだ。
このバグを踏むと、例えば、31000件ロードしたら、LDIを実行したノードには31000件、正しく書き込まれる、
しかし、その他のノードでは1000件が失われ30000件だけ書き込まれる。
このバグは 5.7.20-29.24 で修正されている。
2. INSERT INTO ~ ON DUPLICATE KEY UPDATE でノード間不整合
Node consistency compromized for simple INSERT INTO ... ON DUPLICATE KEY UPDATE workload
https://jira.percona.com/browse/PXC-2039
複数ノードに同時並列でINSERT INTO ~ ON DUPLICATE KEY UPDATEを行うとノード間データ不整合が発生。
このバグはパッチは出ているものの、まだパッケージとしてはリリースされていない。
次のリリースに取り込まれるであろう。
3. Crash recovery 時にリカバリされないデータが発生
Transaction lost after recovery
https://jira.percona.com/browse/PXC-895
前提として、いわゆる durable (以下)なパラメータでPXCを運用している人のみが気にすべきバグである。
innodb_flush_log_at_trx_commit = 1PXCは複数ノードでデータを複製している。ノードが死んだ場合は、生きてるノードから最新のデータを
innodb_double_write = 1
コピーする(SST)ため、crash recovery が必要なことは基本的にない。
Crash recovery が必要になるのは、全ノードがダウンした際だけである。
durable なパラメータで運用していない場合、全ノード ダウン時、少々データがロストするのはそもそも「仕様」である。
自分は durable で運用している。
複数のサーバが同時に死ぬことは、ほとんどありえないが、「ドミノ倒し」になることは有り得るからだ。
負荷やバグでノードが次々と死んでいくケースである。
実際、上記の1,2 のバグを踏んだ結果、残り1ノードになってしまうケースがある。
PXCではデータ不整合を検知すると、そのノードは自発的にシャットダウンする。
これ自体はデータ不整合が新たな不整合を生まないための仕組みで、望ましい挙動である。
しかし、結果として、1ノードになってしまうのだ。
このような状態でさらに想定外の事態が起きても、データロストしないよう durableな設定 で保険をかけているのだが、その保険が有効に機能してなかったという・・・
このバグも 5.7.20-29.24 で修正されている。
いずれも報告からすぐ修正がなされており、PXCのサポート体制は評価できる。
PXC5.7を利用している人は、最新バージョンに今すぐバージョンアップしよう。
(2のバグFIXはまだリリースされてないけど・・・)