MySQL 5.6 DBから複製されるMySQL 5.1 DBで発生する可能性がある潜在的な問題について質問があります。
http://dev.mysql.com/doc/refman/5.6/en/replication-compatibility.html や https://などのリソースに基づいて関連するリスクを知っていますserverfault.com/questions/262936/is-replication-from-mysql-5-5-master-to-a-5-1-slave-possible
ただし、MySQL 5.1 DBを5.6バージョンに置き換えようとしているため、これは非常に特殊なケースであり、ダウンタイムを最小限に抑える唯一の方法は、5.6 DBを最初にセットアップしてから、5.1 DBから複製することですこれはまた、5.6 DBから複製して循環複製を形成します。これの目的は、スイッチオーバー中に(5.1の代わりに5.6 DBがライブ書き込みを受信するアクティブデータベースになる場合)、書き込みデータが失われないようにすることです。
5.1 DBを5.6 DBからレプリケートする前にこのような設定をしたことがある人がいるかどうか、また問題が発生したかどうかを知りたいと思いました。レプリケーション中に5.1 DBで5.6 DBのどのSQLコマンドが問題になる可能性があるのかわかりません。
正確には、5.6バージョンは5.6.21、5.1バージョンは5.1.73です。
ありがとう
信じられないかもしれませんが、私は一度それをしてはいけない理由について投稿しました( MySQL 5.5でutf8mb4を完全に無効にするにはどうすればよいですか? )。しかし、私の古い投稿の精神と @ ChristopherSchultz からのコメントの中で、私は手足を出しますそれを行う方法を教えてください。次に、すべきでない理由を教えてください。
空のバイナリログのホームポジションに関する投稿を書いたことがあります。
120
MySQL 5.6107
MySQL 5.5の場合106
MySQL 5.1の場合98
MySQL 4.1/5.0の場合このフォーラムで何年にもわたって、MySQLのバージョンに関係なくすべてのバイナリログに共通の位置があることを誰か(アーロンブラウンかモーガントッカーのどちらか)から学びました。位置4。
私は一度それを答えに入れました(Mar 05, 2013
: マスターを停止しないMySQLレプリケーション )。私の答えのステップ06で、私はこれを書きました:
CHANGE MASTER TO
MASTER_Host='10.1.20.30',
MASTER_PORT=3306,
MASTER_USER='repluser',
MASTER_PASSWORD='replpass',
MASTER_LOG_FILE='mysql-bin.000001',
MASTER_LOG_POS=4;
これらの他の投稿でもポジション4を使用しました
Apr 02, 2014
: ネットワークからの読み取り中にレプリケーションイベントのチェックサム検証が失敗したことを修正するにはどうすればよいですか。エラーコード:174Mar 05, 2014
: MySQLサーバーホストのクロック時間を変更するリスク理由のために、他の投稿でこの情報を繰り返すことはめったにありません。個人的には、binlogイベントは、各イベントのサイズ(バイト単位)の点でバージョンごとに異なる形で表現されるのではないかと心配しています。信じられないかもしれませんが、過去2週間、DBサーバーをMySQL 5.5からアップグレードしています。 MySQL 5.6に。混合モードのバイナリロギングが原因で、レプリケーションが中断し、標準のレプリケーションテクニックではbinlogファイルと位置からリセットできないというまれなイベントがありました。マスターでバイナリログをホース処理し、データをコピーし、レプリケーションを最初から数回実行する必要がありました(400 VMのうち5つですが、それでも5回発生しました)。新しいマスターから古いスレーブに複製すると、これらの線に沿ってさらに多くの問題が発生すると確信しています。
したがって、理論的にはそれが可能であり、MySQLが異議を唱えることはありません。つまり、MySQLレプリケーションが認識せず、解釈できない形式のbinlogイベントに遭遇するまでです。
参考までに、この例のCHANGE MASTER TOコマンド
CHANGE MASTER TO
MASTER_Host='master2.mycompany.com',
MASTER_USER='replication',
MASTER_PASSWORD='bigs3cret',
MASTER_PORT=3306,
MASTER_LOG_FILE='master2-bin.001',
MASTER_LOG_POS=4,
MASTER_CONNECT_RETRY=10;
MySQL 5.6 Documentation に表示されます。 MySQL 4.1ドキュメント にもあります。
したがって、ポジション4は常にわかっていました(私は2、3年しか知りません)。それにもかかわらず、私は古いマスターから新しいスレーブへのMySQLレプリケーションを信頼しています(ただし永続的にではありません)。新しいマスターから古いスレーブへのMySQLレプリケーションを信頼していません。
バージョンが異なるためにbinlogイベントが失われるリスクが増えるだけなので、循環レプリケーションパスを使用しないでください。常に1つの方向を新しいバージョンに複製する必要があります。次に、新しいバージョンにフェイルオーバーします。
5.1から5.5と5.5から5.6は、あなたが計画しているように、短期間で成功しました。段階的なアップグレードを実行できますか?つまり、5.1から5.5から5.6ですか?
発生する可能性のある問題のいくつかは、ワークロードに固有の事柄が原因である可能性があります。私はpt-upgradeツール( http://www.percona.com/doc/percona-toolkit/2.2/pt-upgrade.html )を使用して、古いバッチに対してクエリのバッチを実行しましたテスト用に、新しいバージョンに複製するバージョン(本番規模のデータを持つテストサーバーの別のペアで)。
一般的なルールは、新しいバージョンから古いバージョンに複製しないことです。
新しいバージョンへの複製は、実行すべき正確なアップグレードパスです。スレーブが1つしかない場合は、それをマスターに昇格させます。古いマスターをスレーブとして再接続できるように、昇格する前に必ずshow master statusの出力を保持する必要があります。
複数のスレーブがある場合は、古いマスターから複製する新しいマスターのみを使用し、昇格前に他のスレーブをから複製して新しいマスターにする必要があります。