MySQL - レプリケーションのソースを表示

== 概要 ==
MySQLのレプリケーションは、ソースサーバのデータを1つ以上のレプリカサーバに複製する機能である。<br>
ソースサーバのデータ変更がバイナリログに記録され、レプリカサーバがこれを取得して実行することで、データの同期が実現される。<br>
<br>
レプリケーションの主な用途は、読み取りスケーリング (レプリカへの読み取り分散)、バックアップ (レプリカからのバックアップ取得)、災害対策 (地理的に分散したレプリカ配置)、高可用性構成 (フェイルオーバー) である。<br>
<br>
MySQL 8.0以降では、デフォルトでバイナリロギングが有効になっており、レプリケーション構成が容易である。<br>
また、MySQL 8.0.26以降では、用語がmaster / slave から source / replicaに変更され、MySQL 8.4ではCHANGE MASTER TO等の旧構文が完全削除された。<br>
<br>
レプリケーション方式には、位置ベースレプリケーション (バイナリログファイル名と位置で同期) と GTIDレプリケーション (グローバルトランザクション識別子で同期) の2種類がある。<br>
現在の推奨はGTIDレプリケーションであり、フェイルオーバーやトポロジ変更が容易になる。<br>
<br>
半同期レプリケーションを使用することで、少なくとも1つのレプリカへのデータ転送を保証し、データ損失のリスクを低減できる。<br>
<br>
レプリケーションの設定には、ソースサーバとレプリカサーバの両方での設定変更、レプリケーション用ユーザの作成、バイナリログ形式の選択が必要である。<br>
<br>
認証に関しては [[MySQL - 認証プラグイン]]、レプリケーション通信の暗号化については [[MySQL - SSL TLS接続]]、設定パラメータの詳細は [[MySQL - 設定ファイル]] を参照すること。<br>
<br><br>

== レプリケーションのアーキテクチャ ==
MySQLレプリケーションは、ソースサーバとレプリカサーバ間でのデータ同期を実現する仕組みである。<br>
基本的には、ソースサーバの変更をバイナリログに記録し、レプリカサーバがこれを取得して実行する方式である。<br>
<br>
==== 基本的な仕組み ====
レプリケーションの基本的な流れを以下に示す。<br>
<br>
* ソースサーバがデータベース変更をバイナリログに記録
*: INSERT, UPDATE, DELETE, CREATE TABLE等の変更がイベントとして記録される
* レプリカのI/Oスレッドがソースサーバに接続
*: レプリケーション用ユーザで認証を行う
* I/Oスレッドがバイナリログイベントを取得
*: ソースサーバのBinlog Dump Threadから受信
* 取得したイベントをリレーログに書き込み
*: レプリカサーバのローカルファイルに一時保存
* レプリカのSQLスレッドがリレーログのイベントを読み取り
*: リレーログを順次処理
* SQLスレッドがイベントを実行してデータを反映
*: ソースサーバと同じ変更をレプリカで再現
<br>
この仕組みにより、ソースサーバのデータ変更がレプリカサーバに伝播される。<br>
デフォルトでは非同期レプリケーションであり、ソースサーバはレプリカの確認を待たずに処理を継続する。<br>
<br>
==== レプリケーションスレッド ====
レプリケーションでは、以下のスレッドが動作する。<br>
<br>
<center>
{| class="wikitable"
|+ ソースサーバ側のスレッド
! スレッド名 !! 説明
|-
| Binlog Dump Thread || レプリカが接続すると起動される。<br>バイナリログの内容をレプリカに送信する。<br>複数のレプリカが接続している場合、各レプリカごとに1つのBinlog Dump Threadが動作する。
|}
</center>
<br>
<center>
{| class="wikitable"
|+ レプリカサーバ側のスレッド
! スレッド名 !! 説明
|-
| I/O Thread || ソースサーバに接続してバイナリログイベントを受信する。<br>受信したイベントをリレーログに書き込む。<br>接続が切れた場合は自動的に再接続を試行する。
|-
| SQL Thread || リレーログからイベントを読み取る。<br>イベントを実行してデータをレプリカに反映する。<br>単一スレッドまたはマルチスレッド (並列実行) で動作可能である。
|}
</center>
<br>
===== マルチスレッドレプリカ =====
<code>slave_parallel_workers</code> (または <code>replica_parallel_workers</code>) パラメータを1以上に設定することにより、複数のワーカースレッドが並列でイベントを実行できる。<br>
これにより、レプリケーション遅延の低減が期待できる。<br>
<br>
 <syntaxhighlight lang="ini">
 [mysqld]
 replica_parallel_workers = 4
 replica_parallel_type = LOGICAL_CLOCK
 </syntaxhighlight>
<br>
===== スレッドの状態確認 =====
 <syntaxhighlight lang="mysql">
 SHOW REPLICA STATUS\G
 
 -- 主要フィールド
 -- Replica_IO_Running: Yes/No (I/Oスレッドの状態)
 -- Replica_SQL_Running: Yes/No (SQLスレッドの状態)
 </syntaxhighlight>
<br>
==== レプリケーションの種類 ====
MySQLでは、以下のレプリケーション方式が提供されている。<br>
<br>
<center>
{| class="wikitable"
|+ 非同期レプリケーション
! 特性 !! 説明
|-
| デフォルトの方式 || 追加設定不要である。
|-
| ソースサーバの動作 || ソースサーバはレプリカの確認を待たない。<br>コミット後すぐにクライアントに応答を返す。
|-
| パフォーマンス || 最も高いパフォーマンスを実現する。<br>レプリカの遅延がソースに影響しない。
|-
| データ転送保証 || レプリカへのデータ転送は保証されない。<br>ソースサーバ障害時にデータ損失の可能性がある。
|}
</center>
<br>
<center>
{| class="wikitable"
|+ 半同期レプリケーション
! 特性 !! 説明
|-
| 有効化方法 || プラグインをインストールして有効化する。<br><u>rpl_semi_sync_source</u> および <u>rpl_semi_sync_replica</u> を使用する。
|-
| ソースサーバの動作 || ソースサーバは少なくとも1つのレプリカがリレーログに書き込むまで待機する。<br>コミット完了前にレプリカからの確認を待つ。
|-
| データ損失対策 || データ損失のリスクを低減する。<br>レプリカへのデータ転送を保証する。
|-
| フォールバック機能 || タイムアウト時は非同期にフォールバックする。<br>レプリカが応答しない場合でもサービス継続が可能である。
|}
</center>
<br>
<center>
{| class="wikitable"
|+ グループレプリケーション
! 特性 !! 説明
|-
| レプリケーション方式 || 複数ノード間で合意ベースのレプリケーションを実現する。<br>Paxosベースの分散合意アルゴリズムを採用している。
|-
| フェイルオーバーとマスター構成 || 自動フェイルオーバーとマルチマスター構成に対応する。<br>ノード障害時の自動復旧が可能である。
|-
| 高可用性 || 高可用性を重視したレプリケーション方式である。<br>データの一貫性を保証する。
|}
</center>
<br>
==== 用語変更 (MySQL 8.0.26以降) ====
MySQL 8.0.26以降では、レプリケーション関連の用語が変更された。<br>
MySQL 8.4では旧構文が完全削除されたため、新構文の使用が必須である。<br>
<br>
<center>
{| class="wikitable"
|+ MySQLレプリケーション用語の変更
! 旧用語 !! 新用語 !! 説明
|-
| master || source || ソースサーバ
|-
| slave || replica || レプリカサーバ
|-
| CHANGE MASTER TO || CHANGE REPLICATION SOURCE TO || レプリケーション設定変更コマンド
|-
| SHOW SLAVE STATUS || SHOW REPLICA STATUS || レプリケーション状態確認コマンド
|-
| START SLAVE || START REPLICA || レプリケーション開始コマンド
|-
| STOP SLAVE || STOP REPLICA || レプリケーション停止コマンド
|-
| rpl_semi_sync_master || rpl_semi_sync_source || 半同期レプリケーションプラグイン名
|}
</center>
<br><br>

== バイナリログ ==
バイナリログは、MySQLのレプリケーションとポイントインタイムリカバリの中核となる機能である。<br>
データベース変更を記述するイベントを格納し、レプリケーションやデータ復旧に使用される。<br>
<br>
==== バイナリログの概要 ====
バイナリログの基本的な特徴を以下に示す。<br>
<br>
* データベース変更をイベントとして記録
*: INSERT, UPDATE, DELETE, CREATE TABLE, ALTER TABLE等
* 2つの主要な役割を持つ
*: レプリケーション (レプリカサーバへのデータ転送)
*: ポイントインタイムリカバリ (任意の時点までのデータ復旧)
* MySQL 8.0ではデフォルトで有効
*: 明示的な <code>--skip-log-bin</code> オプションで無効化可能
* バイナリログファイルは連番で管理
*: mysql-bin.000001, mysql-bin.000002 のように連番が付与される
* ログローテーションが発生する
*: <code>max_binlog_size</code> を超えた場合や <code>FLUSH BINARY LOGS</code> 実行時
<br>
バイナリログの基本的な使用例を以下に示す。<br>
<br>
 <syntaxhighlight lang="mysql">
 -- バイナリログ一覧を表示
 SHOW BINARY LOGS;
 
 -- 現在使用中のバイナリログファイルを確認
 SHOW MASTER STATUS;
 
 -- バイナリログのイベントを表示
 SHOW BINLOG EVENTS IN 'mysql-bin.000001';
 
 -- ログローテーション実行
 FLUSH BINARY LOGS;
 </syntaxhighlight>
<br>
==== バイナリログ形式 ====
バイナリログには、3つの記録形式がある。<br>
MySQL 8.0のデフォルトはROW形式である。<br>
<br>
<center>
{| class="wikitable"
|+ STATEMENT形式
! 特性 !! 説明
|-
| ログ記録方式 || SQL文をそのまま記録する。実行されたSQL文が記録される。
|-
| ログサイズ || ログサイズが小さい。SQL文1つで多数の行を変更してもログサイズは小さい。
|-
| 非決定的関数での問題 || 非決定的関数で再現性に問題がある。NOW()、RAND()、UUID() 等は実行時刻により結果が変化する。
|-
| レプリカでの結果 || レプリカで異なる結果が発生する可能性がある。データ不整合の原因となる。
|}
</center>
<br>
<center>
{| class="wikitable"
|+ ROW形式
! 特性 !! 説明
|-
| ログ記録方式 || 行変更を記録する。<br>変更された行のデータを記録する。
|-
| MySQL 8.0での位置付け || MySQL 8.0のデフォルトである。<br>最も安全な形式である。
|-
| 安全性 || 最も安全である。<br>非決定的関数でもデータ整合性を保証する。
|-
| ログサイズ || ログサイズが大きい。<br>多数の行を変更した場合はログサイズが増大する。
|-
| レプリカでの実行 || レプリカでの実行が高速である。<br>SQL文の再解析が不要である。
|}
</center>
<br>
<center>
{| class="wikitable"
|+ MIXED形式
! 特性 !! 説明
|-
| デフォルト動作 || 通常はSTATEMENT形式である。<br>基本的にはSQL文を記録する。
|-
| 自動切替機能 || 必要時にROW形式に自動切替する。<br>非決定的関数が使用された場合は自動的にROW形式に切り替える。
|-
| バランス || ログサイズと安全性のバランスが取れている。<br>状況に応じて最適な形式を選択する。
|}
</center>
<br>
* 形式の設定例
*: <syntaxhighlight lang="ini">
 [mysqld]
 binlog_format = ROW
 </syntaxhighlight>
