はじめに：以前、MySQLマスタースレーブレプリケーションを実装する方法についての記事がありましたが、今日は、MySQLマスタースレーブデータの整合性を確保する方法を紹介します。率直に言って、MySQLマスタースレーブレプリケーションの原則は、マスターがデータを書き込むときに書き込みログを残し、スレーブはデータ実行プロセスを模倣してマスターが残したログに従ってデータを書き込むというものです。MySQLマスタースレーブレプリケーションの原則を理解すると、マスタースレーブの不整合につながる可能性のある2つのステップがあることを明確に理解できます。
1、mater日志写入不成功导致slave不能正常模仿。
2、slave根据master日志模仿时写入不成功。
今日は、これらの2つの次元からマスターとスレーブ間の不整合の問題を解決します。
1. MySQL（マスター側）のログとデータが統一されていることを確認し、停電やダウンタイムなどの異常な状況に対処します。
さらに数回のビープ音：
1。プラグイン可能なデータベースシステムとして、MySQLはプラグインストレージエンジンをサポートします。サーバーレイヤーとストレージエンジンレイヤーに分割されるように設計されています。
2.サーバー層で、MySQLはデータベースのさまざまな操作のBinlogバイナリログをイベントの形式で記録します。その基本的なコア機能は、レプリケーションとバックアップです。さらに、さまざまなビジネスシナリオのニーズを組み合わせ、Binlogの特性に基づいて強力なMySQLエコシステムを構築しました。たとえば、DTS、ユニット化、異種システム間のリアルタイム同期などです。Binlogは長い間不可欠な部分になっています。 MySQLエコシステム。モジュール。
3.ストレージエンジンレイヤーでは、より一般的なストレージエンジンとしてのInnoDBは、高可用性と高性能のバランスが取れており、MySQLを使用するための最初の選択肢になっています（PS：MySQL 5.5.5以降の公式、 InnoDBはMySQLのデフォルトのストレージエンジンとして機能します）。ほとんどのリレーショナルデータベースと同様に、InnoDBはWALテクノロジを使用します。つまり、InnoDB REDOログはデータファイルへの物理的な変更を記録し、ログが常に最初になるようにします。データファイルを永続化する前に、前のREDOログがディスクに書き込まれていることを確認します。BinlogとInnoDBREDO Logをディスクに配置するかどうかは、異常なダウンタイム後にインスタンスのデータを回復できる範囲に直接影響します。InnoDBは、トランザクションがコミットされたときにログの書き込み方法と戦略を制御するための対応するパラメーターを提供します。次に例を示します。
innodb_flush_method:控制innodb数据文件、日志文件的打开和刷写的方式，建议取值：fsync、O_DIRECT。
innodb_flush_log_at_trx_commit:控制每次事务提交时，重做日志的写盘和落盘策略，可取值：0，1，2。
当innodb_flush_log_at_trx_commit=1时，每次事务提交，日志写到InnoDB Log Buffer后，会等待Log Buffer中的日志写到Innodb日志文件并刷新到磁盘上才返回成功。
sync_binlog：控制每次事务提交时，Binlog日志多久刷新到磁盘上，可取值：0或者n(N为正整数)。
不同取值会影响MySQL的性能和异常crash后数据能恢复的程度。当sync_binlog=1时，MySQL每次事务提交都会将binlog_cache中的数据强制写入磁盘。
innodb_doublewrite：控制是否打开double writer功能，取值ON或者OFF。
当Innodb的page size默认16K，磁盘单次写的page大小通常为4K或者远小于Innodb的page大小时，发生了系统断电/os crash ，刚好只有一部分写是成功的，则会遇到partial page write问题，从而可能导致crash后由于部分写失败的page影响数据的恢复。InnoDB为此提供了Double Writer技术来避免页断裂(partial write)的发生。
innodb_support_xa:控制是否开启InnoDB的两阶段事务提交.默认情况下，innodb_support_xa=true，支持xa两段式事务提交。
上記のビープ音により、次の構成が得られます。
#以下配置保证bin-log写入后事务提交流程会变成两阶段提交，这里的两阶段提交并不涉及分布式事务，mysql把它称之为内部xa事务
innodb_support_xa=ON
#以下配置能够保证不论是MySQL Crash 还是OS Crash 或者是主机断电重启都不会丢失数据
innodb_doublewrite=ON
#以下配置保证每次事务提交后，都能实时刷新到磁盘中，尤其是确保每次事务对应的binlog都能及时刷新到磁盘中，只要有了binlog，InnoDB就有办法做数据恢复，不至于导致主从复制的数据丢失
innodb_flush_log_at_trx_commit = 1
sync_binlog = 1
mysql構成
2.同期中にMySQL（スレーブ側）がマスター側と同期することを確認します。
1.非同期レプリケーション
メインライブラリは、クライアントから送信されたトランザクションの実行後すぐに結果をクライアントに返し、スレーブライブラリが結果を受信して処理したかどうかを気にしないため、問題が発生します。マスターがクラッシュした場合、マスターはすでに結果を持っています。送信されたトランザクションはスレーブライブラリに送信されない場合があります。この場合、強制されたスレーブがマスターに昇格し、「データの不整合」が発生する可能性があります。初期のMySQL（5.5より前）は非同期レプリケーションのみをサポートしていました。
2.準同期レプリケーション
MySQLは5.5で準同期レプリケーションを導入しました。マスターライブラリは、クライアントによって送信されたトランザクションに応答する前に、少なくとも1つのスレーブライブラリがリレーログを受信して書き込むことを確認する必要があります。準同期レプリケーションは、rpl_semi_sync_master_wait_pointパラメータを使用してリンクを制御します。マスターがスレーブACKを受信します。ACKを受信した後、マスターはステータスをクライアントに返します。このパラメーターには、AFTER_SYNCとAFTER_COMMITの2つのオプションがあります。
rpl_semi_sync_master_wait_point=WAIT_AFTER_COMMIT
rpl_semi_sync_master_wait_pointがWAIT_AFTER_COMMITの場合、commitTrxの呼び出しは、エンジンレイヤーのコミット後、つまりスレーブACKの待機中に行われますが、現在のクライアントは返されませんが、トランザクションはコミットされ、他のクライアントはコミットされたトランザクションを読み取ります。スレーブ側がトランザクションのイベントを読み取っておらず、メインライブラリが同時にクラッシュする場合は、スタンバイライブラリに切り替えます。その後、以前に読み取ったトランザクションがなくなり、データの不整合の問題が発生します。メインライブラリを開始できない場合、メインライブラリで実際に正常にコミットされたトランザクションがスレーブライブラリで見つからない、つまりデータが失われます。
PS：早くも11年前、Alibabaデータベースは、エンジン層でコミットする前にスレーブACKを待機することで、この問題を解決するために革新しました。
3.完全同期レプリケーション
上記の問題に対応して、MySQLは5.7.2で正式にロスレス準同期を導入しました。binlogsyncを呼び出した後、エンジン層でコミットする前にスレーブACKを待ちます。このように、トランザクションは、スレーブがトランザクションイベントを受信したことを確認した後にのみコミットされます。
rpl_semi_sync_master_wait_point=WAIT_AFTER_SYNC
after_syncモードでは、メインライブラリがトランザクションをコミットしないため、after_commitモードによって引き起こされるデータの不整合の問題が解決されます。ただし、問題が発生します。メインライブラリがbinlogフラッシュされ、binlogがスタンバイライブラリに同期されると、binlog同期の前にアボートが発生し、このトランザクションがメインライブラリで正常に送信されなかったことは明らかです（binlogが送信されなかったため）中止前に同期されます。メインライブラリが復元された後、トランザクションはロールバックされます）が、スレーブライブラリはこれらのBinlogを受信して正常に実行されるため、スレーブライブラリの余分なデータと同等であり、「データの不整合」が発生する可能性があります。
さらに、MySQLの準同期レプリケーションアーキテクチャでは、メインデータベースがスタンバイデータベースのackを待機しているときに、タイムアウトが非同期に縮退すると、「データの不整合」が発生する可能性もあります。
3.備考とソリューション（上記のソリューションのアイデアは、会社のビジネスシナリオの99.8％を満たすことができます）
1.上記の2つのポイントの分析と構成を通じて、MySQL自体のRepliactionは、角質を好むクラスメートの欲求をもはや満たすことができないことがわかりました（バックエンドプログラマーは慎重に考える必要があります）。完了しましたか？マスタースレーブデータの絶対的な一貫性を確保するために、以下に2つのアイデアを提供します（今日は少し疲れています。アイデアだけです。次回は具体的な解決策を聞いてください）。
2. AlibabaCloud自体が開発したデータ修正プラットフォーム。
3. PXCデータの強力な整合性ソリューションであり、複数のマスターと複数のスレーブをサポートします。欠点は、クラスターを実行するためにパフォーマンスにほとんど違いがないマシンのボスに適用する必要があることです。
著者：孤独なスティックスティック
リンク：https：//www.jianshu.com/p/328ad87bde5e
出典：ジェーンの本
は著者が著作権を所有しています。商用の再版については、著者に連絡して許可を求め、非商用の再版については、出典を示してください。