以下の側面から、一貫性のない MySQL マスター/スレーブ レプリケーションの問題に対処します。

Mysql マスター/スレーブ構成をセットアップするとき、マスターがスレーブと同期しているか、エラーや遅延が発生することがよくあります。以下では、これらの側面に基づいてエラーをトラブルシューティングできます。

やや大規模な Web サイトでは、基本的に mysql マスターとスレーブのレプリケーションが構成されますが、一方では mysql マスターとスレーブはデータベースの読み取りと書き込みを分離するために使用されます。 mysql 自体はそれほど強力ではありません。通常は、マスター/スレーブ レプリケーションが使用され、スレーブでデータのバックアップが実行されます。

MySQL のマスターとスレーブのレプリケーション プロセスでは、多かれ少なかれマスターとスレーブの同期状況が発生します。この記事では、主にマスターとスレーブの同期状況について説明します。データベースレベルの不整合。
1. ネットワーク遅延

mysql のマスター/スレーブ レプリケーションは binlog に基づく非同期レプリケーションであるため、当然ながら、特にマスターとスレーブ間の同期の原因のほとんどはネットワーク遅延です。コンピュータ室ではデータが同期される可能性が非常に高いため、読み取りと書き込みを分離し、ビジネス層からの初期の設計に注意してください。

2. マスターマシンとスレーブマシンの負荷は一貫していません

mysql マスター/スレーブレプリケーションはマスターデータベース上で 1 つの IO スレッドを開始し、上から 1 つの SQL スレッドと 1 つの IO スレッドを開始するため、どちらかのマシンで負荷が非常に高く、ビジー状態になるため、いずれかのスレッドのリソースが不足し、マスター/スレーブの不整合が発生します。

3. Max_allowed_pa​​cket の設定が矛盾しています

マスター データベースで設定された max_allowed_pa​​cket が、マスター データベースで実行できる場合、スレーブ データベースでの設定が小さすぎます。実行できず、マスター Never の不整合が発生します。

4. キー自動インクリメントキーから始まるキー値と自動インクリメントステップ設定の不一致によるマスタースレーブの不一致。

5. mysql が異常ダウンしたときに、sync_binlog=1 または innodb_flush_log_at_trx_commit=1 が設定されていない場合、binlog またはリレーログ ファイルが破損し、マスターとスレーブの不整合が発生する可能性が非常に高くなります。

6. マスターとスレーブの同期は、mysql 自体のバグによって引き起こされます。

7. バージョンが不一致です。特に上位バージョンがマスターで下位バージョンがスレーブの場合、マスター データベースでサポートされている機能がスレーブ データベースではサポートされません。

上記は、一般的なマスターとスレーブの同期状況の一部です。他にも同期が失われる状況が発生する可能性があります。発生したマスターとスレーブの不一致の状況について教えてください。

上記の状況に基づいて、まず max_allowed_pa​​cket、自動インクリメント キーの開始点、および成長点の設定が一貫していることを確認してから、パフォーマンスの一部を犠牲にしてメイン サーバーで sync_binlog を有効にすることをお勧めします。次の内容を設定します

1. innodb_flush_logs_at_trx_commit = 1
2. innodb-support_xa = 1 # Mysql 5.0 以降
3. innodb_safe_binlog に基づいて、皆様のお役に立てれば幸いです。環境から生じる問題の解決策。

関連記事:

MySQLマスタースレーブレプリケーションに基づくMycatの読み書き分離の例

Dockerを使用してMySQLマスタースレーブレプリケーション環境を迅速に構築する方法の詳細

以上が以下の側面から、一貫性のない MySQL マスター/スレーブ レプリケーションの問題に対処します。の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。