*: <br>
* 設定を動的に変更
*: <syntaxhighlight lang="mysql">
 SET GLOBAL binlog_format = 'ROW';
 SET SESSION binlog_format = 'ROW';
 </syntaxhighlight>
<br>
MySQL 8.0.34以降の変更を以下に示す。<br>
<br>
* <code>binlog_format</code> パラメータが非推奨化
*: 将来のバージョンで削除予定
* 将来はROW形式のみサポート予定
*: STATEMENT形式とMIXED形式は廃止予定
<br>
==== バイナリログ関連パラメータ ====
バイナリログの動作を制御する主要パラメータを以下に示す。<br>
<br>
<center>
{| class="wikitable"
|+ MySQLバイナリログ設定パラメータ一覧
! カテゴリ !! パラメータ名 !! 説明
|-
| 基本パラメータ || log_bin || バイナリロギングの有効 / 無効を設定する。<br>MySQL 8.0デフォルト: ON<br>設定例: log_bin = mysql-bin
|-
| 基本パラメータ || server_id || 各サーバの一意識別子<br>範囲: 1〜4294967295<br><br>レプリケーション構成では必須である。<br>設定例: server_id = 1
|-
| 基本パラメータ || binlog_format || ロギング形式 (ROW/STATEMENT/MIXED) を指定する。<br>MySQL 8.0デフォルト: ROW<br>MySQL 8.0.34以降は非推奨である。
|-
| ROW形式関連 || binlog_row_image || ROW形式での記録内容を指定する。<br>FULL (デフォルト): 全カラムを記録する。<br>MINIMAL: 変更されたカラムのみ記録する。<br>NOBLOB: BLOBカラムを除外する。
|-
| ログ管理 || binlog_expire_logs_seconds || バイナリログ保持期間 (秒) を設定する。<br>デフォルト: 2592000 (30日)。<br><br>古いログは自動削除される。
|-
| ログ管理 || max_binlog_size || バイナリログファイルの最大サイズを設定する。<br>デフォルト: 1GB。<br><br>この値を超えるとログローテーションが発生する。
|-
| ログ管理 || binlog_cache_size || トランザクション用キャッシュサイズを設定する。<br>デフォルト: 32KB。<br><br>トランザクションが大きい場合は増やす。
|-
| 安全性関連 || sync_binlog || ディスク同期ポリシーを設定する。<br>デフォルト: 1 (最も安全)<br>1: 各トランザクション後に同期する。<br>0: OSに任せる。(高速だが障害時にデータ損失)
|-
| 安全性関連 || binlog_encryption || バイナリログ暗号化の有効 / 無効を設定する。<br>MySQL 8.0.14以降で利用可能である。<br>デフォルト: OFF
|-
| セッション制御 || sql_log_bin || セッション単位でバイナリロギング制御を行う。<br>デフォルト: ON<br>設定例: <u>SET sql_log_bin = 0;</u> (一時的に無効化)
|}
</center>
<br>
設定ファイルの例を以下に示す。<br>
<br>
 <syntaxhighlight lang="ini">
 [mysqld]
 server_id = 1
 log_bin = /var/lib/mysql/mysql-bin
 binlog_format = ROW
 binlog_row_image = FULL
 max_binlog_size = 1G
 binlog_expire_logs_seconds = 2592000
 sync_binlog = 1
 binlog_cache_size = 32K
 </syntaxhighlight>
<br>
==== バイナリログの管理 ====
バイナリログの管理操作を以下に示す。<br>
<br>
* バイナリログ一覧の確認
*: <syntaxhighlight lang="mysql">
 SHOW BINARY LOGS;
 
 -- 結果例:
 -- +------------------+-----------+
 -- | Log_name         | File_size |
 -- +------------------+-----------+
 -- | mysql-bin.000001 | 1073741824|
 -- | mysql-bin.000002 | 177       |
 -- +------------------+-----------+
 </syntaxhighlight>
*: <br>
* 現在のバイナリログ位置の確認
*: <syntaxhighlight lang="mysql">
 SHOW MASTER STATUS;
 
 -- 結果例:
 -- +------------------+----------+--------------+------------------+
 -- | File             | Position | Binlog_Do_DB | Binlog_Ignore_DB |
 -- +------------------+----------+--------------+------------------+
 -- | mysql-bin.000002 | 177      |              |                  |
 -- +------------------+----------+--------------+------------------+
 </syntaxhighlight>
*: <br>
* 古いバイナリログの削除
*: <syntaxhighlight lang="mysql">
 -- 指定日時より古いログを削除
 PURGE BINARY LOGS BEFORE '2026-02-01 00:00:00';
 
 -- 指定ファイルより古いログを削除
 PURGE BINARY LOGS TO 'mysql-bin.000005';
 
 -- 全バイナリログ削除 (ソースサーバのみ、レプリケーション中は危険)
 RESET MASTER;
 </syntaxhighlight>
*: <br>
* バイナリログの検査と再生
*: <syntaxhighlight lang="bash">
 # バイナリログの内容を表示
 mysqlbinlog /var/lib/mysql/mysql-bin.000001
 
 # 特定時刻範囲のイベントを抽出
 mysqlbinlog --start-datetime="2026-02-15 10:00:00" \
             --stop-datetime="2026-02-15 11:00:00" \
             mysql-bin.000001
 
 # バイナリログを再生 (ポイントインタイムリカバリ)
 mysqlbinlog mysql-bin.000001 | mysql -u root -p
 
 # 特定位置範囲のイベントを再生
 mysqlbinlog --start-position=154 --stop-position=1234 \
             mysql-bin.000001 | mysql -u root -p
 </syntaxhighlight>
*: <br>
* バイナリログのローテーション
*: <syntaxhighlight lang="mysql">
 -- 手動でバイナリログをローテーション
 FLUSH BINARY LOGS;
 
 -- 自動ローテーション条件:
 -- 1. max_binlog_size を超えた場合
 -- 2. サーバ再起動時
 -- 3. FLUSH BINARY LOGS 実行時
 </syntaxhighlight>
<br>
詳細な設定方法は、[[MySQL - 設定ファイル]] を参照すること。<br>
<br><br>

== 位置ベースレプリケーション ==
位置ベースレプリケーションは、バイナリログファイル名と位置 (position) を使用してレプリケーションを設定する従来の方式である。<br>
シンプルな構成では有効だが、ログローテーションやフェイルオーバー時の管理が煩雑になる。<br>
<br>
==== ソースサーバの設定 ====
ソースサーバの設定手順 (<u>my.cnfファイル</u>) を以下に示す。<br>
<br>
 <syntaxhighlight lang="ini">
 [mysqld]
 server_id = 1
 log_bin = mysql-bin
 binlog_format = ROW
 </syntaxhighlight>
<br>
<center>
{| class="wikitable"
|+ パラメータの意味
! パラメータ名 !! 説明
|-
| server_id || 各サーバの一意識別子<br>レプリケーション構成内で重複しない値を設定する。
|-
| log_bin || バイナリログの有効化<br>ファイル名のプレフィックスを指定する。
|-
| binlog_format || バイナリログ形式<br>ROW形式を推奨する。
|}
</center>
<br>
* サーバ再起動
*: <syntaxhighlight lang="bash">
 systemctl restart mysqld
 </syntaxhighlight>
*: <br>
* レプリケーション用ユーザの作成
*: 認証方式の詳細は、[[MySQL - 認証プラグイン]] を参照すること。
*: <syntaxhighlight lang="mysql">
 CREATE USER 'repl_user'@'%' IDENTIFIED BY 'password';
 GRANT REPLICATION SLAVE ON *.* TO 'repl_user'@'%';
 FLUSH PRIVILEGES;
 </syntaxhighlight>
*: <br>
* バイナリログ位置の確認
*: <syntaxhighlight lang="mysql">
 SHOW MASTER STATUS;
 
 -- 結果例:
 -- +------------------+----------+--------------+------------------+
 -- | File             | Position | Binlog_Do_DB | Binlog_Ignore_DB |
 -- +------------------+----------+--------------+------------------+
 -- | mysql-bin.000001 | 154      |              |                  |
 -- +------------------+----------+--------------+------------------+
 </syntaxhighlight>
<br>
この情報 (File, Position) をレプリカサーバの設定で使用する。<br>
<br>
==== レプリカサーバの設定 ====
レプリカサーバの設定手順 (<u>my.cnfファイル</u>) を以下に示す。<br>
<br>
 <syntaxhighlight lang="ini">
 [mysqld]
 server_id = 2
 relay_log = mysql-relay-bin
 read_only = 1
 </syntaxhighlight>
<br>
<center>
{| class="wikitable"
|+ パラメータの意味
! パラメータ名 !! 説明
|-
| server_id || ソースサーバとは異なる一意識別子。例: 2, 3, 4 等
|-
| relay_log || リレーログのファイル名プレフィックス。レプリカサーバで必須である。
|-
| read_only || 読み取り専用モード。レプリカへの誤った書き込みを防止する。
|}
</center>
<br>
* サーバ再起動
*: <syntaxhighlight lang="bash">
 systemctl restart mysqld
 </syntaxhighlight>
*: <br>
* レプリケーション接続の設定 (MySQL 8.0.23以降の新構文)
*: <syntaxhighlight lang="mysql">
 CHANGE REPLICATION SOURCE TO
   SOURCE_HOST='source.example.com',
   SOURCE_PORT=3306,
   SOURCE_USER='repl_user',
   SOURCE_PASSWORD='password',
   SOURCE_LOG_FILE='mysql-bin.000001',
   SOURCE_LOG_POS=154;
 </syntaxhighlight>
