web-dev-qa-db-ja.com

MySQLレプリケーション-スレーブ更新

MySQLのマスター/スレーブ設定があります。スレーブデータベースに変更を加えた場合...

  1. それは何らかの方法で同期を台無しにしますか？
  2. 変更は、次のレプリケーションイベント中にマスターから上書きされますか？
  3. 上記（2）オプションを発生させることはできますか？
mysqlmysqladmin
5
user1249065

質問に対する回答は次のとおりです：

1）何らかの方法で同期が台無しになる

Answer：はい、スレーブがリレーログから読み取り、サーバーで更新を行うと、レプリケーションプロセスが台無しになります。例：スレーブに行が追加されていて、マスターに行がない場合、「INSERT INTO ...」クエリは失敗し、レプリケーションプロセスが停止する可能性があります。

2）変更は次のレプリケーションイベント中にマスターから上書きされますか？上記（2）オプションを実行できますか？

回答：いいえ。 pt-table-sync ツールを使用できる代替手段があります

このツールはデータを変更するため、最大限の安全性を確保するために、使用する前にデータをバックアップする必要があります。 --replicateまたは--sync-to-masterメソッドを使用してレプリケーションスレーブであるサーバーを同期すると、レプリケーションスレーブではなく、常にレプリケーションマスターで変更が行われます。これは一般に、レプリカをマスターと同期させる唯一の安全な方法です。

注：スレーブを read_only として設定することをお勧めします。この変数は、安全でない書き込みがスレーブで発生するのを防ぐのに役立ちます。ただし、ユーザーにSUPER特権が不必要に付与されていない場合のみ。

1
Peter Venderberghe

以下にインラインで回答を見つけてください。

1。何らかの方法で同期が台無しになりますか-

高可用性アーキテクチャのビュー "YES"。マスターが安定している限り、問題が発生することはありません。

2。次のレプリケーションイベント中に変更がマスターから上書きされますか

Depends upon your changes.

マスター

create table test (id int, name varchar(20));
insert into test values (12,'Mannoj');

-------------------------
|id  | name             |
-------------------------
|12  | Mannoj           |
-------------------------

スレーブでも確認できる同じデータと構造。

今スレーブ上次のように更新します

update table test set name='Villain' where id=12;

現在、マスターはこのように更新しようとしています。

update table test set id=14 where  name='Mannoj';

今度はスレーブで同期が壊れています。 SQL_SLAVE_THREADが停止します。

または、それを追加しようとする他の矛盾するステートメントは壊れます、上記はそのためのより良い例です。

ただし、マスターで以下のような更新を取得した場合、スレーブデータがマスターと整合していることを確認してください。

update table test set name='Hero' where id=12;

これについては、アプリケーションアーキテクチャについて十分に確認する必要があります。アプリケーションチームに再確認することをお勧めします。おそらくあなたも彼らのコードをチェックするかもしれません。

。（2）オプションを発生させることはできますか？

はい、以下のポイントを満たす必要があれば、これを克服できます。

  • HAのダウンタイムなし

    • 現在のスレーブ（S1）のバックアップから別の新しいスレーブサーバー（S2）を用意します。両方のスレーブを1つのマスター（M）に向けます。それがクラッシュしたとしても、あなたが最も気になることはありませんが、S2であなたの仕事をしてください。 （または）

  • HAのダウンタイムあり

    これを行うには、アプリケーションの内外を知っている必要があります。アプリケーションがDMLを実行するのは、最新の数秒などの最新のデータのみであり、古いデータではない場合、1つ以下が役立つと仮定します。

    • スレーブでスレーブlog_slave_updatesを有効にしておく。
    • ここでSTOP SLAVE SQL_THREAD;Insight->を発行しますが、IO_SLAVE_THREADは、適用する必要がある領域よりもRELAY_LOGに追加された領域を取得し続けます。このリレーログは、リレーログとマスターのバイナリログで自動パージを有効にするまで、SQLスレッドによって実行されたときにのみパージされます。これにより、マスターサイトからスレーブサイトへのトランザクションの発生に関する情報が得られます。
    • その後、スレーブで変更を行うことができます。
    • スレーブの変更が完了したら、スレーブのバイナリログを追跡し、マスターの各dmlの対応する値を現在のライブデータで確認し、スレーブの値も変更できます。
    • これでSTART SLAVE SQL_THREAD;を発行できますもちろん、Last_Error: and Seconds_Behind_Master: NULLでエラーがスローされます
    • SET GLOBAL sql_slave_skip_counter = 1とSTART SLAVE SQL_THREAD;->これを取得するまでSeconds_Behind_Master: 0を実行してください
1
Mannoj

MySQL Clusterを使用していない限り、レプリケーションは厳密に一方向の操作です。 notはスレーブコピーに変更を加える必要があります。

もしあなたがそうするならばどうなるかについては、言うのは難しいです、私は愚かなことをしようとするほど十分に馬鹿ではありませんでした:-)

私はそれがあなたが契約を破るときそれがソフトウェアがすることは何でもするであろうと思う-それがうまくいくものは何でも喜ばせる。

私のアドバイスは、あなたの心を横切るその行動の考えの最も可能性についてさえ考えないことです（ダグラスアダムスHHGTTGから言い換え）。

0
paxdiablo

最初に、マスターサーバーがクラッシュし、スレーブが新しい​​マスターに昇格する前に各スレーブが異なるステータスに追いつくなどの極端な状況でない限り、そうすることを避けるべきであることに完全に同意します。

そうする必要がある場合は、mysqlレプリケーション（または「同期」）のメカニズムを最初に理解することが重要だと思います。

マスターサーバー側では、変更が発生するたびに、対応するバイナリログのみをスレーブに送信します。スレーブには、バイナリ形式のSQLクエリが含まれています。

スレーブサーバー側では、IOスレッドを使用し、マスターのイベントを待機し続けます。新しいイベントが発生すると、スレーブはバイナリログを独自のリレーログに保存し、別のSQLスレッドをリレーログのコンテンツの実行を開始します。現在のリレーログのすべてのコンテンツが実行されると、デフォルトで自動的に削除されます（relay_log_purge = 0を手動で設定しない限り）。

したがって、簡単にするために、レプリケーションまたは同期のプロセスは2つのステップです。最初にマスターで発生した同じSQLクエリをスレーブに転送し、次に各スレーブが受信したSQLクエリを実行します。

今私はあなたの場合に何が起こるかは非常に簡単だと思います：

  1. 変更内容によって異なります。たとえば、スレーブで主キーの値を手動で挿入/更新し、後でマスターで同じ値が設定された場合、マスターでは成功しますがスレーブでは失敗します。スレーブで「SHOW SLAVE STATUS」を使用してエラーメッセージを表示できます。

  2. スレーブで手動で変更した後、上書きイベント（つまりsql）がマスターで発行された場合は、完全に可能です。また、上記の例のように競合は発生しません。

  3. あなたは私が推測する答えを得ました。

0
Brilliun