MySql のマスターとスレーブの同期を 1 つの記事で徹底的に理解する-mysql チュートリアル-php.cn

この記事では、MySQL のマスターとスレーブの同期や動作原理などを中心に、MySql に関する知識を紹介します。

1 はじめに

皆さん、こんにちは。Mysql は誰にとっても最も一般的に使用されているデータベースです。以下は、mysql のマスターとスレーブの同期に関する知識ポイントを共有するものです。 Mysqlの基礎知識ですが、間違いがあればご指摘ください。

2 MySql マスター/スレーブ同期の概要

MySQL マスター/スレーブ同期、つまり MySQL レプリケーションは、1 つのデータベースサーバーから複数のデータベースサーバーにデータを同期できます。 MySQLデータベースにはマスタ・スレーブ同期機能が搭載されており、構築後はデータベースやテーブルの構造に基づいたさまざまな方式でマスタ・スレーブ同期を実現できます。

Redis は高性能のインメモリデータベースですが、今日の主役ではありません。MySQL はディスクファイルをベースとしたリレーショナルデータベースです。Redis と比較すると、読み取り速度は遅くなりますが、強力です。 . 永続的なデータの保存に使用できます。実際の業務ではMySQLと連携してRedisをキャッシュとして利用することが多いですが、データアクセス要求があった場合、まずキャッシュから検索し、存在する場合は直接取り出し、存在しない場合は、データベースへのアクセスが再度行われるため、パフォーマンスが向上し、読み取りの効率化により、バックエンドデータベースへのアクセスの負荷も軽減されます。 Redis のようなキャッシュアーキテクチャの使用は、同時実行性の高いアーキテクチャの非常に重要な部分です。

ビジネス量が増大し続けるにつれて、データベースへの負荷も増大し続けます。キャッシュ内の頻繁な変更もデータクエリの結果に大きく依存するため、データクエリ効率の低下、高負荷、多すぎる接続など。電子商取引のシナリオでは、読み取りが多く書き込みが少ないという典型的なシナリオがよくあります。MySQL のマスター/スレーブアーキテクチャを使用し、読み取りと書き込みを分離して、マスターサーバー (マスター) が書き込みリクエストを処理し、スレーブサーバーが書き込みリクエストを処理するようにすることができます。 (スレーブ) は読み取りリクエストを処理します。これにより、データベースの同時処理能力がさらに向上します。下の図に示すように:

上の図では、2 つのスレーブライブラリが追加されていることがわかります。これら 2 つのスレーブライブラリは、大量の読み取りリクエストに耐えることができます。一緒に主要な負荷を共有し、ライブラリのプレッシャーを軽減します。スレーブデータベースは、マスター/スレーブレプリケーションを通じてマスターデータベースのデータを継続的に同期し、スレーブデータベースのデータがマスターデータベースのデータと一貫していることを確認します。

次に、マスタ/スレーブ同期の機能とマスタ/スレーブ同期の実装方法を見てみましょう。

3 マスター/スレーブ同期の役割

一般に、すべてのシステムがデータベースのマスター/スレーブアーキテクチャを設計する必要があるわけではありません。これは、アーキテクチャ自体にはい、目的がデータベースへの高同時アクセスの効率を向上させることである場合、データベースのパフォーマンスを最大限に引き出すために、まず SQL ステートメントとインデックスを最適化する必要があります。次に、次のようなキャッシュ戦略を採用する必要があります。 Redis や MongoDB などのキャッシュツールを使用することで、データをインメモリデータベースに保存して読み取り効率を向上させることで高いパフォーマンスを実現し、データベースは読み取りと書き込みを分離するマスター/スレーブアーキテクチャを採用しています。システムの使用と保守のコストは、アーキテクチャのアップグレードに応じて徐々に増加します。

本題に戻りますが、マスターとスレーブの同期はデータベースのスループットを向上させるだけでなく、次の 3 つの側面もあります。

3.1 読み取りと書き込みの分離