<br>
<center>
{| class="wikitable"
|+ CHANGE REPLICATION SOURCE TO オプション一覧
! オプション名 !! 説明
|-
| SOURCE_HOST || ソースサーバのホスト名またはIPアドレス
|-
| SOURCE_PORT || ソースサーバのポート番号 (デフォルト: 3306)
|-
| SOURCE_USER || レプリケーション用ユーザ名
|-
| SOURCE_PASSWORD || レプリケーション用パスワード
|-
| SOURCE_LOG_FILE || ソースサーバのバイナリログファイル名
|-
| SOURCE_LOG_POS || ソースサーバのバイナリログ位置
|}
</center>
<br>
旧構文を以下に示す。(MySQL 8.0.22以前、MySQL 8.4で削除)<br>
<br>
 <syntaxhighlight lang="mysql">
 CHANGE MASTER TO
   MASTER_HOST='source.example.com',
   MASTER_PORT=3306,
   MASTER_USER='repl_user',
   MASTER_PASSWORD='password',
   MASTER_LOG_FILE='mysql-bin.000001',
   MASTER_LOG_POS=154;
 </syntaxhighlight>
<br>
<u>MySQL 8.4では旧構文が完全削除されたため、新構文の使用が必須である。</u><br>
<br>
==== レプリケーションの開始と停止 ====
レプリケーションの基本操作を以下に示す。<br>
<br>
* レプリケーション開始
*: <syntaxhighlight lang="mysql">
 START REPLICA;
 
 -- または I/O Thread のみ開始
 START REPLICA IO_THREAD;
 
 -- または SQL Thread のみ開始
 START REPLICA SQL_THREAD;
 </syntaxhighlight>
*: <br>
* レプリケーション状態確認
*: <syntaxhighlight lang="mysql">
 SHOW REPLICA STATUS\G
 
 -- 主要フィールド:
 -- Replica_IO_Running: Yes/No (I/Oスレッドの状態)
 -- Replica_SQL_Running: Yes/No (SQLスレッドの状態)
 -- Seconds_Behind_Source: レプリケーション遅延秒数
 -- Last_Error: エラーメッセージ
 -- Source_Host: ソースサーバのホスト名
 -- Source_Log_File: 現在読み取り中のバイナリログファイル
 -- Read_Source_Log_Pos: 読み取り位置
 
 -- 正常に動作している場合
 -- Replica_IO_Running: Yes
 -- Replica_SQL_Running: Yes
 -- Seconds_Behind_Source: 0
 </syntaxhighlight>
*: <br>
* レプリケーション停止
*: <syntaxhighlight lang="mysql">
 STOP REPLICA;
 
 -- または I/O Thread のみ停止
 STOP REPLICA IO_THREAD;
 
 -- または SQL Thread のみ停止
 STOP REPLICA SQL_THREAD;
 </syntaxhighlight>
*: <br>
* レプリケーション設定のリセット
*: <syntaxhighlight lang="mysql">
 -- レプリケーション設定を削除
 RESET REPLICA;
 
 -- リレーログも削除
 RESET REPLICA ALL;
 </syntaxhighlight>
<br>
旧構文を以下に示す。(MySQL 8.0.22以前、MySQL 8.4で削除)<br>
<br>
 <syntaxhighlight lang="mysql">
 START SLAVE;
 SHOW SLAVE STATUS\G
 STOP SLAVE;
 RESET SLAVE;
 </syntaxhighlight>
<br>
==== 位置ベースレプリケーションの制約 ====
位置ベースレプリケーションには以下に示す制約がある。<br>
<br>
* バイナリログファイル名と位置の管理が煩雑
*: ログローテーションのたびに位置情報が変化
* フェイルオーバー時の設定変更が複雑
*: 新しいソースサーバのバイナリログ位置を手動で特定する必要
* 旧バイナリログ削除後は復旧不可
*: 必要なバイナリログが削除されるとレプリケーション再構築が必要
* マルチソース構成での管理が困難
*: 複数のソースサーバの位置情報を個別管理
<br>
これらの問題を解決するため、現在はGTIDレプリケーションが推奨される。<br>
<br><br>

== GTIDレプリケーション ==
GTID (Global Transaction Identifier) レプリケーションは、グローバルトランザクション識別子を使用したレプリケーション方式である。<br>
位置ベースレプリケーションの制約を解決し、フェイルオーバーやトポロジ変更が容易になる。<br>
<br>
==== GTIDの概要 ====
下表に、GTIDの基本的な特徴を示す。<br>
<br>
<center>
{| class="wikitable"
|+ GTID (Global Transaction ID) の基本的な特徴
! 特徴 !! 説明
|-
| 各トランザクションに一意な識別子を付与 || サーバUUIDとトランザクション番号の組み合わせで実現される。<br>形式は server_uuid:transaction_id である。<br>例: 3E11FA47-71CA-11E1-9E33-C80AA9429562:23
|-
| バイナリログ位置管理が不要 || GTIDで自動的に同期ポイントを決定される。
|-
| フェイルオーバーが容易 || レプリカが新しいソースに接続する際に自動的に適切な位置を特定される。
|-
| レプリケーショントポロジの変更が簡単 || 複雑なレプリケーション構成でも管理が容易である。
|}
</center>
<br>
GTIDの構造を以下に示す。<br>
<br>
 server_uuid: サーバの一意識別子 (自動生成)
 transaction_id: トランザクション番号 (1から始まる連番)
<br>
GTIDセットの例を以下に示す。<br>
<br>
 3E11FA47-71CA-11E1-9E33-C80AA9429562:1-5
 3E11FA47-71CA-11E1-9E33-C80AA9429562:1-5:10-15
 3E11FA47-71CA-11E1-9E33-C80AA9429562:1-5,
 AAAAAAAA-BBBB-CCCC-DDDD-EEEEEEEEEEEE:1-10
<br>
==== GTIDの有効化 ====
GTIDを有効化する設定手順を以下に示す。<br>
<br>
設定ファイル (<u>my.cnfファイル</u>) を編集する。<br>
<br>
 <syntaxhighlight lang="ini">
 [mysqld]
 server_id = 1
 log_bin = mysql-bin
 gtid_mode = ON
 enforce_gtid_consistency = ON
 </syntaxhighlight>
<br>
<center>
{| class="wikitable"
|+ GTIDパラメータの意味
! パラメータ名 !! 説明
|-
| gtid_mode || GTIDモードの有効化を制御する。<br><br>ON: GTID有効<br>OFF: GTID無効
|-
| enforce_gtid_consistency || GTID一貫性の強制を制御する<br><br>ON: GTIDで許可されない操作を禁止する。<br>OFF: 制約チェックなし
|}
</center>
<br>
MySQLサーバを再起動する。<br>
<br>
 systemctl restart mysqld
<br>
GTID状態を確認する。<br>
<br>
 <syntaxhighlight lang="mysql">
 SHOW VARIABLES LIKE 'gtid_mode';
 SHOW VARIABLES LIKE 'enforce_gtid_consistency';
 
 -- 実行済みGTIDセットの確認
 SELECT @@GLOBAL.gtid_executed;
 SELECT @@GLOBAL.gtid_purged;
 </syntaxhighlight>
<br>
==== GTIDベースのレプリケーション設定 ====
GTIDレプリケーションの設定手順を以下に示す。<br>
<br>
ソースサーバを設定する。(<u>my.cnfファイル</u>)<br>
<br>
 <syntaxhighlight lang="ini">
 [mysqld]
 server_id = 1
 log_bin = mysql-bin
 gtid_mode = ON
 enforce_gtid_consistency = ON
 binlog_format = ROW
 </syntaxhighlight>
<br>
レプリケーション用ユーザを作成する。<br>
<br>
 <syntaxhighlight lang="mysql">
 CREATE USER 'repl_user'@'%' IDENTIFIED BY 'password';
 GRANT REPLICATION SLAVE ON *.* TO 'repl_user'@'%';
 FLUSH PRIVILEGES;
 </syntaxhighlight>
<br>
レプリカサーバを設定する。(<u>my.cnfファイル</u>):<br>
<br>
 <syntaxhighlight lang="ini">
 [mysqld]
 server_id = 2
 relay_log = mysql-relay-bin
 gtid_mode = ON
 enforce_gtid_consistency = ON
 read_only = 1
 </syntaxhighlight>
<br>
レプリケーション接続を設定する。<br>
<br>
 <syntaxhighlight lang="mysql">
 CHANGE REPLICATION SOURCE TO
   SOURCE_HOST='source.example.com',
   SOURCE_PORT=3306,
   SOURCE_USER='repl_user',
   SOURCE_PASSWORD='password',
   SOURCE_AUTO_POSITION=1;
 </syntaxhighlight>
<br>
<center>
{| class="wikitable"
|+ GTID自動位置決定の重要な違い
! 項目 !! 説明
|-
| SOURCE_AUTO_POSITION=1 || GTIDベースの自動位置決定を有効化する。<br><u>SOURCE_LOG_FILE</u>、<u>SOURCE_LOG_POS</u> の指定は不要である。
|-
| レプリカの動作 || レプリカが自動的に最適な同期ポイントを決定される。<br>既に実行済みのGTIDをスキップして次のトランザクションから実行される。
|}
</center>
<br>
レプリケーションを開始する。<br>
<br>
 <syntaxhighlight lang="mysql">
 START REPLICA;
 
 -- 状態確認
 SHOW REPLICA STATUS\G
 
 -- 主要フィールド:
 -- Auto_Position: 1 (GTIDモード有効)
 -- Retrieved_Gtid_Set: 取得したGTIDセット
 -- Executed_Gtid_Set: 実行済みGTIDセット
 </syntaxhighlight>
<br>
==== GTIDの制約と注意事項 ====
GTIDレプリケーションには以下の制約がある。<br>
<br>
<center>
{| class="wikitable"
|+ GTID有効時の制約事項
! 制約事項 !! 説明
|-
| CREATE TABLE ... SELECT 禁止 (MySQL 8.0.21で緩和) || この構文は2つの操作 (CREATE と INSERT) を含むため制限されている。<br><br>回避策: CREATE TABLE と INSERT INTO ... SELECT を分離する。
|-
| 一時テーブルの制限 || <u>CREATE TEMPORARY TABLE</u> はGTID内では制限されている。
|-
| トランザクション内での非トランザクショナルテーブル操作の制限 || MyISAM等の非トランザクショナルテーブルの使用に制約がある。
|}
</center>
<br>
<u>enforce_gtid_consistency=ON</u> で禁止される操作を以下に示す。<br>
<br>
* 一般テーブル
*: <syntaxhighlight lang="mysql">
 -- CREATE TABLE ... SELECT (MySQL 8.0.20以前)
 CREATE TABLE new_table SELECT * FROM old_table;
 -- ERROR: Statement violates GTID consistency
 
 -- 回避策
 CREATE TABLE new_table LIKE old_table;
 INSERT INTO new_table SELECT * FROM old_table;
 </syntaxhighlight>
*: <br>
* 一時テーブル
*: <syntaxhighlight lang="mysql">
 -- トランザクション外では使用可能
 CREATE TEMPORARY TABLE temp_data (id INT);
 INSERT INTO temp_data VALUES (1);
 DROP TEMPORARY TABLE temp_data;
 
 -- トランザクション内では制限
 START TRANSACTION;
 CREATE TEMPORARY TABLE temp_data (id INT); -- 制限される
 COMMIT;
 </syntaxhighlight>
