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

Question

私は、リモートマスターに読み取り専用スレーブとして機能するMySQL Server 5.1インスタンスで構成されているクライアントPC（WIN）で実行するアプリケーションを開発しています。リモートマスターには数十のスキーマがありますが、クライアントごとに1つしか必要ないので、 複製-DO-DB My.iniに設定して、クライアントが必要とするスキーマのみを再現します。レプリケーションは機能しますが、クライアントがデータ使用量によって充電する3Gワイヤレスでのみインターネットアクセスが利用できる世界の地域に入ると、データプランの制限を迅速に超えて高価な問題に直面します。

私が理解しているように、MySQLはすべてのスキーマのすべてのトランザクションを単一のビンログファイルに書き込みます。つまり、各クライアントはマスター上のすべてのスキーマで実行されるすべてのトランザクションをダウンロードする必要があります。 複製-DO-DB クライアントのmy.iniファイルの設定。

この非効率性を最小限に抑えるために、私は採用しました Slave_compressed_protocol = 1 設定は、送信されたデータを50％削減しているように見えますが、それでもクライアントがデータ制限3G請求書をすばやく超える原因となります。

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

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

---

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

これ したほうがいい その結果、クライアントはスキーマのビンログデータのみを引っ張ります。 （私が知る限り）マイナス面は、セットアップの複雑さを劇的に増加させ、より脆弱にする可能性が高いことです。

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

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

Answer 1

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

配布マスターは、log-binが有効になり、ログスレーブアップデートが有効になっているMySQLスレーブであり、 ブラックホールストレージエンジン. 。 Replicate-Do-DBを配布マスターに適用し、Binloggedが必要なDBスキーマのみを含む配布マスターにバイナリログを作成できます。 このようにして、配布マスターからの発信ビンログのサイズを縮小します。

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

1. MySQLDUMP-No-Dataオプションを使用してデータベースを使用して、スキーマのみのダンプを生成します。
2. スキーマのみのダンプを配布マスターにロードします。
3. 配布マスターのすべてのテーブルをブラックホールストレージエンジンに変換します。
4. 実際のデータを持つマスターからの配布マスターへのレプリケーションをセットアップします。
5. 分布マスターの/etc/my.cnfにReplicate-Do-dbオプションを追加します。

手順2と3の場合、スキーマのみのダンプを編集し、エンジン= myisamとエンジン= innodbをエンジン=ブラックホールで置き換え、その編集したスキーマのみのダンプを配布マスターにロードすることもできます。

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

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

テーブルのブラックホールストレージエンジンへの変換をスクリプト化するための追加ボーナスは、 メモリストレージエンジン テーブルも変換されます。メモリストレージエンジンテーブルは、データストレージ用のディスクスペースを占有しませんが、メモリを取り上げます。メモリテーブルをブラックホールに変換すると、配布マスターのメモリが整理されています。

DDLをディストリビューションマスターに送信しない限り、クライアントに必要なDB情報だけを複製できるようにする前に、DML（挿入、更新、削除）を送信できます。

私はすでに、ディストリビューションマスターの使用について議論する別のstackexchangeサイトに投稿を書きました.

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

設定した場合 max_binlog_size 途方もなく小さいものには、ビンログを収集して小さな塊で出荷することができます。リレーログのサイズを設定するための個別のオプションもあります。 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ステートメントがテーブル内の複数の行を更新する場合、ステートメントベースのバイナリロギング（SBBL）はSQLステートメントのみを保存します。行ベースのバイナリロギング（RBBL）を使用した同じSQLステートメントは、各行の行の変更を実際に記録します。これにより、SQLステートメントを送信することで、RBBLを介してSBBLを使用するバイナリログのスペースを節約することが明らかになります。

別の問題は、テーブル名にデータベースが準備されているReplicate-Do-DBと組み合わせてRBBLを使用することです。. 。これは、特に配布マスターにとっては、奴隷にとっては良いことではありません。したがって、すべてのDMLにAAデータベースとテーブル名の前に期間がないことを確認してください。

Answer 2

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

「配布マスター」について注意してください - それは「失敗の単一のポイント」です。つまり、死んだ場合、それ以降のすべての奴隷はデータを受信しず、リレーの再構築には仕事が必要です。

SBR対RBR-クエリに依存します。どちらかが他のものよりも良くも悪くもあります。

配布マスターを本物のマスターと同じマシン、またはマスターの「近く」のマシンに置きます。個別のポートを使用して、インスタンスを分離します。