こんにちは。cloudpack の 脳筋 (岸上) です。

MariaDB Galera Cluster – Known Limitations の日本語訳です。

ありがとう同僚のInoiうじそしてGoogle翻訳こんにゃく

MariaDB Galera Cluster既知の問題

この記事ではMariaDB Galera Clusterの既知の問題と制約に関する情報を記載しています。

codership.comからの制限

  • 現在レプリケーションはInnoDBのみ動作します。 他のシステム(mysql.)テーブルなどのテーブルへの書き込みはレプリケーションされません （この制限は暗黙的にmysql.テーブルを変更するユーザの作成などのDDLステートメントを除外し、レプリケーションします） MyISAMはwsrep_replication_myisamシステム変数で実験的なサポートが行われています。
  • LOCK TABLES, FLUSH TABLES {explicit table list} WITH READ LOCK, (GET_LOCK(), RELEASE_LOCK(),…)はサポートされません、これら制限を克服するにはトランザクションを正しく使用できる必要があります。 グローバルロックの操作FLUSH TABLES WITH READ LOCKはサポートしています。
  • 全てのテーブルに主キーが必要です(複数列の主キーはサポートされます) 主キーのないテーブルへのDELETEはサポートされません。 また、主キーのないテーブル内の行は別のノードに異なる順序で表示される可能性があります。
  • もしクエリログを有効にした場合はlog_output=FILEにする必要があります。
  • XAトランザクションはサポートしません。
  • トランザクションのサイズ。Galeraはトランザクションのサイズを明示的に制限中に、writeset は、単一のバッファーをメモリ常駐として処理されます非常に大きなトランザクション (負荷データなど） される可能性があります結果、ノードのパフォーマンスに影響を与えます。避けるため、wsrep_max_ws_rows および wsrep_max_ws_size システム変数 128 K にトランザクション行とデフォルト トランザクション サイズを 1 Gb に制限します。必要に応じて、ユーザー可能性がありますそれらの制限値を大きくしたいです。将来のバージョンは、トランザクションの断片化のサポートを追加します。

他に観察されたこと(特に順序関係なく)

  • もしあなたがstate transferとしてmysqldumpを使っていて、 どんな理由であれ(例：接続のためのデータベースアカウントを持っていなかったり、 必要な許可がなかったり) 失敗すると、サーバーエラーログには、「SQL SYNTAX error」と表示されるだろう。 自分が愚かだと思う必要はない、これはメッセージを伝えるための一風変わった方法なのだ。 (インチキのSQLの中の擬似ステートメントはこのエラーメッセージを含むだろう。)
  • どんな大きなトランザクションも使ってはいけない。100K行挿入するだけで、 200~300Mbを必要とするだろう。もっと悪いシナリオだと、500K行のために1.5Gb、 1M行のために3.5Mbだ。詳しくはMDEV-466をみてほしい。 (それが閉じられているように見えるだろうが、修復されたから閉じられていない。)
  • DDLが関係しているとき、ロックでは弱い。たとえば、もしあなたの DMLトランザクションがテーブルを使って、平行するDDLステートメントがスタートしたとき、 通常のMySQLのセットアップでは、メタデータロックを待つことになるだろう。しかしGaleraの コンテクストでは、すぐに実行される。たとえあなたがただ１つのノードを動かしていても、それを クラスター・ノードとして構成していれば、そうなる。MDEV-468も見てほしい。この現象は様々な 副作用を引き起こすかもしれず、その結果は未だ調査されていない。これは出来るだけ避けてほしい。
  • auto-incrementがシーケンシャルになることをあてにしてはいけない。 Galeraはコンフリクトしない独自のシーケンスを生み出すためのautoincrement incrementに 基づいたメカニズムをつかっているため、すべてのノードにおいてシークエンスにはギャップがある。
  • 時々、SHOW以外のほとんどすべてのステートメントにおいて、「Unknown command」エラーを 出し始めたり、他のサービスコマンドを出し始めたりするかもしれない。クラスタが分割されて、ノードが 小さい方のパートにあるとき、ネットワーク障害の間、ノードが一時的にお互いを見失ってるときに、 これは起こる。このエラーは恐ろしいが、サーバーがおかしくなったことを意味している訳ではない。 おかしくなるかもしれないということを意味しているに過ぎない。またこれは、ノードがstateを他のノードに 送った時にも起こった。
  • 一時的な分割の後、もしクラスタの”よい”方のノードがまだreachableで、 stateが修正されたら再同期が起きる。 その過程で、クラスタの”悪い”方のノードは、すべてのクライアントのコネクションを落とす。 それはかなり突然のものかもしれない。もしクライアントがアイドル状態で何かおかしなことが 起こっていることさえ知らなかった場合は特にそうだ。 隔離されたノードへの接続が回復された後、もしノード上のフローがあれば、 それが同期するのには長い時間がかる。その間は”よい”ノードは「 クラスタはすでに通常のサイズであり同期されている。」と言い、 再参加しているノードは「参加している(しかし同期はされていない)」と言う。 この接続は「unknown command」であり続ける。これも結局気にしない方がいい。
  • binlog_formatがstartupにおいてチェックされ、ROW (Binary Log Formats参照)であるときに限り、ランタイムに変更 することができる。binlog_formatをランタイムに変更してはいけない。 複製が失敗するだけでなく、他のすべてのノードをクラッシュさせる可能性がある。
  • もしあなたがstate transferのためにrsyncを使っていて、 state transferが終わる前にノードがクラッシュするなら、rsyncプロセス は永遠に宙ぶらりんで、ポートをふさいでノードの再起動ができないかもしれない。 この問題は「port in use」としてサーバーエラーログに現れる。 孤立したrsyncプロセスを見つけ、手動で殺すべきだ。
  • パフォーマンス：クラスタのパフォーマンスは、最も遅いノードのより高く ならない。しかし、もしただ一つのノードだけでも、そのパフォーマンスは、 standalone modeで同じサーバーを動かすときに比べてかなり低い (wsrep プロバイダーが無いとき)。これは大きいトランザクションに 特に当てはまる。
  • Windowsはサポートされていない。
  • レプリケーション・フィルタ：Galera cluster内では、レプリケーション・フィルタは 注意して扱ったほうがいい。InnoDB DML updates以外の基本的なルールとしては、以下のレプリケーション・ フィルタはGalera clusterにおいて有効でない:binlog-do-db , binlog-ignore-db, replicate-wild-do-db, replicate-wild-ignore-db しかし、replicate-do-db, replicate-ignore-dbは、InnoDBとMyISAMエンジンのDDLとDML には有効だ。 前述のように、レプリケーション・フィルタは注意してあつかった方がいい。不一致を生み出し、 レプリケーションが中止になるかもしれないからだ。(MDEV-421, MDEV-6229を参照)
  • FLUSH PRIVILEGESはレプリケートされない。
  • MariaDB Galera Cluster versions 5.5.40-galeraと10.0.14-galeraの前に、 クエリキャッシュは切る必要がある。
  • マスターがGaleraノードにスレーブとして動くレプリケーションをする非同期の レプリケーション設定において、並列レプリケーション(slave-parallel-threads > 1) は現在サポートされていない。(MDEV-6860参照)

元記事はこちらです。
「MariaDB Galera Cluster Known Limitationsを勝手に翻訳」