マスター/スレーブレプリケーションを通じてデータを同期し、読み取りと書き込みの分離を通じてデータベースの同時処理能力を向上させることができます。簡単に言うと、データは複数のデータベースに配置され、そのうちの 1 つはマスターデータベース、残りはスレーブデータベースです。メインデータベースのデータが変更されると、データはスレーブデータベースに自動的に同期され、プログラムは読み書き分離方式を使用してスレーブデータベースからデータを読み取ることができます。電子商取引アプリケーションは多くの場合、「読み取りが多く、書き込みが少ない」ため、読み取りと書き込みを分離することで、より高い同時アクセスを実現できます。当初は、すべての読み取りおよび書き込みの負荷は 1 台のサーバーによって負担されていましたが、現在では、複数のサーバーが読み取りリクエストを共同で処理するため、メインデータベースへの負荷が軽減されています。さらに、スレーブサーバー上でロードバランシングを実行できるため、異なる読み取りリクエストをポリシーに従って異なるスレーブサーバーに均等に分散でき、読み取りがよりスムーズになります。読み込みをスムーズにするもう一つの理由は、ロックテーブルの影響を軽減するためで、例えば書き込みをメインライブラリに任せておけば、メインライブラリで書き込みロックが発生しても、スレーブライブラリのクエリ動作には影響を与えません。

3.2 データバックアップ

マスターとスレーブの同期は、データホットバックアップメカニズムにも相当します。これは、メインデータベースの通常の動作の下で、データベースに影響を与えることなくバックアップされます。データサービスの提供。

3.3 高可用性

データバックアップは実際には冗長メカニズムです。この冗長方法を通じて、データベースの高可用性を交換できます。サーバーに障害が発生すると、、ダウンタイムやその他の利用できない状況では、フェイルオーバーを迅速に実行でき、スレーブデータベースがマスターデータベースとして機能して、サービスの通常の動作を保証できます。電子商取引システムデータベースの高可用性 SLA 指標について学習できます。

4 マスター/スレーブ同期の原理

マスター/スレーブ同期の原理について言えば、データベース内の重要なログファイル、つまりデータベースを更新するイベントを記録する Binlog バイナリファイルについて理解する必要があります。実際、マスター/スレーブ同期の原理Binlog に基づいており、データは同期されています。

マスター/スレーブレプリケーションのプロセスでは、操作は 3 つのスレッドに基づいて行われます。1 つはマスターノードにあるバイナリダンプスレッドで、他の 2 つのスレッドは I/O スレッドと SQL

##上記の図と組み合わせて、マスター/スレーブレプリケーションの中心的なプロセスを理解してみましょう:

マスターノードが書き込みリクエストを受信した場合、書き込みリクエストは追加、削除、または変更操作である可能性があり、このとき、書き込みリクエストの更新操作は binlog ログに記録されます。
マスターノードは、図のスレーブノード (slave01 ノードとスレーブ 02 ノードなど) にデータをコピーします。このプロセスでは、各スレーブノードが最初にマスターに接続されている必要があります。ノードがマスターノードに接続されると、マスターノードは各スレーブノードのバイナリログダンプスレッドを作成し、バイナリログを各スレーブノードに送信します。
binlog ダンプスレッドは、マスターノードの binlog ログを読み取り、その binlog ログをスレーブノードの I/O スレッドに送信します。メインライブラリがイベントを読み取ると、Binglog がロックされ、読み取りが完了するとロックが解除されます。
スレーブノードの I/O スレッドは、binlog ログを受信した後、まず binlog ログをローカルのリレーログに書き込み、binlog ログはリレーログに保存されます。
スレーブノードの SQL スレッドは、リレーログ内の binlog ログを読み取り、特定の追加、削除、変更操作に解析し、マスターノードで実行されたこれらの操作を Do に組み込みます。スレーブノード上で再度実行することでデータ復元の効果が得られ、マスターノードとスレーブノード間のデータの整合性が確保されます。

マスタスレーブ同期のデータ内容は、実はバイナリログ(Binlog)ですバイナリログと呼ばれていますが、実際にはイベントが次々と記録されており、これらのイベントがそれに相当しますINSERT、UPDATE、DELETE などのデータベース更新操作を処理します。

