帯域幅の問題に対処するために、MySQL 5.0レプリケーションで何ができますか？

リモートマスターの読み取り専用スレーブとして機能するMySQLサーバー5.1インスタンスで構成されたクライアントPC（Win）で実行するアプリケーションを開発しています。リモートマスターには多数のスキーマがありますが、クライアントごとに1つしか必要ないため、my.iniでreplication-do-db設定を指定して、クライアントが必要とするスキーマのみを複製します。レプリケーションは機能しますが、クライアントがデータ使用量によって課金される3Gワイヤレス経由でのみインターネットアクセスが利用できる世界の地域に入ると、データプランの制限をすぐに超えて、高価な問題が発生します。

私が理解しているように、MySQLはすべてのスキーマのすべてのトランザクションを単一のbinlogファイルに書き込みます。つまり、各クライアントはマスターのすべてのスキーマで実行されるすべてのトランザクションをダウンロードし、ダウンロードしたら、レプリケーションごとにデータベースフィルターを適用する必要があります。クライアントのmy.iniファイルのdo-db設定。

この非効率性を最小限に抑えるために、slave_compressed_protocol = 1の設定を使用しました。これにより、送信データが50％削減されるように見えますが、クライアントのデータ制限をすぐに超えて3Gの請求額が発生します。

私がこれに直面しているのは自分だけだとは想像できないので、x = yを設定することでこれを達成する方法についてたくさんの答えが得られると確信しています。ただし、このような設定のドキュメントも、推奨されるアプローチも見つかりません。

これまでのところ、可能な解決策に対する私の考えは、フィードバックまたは代替ルートを提供してください：

1. 各スキーマに「プロキシ」スレーブを設定します（異なるボックス、または異なるMySQLインスタンス/ポートを持つ同じボックスに）
2. クライアントが複製したい1つのデータベースのみをreplicate-do-dbにプロキシスレーブを設定します。
3. クライアントのMySQLインスタンスを適切なプロキシスレーブのスレーブとして構成します。

これがなければならないだけで自分のスキーマのビンログデータを引っ張って、クライアントにつながります。欠点（私が知る限り）は、セットアップの複雑さを劇的に増加させ、おそらくより脆弱にすることです。

考え？このアプローチは機能しますか？

RedHatでMySQL 5.0サーバーを実行していることに注意してください。ただし、ソリューションが生成される場合は5.5にアップグレードできます。

提案＃1：配布マスターを使用する

配布マスターは、log-binが有効、log-slave-updatesが有効なmysqlスレーブであり、BLACKHOLE Storage Engineを持つテーブルのみが含まれます。replicate-do-dbをディストリビューションマスターに適用し、バイナリログに記録するDBスキーマのみを含むバイナリログをディストリビューションマスターで作成できます。このようにして、配布マスターからの発信バイナリログのサイズを縮小します。

次のように配布マスターをセットアップできます。

1. --no-dataオプションを使用してスキーマのみのダンプを生成し、データベースをmysqldumpします。
2. スキーマのみのダンプを配布マスターに読み込みます。
3. 配布マスターのすべてのテーブルをBLACKHOLEストレージエンジンに変換します。
4. 実際のデータを持つマスターからディストリビューションマスターへのレプリケーションをセットアップします。
5. replicate-do-dbオプションをディストリビューションマスターの/etc/my.cnfに追加します。

手順2および3では、スキーマのみのダンプを編集し、ENGINE = MyISAMおよびENGINE = InnoDBをENGINE = BLACKHOLEに置き換えてから、編集したスキーマのみのダンプを配布マスターにロードすることもできます。

手順3でのみ、配布マスターですべてのMyISAMおよびInnoDBテーブルのBLACKHOLEへの変換をスクリプト化する場合は、次のクエリを実行してテキストファイルに出力します。

mysql -h... -u... -p... -A --skip-column-names -e"SELECT CONCAT('ALTER TABLE ',table_schema,'.',table_name', ENGINE=BLACKHOLE;') BlackholeConversion FROM information_schema.tables WHERE table_schema NOT IN ('information_schema','mysql') AND engine <> 'BLACKHOLE'" > BlackholeMaker.sql

テーブルのBLACKHOLEストレージエンジンへの変換をスクリプト化することに対する追加のボーナスは、MEMORYストレージエンジンテーブルも変換されることです。MEMORYストレージエンジンテーブルはデータストレージ用のディスク領域を占有しませんが、メモリを占有します。MEMORYテーブルをBLACKHOLEに変換すると、Distribution Masterのメモリが整理されます。

DDLをDistribution Masterに送信しない限り、クライアントに必要なDB情報のみをレプリケートさせる前に、必要なDML（INSERT、UPDATE、DELETE）を送信できます。

私はすでに別のStackExchangeサイトで、Distribution Masterの使用について説明する投稿を書いています。

提案＃2：より小さなバイナリログとリレーログを使用する

max_binlog_sizeを途方もなく小さな値に設定すると、binlogを収集して小さなチャンクで出荷できます。リレーログのサイズを設定するための別のオプションmax_relay_log_sizeもあります。max_relay_log_size = 0の場合、デフォルトでmax_binlog_sizeに設定されている値が使用されます。

提案＃3：準同期レプリケーションを使用する（MySQL 5.5のみ）

メインデータベースと複数のディストリビューションマスターをMySQL 5.5としてセットアップします。メインデータベースがバイナリログを配布マスターに迅速に出荷できるように、半同期レプリケーションを有効にします。すべてのスレーブがディストリビューションマスターである場合、半同期レプリケーションまたはMySQL 5.5は必要ない場合があります。ディストリビューションマスター以外のスレーブのいずれかにレポート、高可用性、パッシブスタンバイ、またはバックアップの目的で実際のデータがある場合は、半同期レプリケーションと組み合わせてMySQL 5.5を使用します。

提案＃4：行ベースではなくステートメントベースのバイナリロギングを使用する

SQLステートメントがテーブル内の複数の行を更新する場合、Statement-Based Binary Logging（SBBL）はSQLステートメントのみを保存します。行ベースバイナリロギング（RBBL）を使用した同じSQLステートメントは、各行の行の変更を実際に記録します。これにより、SQLステートメントを送信すると、RBBLを介してSBBLを実行するバイナリログのスペースが節約されることが明らかになります。

別の問題は、テーブル名の前にデータベースが付加されているreplicate-do-dbとともにRBBLを使用することです。これは、スレーブ、特にディストリビューションマスターに適していません。したがって、すべてのDMLにデータベースとテーブル名の前にピリオドがないことを確認してください。

max_binlog_sizeは無関係である必要があります-binlogデータは継続的にストリーミングされます。

「Distribution Master」に関する注意-これは「単一障害点」です。つまり、それが死んだ場合、それを超えるすべてのスレーブはデータを受信せず、リレーの再構築が必要になります。

SBR vs RBR-クエリに依存します。どちらかが他よりも良い場合も悪い場合もあります。

配布マスターを実際のマスターと同じマシンに配置するか、マスターの「近くにある」マシンに配置します。個別のポートを使用して、インスタンスを個別に保ちます。