<br>
==== オンラインでのGTID有効化 ====
既存のレプリケーション構成でGTIDを段階的に有効化する手順を以下に示す。<br>
<br>
以下の手順により、レプリケーションを停止せずにGTIDモードに移行できる。<br>
<br>
# ステップ1 : GTID一貫性チェックを警告モードで有効化
#: エラーログを監視して警告が出ないことを確認する。
#: <syntaxhighlight lang="mysql">
 SET GLOBAL ENFORCE_GTID_CONSISTENCY = WARN;
 </syntaxhighlight>
#: <br>
# ステップ2 : GTID一貫性を強制
#: <syntaxhighlight lang="mysql">
 SET GLOBAL ENFORCE_GTID_CONSISTENCY = ON;
 </syntaxhighlight>
#: <br>
# ステップ3 : GTIDモードをOFF_PERMISSIVEに変更
#: この状態では、匿名トランザクション (GTID無し) と GTID付きトランザクションの両方を受け入れる。
#: <syntaxhighlight lang="mysql">
 SET GLOBAL GTID_MODE = OFF_PERMISSIVE;
 </syntaxhighlight>
#: <br>
# ステップ4 : GTIDモードをON_PERMISSIVEに変更
#: この状態では、新規トランザクションはGTID付きで記録され、匿名トランザクションも処理可能。
#: <syntaxhighlight lang="mysql">
 SET GLOBAL GTID_MODE = ON_PERMISSIVE;
 </syntaxhighlight>
#: <br>
# ステップ5 : 全匿名トランザクションの完了を確認
#: <syntaxhighlight lang="mysql">
 SHOW STATUS LIKE 'ONGOING_ANONYMOUS_TRANSACTION_COUNT';
 
 -- 結果が0になるまで待機
 </syntaxhighlight>
#: <br>
# ステップ6 : GTIDモードをONに変更
#: <syntaxhighlight lang="mysql">
 SET GLOBAL GTID_MODE = ON;
 </syntaxhighlight>
#: <br>
# ステップ7 : レプリカで <u>SOURCE_AUTO_POSITION=1</u> に変更
#: <syntaxhighlight lang="mysql">
 STOP REPLICA;
 CHANGE REPLICATION SOURCE TO SOURCE_AUTO_POSITION=1;
 START REPLICA;
 </syntaxhighlight>
#: <br>
# ステップ8 : 設定ファイルに永続化 (<u>my.cnfファイル</u>)
#: <syntaxhighlight lang="ini">
 [mysqld]
 gtid_mode = ON
 enforce_gtid_consistency = ON
 </syntaxhighlight>
<br><br>

== 半同期レプリケーション ==
半同期レプリケーションは、非同期レプリケーションとフルシンクロナスレプリケーションの中間に位置する方式である。<br>
ソースサーバのデータ損失リスクを低減しつつ、パフォーマンスへの影響を最小限に抑える。<br>
<br>
==== 半同期レプリケーションの仕組み ====
半同期レプリケーションの動作を以下に示す。<br>
<br>
<center>
{| class="wikitable"
|+ 半同期レプリケーションの動作と特性
! カテゴリ !! 項目 !! 説明
|-
| rowspan="4" | 動作フロー || ソースサーバがトランザクションをコミット || バイナリログに書き込まれる。
|-
| 少なくとも1つのレプリカがリレーログに書き込み完了 || レプリカからの確認 (ACK) を待つ。
|-
| レプリカからの確認を受信 || リレーログへの書き込み完了を通知される。
|-
| ソースサーバがクライアントにコミット完了を返す || クライアントに応答を返される。
|-
| rowspan="2" | 非同期レプリケーションとの違い || 非同期レプリケーション || ソースサーバはレプリカの確認を待たない。<br>レプリカへのデータ転送は保証されない。
|-
| 半同期レプリケーション || ソースサーバは少なくとも1つのレプリカからの確認を待つ。<br>レプリカへのデータ転送を保証する。
|-
| rowspan="2" | 利点 || データ損失リスク低減 || ソースサーバ障害時のデータ損失リスクを低減する。<br>コミット済みトランザクションは少なくとも1つのレプリカに転送済みである。
|-
| フェイルオーバー時のデータ一貫性向上 || レプリカが最新のデータを持つため、データ一貫性が向上される。
|-
| rowspan="2" | 欠点 || レイテンシ増加 || レプリカからの確認待ちによるレイテンシが増加する。<br>非同期レプリケーションより遅い。
|-
| タイムアウト発生 || レプリカがダウンするとタイムアウトが発生する。<br>タイムアウト後は非同期にフォールバックされる。
|}
</center>
<br>
==== プラグインのインストールと設定 ====
半同期レプリケーションはプラグインとして提供される。<br>
MySQL 8.0.26以降の新プラグイン名を使用する。<br>
<br>
* ソースサーバでのプラグインインストール
*: <syntaxhighlight lang="mysql">
 INSTALL PLUGIN rpl_semi_sync_source SONAME 'semisync_source.so';
 
 -- プラグイン確認
 SHOW PLUGINS;
 </syntaxhighlight>
*: <br>
* レプリカサーバでのプラグインインストール
*: <syntaxhighlight lang="mysql">
 INSTALL PLUGIN rpl_semi_sync_replica SONAME 'semisync_replica.so';
 
 -- プラグイン確認
 SHOW PLUGINS;
 </syntaxhighlight>
*: <br>
* 旧プラグイン名 (MySQL 8.0.25以前、MySQL 8.4で削除)
*: <syntaxhighlight lang="mysql">
 -- ソース側 (旧)
 INSTALL PLUGIN rpl_semi_sync_master SONAME 'semisync_master.so';
 
 -- レプリカ側 (旧)
 INSTALL PLUGIN rpl_semi_sync_slave SONAME 'semisync_slave.so';
 </syntaxhighlight>
*: <br>
* ソースサーバでの有効化
*: <syntaxhighlight lang="mysql">
 SET GLOBAL rpl_semi_sync_source_enabled = 1;
 
 -- 確認
 SHOW VARIABLES LIKE 'rpl_semi_sync_source_enabled';
 </syntaxhighlight>
*: <br>
* レプリカサーバでの有効化
*: <syntaxhighlight lang="mysql">
 SET GLOBAL rpl_semi_sync_replica_enabled = 1;
 
 -- 確認
 SHOW VARIABLES LIKE 'rpl_semi_sync_replica_enabled';
 
 -- レプリケーションを再起動 (設定反映のため)
 STOP REPLICA IO_THREAD;
 START REPLICA IO_THREAD;
 </syntaxhighlight>
*: <br>
* 設定ファイルでの永続化 (<u>my.cnfファイル</u>)
** ソースサーバ
**: <syntaxhighlight lang="ini">
 [mysqld]
 plugin_load_add = semisync_source.so
 rpl_semi_sync_source_enabled = 1
 rpl_semi_sync_source_timeout = 10000
 </syntaxhighlight>
**: <br>
** レプリカサーバ
**: <syntaxhighlight lang="ini">
 [mysqld]
 plugin_load_add = semisync_replica.so
 rpl_semi_sync_replica_enabled = 1
 </syntaxhighlight>
<br>
==== rpl_semi_sync_source_wait_point ====
半同期レプリケーションには、2つの待機ポイント設定がある。<br>
<br>
AFTER_SYNC (デフォルト、ロスレス半同期):<br>
<br>
<center>
{| class="wikitable"
|+ BEFORE_COMMIT (MySQL 8.0.26以降のデフォルト)
! カテゴリ !! 説明
|-
| rowspan="5" | トランザクション処理順序 || 1. バイナリログ書き込み
|-
| 2. ディスク同期 (sync_binlog=1の場合)
|-
| 3. レプリカからの確認待ち
|-
| 4. ストレージエンジンコミット
|-
| 5. クライアントに応答
|-
| rowspan="2" | メリット || ソースサーバ障害時もコミット済みトランザクションはレプリカに送信済みである。
|-
| データ損失が発生しない (ロスレス)
|-
| デメリット || クライアントはコミット前にレプリカの確認を待つ。
|}
</center>
<br>
<center>
{| class="wikitable"
|+ AFTER_COMMIT (従来型)
! カテゴリ !! 説明
|-
| rowspan="4" | トランザクション処理順序 || 1. バイナリログ書き込み
|-
| 2. ストレージエンジンコミット
|-
| 3. レプリカからの確認待ち
|-
| 4. クライアントに応答
|-
| メリット || ストレージエンジンコミット後にレプリカ確認を行う。
|-
| rowspan="2" | デメリット || ソースサーバ障害時にデータ喪失の可能性がある。
|-
| コミット済みだがレプリカ未転送のトランザクションが存在しうる。
|}
</center>
<br>
設定例を以下に示す。<br>
<br>
 <syntaxhighlight lang="mysql">
 SET GLOBAL rpl_semi_sync_source_wait_point = 'AFTER_SYNC';
 
 -- または
 SET GLOBAL rpl_semi_sync_source_wait_point = 'AFTER_COMMIT';
 </syntaxhighlight>
<br>
<u>データ損失を防ぐため、AFTER_SYNC (デフォルト) の使用を推奨する。</u><br>
<br>
==== タイムアウトと非同期へのフォールバック ====
半同期レプリケーションのタイムアウト動作を以下に示す。<br>
<br>
<center>
{| class="wikitable"
|+ 半同期レプリケーションのタイムアウト設定と確認レプリカ数
! カテゴリ !! パラメータ / 項目 !! 説明
|-
| rowspan="1" | タイムアウト設定 || rpl_semi_sync_source_timeout || レプリカからの確認待ち時間 (ミリ秒) を設定する。<br>デフォルト: 10000 (10秒)<br><br>設定例: <u>SET GLOBAL rpl_semi_sync_source_timeout = 5000;</u>
|-
| rowspan="2" | タイムアウト時の動作 || 指定時間内にレプリカから確認が得られない場合 || 自動的に非同期レプリケーションにフォールバックされる。
|-
|| レプリカが復旧した場合 || レプリカが復旧すると自動的に半同期に戻る。<br>サービスの継続性を保証される。
|-
| rowspan="1" | 確認必要なレプリカ数 || rpl_semi_sync_source_wait_for_replica_count || 確認を待つレプリカの最小数を設定する。<br>デフォルト: 1<br><br>設定例: <u>SET GLOBAL rpl_semi_sync_source_wait_for_replica_count = 2;</u>
|}
</center>
<br>
ステータスを確認する。<br>
<br>
 <syntaxhighlight lang="mysql">
 SHOW STATUS LIKE 'Rpl_semi_sync_source%';
 
 -- 主要ステータス:
 -- Rpl_semi_sync_source_status: ON/OFF (半同期状態)
 -- Rpl_semi_sync_source_clients: 接続中の半同期レプリカ数
 -- Rpl_semi_sync_source_yes_tx: 半同期で成功したトランザクション数
 -- Rpl_semi_sync_source_no_tx: 非同期にフォールバックしたトランザクション数
 -- Rpl_semi_sync_source_timeoutes: タイムアウト回数
 </syntaxhighlight>
