Cloud SQL でのレプリケーションについて

レプリケーションとは、Cloud SQL インスタンスまたはオンプレミスデータベースのコピーを作成して、作業をそのコピーにオフロードする機能です。

はじめに

レプリケーションを使用する主な理由は、パフォーマンスを低下させることなく、データベース内のデータ使用をスケーリングすることです。

その他、次の理由があります。

リージョン間でのデータ移行
プラットフォーム間でのデータ移行
オンプレミスデータベースから Cloud SQL へのデータ移行

また、元のインスタンスが破損した場合にレプリカを昇格させることもできます。

Cloud SQL インスタンスを参照する場合、複製されるインスタンスは「プライマリインスタンス」と呼ばれ、コピーは「リードレプリカ」と呼ばれます。プライマリインスタンスとリードレプリカは Cloud SQL にあります。

オンプレミスデータベースを指している場合、レプリケーションシナリオは「外部サーバーからのレプリケーション」と呼ばれます。このシナリオでは、複製されるデータベースは、ソースデータベースサーバーです。Cloud SQL にあるコピーは Cloud SQL レプリカと呼ばれます。また、Cloud SQL のソースデータベースサーバーを表すインスタンスもあります。このインスタンスをソース表現インスタンスといいます。

障害復旧のシナリオでは、レプリカを昇格させてプライマリインスタンスに変換できます。これにより、停止しているリージョン内のインスタンスの代わりとして使用できます。レプリカを昇格させて、破損したインスタンスと置換することもできます。

Cloud SQL は、次の種類のレプリカをサポートします。

リードレプリカ
クロスリージョンリードレプリカ
リードレプリカのカスケード
外部リードレプリカ
外部サーバーから複製する場合の Cloud SQL レプリカ

Database Migration Service を使用して、ソースデータベースサーバーから Cloud SQL に継続的にレプリケーションすることもできます。

Cloud SQL は、2 台の外部サーバー間のレプリケーションをサポートしていません。ただし、Cloud SQL はグローバルトランザクション識別子（GTID）ベースのレプリケーションをサポートしています。GTID は、サーバーとレプリケーション設定内の各トランザクションを一意に識別します。各トランザクションには一意の識別子があるため、MySQL サーバーは実行されたトランザクションを追跡できます。GTID は絶対座標を使用するため、Cloud SQL インスタンスのレプリカがそのプライマリインスタンスを指すことができ、バイナリログのファイル名や CHANGE MASTER ステートメントでの位置を指定する必要はありません。レプリカとポイントインタイムリカバリで発生するエラーは少なくなります。これらのメリットのため、Cloud SQL では GTID ベースのレプリケーションを無効にできません。

リードレプリカ

リードレプリカを使用して Cloud SQL インスタンスから作業をオフロードします。リードレプリカとは、プライマリインスタンスの正確なコピーです。プライマリインスタンスのデータやその他の変更は、リードレプリカでほぼリアルタイムで更新されます。

リードレプリカは読み取り専用です。書き込みはできません。リードレプリカは、クエリ、読み取りリクエスト、アナリティクストラフィックを処理し、プライマリインスタンスの負荷を低減します。

レプリカの接続名と IP アドレスを使用して、レプリカに直接接続します。プライベート IP アドレスを使用してレプリカに接続している場合は、接続がプライマリインスタンスから継承されるため、レプリカに追加の VPC プライベート接続を作成する必要はありません。

リードレプリカの作成方法の詳細については、リードレプリカの作成をご覧ください。リードレプリカの管理については、リードレプリカの管理をご覧ください。

プライマリインスタンスで HA を使用する場合は、プライマリインスタンスとは異なるゾーンにリードレプリカを配置することをおすすめします。これにより、プライマリインスタンスが配置されたゾーンで障害が発生しても、リードレプリカのオペレーションを継続できます。詳細については、高可用性の概要をご覧ください。

適切なマシンタイプを選択する

リードレプリカのマシンタイプは、プライマリマシンタイプと異なる場合があります。CPU とメモリの使用状況など、インスタンスの指標をモニタリングして、レプリカインスタンスがワークロードに適したサイズになるようにしてください（特にプライマリインスタンスよりも小さい場合）。レプリカインスタンスのサイズが小さすぎると、メモリ不足（OOM）が頻繁に発生するなど、パフォーマンスが低下しやすくなります。

クロスリージョンリードレプリカ

クロスリージョンレプリケーションでは、プライマリインスタンスとは異なるリージョンにリードレプリカを作成できます。クロスリージョンリードレプリカは、リージョン内のレプリカを作成するで説明した方法で作成します。

クロスリージョンレプリカ:

