私は、3ノードのPercona XtraDBクラスターを手に入れました。mysqlcheck
によると、一部のテーブルが破損しています(一部のインデックスに含まれるエントリの数が間違っています)。
mydb.mytable
Warning : InnoDB: Index 'foo' contains 1393929 entries, should be 1393918.
Warning : InnoDB: Index 'bar' contains 1393921 entries, should be 1393918.
error : Corrupt
クラスタでOPTIMIZE TABLE
を実行するためのベストプラクティスは何ですか?
ユーザーのいないテスト環境でいくつかの実験を行いましたが、ノードのOPTIMIZE TABLE
が他のノードにその効果を自動的に伝播しないようです。これは、このコマンドがその内容や定義ではなく、インデックスとテーブルのストレージスペースを変更するという事実と一致しています。
各ノードの本番環境でコマンドを実行し、次のノードで実行する前にコマンドを完了させることの欠点は何ですか?
MySQL(および私の知る限りPercona XtraDB Cluster)が分散テーブルロックをサポートしていないことを考えると、ユーザーにはどのような影響がありますか?これにより、クラスターの一貫性が失われますか?
実行する必要がある場合 OPTIMIZE TABLE
PXCでは、バイナリログへの記録を3つの方法のいずれかで拒否することでこれを実現できます。
SET sql_log_bin = 0;
OPTIMIZE TABLE mydb.mytable;
SET sql_log_bin = 1;
OPTIMIZE NO_WRITE_TO_BINLOG TABLE mydb.mytable;
OPTIMIZE LOCAL TABLE mydb.mytable;
上記のいずれかを実行 OPTIMIZE TABLE
クラスターからの読み取りと書き込みのリダイレクト中に、一度に1つのPXCノードでのシナリオ。データが巨大な場合は、PXCノードをクラスターから削除し、 OPTIMIZE TABLE
必要に応じて、PXCをクラスターに追加します。
3ノードクラスタでは、pt-online-schema-changeを使用するのが最善の方法です。
次に以下を実行します。
pt-online-schema-change --execute --alter "ENGINE=InnoDB" h=localhost,u=root,p=password,D=dbname,t=tablename
any InnoDBシステムでのOPTIMIZE TABLE
のベストプラクティス:do not実行します。努力する価値はほとんどありません。
Galeraクラスター(PXCなど)で実行する必要がある場合は、ALTER
として扱います。小さいテーブルの場合は、TOI(簡単にするため)を使用します。 RSU(ブロックを回避するため)が大きい場合。
OPTIMIZE
はテーブルの内容を変更せず、レイアウトのみを変更するので、質問を完了させるための質問、不整合は関係ありません。