<br>
レプリカ側のステータスを確認する。<br>
<br>
 <syntaxhighlight lang="mysql">
 SHOW STATUS LIKE 'Rpl_semi_sync_replica%';
 
 -- 主要ステータス:
 -- Rpl_semi_sync_replica_status: ON/OFF (半同期状態)
 </syntaxhighlight>
<br>
設定ファイルの例を以下に示す。(<u>my.cnfファイル</u>)<br>
<br>
 <syntaxhighlight lang="ini">
 [mysqld]
 plugin_load_add = semisync_source.so
 rpl_semi_sync_source_enabled = 1
 rpl_semi_sync_source_timeout = 10000
 rpl_semi_sync_source_wait_point = AFTER_SYNC
 rpl_semi_sync_source_wait_for_replica_count = 1
 </syntaxhighlight>
<br><br>

== レプリケーションフィルタ ==
レプリケーションフィルタは、特定のデータベースやテーブルのみをレプリケーション対象とする機能である。<br>
不要なデータのレプリケーションを防ぎ、ストレージとネットワーク帯域を節約できる。<br>
<br>
==== データベースレベルのフィルタ ====
データベース単位でレプリケーション対象を制御する方法を以下に示す。<br>
<br>
<center>
{| class="wikitable"
|+ ソース側フィルタ
! パラメータ名 !! 説明
|-
| binlog_do_db || 指定したデータベースのみバイナリログに記録する。<br>設定例: <u>binlog_do_db = db1</u>
|-
| binlog_ignore_db || 指定したデータベースをバイナリログに記録しない。<br>設定例: <u>binlog_ignore_db = test</u>
|}
</center>
<br>
<center>
{| class="wikitable"
|+ レプリカ側フィルタ
! パラメータ名 !! 説明
|-
| replicate_do_db || 指定したデータベースのみレプリケーションする。<br>設定例: <u>replicate_do_db = db1</u>
|-
| replicate_ignore_db || 指定したデータベースをレプリケーションしない。<br>設定例: <u>replicate_ignore_db = test</u>
|}
</center>
<br>
設定ファイルでの例を以下に示す。(<u>my.cnfファイル</u>)<br>
<br>
 <syntaxhighlight lang="ini">
 [mysqld]
 # ソース側
 binlog_do_db = production_db
 binlog_ignore_db = test_db
 binlog_ignore_db = development_db
 
 # レプリカ側
 replicate_do_db = production_db
 replicate_ignore_db = test_db
 </syntaxhighlight>
<br>
動的に設定を変更する方法を以下に示す。<br>
<br>
 <syntaxhighlight lang="mysql">
 CHANGE REPLICATION FILTER REPLICATE_DO_DB = (db1, db2);
 CHANGE REPLICATION FILTER REPLICATE_IGNORE_DB = (test, temp);
 </syntaxhighlight>
<br>
現在のフィルタ設定を確認する。<br>
<br>
 <syntaxhighlight lang="mysql">
 SHOW REPLICA STATUS\G
 
 -- フィルタ関連フィールド:
 -- Replicate_Do_DB: レプリケーション対象データベース
 -- Replicate_Ignore_DB: レプリケーション除外データベース
 </syntaxhighlight>
<br>
==== テーブルレベルのフィルタ ====
テーブル単位でレプリケーション対象を制御する方法を以下に示す。<br>
<br>
<center>
{| class="wikitable"
|+ テーブル指定フィルタ
! パラメータ名 !! 説明
|-
| replicate_do_table || 指定したテーブルのみレプリケーションする。<br>設定例: <u>replicate_do_table = db1.table1</u>
|-
| replicate_ignore_table || 指定したテーブルをレプリケーションしない。<br>設定例: <u>replicate_ignore_table = db1.temp_table</u>
|}
</center>
<br>
<center>
{| class="wikitable"
|+ ワイルドカードフィルタ
! パラメータ名 !! 説明
|-
| replicate_wild_do_table || ワイルドカードパターンでレプリケーション対象を指定する。<br>設定例: <u>replicate_wild_do_table = db1.log_%</u>
|-
| replicate_wild_ignore_table || ワイルドカードパターンでレプリケーション除外を指定する。<br>設定例: <u>replicate_wild_ignore_table = %.temp_%</u>
|}
</center>
<br>
設定ファイルでの例を以下に示す。(<u>my.cnfファイル</u>)<br>
<br>
 <syntaxhighlight lang="ini">
 [mysqld]
 # 特定テーブルのみレプリケーション
 replicate_do_table = db1.orders
 replicate_do_table = db1.customers
 
 # 特定テーブルを除外
 replicate_ignore_table = db1.temp_data
 
 # ワイルドカードパターン
 replicate_wild_do_table = db1.log_%
 replicate_wild_ignore_table = %.cache_%
 </syntaxhighlight>
<br>
動的に設定を変更する方法を以下に示す。<br>
<br>
 <syntaxhighlight lang="mysql">
 CHANGE REPLICATION FILTER REPLICATE_DO_TABLE = (db1.table1, db2.table2);
 CHANGE REPLICATION FILTER REPLICATE_IGNORE_TABLE = (db1.temp_table);
 CHANGE REPLICATION FILTER REPLICATE_WILD_DO_TABLE = ('db1.log_%');
 CHANGE REPLICATION FILTER REPLICATE_WILD_IGNORE_TABLE = ('%.cache_%');
 </syntaxhighlight>
<br>
複数フィルタの組み合わせ方法を以下に示す。<br>
<br>
 <syntaxhighlight lang="mysql">
 CHANGE REPLICATION FILTER
   REPLICATE_DO_DB = (db1),
   REPLICATE_WILD_IGNORE_TABLE = ('db1.temp_%');
 </syntaxhighlight>
<br>
==== フィルタの注意事項 ====
レプリケーションフィルタ使用時の注意点を以下に示す。<br>
<br>
<center>
{| class="wikitable"
|+ binlog_formatによる動作の違い
! binlog_format !! 説明
|-
| STATEMENT形式 || デフォルトデータベース (USE文で指定) を基準にフィルタされる。<br>クロスデータベース文で予期しない動作が発生する可能性がある。
|-
| ROW形式 || 変更された行のデータベースを基準にフィルタされる。<br>より正確なフィルタリングが実現される。
|}
</center>
<br>
クロスデータベース文の扱いを以下に示す。<br>
<br>
 <syntaxhighlight lang="mysql">
 USE db1;
 UPDATE db2.table1 SET col1 = 1;
 
 -- STATEMENT形式: db1がフィルタ対象かで判定
 -- ROW形式:       db2がフィルタ対象かで判定
 </syntaxhighlight>
<br>
<u>※ROW形式での推奨事項</u><br>
<u>データ整合性のため、ROW形式でのレプリケーションフィルタ使用を推奨する。</u><br>
<br>
GTIDとフィルタの組み合わせを以下に示す。<br>
* GTIDモードでフィルタを使用する場合の制約
*: マルチソース構成では各チャネルで同じフィルタ設定が必要となる。
*: GTIDセットの不整合に注意する。
<br>
<u>※外部キー制約の問題</u><br>
* <u>親テーブルと子テーブルを異なるフィルタで扱うと整合性が破綻</u>
*: 外部キー制約を持つテーブルは同じフィルタ設定を推奨
<br>
 <syntaxhighlight lang="mysql">
 -- 親テーブルと子テーブルは同じフィルタ設定
 CHANGE REPLICATION FILTER
   REPLICATE_DO_TABLE = (db1.parent, db1.child);
 </syntaxhighlight>
<br>
フィルタのクリア方法を以下に示す。<br>
<br>
 <syntaxhighlight lang="mysql">
 CHANGE REPLICATION FILTER REPLICATE_DO_DB = ();
 CHANGE REPLICATION FILTER REPLICATE_IGNORE_DB = ();
 CHANGE REPLICATION FILTER REPLICATE_DO_TABLE = ();
 CHANGE REPLICATION FILTER REPLICATE_WILD_DO_TABLE = ();
 </syntaxhighlight>
<br><br>

== マルチソースレプリケーション ==
マルチソースレプリケーションは、1つのレプリカサーバが複数のソースサーバから並行してレプリケーションを受ける機能である。<br>
複数のソースサーバのデータを1つのレプリカサーバに集約する場合に有用である。<br>
<br>
==== マルチソースレプリケーションの概要 ====
マルチソースレプリケーションの特徴を以下に示す。<br>
<br>
* 1つのレプリカが複数のソースから並行レプリケーション
*: 各ソースサーバは独立したチャネルで接続
* 各ソースに独立したチャネル (FOR CHANNEL 'channel_name')
*: チャネル名でソースサーバを識別
* 各チャネルは独自のI/O Thread、SQL Thread、リレーログを持つ
*: 完全に独立したレプリケーション処理
* GTIDモードと位置ベースの両方で使用可能
*: GTIDモードを推奨
<br>
使用例:<br>
<br>
* 複数のソースサーバのデータを1つのレプリカに集約
*: データウェアハウスやレポーティングサーバ
* 地理的に分散したソースサーバからのデータ収集
*: 複数拠点のデータを中央で集約
* シャーディング構成での集約レプリカ
*: 各シャードのデータを1つのレプリカに統合
<br>
==== 設定方法 ====
マルチソースレプリケーションの設定手順を以下に示す。<br>
<br>
レプリカサーバを設定する。(<u>my.cnfファイル</u>)<br>
<br>
 <syntaxhighlight lang="ini">
 [mysqld]
 server_id = 100
 relay_log = mysql-relay-bin
 gtid_mode = ON
 enforce_gtid_consistency = ON
 master_info_repository = TABLE
 relay_log_info_repository = TABLE
 </syntaxhighlight>
<br>
<center>
{| class="wikitable"
|+ マルチソースレプリケーション設定パラメータ
! パラメータ名 !! 説明
|-
| master_info_repository = TABLE || ソース情報をテーブルに保存する。マルチソース必須である。
|-
| relay_log_info_repository = TABLE || リレーログ情報をテーブルに保存する。マルチソース必須である。
|}
</center>
<br>
* チャネルごとのレプリケーション設定
*: <syntaxhighlight lang="mysql">
 -- ソース1への接続設定
 CHANGE REPLICATION SOURCE TO
   SOURCE_HOST='source1.example.com',
   SOURCE_PORT=3306,
   SOURCE_USER='repl_user',
   SOURCE_PASSWORD='password',
   SOURCE_AUTO_POSITION=1
   FOR CHANNEL 'source1';
 
 -- ソース2への接続設定
 CHANGE REPLICATION SOURCE TO
   SOURCE_HOST='source2.example.com',
   SOURCE_PORT=3306,
   SOURCE_USER='repl_user',
   SOURCE_PASSWORD='password',
   SOURCE_AUTO_POSITION=1
   FOR CHANNEL 'source2';
 
 -- ソース3への接続設定
 CHANGE REPLICATION SOURCE TO
   SOURCE_HOST='source3.example.com',
   SOURCE_PORT=3306,
   SOURCE_USER='repl_user',
   SOURCE_PASSWORD='password',
   SOURCE_AUTO_POSITION=1
   FOR CHANNEL 'source3';
 </syntaxhighlight>