レプリカをアプリケーションのリージョンのより近くで利用できるようにすることで、読み取りパフォーマンスを向上させます。
リージョンの障害から保護するために、追加の障害復旧機能を提供します。
リージョン間でデータを移行できます。

クロスリージョンレプリカの詳細については、リージョン移行または障害復旧のためにレプリカを昇格させるをご覧ください。

リードレプリカのカスケード

カスケードレプリケーションでは、同じリージョンまたは別のリージョンの別のリードレプリカの下にリードレプリカを作成できます。カスケードレプリカは次のような場合に使用します。

障害復旧: リードレプリカのカスケード階層を使用して、プライマリインスタンスとそのリードレプリカのトポロジをシミュレートできます。停止している間も、選択したリードレプリカがプライマリに昇格し、新しいプライマリのリードレプリカのレプリケーションが継続して、使用可能な状態になります。
パフォーマンスの改善: レプリケーション作業を複数のリードレプリカにオフロードすることで、プライマリインスタンスの負担を軽減します。
読み取りのスケーリング: レプリカを増やして読み取りの負荷を軽減できます。
コスト削減: 他のリージョンでクロスリージョンレプリケーションを含む単一のカスケードレプリカを使用すると、ネットワーク費用を削減できます。

用語

カスケードレプリカ: 独自のレプリカを持つリードレプリカ。
レベル: カスケードレプリカの階層内に、レプリカのレベルを作成できます。たとえば、インスタンスに 4 つのレプリカを追加すると、これらのレプリカは同じレベルになります。
兄弟インスタンス: 同じプライマリインスタンスから複製された複数のレプリカ。兄弟要素は、レプリカ階層の同じレベルにあります。1 つのレプリカには最大 9 個の兄弟要素を設定できます。
リーフレプリカ: 独自のレプリカがないリードレプリカ。マルチレベルのレプリケーション階層で最後のレベルにあるのがリーフレプリカです。
昇格: 階層の任意のレベルのレプリカをプライマリインスタンスに変換するアクション。昇格するときに、レプリカのカスケードレプリカ階層は保持されます。

カスケードレプリカを構成する

カスケードレプリカを使用すると、既存のレプリカにリードレプリカを追加できます。プライマリインスタンスを含む、最大 4 レベルまでのレプリカを追加できます。レプリカをカスケードレプリカ階層の最上位に昇格させると、そのレプリカがプライマリインスタンスになり、カスケードレプリカのレプリケーションが継続します。

構成を計画するには、リードレプリカの想定動作を確認する必要があります。次の 2 つのセクションでは、障害復旧とマルチリージョンレプリケーションの構成について説明します。

障害復旧

停止時にカスケードレプリカによって迅速に回復する仕組みを理解するには、次のレプリケーションシナリオを検討してください。

構成

別のリージョンのカスケードレプリカを使用したカスケードレプリカ構成の図

サービスの停止

サービス停止中の昇格の図

昇格

レプリカを使用した新しいインスタンスの図

障害復旧構成でリージョン B のインスタンスを使用し、次のレプリカがあるとします。

プライマリインスタンス（レプリカ A）に接続されている同じリージョン内のレプリカ
プライマリに接続された他のリージョンのレプリカ（カスケードレプリカ）。

リージョン B のカスケードレプリカにリードレプリカを作成できます。

[サービスの停止] タブで、リージョン A でサービスが停止している場合、カスケードレプリカがプライマリインスタンスに昇格されます。ここにはすでにリードレプリカが存在しているため、リカバリ時間目標（RTO）が短縮されています。

[プロモート] タブでカスケードレプリカが昇格すると、そのレプリカも昇格し、引き続きレプリケーションが実行されます。

マルチリージョンのレプリケーション

カスケードレプリカのもう 1 つのユースケースは、コスト効率の高い方法で読み取り容量を 2 番目のリージョンに分散することです。レプリカ B からレプリケーションするカスケードレプリカ C と D を作成できます。クライアントは、レプリカ B、C、D に読み取りクエリを分散して、各レプリカの負荷を軽減できます。クロスリージョンネットワークトラフィックの料金が発生するのは、プライマリインスタンスからレプリカ B までの 1 回だけです。ユーザー B から C と D へのレプリケーションでは、無料のリージョン内ネットワーク転送が使用されます。

マルチリージョンレプリケーション用のカスケードレプリカを使用して、最大 4 つのインスタンスの階層を作成できます。

プライマリ A → レプリカ B → レプリカ C とレプリカ D

制限事項

