Percona XtraDBクラスターとMySQLレプリケーション
Percona xtradbクラスターで3ノードマルチマスターレプリケーションをセットアップしましたが、完全に機能します。
今私はいつものようにレプリケーションを設定するいくつかの読み取り専用スレーブを追加しようとしましたが、binlogには新しい挿入が含まれていないようです、
データベースのマスターにbinlog_do_dbを設定しました。スレーブはログの位置はマスターの位置と同じですが、新しいデータはありませんと言っています。
Xtradbクラスターでレプリケーションを行う特別な方法はありますか？
binlogに新しい挿入が含まれていないようです
Binlogにそれらが実際には含まれていないと言っているのかどうか、そして mysqlbinlog でこれを確認したのか、それともそうではないように見えます、それらは複製しないため。
PXC ニーズlog_slave_updatesは、非同期スレーブのマスターとして機能するノードでオンになっています。それ以外の場合、すべてがマスターのバイナリログに書き込まれるわけではありません。これは、マスターとしての通常のMySQLサーバーとは大きく異なります。この場合、log_slave_updatesは何もしません（マスターが実際に別のマスターのスレーブでない限り）。
それ以外の場合は、replicate_do_dbとbinlog_do_dbとそれらに関連するすべてのオプションを構成から削除してから、それらを脳から削除します。それらがあなたの睡眠中にどのように機能するかを正確に知らない限り、それらは決して追加されるべきではありません。最も単純で、はるかに信頼性の高いレプリケーション構成は、これからも常に、すべてをレプリケートします。これがデフォルトです。
スレーブのbinlog_formatを忘れてください。 絶対にスレーブ自体が他の対象スレーブを持たない限り、そしてマスターがROWフォーマットを使用している場合を除き、違いはありません、スレーブがサブテンドスレーブで構成されている場合、スレーブはstillROW形式でログインします。また、スレーブのbinlogs（リレーログと混同しないでください）は、スレーブでlog_slave_updatesが有効になっていない限り、アップストリームマスターから受信したステートメントをログに記録しません。
同じことがinnodb_flush_log_at_trx_commitにも当てはまります。実際の複製には影響しません。これは、ACIDコンプライアンスとパフォーマンスの間のトレードオフを決定する設定です。
バイナリログ形式：Percona XtraDB Cluster（PXC）は binlog_formatROWのように、すべての読み取り専用スレーブにもその設定が必要です。
binlog_do_db：特定のデータベースのすべてのオプションのみを記録します。それにもかかわらず、これは時々誤解されているオプションです。 レプリケーションがどのように混乱するかについては、mysqlperformanceblog からこのブログエントリをお読みください。
ROWベースのバイナリログの binlog_do_db について
行ベースのロギング。ロギングはデータベースdb_nameに制限されています。 db_nameに属するテーブルへの変更のみがログに記録されます。デフォルトのデータベースはこれに影響を与えません。サーバーが--binlog-do-db = salesで起動され、行ベースのロギングが有効であり、次のステートメントが実行されたとします。
USE prices; UPDATE sales.february SET amount=amount+100;Salesデータベースの2月のテーブルに対する変更は、UPDATEステートメントに従ってログに記録されます。これは、USEステートメントが発行されたかどうかに関係なく発生します。ただし、行ベースのログ形式と--binlog-do-db = salesを使用している場合、次のUPDATEによる変更はログに記録されません。
USE prices; UPDATE prices.march SET amount=amount-25;USE価格ステートメントがUSE販売に変更されても、UPDATEステートメントの影響はバイナリログに書き込まれません。
行ベースのロギングとは対照的に、ステートメントベースのロギングの--binlog-do-db処理におけるもう1つの重要な違いは、複数のデータベースを参照するステートメントに関して発生します。サーバーが--binlog-do-db = db1で起動され、次のステートメントが実行されたとします。
USE db1; UPDATE db1.table1 SET col1 = 10, db2.table2 SET col2 = 20;ステートメントベースのロギングを使用している場合、両方のテーブルへの更新はバイナリログに書き込まれます。ただし、行ベースのフォーマットを使用する場合、table1への変更のみがログに記録されます。 table2は別のデータベースにあるため、UPDATEによって変更されません。ここで、USE db1ステートメントの代わりに、USE db4ステートメントが使用されていたとします。
USE db4; UPDATE db1.table1 SET col1 = 10, db2.table2 SET col2 = 20;この場合、ステートメントベースのロギングを使用すると、UPDATEステートメントはバイナリログに書き込まれません。ただし、行ベースのロギングを使用すると、table1への変更はログに記録されますが、table2への変更はログに記録されません。つまり、-binlog-do-dbで指定されたデータベース内のテーブルへの変更のみがログに記録され、デフォルトの選択が記録されます。データベースはこの動作に影響を与えません。
これに基づいて、PXCでbinlog_do_dbを実行するのではなく、スレーブで replicate_do_db を実行することをお勧めします。