MySQLマスターコピー(非同期コピーと半同期コピー)
3829 ワード
1.MySQlマスターコピー原理:プライマリ・サーバのbinlogログをサーバから1回実行し、プライマリ・セカンダリ・データの一貫した状態にコピーします. プロセス:ライブラリからI/Oスレッドを開き、メインライブラリにBinlogログを要求します.プライマリノードはbinlog dumpスレッドを開き、自分のバイナリログをチェックし、スレーブノードに送信します.ライブラリから受信したデータを中継ログ(Relay log)に保存し、SQLスレッドを1つ開き、Relayの操作を自分のマシン上で1回 実行する.の利点: は、代替データベースとして機能し、トラフィック に影響を及ぼさない.は読み書き分離が可能で、一般的には1つの書き込みライブラリ、1つ以上の読み取りライブラリであり、異なるサーバに分布し、サーバとデータベースの性能を十分に発揮するが、データの一貫性を保証する
2.マスターコピーのログ形式
ここでのログフォーマットとは、バイナリ・ログの3つのフォーマットです.文statementベースのレプリケーション、行rowベースのレプリケーション、文ベースおよび行(mix)ベースのレプリケーションです.ここでrowベースのレプリケーション方式は、プライマリ・スレーブ・ライブラリ・データの一貫性を保証しますが、ログ量が多く、設定時にディスクのスペースの問題を考慮します.
3.アーキテクチャのコピー
3.1、一主多従アーキテクチャ
メインライブラリの要求圧力が非常に大きい場合、1つのメインマルチスレーブレプリケーションアーキテクチャを構成することによって読み書き分離を実現し、リアルタイム性に対する要求があまり高くない大量の要求を負荷均衡によって複数のスレーブライブラリに配布してデータを読み取り、メインライブラリの読み取り圧力を低減することができる.また、プライマリ・ライブラリでダウンタイムが発生した場合、1つのスレーブ・ライブラリをプライマリ・ライブラリに切り替えてサービスを継続できます.
3.2、マルチレベルのレプリケーションアーキテクチャ
各スレーブ・ライブラリには、binlogログをプッシュする独立したBinlog Dumpスレッドがあるため、スレーブ・ライブラリの数が増えるにつれて、スレーブ・ライブラリのIO圧力とネットワーク圧力も増加し、マルチレベル・レプリケーション・アーキテクチャが誕生します.
マルチレベル・レプリケーション・アーキテクチャは、プライマリ・マルチ・ベースに基づいて、プライマリ・ライブラリと各セカンダリ・ライブラリの間に2次プライマリ・ライブラリMaster 2を追加します.この2次プライマリ・ライブラリは、1次プライマリ・ライブラリにプッシュされたBInlogログを各セカンダリ・ライブラリにプッシュするだけで、1次プライマリ・ライブラリのプッシュ圧力を軽減します.
しかし、Binlogログは2回のレプリケーションを経てライブラリに到達し、レプリケーションの遅延が増加するという欠点があります.
この問題は,ブラックホールエンジン(ブラックホールエンジン)を2次ライブラリに適用することで解決でき,マルチレベルレプリケーションの遅延を低減できる.
ブラックホールエンジンとは、Blackholeテーブルに書き込まれたデータがディスクに書き込まれないため、このBlackholeテーブルは常に空のテーブルであり、データの挿入/更新/削除操作はBinlogにのみ記録され、ライブラリからコピーされます.
3.3、ダブルマスターコピー/Dual Masterアーキテクチャ
デュアルプライマリ・レプリケーション・アーキテクチャは、プライマリ・スレーブの切り替えが必要なシーンに適しています.
プライマリ・ライブラリが1つしかないアーキテクチャでは、プライマリ・ライブラリがダウンタイムした後、そのうちの1つをライブラリからプライマリ・ライブラリに切り替えてサービスを継続します.元のプライマリ・ライブラリにはデータ・ソースがありません.この新しいプライマリ・ライブラリが新しいデータを受信すると、元のプライマリ・ライブラリは同期していません.そのため、データの違いがますます大きくなり、元のプライマリ・ライブラリはレプリケーション環境の一員になれません.元のプライマリ・ライブラリが正常に復元されたら、レプリケーション環境に再追加する必要があります.
それは、プライマリ・ライブラリの重複追加の問題を回避するために、デュアル・プライマリ・レプリケーションが発生します.2つのデータベースは互いにプライマリ・スレーブであり、プライマリ・ライブラリがダウンタイムでリカバリされると、元のライブラリ(現在のプライマリ・ライブラリ)のスレーブであるため、新しいプライマリ・ライブラリのデータがコピーされます.では、プライマリ・ライブラリの役割がどのように切り替えられても、元のプライマリ・ライブラリはレプリケーション環境から離れません.
4.コピー方式
MySQLのプライマリ・スレーブ・レプリケーションには、非同期レプリケーションとセミ同期レプリケーションの2つのレプリケーションがあります.
4.1非同期レプリケーション
1、論理的
MySQLのデフォルトのレプリケーションは非同期で、プライマリ・ライブラリはクライアントからコミットされたトランザクションを実行した後、すぐに結果をクライアントに返します.ライブラリから受信して処理したかどうかは気にしません.これにより、プライマリがcrashを落とした場合、プライマリがコミットしたトランザクションがライブラリに転送されない可能性があります.この場合、強制的にアップグレードされます.新しいプライマリ上のデータが不完全になる可能性があります.
2、技術上
プライマリ・ライブラリはトランザクションBinlogイベントをBinlogファイルに書き込みます.この場合、プライマリ・ライブラリはDumpスレッドに新しいBinlogを送信するように通知するだけで、プライマリ・ライブラリはコミット操作を処理し続けます.この場合、これらのBinlogがライブラリ・ノードに転送されることは保証されません.
4.2フル同期レプリケーション
1、論理的
プライマリ・ライブラリがトランザクションを実行すると、すべてのスレーブ・ライブラリがトランザクションを実行してからクライアントに返されます.すべてのトランザクションがライブラリから実行されるまで待機する必要があるため、フル同期レプリケーションのパフォーマンスには大きな影響があります.
2、技術上
プライマリ・ライブラリがトランザクションをコミットした後、すべてのスレーブ・ノードが受信し、APPLYがコミットされ、その後、プライマリ・ライブラリ・スレッドが後続の操作を続行する必要があります.しかし、欠点は、プライマリ・ライブラリがトランザクションを完了する時間が長くなり、パフォーマンスが低下することです.
4.3半同期レプリケーション
1、論理的
フル同期レプリケーションとフル非同期レプリケーションの間の1つで、マスターライブラリは少なくとも1つのライブラリノードから受け取り、Flush BinlogからRelay Logファイルまで待つだけで、マスターライブラリはすべてのスレーブからマスターライブラリへのフィードバックを待つ必要はありません.同時に、ここでは完全に完了し、提出されたフィードバックではなく、受信されたフィードバックにすぎず、多くの時間を節約します.
2、技術上
非同期レプリケーションとフル同期レプリケーションの間で、プライマリ・ライブラリは、クライアントがコミットしたトランザクションを実行した後、すぐにクライアントに戻るのではなく、少なくとも1つのライブラリから受信されrelay logに書き込まれてからクライアントに戻るのを待つ.非同期レプリケーションに比べて、半同期レプリケーションはデータのセキュリティを向上させ、同時にある程度の遅延をもたらし、この遅延は少なくともTCP/IP往復の時間である.したがって、半同期レプリケーションは、低遅延のネットワークで使用することが望ましい.
2.マスターコピーのログ形式
ここでのログフォーマットとは、バイナリ・ログの3つのフォーマットです.文statementベースのレプリケーション、行rowベースのレプリケーション、文ベースおよび行(mix)ベースのレプリケーションです.ここでrowベースのレプリケーション方式は、プライマリ・スレーブ・ライブラリ・データの一貫性を保証しますが、ログ量が多く、設定時にディスクのスペースの問題を考慮します.
show variables like ‘%binlog%format%’; # binlog
set binlog_format = ‘row’; # ， session
set global binlog_format = ‘row’; # binlog ， Session3.アーキテクチャのコピー
3.1、一主多従アーキテクチャ
メインライブラリの要求圧力が非常に大きい場合、1つのメインマルチスレーブレプリケーションアーキテクチャを構成することによって読み書き分離を実現し、リアルタイム性に対する要求があまり高くない大量の要求を負荷均衡によって複数のスレーブライブラリに配布してデータを読み取り、メインライブラリの読み取り圧力を低減することができる.また、プライマリ・ライブラリでダウンタイムが発生した場合、1つのスレーブ・ライブラリをプライマリ・ライブラリに切り替えてサービスを継続できます.
3.2、マルチレベルのレプリケーションアーキテクチャ
各スレーブ・ライブラリには、binlogログをプッシュする独立したBinlog Dumpスレッドがあるため、スレーブ・ライブラリの数が増えるにつれて、スレーブ・ライブラリのIO圧力とネットワーク圧力も増加し、マルチレベル・レプリケーション・アーキテクチャが誕生します.
マルチレベル・レプリケーション・アーキテクチャは、プライマリ・マルチ・ベースに基づいて、プライマリ・ライブラリと各セカンダリ・ライブラリの間に2次プライマリ・ライブラリMaster 2を追加します.この2次プライマリ・ライブラリは、1次プライマリ・ライブラリにプッシュされたBInlogログを各セカンダリ・ライブラリにプッシュするだけで、1次プライマリ・ライブラリのプッシュ圧力を軽減します.
しかし、Binlogログは2回のレプリケーションを経てライブラリに到達し、レプリケーションの遅延が増加するという欠点があります.
この問題は,ブラックホールエンジン(ブラックホールエンジン)を2次ライブラリに適用することで解決でき,マルチレベルレプリケーションの遅延を低減できる.
ブラックホールエンジンとは、Blackholeテーブルに書き込まれたデータがディスクに書き込まれないため、このBlackholeテーブルは常に空のテーブルであり、データの挿入/更新/削除操作はBinlogにのみ記録され、ライブラリからコピーされます.
3.3、ダブルマスターコピー/Dual Masterアーキテクチャ
デュアルプライマリ・レプリケーション・アーキテクチャは、プライマリ・スレーブの切り替えが必要なシーンに適しています.
プライマリ・ライブラリが1つしかないアーキテクチャでは、プライマリ・ライブラリがダウンタイムした後、そのうちの1つをライブラリからプライマリ・ライブラリに切り替えてサービスを継続します.元のプライマリ・ライブラリにはデータ・ソースがありません.この新しいプライマリ・ライブラリが新しいデータを受信すると、元のプライマリ・ライブラリは同期していません.そのため、データの違いがますます大きくなり、元のプライマリ・ライブラリはレプリケーション環境の一員になれません.元のプライマリ・ライブラリが正常に復元されたら、レプリケーション環境に再追加する必要があります.
それは、プライマリ・ライブラリの重複追加の問題を回避するために、デュアル・プライマリ・レプリケーションが発生します.2つのデータベースは互いにプライマリ・スレーブであり、プライマリ・ライブラリがダウンタイムでリカバリされると、元のライブラリ(現在のプライマリ・ライブラリ)のスレーブであるため、新しいプライマリ・ライブラリのデータがコピーされます.では、プライマリ・ライブラリの役割がどのように切り替えられても、元のプライマリ・ライブラリはレプリケーション環境から離れません.
4.コピー方式
MySQLのプライマリ・スレーブ・レプリケーションには、非同期レプリケーションとセミ同期レプリケーションの2つのレプリケーションがあります.
4.1非同期レプリケーション
1、論理的
MySQLのデフォルトのレプリケーションは非同期で、プライマリ・ライブラリはクライアントからコミットされたトランザクションを実行した後、すぐに結果をクライアントに返します.ライブラリから受信して処理したかどうかは気にしません.これにより、プライマリがcrashを落とした場合、プライマリがコミットしたトランザクションがライブラリに転送されない可能性があります.この場合、強制的にアップグレードされます.新しいプライマリ上のデータが不完全になる可能性があります.
2、技術上
プライマリ・ライブラリはトランザクションBinlogイベントをBinlogファイルに書き込みます.この場合、プライマリ・ライブラリはDumpスレッドに新しいBinlogを送信するように通知するだけで、プライマリ・ライブラリはコミット操作を処理し続けます.この場合、これらのBinlogがライブラリ・ノードに転送されることは保証されません.
4.2フル同期レプリケーション
1、論理的
プライマリ・ライブラリがトランザクションを実行すると、すべてのスレーブ・ライブラリがトランザクションを実行してからクライアントに返されます.すべてのトランザクションがライブラリから実行されるまで待機する必要があるため、フル同期レプリケーションのパフォーマンスには大きな影響があります.
2、技術上
プライマリ・ライブラリがトランザクションをコミットした後、すべてのスレーブ・ノードが受信し、APPLYがコミットされ、その後、プライマリ・ライブラリ・スレッドが後続の操作を続行する必要があります.しかし、欠点は、プライマリ・ライブラリがトランザクションを完了する時間が長くなり、パフォーマンスが低下することです.
4.3半同期レプリケーション
1、論理的
フル同期レプリケーションとフル非同期レプリケーションの間の1つで、マスターライブラリは少なくとも1つのライブラリノードから受け取り、Flush BinlogからRelay Logファイルまで待つだけで、マスターライブラリはすべてのスレーブからマスターライブラリへのフィードバックを待つ必要はありません.同時に、ここでは完全に完了し、提出されたフィードバックではなく、受信されたフィードバックにすぎず、多くの時間を節約します.
2、技術上
非同期レプリケーションとフル同期レプリケーションの間で、プライマリ・ライブラリは、クライアントがコミットしたトランザクションを実行した後、すぐにクライアントに戻るのではなく、少なくとも1つのライブラリから受信されrelay logに書き込まれてからクライアントに戻るのを待つ.非同期レプリケーションに比べて、半同期レプリケーションはデータのセキュリティを向上させ、同時にある程度の遅延をもたらし、この遅延は少なくともTCP/IP往復の時間である.したがって、半同期レプリケーションは、低遅延のネットワークで使用することが望ましい.