レプリカを持つレプリカは削除できません。レプリカを削除するには、リーフレプリカから始めて、階層の上を順に進む必要があります。
リージョンの循環依存はサポートされていません。カスケードレプリカのレプリカをプライマリインスタンスと同じリージョンに配置する場合は、カスケードレプリカも同じリージョンに配置する必要があります。

外部リードレプリカ

外部リードレプリカは、Cloud SQL プライマリインスタンスを複製する外部 MySQL インスタンスです。たとえば、Compute Engine で実行される MySQL インスタンスは外部インスタンスとみなされます。

外部リードレプリカには次の制限があります。

他のクラウドプラットフォームでホストされる MySQL インスタンスに複製できないことがあります。他のプロバイダのドキュメントを確認してください。たとえば、構成フィールド replicate-ignore-db の設定は必須であり、許可されていないクラウドプロバイダはサポートされていません。その他の必要な構成フィールドについては、外部レプリカの構成をご覧ください。
ネットワークまたはサーバーの停止などによって複製が数時間中断された場合、レプリカはプライマリよりも古い状態のものになります。プライマリに再接続され、複製が再開されると、レプリカは最新状態になります。ただし、中断時間が Cloud SQL のレプリケーションログの保存期間（7 つのバックアップ）よりも長かった場合は、レプリカを削除して新しく作成する必要があります。
プライマリから外部レプリカに流れるデータは、アウトバウンドデータ転送として課金されます。Cloud SQL インスタンスタイプのデータ転送料金については、料金ページをご覧ください。

レプリケーションのユースケース

次のユースケースは、レプリケーションのタイプごとに適用されます。

名前	プライマリ	レプリカ	利点と使用例	詳細
リードレプリカ	Cloud SQL インスタンス	Cloud SQL インスタンス	追加の読み取り容量分析対象	リードレプリカの作成リードレプリカの管理レプリケーションの指標レプリケーションラグリードレプリカのインデックス
クロスリージョンリードレプリカ	Cloud SQL インスタンス	Cloud SQL インスタンス	追加の読み取り容量分析対象追加の障害復旧機能読み取りパフォーマンスを向上させるリージョン間でデータを移行する	リードレプリカの作成リードレプリカの管理レプリケーションの指標
外部リードレプリカ	Cloud SQL インスタンス	Cloud SQL に対する外部 MySQL インスタンス	外部接続のレイテンシの削減アナリティクスのターゲット他のプラットフォームへの移行パス	外部レプリカを構成する
外部サーバーからのレプリケーション	Cloud SQL に対する外部 MySQL インスタンス	Cloud SQL for MySQL インスタンス	Cloud SQL への移行パス Google Cloud Platform へのデータレプリケーションアナリティクスのターゲット	外部サーバーからのレプリケーション

リードレプリカを作成するための前提要件

プライマリ Cloud SQL インスタンスのリードレプリカを作成するには、インスタンスが次の要件を満たしている必要があります。

自動バックアップが有効になっていること。
バイナリロギングが有効になっていること。これには、ポイントインタイムリカバリが有効になっている必要があります。このログの影響についてはこちらをご確認ください。
バイナリロギングを有効にした後に、少なくとも 1 つのバックアップが作成されていること。

外部レプリカの追加要件:

レプリカの MySQL バージョンがプライマリインスタンスの MySQL バージョン以降であること。詳細については、こちらをご覧ください。
セキュリティ上、プライマリインスタンスで SSL / TLS を構成すること。詳細については、こちらをご覧ください。

バイナリロギングを有効にした場合の影響

リードレプリカをサポートするには、ポイントインタイムリカバリを有効にして、プライマリインスタンスのバイナリロギングを有効にする必要があります。その結果、次の影響があります。

パフォーマンスのオーバーヘッド
Cloud SQL は、MySQL フラグ sync_binlog=1 と innodb_support_xa=true による行ベースのレプリケーションを使用します。そのため、書き込みオペレーションのたびにディスクの fsync が余分に必要となり、パフォーマンスが低下します。
ストレージのオーバーヘッド
バイナリログのストレージは、通常のデータと同じレートで課金されます。バイナリログは、最も古い自動バックアップの日付で自動的に切り捨てられます。現在、Cloud SQL は最新の 7 つの自動バックアップとすべてのオンデマンドバックアップを保持します。課金対象となるバイナリログのサイズはワークロードによって異なるため、請求される料金も異なります。たとえば、書き込み中心のワークロードでは、読み取り中心のワークロードよりも多くのバイナリログ容量を消費します。

バイナリログのサイズは、SHOW BINARY LOGS MySQL コマンドを使用して確認できます。

バックアップを作成すると、データと一緒にログがバックアップに保存されます。

リードレプリカのバイナリロギング

