3つのうち1つだけのGaleraノードへの読み取りと書き込みのバランスをとるHAProxyがあります。
このバランシングが正常に機能する場合、パラメータwsrep_log_conflicts
およびcert.log_conflicts
は、競合やエラーをログに記録しないでください。/var/logファイルシステムがメッセージでいっぱいになりませんか?
wsrep_log_conflicts
とcert.log_conflicts
を有効にすることの欠点は何ですか?デフォルトで有効になっていないのはなぜですか?
詳細を教えてください。私が見つけたのは マルチマスターの競合への対処
最後に、wsrep_log_conflictsおよびcert.log_conflictsを介して競合ログ機能を有効にできます。
# Enable Conflict Logging
wsrep_log_conflicts=ON
wsrep_provider_options="cert.log_conflicts=YES"
これらのパラメーターにより、データベースサーバーでさまざまな形式の競合ログが有効になります。オンにすると、ノードは、競合が発生したテーブルとスキーマの名前、競合を発生させたキーの実際の値など、発生した競合に関する追加情報をログに記録します。
7:51:13 [Note] WSREP: trx conflict for key (1,FLAT8)056eac38 0989cb96:
source: cdeae866-d4a8-11e3-bd84-479ea1a1e941 version: 3 local: 1 state:
MUST_ABORT flags: 1 conn_id: 160285 trx_id: 29755710 seqnos (l: 643424,
g: 8749173, s: 8749171, d: 8749171, ts: 12637975935482109) <--X-->
source: 5af493da-d4ab-11e3-bfe0-16ba14bdca37 version: 3 local: 0 state:
APPLYING flags: 1 conn_id: 157852 trx_id: 26224969 seqnos (l: 643423,
g: 8749172, s: 8749171, d: 8749170, ts: 12637839897662340)
Galeraクラスターでは、どのノードもマスターノードの役割を果たすことができます。
このようなノードは、DML(INSERT、UPDATE、およびDELETE)を実行できます。
DMLステートメントが複数のマスターノードに分散していて、同じテーブルをターゲットにしている場合は、ログの競合を予期する必要があります。どうして ?
Galera wsrepライブラリは、クラスター内のすべてのノードがDMLの変更をコミットする準備ができている場合にコミットするように設計されています。 1つのノードでそれができない場合、すべてのノードでコミットを放棄する必要があります。それは基本的にオールオアナッシングコミットです。
参照したドキュメント の下部を見ると、WORKING AROUND MULTI-MASTER CONFLICTS
という見出しの下にログの競合を最小限に抑えるための提案があります。
Galera Clusterはマルチマスターの競合を自動的に解決しますが、発生の頻度を最小限に抑えるために実行できる手順があります。
- ホットスポットを分析し、デッドロック例外をキャッチするようにアプリケーションロジックを変更できるかどうかを確認します。
- Wsrep_retry_autocommitを使用して、ノードレベルでロジックの再試行を有効にします。
- マスターノードの数を制限するか、マスタースレーブモデルに切り替えます。
注ホットスポットテーブルへのアクセスを除外できる場合は、ホットスポットテーブルへの書き込みのみをマスタースレーブとして扱うだけで十分です。 。
したがって、あなたの質問に答えるには、デッドロックをキャッチしたときにコードの書き直し、自動コミットの調整、1つのマスターノードへの書き込みが必要になる可能性があるため、これらの提案を実装することは欠点になります(これにより、Galeraクラスターが書き込みのボトルネックになる可能性があります3ノードをはるかに超えてスケールを書き込まないでください)。
書き込みが多いクラスターがあり、ログを頻繁に検査する必要がある可能性があるため(競合が発生しない場合でも)、オプションはデフォルトではおそらく有効になっていません。したがって、wsrep_log_conflictsとcert.log_conflictsを有効にすることがチューニングの責任になります。
この情報は、DBAにとって重要ではない可能性があります。アプリケーションが競合を正しく処理している場合、それらをログに記録する必要はありません。それは予想される振る舞いでしょう。特定の問題をデバッグしている場合にのみ、このレベルのログを有効にします。そうしないと、ログに大量のスパムが生成されます。