このページは機械翻訳したものです。
レプリカサーバーは、接続メタデータリポジトリと適用者メタデータリポジトリの 2 つのレプリケーションメタデータリポジトリを作成します。 レプリケーションメタデータリポジトリは、レプリカサーバーの停止後も存続します。 バイナリログファイルの位置ベースのレプリケーションを使用している場合、レプリカは再起動時に 2 つのリポジトリを読み取り、以前にソースからバイナリログを読み取り、独自のリレーログを処理していた距離を判断します。 GTID ベースのレプリケーションが使用されている場合、レプリカはその目的のためにレプリケーションメタデータリポジトリを使用しませんが、含まれている他のメタデータのために必要です。
- レプリカ接続メタデータリポジトリには、レプリケーション I/O スレッドがレプリケーションソースサーバーに接続し、ソースバイナリログからトランザクションを取得するために必要な情報が含まれています。 このリポジトリのメタデータには、接続構成、レプリケーションユーザーアカウントの詳細、接続の SSL 設定、レプリケーション I/O スレッドがソースバイナリログから現在読み取っているファイル名と位置が含まれます。 
- レプリカ適用者メタデータリポジトリには、レプリケーション SQL スレッドがレプリカリレーログからトランザクションを読み取り、適用するために必要な情報が含まれています。 このリポジトリのメタデータには、レプリケーション SQL スレッドがリレーログ内のトランザクションを実行したファイル名と位置、およびソースバイナリログ内の同等の位置が含まれます。 また、ワーカースレッドの数やチャネルの - PRIVILEGE_CHECKS_USERアカウントなど、トランザクションを適用するプロセスのメタデータも含まれます。
        接続メタデータリポジトリは mysql システムスキーマの slave_master_info テーブルに書き込まれ、適用者メタデータリポジトリは mysql システムスキーマの slave_relay_log_info テーブルに書き込まれます。 mysqld がレプリケーションメタデータリポジトリのテーブルを初期化できないが、レプリカの起動を続行できる場合は、警告メッセージが発行されます。 この状況は、リポジトリのテーブルの使用をサポートしていない MySQL のバージョンから、サポートされているバージョンにアップグレードする場合に最も発生する可能性があります。 
      