バイナリロギングはリードレプリカインスタンスでサポートされています（MySQL 5.7 および 8.0 のみ）。レプリカのバイナリロギングを有効にするには、プライマリインスタンス名ではなくレプリカのインスタンス名を指定して、プライマリと同じ API コマンドを使用します。「enable binary logging」と「enable point-in-time recovery」という用語は同じ意味で使用されています。
sync_binlog フラグを使用して、レプリカ（プライマリではなく）のインスタンスのバイナリロギングの耐久性を設定できます。これにより、MySQL サーバーがバイナリログをディスクに同期する頻度を制御できます。
プライマリのバックアップが無効になっている場合でも、レプリカでバイナリロギングを有効にできます。
この値を持つレプリカがスタンドアロンサーバーに昇格されている場合、設定はスタンドアロンサーバーで安全な値 1 にリセットされます。

課金

リードレプリカは、標準 Cloud SQL インスタンスと同じレートで課金されます。データレプリケーションには課金されません。
外部レプリカの場合、プライマリから外部レプリカに流れるデータはデータ転送として課金されます。Cloud SQL インスタンスタイプのデータ転送料金については、料金ページをご覧ください。
クロスリージョンリードレプリカの料金は、リージョン内で新しい Cloud SQL インスタンスを作成する場合と同じです。Cloud SQL インスタンスの料金を参照して、適切なリージョンを選択します。インスタンスに関連する通常のコストに加えて、クロスリージョンレプリカでは、プライマリインスタンスからレプリカインスタンスに送信されるレプリケーションログに対してクロスリージョンのデータ転送料金が発生します。詳しくは、ネットワーク下り（外向き）の料金をご覧ください。

Cloud SQL リードレプリカのクイックリファレンス

トピック	ディスカッション
バックアップ	レプリカのバックアップは構成できません。
コアとメモリ	リードレプリカでは、プライマリインスタンスとは異なる数のコアとメモリ量を使用できます。
プライマリインスタンスの削除	プライマリインスタンスを削除する前に、すべてのリードレプリカをスタンドアロンインスタンスに昇格するか、リードレプリカを削除する必要があります。
レプリカの削除	レプリカを削除しても、プライマリインスタンスのステータスには影響しません。
バイナリロギングの無効化	プライマリインスタンスのバイナリログを無効にするには、その前にすべてのリードレプリカを昇格または削除する必要があります。
フェイルオーバー	プライマリインスタンスはリードレプリカにフェイルオーバーできず、またリードレプリカは停止時にフェイルオーバーできません。
高可用性	リードレプリカによって、レプリカの高可用性を実現できます。
ロードバランシング	Cloud SQL では、レプリカ間のロードバランシングを行いません。Cloud SQL インスタンスのロードバランシングを実装することもできます。また、接続プールを使用すると、ロードバランシング設定を使用してレプリカ間でクエリを分散し、パフォーマンスを向上させることができます。
メンテナンスの時間枠	メンテナンスの時間枠はリードレプリカに設定できないため、プライマリインスタンスとも共有されません。リードレプリカではメンテナンスをいつでも行えます。リードレプリカのメンテナンスは、プライマリインスタンスと異なる時間に行われます。
複数のリードレプリカ	Cloud SQL はカスケードレプリカをサポートしています。その結果、単一のプライマリインスタンスに対して最大で 10 個のレプリカを作成できます。また、レプリカはプライマリを含む最大 4 つのレベルで連結できます。
並列レプリケーション	並列レプリケーションを使用したパフォーマンスの向上については、並列レプリケーションの構成をご覧ください。
プライベート IP	プライベート IP アドレスを使用してレプリカに接続している場合は、プライマリインスタンスから継承されるため、レプリカに追加の VPC プライベート接続を作成する必要はありません。
プライマリインスタンスの復元	レプリカのプライマリインスタンスは、そのレプリカが存在する場合は復元できません。インスタンスをバックアップから復元する前や、インスタンスでポイントインタイムリカバリを実行する前に、すべてのレプリカを昇格または削除する必要があります。
設定	root パスワード、ユーザーテーブルの変更などのプライマリインスタンスの MySQL 設定は、レプリカに伝播されます。CPU とメモリの変更はレプリカに伝播されません。
レプリカの停止	レプリカの `stop` は実行できません。`restart`、`delete`、`disable replication` は可能ですが、プライマリインスタンスで行うように停止することはできません。
レプリカのアップグレード	リードレプリカでは、中断を伴うアップグレードが時間に関係なく行われる可能性があります。
ユーザーテーブル	レプリカに変更を加えることはできません。すべてのユーザー変更は、プライマリインスタンスで行う必要があります。