> ## Documentation Index
> Fetch the complete documentation index at: https://villagesql.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# MySQL のリードレプリカ

> MySQL のレプリカで読み取りをスケールする方法: クエリのルーティング、レプリケーションラグとの付き合い方、およびすべてのレプリカ構成が直面する read-your-own-writes の問題。

> [card] [VillageSQL is a drop-in replacement for MySQL with extensions.](https://villagesql.com/docs/en/8.4/stable/install-server.md)
>
> All examples on this page work on VillageSQL. Install Now →

リードレプリカは、ソースが書き込むすべてを再生し、読み取りクエリに応答する 2 台目のサーバーです。レプリカは読み取りをほぼ線形にスケールし、フェイルオーバー用のウォームコピーを提供します。その代償として、アプリケーションが引き受けなければならない新しい問題が 1 つあります。レプリカは常にわずかに遅れており、どの設定オプションでもそれをなくすことはできません。レプリケーション自体の構築は[レプリケーションの基本](https://villagesql.com/docs/ja/guides/replication-basics.md)で扱います。このガイドはレプリカをうまく使うことについてです。

## レプリカの用途

* **読み取りのスケーリング。** ダッシュボード、検索、エクスポート、および API の読み取りがソースから移動し、ソースの容量を書き込みのために残します。
* **高コストなクエリの分離。** アナリストの 40 秒かかる集計はレプリカで実行され、誰もブロックしません。
* **ウォームスタンバイ。** 最新のレプリカは、ソースが障害を起こしたときに昇格できます。

一方、レプリカは書き込みをスケールするツールではありません。すべてのレプリカはソースが受けるすべての書き込みを再生するため、レプリカは書き込み容量をまったく増やしません。

## 読み取りのルーティング

MySQL はクエリをルーティングしてくれません。スタックの中の何かが、書き込みをソースへ、選択した読み取りをレプリカへ送る必要があります。

* **アプリケーションレベルのルーティング。** ほとんどのフレームワークが直接サポートしています（Django のデータベースルーター、Rails の `connects_to`/ロール、Laravel の読み取り/書き込み接続）。シンプルで明示的で、アプリケーションがクエリごとに決定します。
* **プロキシ。** ProxySQL などはステートメントの種類やルールでルーティングするため、アプリケーションは 1 つの接続文字列を保ちます。これはフェイルオーバーも一元化します。

アプリケーションレベルのルーティングから始めてください。それは正しい問いを早い段階で強制します。「このクエリはレプリカで実行できるか」ではなく「このクエリは古いデータを許容できるか」です。

## レプリケーションラグ: 本当に難しい部分

レプリケーションはデフォルトで非同期です。ソースでのコミットはレプリカが変更を適用する前に返るため、その直後のレプリカの読み取りは、すでに成功した書き込みを見逃すことがあります。ラグはレプリカで測定します。

```sql theme={null}
SHOW REPLICA STATUS\G
```

`Seconds_Behind_Source` フィールドが標準的なシグナルです。通常はゼロ付近で、書き込みのバースト、大きなトランザクション、およびスキーマ変更の下で急上昇します。これにアラートを設定し、読み取りパスごとの許容値を把握しておいてください。

典型的な障害は **read-your-own-writes** です。ユーザーがプロファイルを保存し（ソースへの書き込み）、次のページがレプリカからそれを読み込むと、レプリカはまだその書き込みを適用していません。ユーザーには自分の変更が消えたように見えます。標準的な緩和策を、コストの低い順に示します。

* **書き込み後の固定。** セッションが書き込んだ後、そのセッションの読み取りを数秒間ソースにルーティングします。多くのフレームワークとプロキシがこのパターンを直接サポートしています。
* **許容度によるルーティング。** 金銭の残高や編集直後のページはソースから読み取り、閲覧ページ、検索、および分析はレプリカから読み取ります。
* **GTID によるセッション一貫性。** 書き込み後にトランザクション識別子を取得し、レプリカの読み取りで `WAIT_FOR_EXECUTED_GTID_SET()` を使ってそれを待ちます。正確ですが、リクエストを通して GTID を引き回す仕組みが必要です。

## 2 つの実践的なルール

* **レプリカは余り物ではなく、同等以上のハードウェアであるべきです。** ソースより遅いレプリカは、まさにレプリカを追加する理由となった負荷の下で遅れていきます。
* **昇格をリハーサルしてください。** 一度も昇格させたことのないレプリカは、一度も復元したことのないバックアップと同じです。必要になる前にフェイルオーバーの手順を練習してください。

VillageSQL はこのレプリケーションの仕組みを MySQL 8.4 から変更なしで引き継いでいるため、上記のすべてが VillageSQL にも当てはまります。

## 関連項目

* [レプリケーションの基本](https://villagesql.com/docs/ja/guides/replication-basics.md) — このガイドの土台となるレプリケーションの構築
* [バイナリログ](https://villagesql.com/docs/ja/guides/binary-logging.md) — レプリカが再生するログストリーム
* [コネクションプーリング](https://villagesql.com/docs/ja/guides/connection-pooling.md) — 読み取りと書き込みを分けた後の、ロールごとのプーリング


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.