*: <br>
* チャネル別のレプリケーション開始
*: <syntaxhighlight lang="mysql">
 -- 全チャネル開始
 START REPLICA;
 
 -- 特定チャネルのみ開始
 START REPLICA FOR CHANNEL 'source1';
 START REPLICA FOR CHANNEL 'source2';
 
 -- 特定チャネルのI/Oスレッドのみ開始
 START REPLICA IO_THREAD FOR CHANNEL 'source1';
 </syntaxhighlight>
*: <br>
* チャネル別のレプリケーション停止
*: <syntaxhighlight lang="mysql">
 -- 全チャネル停止
 STOP REPLICA;
 
 -- 特定チャネルのみ停止
 STOP REPLICA FOR CHANNEL 'source1';
 
 -- 特定チャネルのSQLスレッドのみ停止
 STOP REPLICA SQL_THREAD FOR CHANNEL 'source2';
 </syntaxhighlight>
*: <br>
* チャネル別の状態確認
*: <syntaxhighlight lang="mysql">
 -- 全チャネルの状態確認
 SHOW REPLICA STATUS\G
 
 -- 特定チャネルの状態確認
 SHOW REPLICA STATUS FOR CHANNEL 'source1'\G
 </syntaxhighlight>
*: <br>
* チャネル別のフィルタ設定
*: <syntaxhighlight lang="mysql">
 -- source1チャネルはdb1のみレプリケーション
 CHANGE REPLICATION FILTER
   REPLICATE_DO_DB = (db1)
   FOR CHANNEL 'source1';
 
 -- source2チャネルはdb2のみレプリケーション
 CHANGE REPLICATION FILTER
   REPLICATE_DO_DB = (db2)
   FOR CHANNEL 'source2';
 </syntaxhighlight>
*: <br>
* チャネルのリセット
*: <syntaxhighlight lang="mysql">
 -- 特定チャネルのレプリケーション設定を削除
 RESET REPLICA FOR CHANNEL 'source1';
 RESET REPLICA ALL FOR CHANNEL 'source1';
 </syntaxhighlight>
*: <br>
* Performance Schemaでのモニタリング
*: <syntaxhighlight lang="mysql">
 SELECT * FROM performance_schema.replication_connection_status;
 SELECT * FROM performance_schema.replication_applier_status_by_channel;
 </syntaxhighlight>
<br>
<u>※注意</u><br>
* <u>各ソースサーバの server_id は一意である必要がある。</u>
*: 同じserver_idは使用不可
* <u>データベース名の衝突に注意する。</u>
*: 複数ソースで同じデータベース名を使用する場合はフィルタで制御する。
* <u>GTIDモード使用時はGTIDセットの管理に注意する。</u>
*: 各ソースのGTIDセットが重複しないように設定する。
<br><br>

== 遅延レプリケーション ==
遅延レプリケーションは、レプリカサーバでの変更実行を意図的に遅延させる機能である。<br>
誤操作からの回復や過去のデータ状態確認に使用される。<br>
<br>
==== 概要と使用場面 ====
遅延レプリケーションの特徴を以下に示す。<br>
<br>
* レプリカでの変更実行を指定時間だけ遅延
*: SOURCE_DELAY (旧: MASTER_DELAY) オプションで設定
* ソースサーバからのバイナリログ取得は通常通り
*: I/Oスレッドは遅延なし
* SQLスレッドの実行のみを遅延
*: リレーログの実行を指定時間遅らせる
<br>
<center>
{| class="wikitable"
|+ 遅延レプリカの使用場面
! 用途 !! 説明
|-
| 誤操作からの回復 || ソースサーバで誤ってDROPやDELETEを実行した場合、遅延レプリカから復旧することができる。
|-
| テーブル削除やデータ削除の誤操作対策 || 遅延期間内であれば遅延レプリカから復旧可能である。
|-
| 過去のデータ状態確認 || 特定時点のデータ状態を参照することができる。
|-
| 遅延テスト || レプリケーション遅延が発生した場合の動作確認を行うことができる。
|}
</center>
<br>
<center>
{| class="wikitable"
|+ 遅延レプリカからの回復の流れ
! ステップ !! 説明
|-
| ソースサーバで誤操作を実行 || 例: <u>DROP TABLE orders;</u>
|-
| 誤操作を検知 || 遅延レプリカにはまだ反映されていない。
|-
| 遅延レプリカでレプリケーション停止 || 誤操作のイベントが実行される前に停止する。
|-
| 遅延レプリカからデータを復旧 || <code>mysqldump</code> コマンド や バックアップツールでデータを取得する。
|-
| ソースサーバにデータを復元 || 誤操作前の状態に戻す。
|}
</center>
<br>
==== 設定方法 ====
遅延レプリケーションの設定手順を以下に示す。<br>
<br>
* 遅延時間の設定
*: <syntaxhighlight lang="mysql">
 -- 1時間 (3600秒) 遅延
 CHANGE REPLICATION SOURCE TO SOURCE_DELAY = 3600;
 
 -- 30分 (1800秒) 遅延
 CHANGE REPLICATION SOURCE TO SOURCE_DELAY = 1800;
 
 -- 遅延なし (通常レプリケーション)
 CHANGE REPLICATION SOURCE TO SOURCE_DELAY = 0;
 </syntaxhighlight>
*: <br>
* 旧構文 (MySQL 8.0.22以前、MySQL 8.4で削除)
*: <syntaxhighlight lang="mysql">
 CHANGE MASTER TO MASTER_DELAY = 3600;
 </syntaxhighlight>
*: <br>
* マルチソースレプリケーションでのチャネル別設定
*: <syntaxhighlight lang="mysql">
 -- 特定チャネルのみ遅延
 CHANGE REPLICATION SOURCE TO SOURCE_DELAY = 3600 FOR CHANNEL 'source1';
 </syntaxhighlight>
*: <br>
* 遅延状態の確認
*: <syntaxhighlight lang="mysql">
 SHOW REPLICA STATUS\G
 
 -- 遅延関連フィールド:
 -- SQL_Delay: 設定された遅延時間 (秒)
 -- SQL_Remaining_Delay: 残りの遅延時間 (秒)
 -- Seconds_Behind_Source: ソースからの実際の遅延秒数
 </syntaxhighlight>
*: <br>
*: <syntaxhighlight lang="text">
 # 出力例
 
 SQL_Delay: 3600
 SQL_Remaining_Delay: 2100
 Seconds_Behind_Source: 3600
 </syntaxhighlight>
*: <br>
* Performance Schemaでの確認
*: <syntaxhighlight lang="mysql">
 SELECT * FROM performance_schema.replication_applier_configuration;
 
 -- DESIRED_DELAY: 設定された遅延時間
 
 SELECT * FROM performance_schema.replication_applier_status;
 
 -- REMAINING_DELAY: 残りの遅延時間
 </syntaxhighlight>
*: <br>
* 誤操作からの回復例
*: <syntaxhighlight lang="mysql">
 -- ステップ1: ソースサーバで誤操作を検知
 -- (例: 10:00にDROP TABLE ordersを実行)
 
 -- ステップ2: 遅延レプリカ (1時間遅延) でレプリケーション停止
 -- (遅延レプリカは09:00のデータ状態)
 STOP REPLICA SQL_THREAD;
 
 -- ステップ3: 遅延レプリカからデータをバックアップ
 mysqldump -u root -p db1 orders > orders_backup.sql
 
 -- ステップ4: ソースサーバにデータを復元
 mysql -u root -p db1 < orders_backup.sql
 
 -- ステップ5: 遅延レプリカのレプリケーション再開
 START REPLICA SQL_THREAD;
 </syntaxhighlight>
<br>
推奨設定を以下に示す。<br>
* <u>遅延時間は業務要件に応じて設定する。</u>
*: 誤操作の検知時間を考慮する。
*: 例: 1時間～数時間
* <u>遅延レプリカは読み取り専用に設定する。</u>
*: <u>read_only = 1</u>
* <u>遅延レプリカは通常の読み取りクエリには使用しない。</u>
*: 理由 : 古いデータが返されるため。
<br><br>

== レプリケーションの監視 ==
レプリケーションの正常性を監視するための方法を以下に示す。<br>
適切な監視により、レプリケーション遅延やエラーを早期に検出できる。<br>
<br>
==== SHOW REPLICA STATUS ====
レプリケーション状態を確認する基本的なコマンドを以下に示す。<br>
<br>
 <syntaxhighlight lang="mysql">
 SHOW REPLICA STATUS\G
 </syntaxhighlight>
<br>
<center>
{| class="wikitable"
|+ SHOW REPLICA STATUS - 接続状態
! フィールド名 !! 説明
|-
| Replica_IO_Running || I/Oスレッドの状態<br><br>Yes: 正常動作<br>No: 停止またはエラー<br>Connecting: 接続試行中
|-
| Replica_SQL_Running || SQLスレッドの状態<br><br>Yes: 正常動作<br>No: 停止またはエラー
|-
| Seconds_Behind_Source || ソースサーバからの遅延秒数<br><br>0または低い値: 正常<br>大きい値: 遅延発生<br>NULL: SQLスレッド停止またはリレーログ処理済み
|}
</center>
<br>
<center>
{| class="wikitable"
|+ SHOW REPLICA STATUS - エラー情報
! フィールド名 !! 説明
|-
| Last_Error || 最後に発生したエラーメッセージ<br>空の場合は、エラー無しである。
|-
| Last_IO_Error || I/Oスレッドの最後のエラー<br>接続エラーやネットワークエラーが表示される。
|-
| Last_SQL_Error || SQLスレッドの最後のエラー<br>SQL実行エラーやデータ不整合が表示される。
|-
| Last_SQL_Errno || 最後のSQLエラーコード<br><br>エラー番号例: 1062 - Duplicate entry
|}
</center>
<br>
<center>
{| class="wikitable"
|+ SHOW REPLICA STATUS : GTID情報
! フィールド名 !! 説明
|-
| Retrieved_Gtid_Set || I/Oスレッドが取得したGTIDセット<br>リレーログに書き込み済みのGTID
|-
| Executed_Gtid_Set || SQLスレッドが実行済みのGTIDセット<br>レプリカで実行完了したGTID
|-
| Auto_Position || GTIDベースの自動位置決定が有効かどうか<br><br>1: GTID有効<br>0: 位置ベース
|}
</center>
<br>
<center>
{| class="wikitable"
|+ SHOW REPLICA STATUS : 位置情報 (位置ベースレプリケーション)
! フィールド名 !! 説明
|-
| Source_Log_File || 現在読み取り中のバイナリログファイル
|-
| Read_Source_Log_Pos || バイナリログの読み取り位置
|-
| Relay_Log_File || 現在処理中のリレーログファイル
|-
| Relay_Log_Pos || リレーログの読み取り位置
|-
| Exec_Source_Log_Pos || ソースサーバのバイナリログで実行済みの位置
|}
</center>
<br>
<center>
{| class="wikitable"
|+ SHOW REPLICA STATUS : 接続情報
! フィールド名 !! 説明
|-
| Source_Host || ソースサーバのホスト名
|-
| Source_Port || ソースサーバのポート番号
|-
| Source_User || レプリケーション用ユーザ名
|}
</center>
<br>
* 正常状態の例
*: <syntaxhighlight lang="text">
 Replica_IO_Running: Yes
 Replica_SQL_Running: Yes
 Seconds_Behind_Source: 0
 Last_Error: (空)
 Retrieved_Gtid_Set: 3E11FA47-71CA-11E1-9E33-C80AA9429562:1-100
 Executed_Gtid_Set: 3E11FA47-71CA-11E1-9E33-C80AA9429562:1-100
 </syntaxhighlight>
