マスター/スレーブレプリケーションの代わりにGalera Clusterを使用することの欠点は何ですか？

通常のマスター/スレーブレプリケーションの代わりにGalera Clusterを使用することの欠点は何ですか？Galeraの0スレーブラグタイム、同期レプリケーション、および単一障害点がないことは非常に魅力的であるように思われますが、なぜGaleraクラスターは一般的ではないのですか？

他の最適化と同様に、すべてのワークロードに適合するわけではありません。

Galeraは、高いレートのトランザクション、またはトランザクションが多数の行を更新するときに圧倒される可能性があります。また、クラスターが同期されると、アプリケーションでCOMMITの遅延が発生する可能性があります。

Galeraは他のノードも同期的に更新しません。ワークセットを同期的に送信するだけです。この方法では、準同期モードでの標準的なレプリケーションに少し似ています。したがって、別のクラスターノードから古いデータを読み取る可能性はまだわずかです。ワークセットのキューがデータベースを更新するまでSELECTを強制的に待機させるオプションを設定できますが、これはSELECTに遅延があることを意味します。SELECTでデッドロックが発生する可能性もありますが、これは直感に反しているようです。

Galeraは素晴らしいですが、万能のテクノロジーではありません。非同期レプリケーションを使用する理由はまだあります。

ガレラのいくつかの欠点は次のとおりです。

• ストレージエンジンのサポート：InnoDB / XtraDBに限定（さらにMyISAMの実験的サポート）
• OSサポート：Linux / Unix-like Osesのみ

注意すべきいくつかの制限もありますが、おそらく回避することができます：

• デフォルト（Total Order Isolation）では、DDL操作は完了するまでクラスター全体をブロックします
• すべてのテーブルには、単一列または複数列の明示的な主キーが必要です。
• ロック：いくつかのタイプの明示的なロックはサポートされていません。

詳細については、Codership（およびDDLのブロックに関するこちら）、MariaDB、およびPerconaの詳細を参照してください。

編集：また、ネットワーク層の固有の信頼性に起因する問題のために、Galeraなどの密結合データベースクラスターは地理的に分散したノードを持つべきではないと主張する人もいます。代わりに、これらの場合には非同期ソリューションを使用する必要があります。参照：ガレラベースのレプリケーション誤用と地理ノード分布：MySQLの高可用性をしない方法。それでも、Galeraブログには次のように記載されています（2015）：

地理的に分散したデータベースクラスターを構築する場合は強力です。複製に対するGaleraのアプローチと製品の特定の機能により、複数のデータセンターにまたがるGaleraクラスターの構築が実用的になり、複数のユーザーがそのようなクラスターを既に運用しています。