このページでは、リードレプリカと外部レプリカを操作する際の要件とベスト プラクティスについて説明します。
リードレプリカ
リードレプリカは、Cloud SQL マスター インスタンスから複製された Cloud SQL インスタンスです。
リードレプリカの設定方法の詳細については、リードレプリカを作成をご覧ください。
リードレプリカ マスター インスタンスの要件
Cloud SQL インスタンスの Cloud SQL リードレプリカを作成するには、そのインスタンスが次の要件を満たしている必要があります。
- バイナリログが有効になっていること。詳細
- バイナリログの有効化後、少なくとも 1 つのバックアップが作成されていること。
Cloud SQL リードレプリカについて
対象
- リードレプリカは高可用性を提供しません。高可用性向けにマスター インスタンスを設定する必要があります。
- リードレプリカはメンテナンスの時間枠の設定をサポートしていません。いつでも中断アップグレードが発生する可能性があります。
- リードレプリカは高可用性を備えていません。設置ゾーンで全面的な停電が生じるとオフラインになります。
オペレーション
- root パスワード、ユーザー テーブルの変更などのマスター インスタンスの MySQL 設定は、レプリカにプロパゲートされます。
- リードレプリカは、マスター インスタンスとは異なるマシンタイプ（または階層）にすることができます。
- レプリカは常にマスター インスタンスと同じ世代（第 1 世代または第 2 世代）になります。
- リードレプリカは、マスター インスタンスと同じリージョンにあることが必要です。
- レプリカのユーザー テーブルに変更を加えることはできません。すべてのユーザー変更は、マスター インスタンスで行う必要があります。
- レプリカのバックアップは設定できません。
- レプリカのマスターは、そのレプリカが存在する場合は復元できません。インスタンスをバックアップから復元したり、インスタンスでポイントインタイム リカバリを実行したりする前に、すべてのレプリカをプロモートまたは削除する必要があります。
- マスター インスタンスを削除するには、その前にすべてのリードレプリカをスタンドアロン インスタンスにプロモートするか、リードレプリカを削除する必要があります。
- マスター インスタンスのバイナリログを無効にするには、その前にすべてのリードレプリカをプロモートまたは削除する必要があります。
- バックアップからのマスターの復元またはマスター上でのポイントインタイム リカバリの実行を行う場合は、そのレプリカのすべてを削除してから再作成する必要があります。
- レプリカのレプリカは作成できません。
課金
- リードレプリカは、標準 Cloud SQL インスタンスと同じレートで課金されます。データ レプリケーションには課金されません。
- レプリカはマスターとの接続を常時維持しているため、マスターが ON_DEMAND アクティベーション ポリシーによる第 1 世代インスタンスであっても、マスター インスタンスは停止されません。このような場合、マスター インスタンスに対する請求額が増加することがあります。詳細
外部リードレプリカ
外部リードレプリカは、Cloud SQL マスターを複製する外部 MySQL インスタンスです。
外部リードレプリカ構成の設定方法の詳細については、外部レプリカの設定をご覧ください。
外部リードレプリカの設定要件
マスター インスタンスの要件:
マスター インスタンスでバイナリログが有効になっていること。 詳細
外部レプリカの要件:
レプリカの MySQL バージョンがマスター インスタンスの MySQL バージョンと同じかそれ以降であること。 詳細
外部レプリカの設定について
外部レプリカの構成には、以下の注意点があります。
- Compute Engine で実行される MySQL インスタンスは外部インスタンスとみなされます。
- マスターから外部レプリカに流れるデータはネットワーク下りとして課金されます。ご使用の Cloud SQL インスタンス タイプ（第 1 世代または第 2 世代）のネットワーク下りの料金については、料金体系のページをご覧ください。
- 他のクラウド プラットフォームでホストされる MySQL インスタンスに複製できないことがあります。他のプロバイダの資料を確認してください。
- ネットワークまたはサーバーの停止などによって複製が数時間中断された場合、レプリカはマスターよりも古い状態のものになります。マスターに再接続され、複製が再開されると、レプリカは最新状態になります。ただし、中断時間が Cloud SQL の複製ログの保存期間（7 つのバックアップ）よりも長かった場合は、レプリカを削除して新しく作成する必要があります。
- セキュリティ上、マスター インスタンスで SSL/TLS を構成する必要があります。 詳しくはこちらをご覧ください。
バイナリログの影響
リードレプリカをサポートするには、マスター インスタンスのバイナリログを有効にする必要があります。その結果、次の影響があります。
-
パフォーマンスのオーバーヘッド
Cloud SQL は、MySQL フラグ
sync_binlog=1とinnodb_support_xa=trueによる行ベースのレプリケーションを使用します。そのため、書き込みオペレーションのたびにディスクの fsync が余分に必要となり、パフォーマンスが低下します。 -
ストレージのオーバーヘッド
バイナリログのストレージは、通常のデータと同じレートで課金されます。Cloud SQL はバイナリログを最も古いバックアップの作成時点から保持します（現在、Cloud SQL は 7 つのバックアップを保持します）。課金対象となるバイナリログのサイズはワークロードによって異なるため、請求される料金も異なってきます。たとえば、書き込み中心のワークロードでは、読み取り中心のワークロードよりも多くのバイナリログ容量を消費します。バイナリログのサイズを確認するには SHOW BINARY LOGS MySQL コマンドを使用します。
-
インスタンスの再起動
バイナリログを有効または無効にすると、インスタンスが再起動されます。既存のデータベース接続が失われ、再確立する必要があります。
次のステップ
- 第 2 世代インスタンスの外部マスター構成について学習します。
- リードレプリカの作成方法を学習します。
- 外部レプリカ構成を設定する方法を学習します。
- 外部マスター構成を設定する方法を学習します。
- レプリカの管理方法を学習します。