*: <br>
* エラー状態の例
*: <syntaxhighlight lang="text">
 Replica_IO_Running: No
 Replica_SQL_Running: Yes
 Last_IO_Error: error connecting to master 'repl_user@source.example.com:3306' - retry-time: 60  retries: 1
 </syntaxhighlight>
<br>
==== Performance Schema によるモニタリング ====
Performance Schemaを使用した詳細な監視方法を以下に示す。<br>
<br>
* レプリケーション接続状態
*: <syntaxhighlight lang="mysql">
 SELECT * FROM performance_schema.replication_connection_status\G
 
 -- 主要カラム:
 -- CHANNEL_NAME:       チャネル名
 -- SOURCE_UUID:        ソースサーバのUUID
 -- THREAD_ID:          I/OスレッドのID
 -- SERVICE_STATE:      ON/OFF/CONNECTING
 -- LAST_ERROR_NUMBER:  エラー番号
 -- LAST_ERROR_MESSAGE: エラーメッセージ
 </syntaxhighlight>
*: <br>
* レプリケーション適用状態
*: <syntaxhighlight lang="mysql">
 SELECT * FROM performance_schema.replication_applier_status\G
 
 -- 主要カラム:
 -- CHANNEL_NAME:    チャネル名
 -- SERVICE_STATE:   ON/OFF
 -- REMAINING_DELAY: 遅延レプリケーションの残り時間
 </syntaxhighlight>
*: <br>
* ワーカースレッド別の状態
*: <syntaxhighlight lang="mysql">
 SELECT * FROM performance_schema.replication_applier_status_by_worker\G
 
 -- 主要カラム:
 -- WORKER_ID:                ワーカースレッドID
 -- THREAD_ID:                スレッドID
 -- SERVICE_STATE:            ON/OFF/IDLE
 -- LAST_ERROR_NUMBER:        エラー番号
 -- LAST_ERROR_MESSAGE:       エラーメッセージ
 -- LAST_APPLIED_TRANSACTION: 最後に適用したGTID
 </syntaxhighlight>
*: <br>
* レプリケーション設定情報
*: <syntaxhighlight lang="mysql">
 SELECT * FROM performance_schema.replication_connection_configuration\G
 
 -- 主要カラム:
 -- CHANNEL_NAME:  チャネル名
 -- HOST:          ソースサーバホスト名
 -- PORT:          ソースサーバポート番号
 -- USER:          レプリケーションユーザ名
 -- AUTO_POSITION: GTID自動位置決定
 </syntaxhighlight>
*: <br>
* レプリケーション遅延の監視クエリ
*: <syntaxhighlight lang="mysql">
 SELECT
   CHANNEL_NAME,
   LAST_QUEUED_TRANSACTION,
   LAST_APPLIED_TRANSACTION,
   APPLYING_TRANSACTION
 FROM performance_schema.replication_connection_status
 JOIN performance_schema.replication_applier_status_by_worker
 USING (CHANNEL_NAME);
 </syntaxhighlight>
<br>
==== レプリケーション遅延の検出と対処 ====
レプリケーション遅延の検出方法と対処法を以下に示す。<br>
<br>
* 遅延の検出方法
*: <syntaxhighlight lang="mysql">
 SHOW REPLICA STATUS\G
 
 -- Seconds_Behind_Source フィールドを確認
 -- 0または小さい値: 正常
 -- 大きい値:       遅延発生
 -- NULL:          SQLスレッド停止
 </syntaxhighlight>
<br>
<u>※注意</u><br>
* <u>Seconds_Behind_SourceはSQLスレッドの遅延のみを示す。</u>
*: I/Oスレッドの遅延は反映されない。
* <u>ネットワークが遅い場合は不正確</u>
*: I/Oスレッドが遅延していても検出されない。
* <u>NULLの場合は、SQLスレッド停止 または リレーログ処理済み</u>
*: レプリケーション状態を確認する必要がある。
<br>
<center>
{| class="wikitable"
|+ レプリケーション遅延の原因
! 原因 !! 説明
|-
| ソースサーバの書き込みが多い || レプリカの処理能力を超えている。
|-
| レプリカサーバのリソース不足 || CPU、メモリ、ディスクI/Oが不足している。
|-
| ネットワーク帯域不足 || 大量のバイナリログ転送により帯域が不足している。
|-
| 単一スレッドでの実行 || マルチスレッドレプリカで改善可能である。
|-
| 大きなトランザクション || 長時間かかるトランザクションがボトルネックとなっている。
|}
</center>
<br>
遅延の対処法を以下に示す。<br>
<br>
* マルチスレッドレプリカの有効化
*: <syntaxhighlight lang="mysql">
 STOP REPLICA SQL_THREAD;
 SET GLOBAL replica_parallel_workers = 4;
 SET GLOBAL replica_parallel_type = LOGICAL_CLOCK;
 START REPLICA SQL_THREAD;
 </syntaxhighlight>
*: <br>
* レプリカサーバのリソース増強
** CPUコア数の増加する。
**: マルチスレッドレプリカの効果向上
** メモリを増加する。
**: バッファプールサイズの拡大
** ディスクI/O性能を向上させる。
**: SSDの使用、RAID構成の最適化
*: <br>
* バイナリログ形式の最適化
*: これにより、バイナリログサイズが削減され、ネットワーク転送量が減少する。
*: <syntaxhighlight lang="mysql">
 SET GLOBAL binlog_row_image = MINIMAL;
 </syntaxhighlight>
*: <br>
* レプリケーションフィルタの使用
*: 不要なデータベースやテーブルをレプリケーション対象から除外することにより、処理量を削減できる。
*: <br>
* 遅延監視スクリプトの例
*: <syntaxhighlight lang="sh">
 #!/usr/bin/env sh
 
 DELAY=$(mysql -e "SHOW REPLICA STATUS\G" | grep Seconds_Behind_Source | awk '{print $2}')
 
 if [ "$DELAY" -gt 60 ]; then
   echo "WARNING: Replication delay is ${DELAY} seconds"
   # アラート送信
 fi
 </syntaxhighlight>
<br><br>

== トラブルシューティング ==
==== レプリケーション停止 ====
レプリケーションが停止した場合の対処法を以下に示す。<br>
<br>
===== エラーの確認 =====
 <syntaxhighlight lang="mysql">
 SHOW REPLICA STATUS\G

 -- Last_Error フィールドを確認
 -- Last_IO_Error:  I/Oスレッドのエラー
 -- Last_SQL_Error: SQLスレッドのエラー
 -- Last_SQL_Errno: SQLエラー番号
 </syntaxhighlight>
<br>
===== 対処法 =====
 Duplicate entry エラー (エラー番号: 1062)
 
 Last_SQL_Error: Error 'Duplicate entry '1' for key 'PRIMARY'' on query.
<br>
* 原因
*: レプリカに既に存在するキーを挿入しようとしたため、データの不整合が発生
*: <br>
* 対処法 (GTIDモード)
*: <syntaxhighlight lang="mysql">
 -- 問題のあるGTIDをスキップ
 SET GTID_NEXT='3E11FA47-71CA-11E1-9E33-C80AA9429562:100';
 BEGIN;
 COMMIT;
 SET GTID_NEXT='AUTOMATIC';
 START REPLICA;
 </syntaxhighlight>
*: <br>
* 対処法 (位置ベース)
*: <syntaxhighlight lang="mysql">
 -- 1つのイベントをスキップ
 STOP REPLICA;
 SET GLOBAL sql_replica_skip_counter = 1;
 START REPLICA;
 </syntaxhighlight>
<br>
 Table doesn't exist エラー (エラー番号: 1146)
 
 Last_SQL_Error: Error 'Table 'db1.orders' doesn't exist' on query.
<br>
* 原因
*: レプリカにテーブルが存在しないため、データベース構造の不整合が発生
*: <br>
* 対処法
*: <syntaxhighlight lang="mysql">
 -- ソースサーバからテーブル定義をコピー
 mysqldump -u root -p --no-data db1 orders > orders_schema.sql
 
 -- レプリカサーバでテーブルを作成
 mysql -u root -p db1 < orders_schema.sql
 
 -- レプリケーション再開
 START REPLICA;
 </syntaxhighlight>
<br>
 I/O Thread接続エラー
 
 Last_IO_Error: error connecting to master 'repl_user@source.example.com:3306'
<br>
* 原因
** ネットワーク接続の問題
**: ファイアウォール、ルーティング
** レプリケーションユーザの認証失敗
**: パスワード誤り、権限不足
** ソースサーバの停止
**: メンテナンスや障害
*: <br>
* 対処法
*: <syntaxhighlight lang="bash">
 # ネットワーク接続確認
 ping source.example.com
 telnet source.example.com 3306
 
 # ソースサーバで接続確認
 mysql -h source.example.com -u repl_user -p
 
 # レプリケーションユーザの権限確認
 SHOW GRANTS FOR 'repl_user'@'%';
 </syntaxhighlight>
<br>
認証に関する詳細は、[[MySQL - 認証プラグイン]]のページを参照すること。<br>
<br>
==== データ不整合 ====
ソースサーバとレプリカサーバのデータ不整合の検出と修復を以下に示す。<br>
<br>
* 不整合の検出 (pt-table-checksum)
*: <syntaxhighlight lang="bash">
 pt-table-checksum --host=source.example.com \
   --user=checksum_user --password=password \
   --databases=db1
 
 # 結果例:
 # DIFFS:  不整合があるテーブル数
 # ROWS:   チェックした行数
 # CHUNKS: チェックしたチャンク数
 </syntaxhighlight>