- mysql.slave_master_infoまたは- mysql.slave_relay_log_infoテーブルの行を手動で更新または挿入しないでください。 そのようにすることは、未定義の動作になる可能性があり、サポートされていません。 レプリケーションの進行中は、- slave_master_infoテーブルと- slave_relay_log_infoテーブルのいずれかまたは両方で書込みロックを必要とするステートメントの実行は許可されません (ただし、読取りのみを実行するステートメントはいつでも許可されます)。
- 接続メタデータリポジトリテーブル - mysql.slave_master_infoのアクセス権限は、ソースに接続するためのレプリケーションユーザーアカウント名とパスワードが含まれているため、データベース管理者に制限する必要があります。 このテーブルを含むデータベースバックアップを保護するには、制限付きアクセスモードを使用します。 MySQL 8.0.21 から、レプリケーションユーザーアカウントの資格証明を接続メタデータリポジトリからクリアし、かわりにレプリケーションチャネルを起動する- START REPLICA | SLAVEステートメントまたは- START GROUP_REPLICATIONステートメントを使用してそれらを常に指定できます。 このアプローチでは、レプリケーションチャネルを再起動するためにオペレータの介入が常に必要ですが、アカウント名とパスワードはレプリケーションメタデータリポジトリに記録されません。
        RESET REPLICA | SLAVE は、レプリケーション接続パラメータ (MySQL Server リリースによって異なります) を除いて、レプリケーションメタデータリポジトリ内のデータをクリアします。 詳細は、RESET REPLICA | SLAVE の説明を参照してください。 
      
        MySQL 8.0 より前は、レプリケーションメタデータリポジトリをテーブルとして作成するには、サーバーの起動時に master_info_repository=TABLE および relay_log_info_repository=TABLE を指定する必要がありました。 それ以外の場合、リポジトリは、master.info および relay-log.info という名前のデータディレクトリにファイルとして作成されたか、--master-info-file オプションおよび relay_log_info_file システム変数で指定された代替の名前と場所を使用して作成されました。 MySQL 8.0 からは、レプリケーションメタデータリポジトリをテーブルとして作成することがデフォルトであり、これらすべてのシステム変数の使用は非推奨になりました。 
      
        mysql.slave_master_info および mysql.slave_relay_log_info テーブルは、InnoDB トランザクションストレージエンジンを使用して作成されます。 アプライヤメタデータリポジトリテーブルへの更新は、トランザクションとともにコミットされます。つまり、予期しないサーバーが停止した場合でも、そのリポジトリに記録されるレプリカ進捗情報は、常にデータベースに適用されているものと一貫性があります。 予期しない停止に対して最も回復可能なレプリカの設定の組合せの詳細は、セクション17.4.2「レプリカの予期しない停止の処理」 を参照してください。 
      
        レプリカデータをバックアップするか、そのデータのスナップショットを転送して新しいレプリカを作成する場合は、レプリケーションメタデータリポジトリを含む mysql.slave_master_info および mysql.slave_relay_log_info テーブルを必ず含めてください。 クローニング操作の場合、レプリケーションメタデータリポジトリがテーブルとして作成されると、クローニング操作中に受信者にコピーされますが、ファイルとして作成されるとコピーされないことに注意してください。 バイナリログファイルの位置ベースのレプリケーションが使用されている場合、レプリケーションメタデータリポジトリは、復元、コピー、またはクローニングされたレプリカの再起動後にレプリケーションを再開するために必要です。 リレーログファイルはないが、まだアプライヤメタデータリポジトリがある場合は、それをチェックして、レプリケーション SQL スレッドがソースバイナリログで実行された距離を判断できます。 その後、CHANGE REPLICATION SOURCE TO ステートメント (MySQL 8.0.23 から) または CHANGE MASTER TO ステートメント (MySQL 8.0.23 より前) を SOURCE_LOG_FILE | MASTER_LOG_FILE および SOURCE_LOG_POS | MASTER_LOG_POS オプションとともに使用して、必要なバイナリログをソースログに再度読み取り、バイナリログからレプリカを読み取ることができます。 
      
        追加のリポジトリであるアプライヤワーカーメタデータリポジトリは、主に内部使用のために作成され、マルチスレッドレプリカ上のワーカースレッドに関するステータス情報を保持します。 アプライヤワーカーメタデータリポジトリには、リレーログファイルの名前と位置、および各ワーカースレッドのソースバイナリログファイルが含まれます。 アプライヤメタデータリポジトリがテーブルとして作成されている場合 (デフォルト)、アプライヤワーカーメタデータリポジトリは mysql.slave_worker_info テーブルに書き込まれます。 適用者メタデータリポジトリがファイルに書き込まれると、適用者ワーカーメタデータリポジトリが worker-relay-log.info ファイルに書き込まれます。 外部で使用するために、ワーカースレッドのステータス情報がパフォーマンススキーマ replication_applier_status_by_worker テーブルに表示されます。 
      
        レプリケーションメタデータリポジトリには、セクション13.4.2「レプリケーションサーバーを制御するための SQL ステートメント」 で説明されている SHOW REPLICA | SLAVE STATUS ステートメントの出力に示されているような情報が最初に含まれていました。 SHOW REPLICA | SLAVE STATUS ステートメントで表示されないレプリケーションメタデータリポジトリに追加された情報。 
      
        接続メタデータリポジトリの場合、次のテーブルに、mysql.slave_master_info テーブルのカラム、SHOW REPLICA | SLAVE STATUS によって表示されるカラムおよび非推奨の master.info ファイルの行の対応関係を示します。
      