さらに、MySQL のすべてのバージョンがデフォルトでサーバーのバイナリログを有効にするわけではないことにも注意する必要があります。マスター/スレーブ同期を実行するときは、まずサーバーがバイナリログを有効にしているかどうかを確認する必要があります。

バイナリログはファイルです。ネットワーク送信中に200msなどの遅延が発生します。これにより、ユーザーがスレーブライブラリから読み込んだデータが最新のデータではなくなる可能性があり、データの不整合が発生します。マスター/スレーブ同期中。たとえば、レコードを更新する場合、この操作はメインデータベースで完了し、100 ミリ秒などの短い時間内に同じレコードが再度読み取られますが、この時点ではスレーブデータベースはデータ同期を完了していません。そうすると、ライブラリから読み取ったデータは古いデータになります。この状況ではどうすればよいでしょうか?

5 マスター/スレーブ同期のデータ整合性問題を解決する方法

ご想像のとおり、操作したいデータがすべて同じデータベースに保存されている場合、データが更新されると、読み取り時にデータの不整合が発生しないように、レコードに書き込みロックを追加できます。ただし、現時点では、スレーブライブラリの役割は、メインライブラリの負荷を分散するために、読み取りと書き込みを分離せずにデータをバックアップすることです。

したがって、読み取りと書き込みを分離した場合のマスターとスレーブの同期におけるデータ不整合の問題、つまりマスターとスレーブ間のデータ複製の問題を解決する方法も見つける必要があります。スレーブはデータの整合性に従う弱いレプリケーションから強いレプリケーション方法に分けると、次の 3 つのレプリケーション方法があります。

5.1 完全同期レプリケーション

まず第一に、完全同期レプリケーションとは、マスターデータベースがトランザクションを完了した後、すべてのスレーブデータベースもトランザクションを完了する必要があることを意味します。処理結果をクライアントに返すことができるため、完全同期レプリケーションのデータ整合性は保証されますが、マスターライブラリはすべてのスレーブライブラリがトランザクションを完了するまで待つ必要があり、パフォーマンスが比較的低くなります。以下に示すように:

5.2 非同期レプリケーション

非同期レプリケーションとは、メインライブラリが送信するときに、バイナリダンプスレッドが送信するよう通知される binlog ログはスレーブライブラリに送信されます。binlog ダンプスレッドが binlog ログをスレーブライブラリに送信すると、スレーブライブラリがトランザクションを同期的に完了するのを待つ必要はありません。マスターライブラリは、処理結果をクライアントに送信します。

メインライブラリは自らトランザクションを完了させればよいため、スレーブライブラリがトランザクションを完了したかどうかを気にすることなく処理結果をクライアントに返すことができ、短期的なマスタースレーブにつながる可能性があります。データの不整合。マスターデータベースに挿入されたばかりの新しいデータをスレーブデータベースからすぐにクエリすると、クエリできない可能性があります。

さらに、トランザクション送信後にメインデータベースがクラッシュした場合、binlog をスレーブデータベースに同期する時間がない場合があり、このとき、回復障害のためにマスター/スレーブノードが切り替わると、データの損失が発生します。したがって、非同期レプリケーションはパフォーマンスは高いものの、データの一貫性という点では最も弱いものになります。

Mysql マスター/スレーブレプリケーションは、デフォルトで非同期レプリケーションを採用します。

5.3 準同期レプリケーション

MySQL バージョン 5.5 以降では、準同期レプリケーションがサポートされています。原則として、クライアントが COMMIT を送信した後、結果はクライアントに直接返されず、少なくとも 1 つのスレーブライブラリが Binlog を受信してリレーログに書き込むのを待ってからクライアントに返します。この利点は、データの一貫性が向上することですが、もちろん、非同期レプリケーションと比較すると、少なくとも 1 つのネットワーク接続の遅延が増加し、メインデータベースへの書き込み効率が低下します。