*: <br>
* 不整合の修復 (pt-table-sync)
*: <syntaxhighlight lang="bash">
 pt-table-sync --execute \
   --sync-to-master replica.example.com \
   --databases=db1 \
   --tables=orders
 
 # 注意: --executeオプションで実際に修復が実行される
 # 事前に --print または --dry-run で確認推奨
 </syntaxhighlight>
*: <br>
* 手動での不整合修復
*: <syntaxhighlight lang="mysql">
 -- レプリケーション停止
 STOP REPLICA;
 
 -- ソースサーバからデータをダンプ
 mysqldump -u root -p --single-transaction db1 orders > orders.sql
 
 -- レプリカサーバでテーブルを再作成
 mysql -u root -p db1 < orders.sql
 
 -- レプリケーション再開
 START REPLICA;
 </syntaxhighlight>
<br>
不整合の予防を以下に示す。<br>
* レプリカサーバを <u>read_only=1</u> に設定する。
*: 誤った書き込みを防止
* GTIDモードを使用する。
*: データ整合性が向上
* ROW形式のバイナリログ
*: 非決定的関数の影響を回避
* 半同期レプリケーション
*: データ損失リスクを低減
<br>
==== 接続エラー ====
レプリケーション接続エラーの診断と対処法を以下に示す。<br>
<br>
* ネットワーク接続確認
*: <syntaxhighlight lang="bash">
 # pingでホスト到達性確認
 ping source.example.com
 
 # telnetでポート接続確認
 telnet source.example.com 3306
 
 # または nc (netcat) を使用
 nc -zv source.example.com 3306
 
 # MySQLクライアントで接続確認
 mysql -h source.example.com -u repl_user -p
 </syntaxhighlight>
*: <br>
* レプリケーションユーザの認証確認
*: <syntaxhighlight lang="mysql">
 -- ソースサーバでユーザ確認
 SELECT User, Host FROM mysql.user WHERE User = 'repl_user';
 
 -- 権限確認
 SHOW GRANTS FOR 'repl_user'@'%';
 
 -- 必要な権限: REPLICATION SLAVE
 
 -- ユーザが存在しない場合は作成
 CREATE USER 'repl_user'@'%' IDENTIFIED BY 'password';
 GRANT REPLICATION SLAVE ON *.* TO 'repl_user'@'%';
 FLUSH PRIVILEGES;
 </syntaxhighlight>
*: <br>
* ファイアウォール設定確認
*: <syntaxhighlight lang="text">
 # iptablesルール確認
 iptables -L -n | grep 3306
 
 # firewalldでポート開放
 firewall-cmd --add-port=3306/tcp --permanent
 firewall-cmd --reload
 </syntaxhighlight>
*: <br>
* server_idの一意性確認
*: <syntaxhighlight lang="mysql">
 -- 各サーバでserver_idを確認
 SHOW VARIABLES LIKE 'server_id';
 
 -- 全てのサーバで異なる値である必要がある
 </syntaxhighlight>
*: <br>
* バイナリログの存在確認
*: <syntaxhighlight lang="mysql">
 -- ソースサーバでバイナリログ確認
 SHOW BINARY LOGS;
 
 -- 現在のバイナリログ位置確認
 SHOW MASTER STATUS;
 </syntaxhighlight>
*: <br>
* SSL/TLS接続の確認
*: レプリケーション接続でSSL/TLSを使用している場合、証明書の有効性を確認する。
*: 詳細は、[[MySQL - SSL TLS接続]]のページを参照すること。<br>
*: <br>
* レプリケーション接続のリセット
*: <syntaxhighlight lang="mysql">
 -- 既存のレプリケーション設定を削除
 STOP REPLICA;
 RESET REPLICA ALL;
 
 -- レプリケーション接続を再設定
 CHANGE REPLICATION SOURCE TO
   SOURCE_HOST='source.example.com',
   SOURCE_PORT=3306,
   SOURCE_USER='repl_user',
   SOURCE_PASSWORD='password',
   SOURCE_AUTO_POSITION=1;
 
 START REPLICA;
 </syntaxhighlight>
<br><br>

== バージョン別の変更点 ==
==== MySQL 8.0の主要変更 ====
下表に、MySQL 8.0での重要な変更点を示す。<br>
<br>
<center>
{| class="wikitable"
|+ MySQL 8.0 レプリケーション機能の改善と変更
! バージョン !! 機能/変更 !! 説明
|-
| MySQL 8.0 || デフォルトでバイナリロギング有効 || log_binがデフォルトでON<br>明示的に無効化しない限りバイナリログが記録される。<br>設定例: <code>--skip-log-bin</code> で無効化
|-
| MySQL 8.0.17 || GTIDモード - オンライン有効化 || オンラインでのGTID有効化がサポートされる。<br>段階的な移行が可能である。
|-
| MySQL 8.0.21 || GTIDモード - CREATE TABLE制約緩和 || <code>CREATE TABLE ... SELECT</code> の制約緩和<br>GTIDモードでも使用可能になる。
|-
| MySQL 8.0.20 || バイナリログトランザクション圧縮 || <u>binlog_transaction_compression</u> パラメータでバイナリログの圧縮によりネットワーク転送量削減が実現される。<br>設定例: <u>SET GLOBAL binlog_transaction_compression = ON;</u>
|-
| MySQL 8.0.22 || レプリカの非同期接続フェイルオーバー || <code>SOURCE_CONNECTION_AUTO_FAILOVER</code> オプションでソースサーバ障害時に自動的に別のソースに接続される。<br>グループレプリケーション構成で有用である。
|-
| MySQL 8.0.23 || 新構文の導入 || <ccode>CHANGE REPLICATION SOURCE TO</code> (CHANGE MASTER TOの新構文)<br><code>START REPLICA</code> / <code>STOP REPLICA</code> (START SLAVE / STOP SLAVEの新構文)<br><code>SHOW REPLICA STATUS</code> (SHOW SLAVE STATUSの新構文)
|-
| MySQL 8.0.26 || 用語の変更 || master → source、slave → replica<br>rpl_semi_sync_master → rpl_semi_sync_source<br>rpl_semi_sync_slave → rpl_semi_sync_replica<br><br>全ての構文とパラメータで変更される。
|-
| MySQL 8.0.34 || binlog_format非推奨化 || binlog_formatパラメータが非推奨になる。<br>将来のバージョンで削除予定である。<br>将来はROW形式のみサポート。<br>STATEMENT形式 と MIXED形式は廃止予定である。
|}
</center>
<br>
==== MySQL 8.4の変更点 ====
MySQL 8.4での破壊的変更を以下に示す。<br>
<br>
<center>
{| class="wikitable"
|+ 旧構文の完全削除
! 旧構文 !! 新構文 !! 説明
|-
| CHANGE MASTER TO || CHANGE REPLICATION SOURCE TO || CHANGE MASTER TO は削除済みである。<br><code>CHANGE REPLICATION SOURCE TO</code> を使用する。
|-
| SHOW SLAVE STATUS || SHOW REPLICA STATUS || SHOW SLAVE STATUS は削除済みである。<br><code>SHOW REPLICA STATUS</code> を使用する。
|-
| START SLAVE / STOP SLAVE || START REPLICA / STOP REPLICA || START SLAVE / STOP SLAVE は削除済みである。<br><code>START REPLICA</code> / <code>STOP REPLICA</code> を使用する。
|-
| RESET SLAVE || RESET REPLICA || RESET SLAVE は削除済みである。<br><code>RESET REPLICA</code> を使用する。
|}
</center>
<br>
<center>
{| class="wikitable"
|+ 旧プラグインの削除
! 旧プラグイン名 !! 新プラグイン名 !! 説明
|-
| rpl_semi_sync_master || rpl_semi_sync_source || rpl_semi_sync_master は削除済みである。<br><u>rpl_semi_sync_source</u> を使用する。
|-
| rpl_semi_sync_slave || rpl_semi_sync_replica || rpl_semi_sync_slave は削除済みである。<br><u>rpl_semi_sync_replica</u> を使用する。
|}
</center>
<br>
<center>
{| class="wikitable"
|+ 旧パラメータの削除
! 旧パラメータ !! 新パラメータ !! 説明
|-
| MASTER_HOST, MASTER_PORT, MASTER_USER 等 || SOURCE_HOST, SOURCE_PORT, SOURCE_USER || CHANGE MASTER TOのオプション名は削除済みである。<br><code>SOURCE_HOST</code>、<code>SOURCE_PORT</code>、<code>SOURCE_USER</code> を使用する。
|-
| slave_parallel_workers || replica_parallel_workers || slave_parallel_workers は削除済みである。<br><u>replica_parallel_workers</u> を使用する。
|-
| slave_parallel_type || replica_parallel_type || slave_parallel_type は削除済みである。<br><u>replica_parallel_type</u> を使用する。
|}
</center>
<br>
<u>※MySQL 8.4へのアップグレード時の注意</u><br>
* <u>アップグレード前に全ての旧構文を新構文に置き換える。</u>
*: スクリプトや設定ファイルの書き換え
* <u>半同期レプリケーションプラグインを新バージョンに変更</u>
*: rpl_semi_sync_source / rpl_semi_sync_replica
* <u>設定ファイル (my.cnfファイル) のパラメータ名を変更</u>
*: slave_ → replica_ に置換
<br>
互換性を確認する方法を以下に示す。<br>
<br>
 <syntaxhighlight lang="mysql">
 -- MySQL 8.0.26以降で新構文が使用可能か確認
 SELECT VERSION();
 
 -- 新構文が使用できることを確認してからアップグレード
 </syntaxhighlight>
<br><br>

== 参考リンク ==
* [https://dev.mysql.com/doc/refman/8.4/en/replication.html MySQL 8.4 Replication - MySQL公式ドキュメント]
* [https://dev.mysql.com/doc/refman/8.0/en/replication-gtids.html MySQL GTID - MySQL公式ドキュメント]
* [https://dev.mysql.com/doc/refman/8.0/en/replication-semisync.html MySQL Semi-Synchronous Replication - MySQL公式ドキュメント]
<br><br>


{{#seo:
|title={{PAGENAME}} : Exploring Electronics and SUSE Linux | MochiuWiki
|keywords=MochiuWiki,Mochiu,Wiki,Mochiu Wiki,MySQL,Database,SQL,Replication,GTID,Binary Log,Semisync,Master,Slave,Source,Replica,レプリケーション,バイナリログ,半同期,データベース,電気回路,電子回路,基板,プリント基板
|description={{PAGENAME}} - MySQLのレプリケーションに関する包括的なガイド | This page is {{PAGENAME}} in our wiki about electronic circuits and SUSE Linux
|image=/resources/assets/MochiuLogo_Single_Blue.png
}}

__FORCETOC__
[[カテゴリ:MySQL]]