マスター/スレーブレプリケーションの代わりにGalera Clusterを使用する場合の欠点は何ですか？
通常のマスター/スレーブレプリケーションの代わりにGalera Clusterを使用する場合の欠点は何ですか？ Galeraの0スレーブラグタイム、同期レプリケーション、および単一障害点がないことは非常に魅力的であるように見えますが、なぜGaleraクラスターが一般的ではないのですか
他の最適化と同様に、すべてのワークロードに適合するわけではありません。
Galeraは、トランザクション率が高い場合、またはトランザクションが多くの行を更新する場合に圧倒されます。また、クラスターが同期されているため、アプリケーションでCOMMITの遅延が発生する可能性があります。
Galeraは他のノードも同期的に更新しません。ワークセットを同期的に送信するだけです。このように、これは準同期モードでの標準的なレプリケーションに少し似ています。したがって、別のクラスターノードから古いデータを読み取る可能性はまだわずかです。ワークセットのキューがデータベースを更新するまでSELECTを強制的に待機するように設定できるオプションがありますが、これはSELECTに遅延があることを意味します。また、直感に反するように見えるSELECTでデッドロックが発生する可能性さえあります。
ガレラは素晴らしいですが、万能のテクノロジーではありません。非同期複製を使用する理由はまだあります。
ガレラのいくつかの欠点は次のとおりです。
- ストレージエンジンのサポート：InnoDB/XtraDBに限定（MyISAMの実験的サポートも）
- OSサポート：Linux/Unixに似たOsesのみ
注意すべきいくつかの制限もありますが、おそらく回避できます。
- デフォルト（Total Order Isolation）では、DDL操作は完了するまでクラスター全体をブロックします。
- すべてのテーブルには、単一列または複数列の明示的な主キーが必要です
- ロック：一部のタイプの明示的ロックはサポートされていません。
詳細については、 Codership （および ここ DDLのブロックについて）、 MariaDB 、および Percona の詳細を参照してください。
EDIT：また、Galeraなどの密結合データベースクラスタには、固有の問題に起因する問題があるため、地理的に分散したノードを含めるべきではないと主張する人もいます。ネットワーク層の信頼性が低い。代わりに、非同期ソリューションをこれらの場合に使用する必要があります。参照： MySQLの高可用性を実行しない方法：地理的Node Galeraベースのレプリケーションの誤用による配布 。それにもかかわらず、Galeraブログ それについて述べています （2015）：
地理的に分散されたデータベースクラスタを構築するケースは強力です。レプリケーションへのGaleraのアプローチと製品の特定の機能により、複数のデータセンターにまたがるGaleraクラスターを構築することが実際に可能になり、複数のユーザーがそのようなクラスターをすでに運用環境に持っています。