MySQL5.7 バージョンでは、rpl_semi_sync_master_wait_for_slave_count パラメータも追加されました。応答する必要があるスレーブライブラリの数を設定できます。デフォルトは 1 です。これは、1 つのスレーブライブラリが応答する限り、クライアントに返すことができます。このパラメータを増やすと、データの一貫性の強度を高めることができますが、マスターデータベースがスレーブデータベースの応答を待つ時間も長くなります。

ただし、準同期レプリケーションには次の問題もあります。

半同期レプリケーションのパフォーマンスは、非同期レプリケーションと比較すると異なります。データを受信するためにスレーブライブラリからの応答を待つ必要がない非同期レプリケーションと比較して、半同期レプリケーションでは、binlog ログの受信を確認するためにスレーブライブラリからの少なくとも 1 つの応答を待つ必要があり、その結果、パフォーマンスの損失。
マスターライブラリがスレーブライブラリからの応答を待つ最大時間は設定可能であり、設定時間を超えると準同期レプリケーションが非同期レプリケーションとなり、非同期レプリケーションの問題も発生します。
MySQL 5.7.2 より前のバージョンでは、半同期レプリケーションにファントム読み取りの問題がありました。

メインライブラリがトランザクションを正常に送信し、スレーブライブラリからの確認を待っているとき、この時点ではスレーブライブラリには処理結果をクライアントに返す時間がありません。ただし、メインライブラリストレージエンジンがすでにトランザクションを送信しているため、他のクライアントはメインライブラリからデータを読み取ることができます。

ただし、メインライブラリが次の 1 秒以内に突然ハングアップし、その時点で次のリクエストが来た場合、メインライブラリがハングアップするため、リクエストはスレーブライブラリにのみ切り替えることができます。スレーブライブラリはマスターライブラリからのリクエストをまだ受け取っていませんデータベースはデータを同期しているため、当然このデータはデータベースから読み込むことができません 1秒前のデータ読み出し結果と比較すると、ファントムリード現象が発生します引き起こされます。

5.4 強化された準同期レプリケーション

強化された準同期レプリケーションは、mysql 5.7.2 以降のバージョンの準同期レプリケーションに加えられた改良です。原理はほぼ同じで、主に魔法の問題を解決します。読み取り問題です。

マスターライブラリがパラメータ rpl_semi_sync_master_wait_point = AFTER_SYNC で構成された後、ストレージエンジンがトランザクションをコミットする前に、マスターライブラリはトランザクションを送信する前にスレーブライブラリからデータ同期の完了の確認を受信する必要があります。これにより、ファントムリード問題です。以下の図を参照してください:

6 概要

上記の内容を通じて、Mysql のマスターとスレーブの同期について理解しました。目標はデータベースの高い同時実行性のみであるため、まず SQL の最適化、インデックス作成、Redis キャッシュデータなどの側面から最適化を検討し、次にマスター/スレーブアーキテクチャを採用するかどうかを検討できます。

マスター/スレーブアーキテクチャの構成において、読み取りと書き込みの分離戦略を採用したい場合は、独自のプログラムを作成するか、サードパーティのミドルウェアを通じて実装することができます。

独自のプログラムを作成する利点は、プログラムがより独立していることです。どのクエリをスレーブデータベースで実行するかを判断できます。高いリアルタイム要件の場合は、どのクエリをスレーブデータベースで実行できるかを考慮することもできます。メインデータベース。同時に、プログラムはデータベースに直接接続するため、ミドルウェア層が削減され、パフォーマンスの損失が軽減されます。

ミドルウェアを使用する方法には明らかな利点があり、強力で使いやすいです。ただし、クライアントとデータベースの間にミドルウェア層を追加するため、ある程度のパフォーマンスが低下すると同時に、商用ミドルウェアの価格は比較的高く、一定の学習コストがかかります。さらに、MaxScale などの優れたオープンソースツールの使用も検討できます。 MariaDB社が開発したMySQLデータミドルウェアです。たとえば、次の図では、MaxScale がデータベースプロキシとして使用され、ルーティングと転送によって読み取りと書き込みの分離が完了します。同時に、MHA ツールを一貫性の高いマスター/スレーブ切り替えツールとして使用して、MySQL の高可用性アーキテクチャを完成させることもできます。