| slave_master_infoテーブルのカラム | SHOW REPLICA | SLAVE STATUSカラム | master.infoファイル行 | 説明 | 
|---|---|---|---|
| Number_of_lines | [None] | 1 | テーブル (またはファイル内の行) のカラム数 | 
| Master_log_name | Source_Log_File | 2 | ソースから現在読み取られているバイナリログの名前 | 
| Master_log_pos | Read_Source_Log_Pos | 3 | ソースから読み取られたバイナリログ内の現在の位置 | 
| Host | Source_Host | 4 | レプリケーションソースサーバーのホスト名 | 
| User_name | Source_User | 5 | ソースへの接続に使用されるレプリケーションユーザーアカウント名 | 
| User_password | パスワード ( SHOW REPLICA | SLAVE STATUSでは表示されません) | 6 | ソースへの接続に使用されるレプリケーションユーザーアカウントのパスワード | 
| Port | Source_Port | 7 | レプリケーションソースサーバーへの接続に使用されるネットワークポート | 
| Connect_retry | Connect_Retry | 8 | レプリカがソースへの再接続を試行するまで待機する期間 (秒) | 
| Enabled_ssl | Source_SSL_Allowed | 9 | レプリカが SSL 接続をサポートするかどうか | 
| Ssl_ca | Source_SSL_CA_File | 10 | 認証局 (CA) 証明書に使用されるファイル | 
| Ssl_capath | Source_SSL_CA_Path | 11 | 認証局 (CA) 証明書へのパス | 
| Ssl_cert | Source_SSL_Cert | 12 | SSL 証明書ファイルの名前 | 
| Ssl_cipher | Source_SSL_Cipher | 13 | SSL 接続のハンドシェイクで使用される可能な暗号のリスト | 
| Ssl_key | Source_SSL_Key | 14 | SSL キーファイルの名前 | 
| Ssl_verify_server_cert | Source_SSL_Verify_Server_Cert | 15 | サーバー証明書を検証するかどうか | 
| Heartbeat | [None] | 16 | レプリケーションハートビートの間隔 (秒単位) | 
| Bind | Source_Bind | 17 | ソースへの接続に使用するレプリカネットワークインタフェース | 
| Ignored_server_ids | Replicate_Ignore_Server_Ids | 18 | 無視するサーバー ID のリスト。 Ignored_server_idsの場合、サーバー ID のリストの前に、無視するサーバー ID の合計数が付きます。 | 
| Uuid | Source_UUID | 19 | ソースの一意の ID | 
| Retry_count | Source_Retry_Count | 20 | 許容される再接続試行の最大数 | 
| Ssl_crl | [None] | 21 | SSL 証明書失効リストファイルへのパス | 
| Ssl_crlpath | [None] | 22 | SSL 証明書失効リストファイルを含むディレクトリへのパス | 
| Enabled_auto_position | Auto_position | 23 | GTID 自動配置が使用中かどうか | 
| Channel_name | Channel_name | 24 | レプリケーションチャネルの名前 | 
| Tls_version | Source_TLS_Version | 25 | ソースの TLS バージョン | 
| Public_key_path | Source_public_key_path | 26 | RSA 公開キーファイルの名前 | 
| Get_public_key | Get_source_public_key | 27 | ソースから RSA 公開キーをリクエストするかどうか | 
| Network_namespace | Network_namespace | 28 | ネットワークネームスペース | 
| Master_compression_algorithm | [None] | 29 | ソースへの接続に許可される圧縮アルゴリズム | 
| Master_zstd_compression_level | [None] | 30 | zstd圧縮レベル | 
| Tls_ciphersuites | [None] | 31 | TLSv1.3 で許可される暗号スイート | 
| Source_connection_auto_failover | [None] | 32 | 非同期接続フェイルオーバーメカニズムをアクティブ化するかどうか | 
        アプライヤメタデータリポジトリの場合、次のテーブルに、mysql.slave_relay_log_info テーブルのカラム、SHOW REPLICA | SLAVE STATUS によって表示されるカラムおよび非推奨の relay-log.info ファイルの行の対応関係を示します。
      
| slave_relay_log_infoテーブルのカラム | SHOW REPLICA | SLAVE STATUSカラム | relay-log.infoファイルの行 | 説明 | 
|---|---|---|---|
| Number_of_lines | [None] | 1 | ファイル内のテーブルまたは行のカラム数 | 
| Relay_log_name | Relay_Log_File | 2 | 現在のリレーログファイルの名前 | 
| Relay_log_pos | Relay_Log_Pos | 3 | リレーログファイル内の現在の位置。この位置までのイベントがレプリカデータベース上で実行されています | 
| Master_log_name | Relay_Source_Log_File | 4 | リレーログファイル内のイベントが読み取られたソースバイナリログファイルの名前 | 
| Master_log_pos | Exec_Source_Log_Pos | 5 | レプリカで実行されたイベントのソースバイナリログファイル内の同等の位置 | 
| Sql_delay | SQL_Delay | 6 | レプリカがソースを遅らせる必要がある秒数 | 
| Number_of_workers | [None] | 7 | レプリケーショントランザクションをパラレルに適用するワーカースレッドの数 | 
| Id | [None] | 8 | 内部目的に使用される ID。現在は常に 1 です | 
| Channel_name | Channel_name | 9 | レプリケーションチャネルの名前 | 
| Privilege_checks_username | [None] | 10 | チャネルの PRIVILEGE_CHECKS_USERアカウントのユーザー名 | 
| Privilege_checks_hostname | [None] | 11 | チャネルの PRIVILEGE_CHECKS_USERアカウントのホスト名 | 
| Require_row_format | [None] | 12 | チャネルが行ベースのイベントのみを受け入れるかどうか | 
| Require_table_primary_key_check | [None] | 13 | CREATE TABLEおよびALTER TABLE操作のためにテーブルに主キーが必要かどうかに関するチャネルポリシー | 
| Assign_gtids_to_anonymous_transactions_type  | [None] | 14 | チャネルが GTID をまだ持っていないレプリケートトランザクションに割り当てるかどうか、および割り当てられている場合はレプリカローカル UUID を使用するか手動で設定した UUID を使用するかどうか | 
| Assign_gtids_to_anonymous_transactions_value  | [None] | 15 | 匿名トランザクションに割り当てられた GTID で使用される UUID |