YakstYakstは、海外の役立つブログ記事などを人力で翻訳して公開するプロジェクトです。修正ありMySQLのレプリケーションでありがちな10の問題レプリケーションに不整合が起きたり、切れてしまったりする際の、一般的な原因10個の仕組みと解決法。未報告Tweetレプリケーションの問題でよくある10パターン。0を設定すると、そのセッション内でバイナリログを無効にできる。マスタのセッション内で実行したDMLやDDLは、スレーブにはレプリケーションされない。マスタでバイナリログをオフにする。sec)reptestデータベースにテーブルを作成してみる(マスタ上で実行)。sec)スレーブで確認してみると、テーブルは作成されていない。スレーブの直接更新アプリケーションからスレーブを直接更新してしまうと、マスタとスレーブは同期しなくなってしまう。スレーブをread_onlyに設定しておくのは良い習慣と言えるが、DBAが直接スレーブを更新してしまうのは防げないかもしれない。以下は、壊れたバイナリログの例。48954702このような場合は、以下のいずれかの方法で修正ができるだろう。masterコマンドを実行して、レプリケーションを再開する。slave;場合によっては、pt-table-checksumやpt-table-syncなどのコマンドを使って、スレーブを同期する。上の2つとも失敗した場合には、データベースをリストアする。リレーログの破損ネットワークやデータの送信時の問題で、リレーログの破損が起きる場合がある。masterコマンドで適切なポジションからレプリケーションを再開させる。バイナリログの削除やパージマスタのバイナリログをパージしてしまう前に、スレーブでそのログが適用済みかを確認しよう。logsコマンドをマスタで実行する時には、特に注意しなければならない。安全でないレプリケーション(確定的でない関数の使用)以下が、確定的でない関数の例だ。これらの関数は、マスタとスレーブで違う結果を返す可能性がある。UUID_SHORT()例を見てみよう。マスタで以下のように実行する。sec)スレーブでは、違う値になり得る。masterの実行は注意が必要だ。間違ったバイナリログのポジションを指定してしまうと、実行されるべき文が抜けてしまう可能性がある。masterなども注意を要する文だ。binlog-do-db、binlog-ignore-db、replicate-do-db、replicate-ignore-dbの影響これらの設定オプションは、レプリケーションするテーブルを選択するのに使う。間違って設定されてしまうとデータのずれの原因になり得る。レプリケーション関連のバグ以下は、レプリケーションを破壊する原因になり得るバグ(現在も有効で未修正のもの)だ。マスタのクラッシュマスタサーバののクラッシュは、レプリケーションエラーを引き起こす事がある。sync_binlog変数が役に立つかもしれない。Variables)この変数の値が0以上の場合、バイナリログへの書き込みをsync_binlog回行うごとにMySQLサーバはバイナリログをディスクに同期します(fdatasync()を使用)。自動コミットが有効な時には1文ごとにバイナリログへの書き込みが行われ、そうでない時にはトランザクションごとに書き込みが行われます。sync_binlogのデフォルト値は0で、この場合(MySQLサーバは)ディスクへの同期は行わずOSに任せるので、他のファイルと同じようにその時その時でバイナリログの中身もディスクに書き出されます。1に設定しておくと、クラッシュの際にもバイナリログ内の最大1つの文あるいはトランザクションしか失われないので、最も安全です。動作的には最も遅くなります(ディスクへの同期を非常に高速化してくれるバッテリ付きのキャッシュ搭載のディスク以外の場合)。@yakstcom_req_jaYakstYakstお問い合わせ。