レプリケーションとは、Cloud SQL インスタンスまたはオンプレミス データベースのコピーを作成して、作業をそのコピーにオフロードする機能です。
はじめに
レプリケーションを使用する主な理由は、パフォーマンスを低下させることなく、データベース内のデータ使用をスケーリングすることです。
その他、次の理由があります。
- リージョン間でのデータ移行
- プラットフォーム間でのデータ移行
- オンプレミス データベースから Cloud SQL へのデータ移行
また、元のインスタンスが破損した場合にレプリカを昇格させることもできます。
Cloud SQL インスタンスを参照する場合、複製されるインスタンスは「プライマリ インスタンス」と呼ばれ、コピーは「リードレプリカ」と呼ばれます。プライマリ インスタンスとリードレプリカは Cloud SQL にあります。
オンプレミス データベースを指している場合、レプリケーション シナリオは「外部サーバーからのレプリケーション」と呼ばれます。このシナリオでは、複製されるデータベースは、ソース データベース サーバーです。Cloud SQL にあるコピーは Cloud SQL レプリカと呼ばれます。また、Cloud SQL のソース データベース サーバーを表すインスタンスもあります。このインスタンスをソース表現インスタンスといいます。
障害復旧のシナリオでは、レプリカを昇格させてプライマリ インスタンスに変換できます。これにより、停止しているリージョン内のインスタンスの代わりとして使用できます。レプリカを昇格させて、破損したインスタンスと置換することもできます。
Cloud SQL は、次の種類のレプリカをサポートします。
Database Migration Service を使用して、ソース データベース サーバーから Cloud SQL に継続的にレプリケーションすることもできます。 注: Cloud SQL では、PostgreSQL の論理レプリケーション機能を使用して独自のレプリケーションを管理できます。Cloud SQL は、2 台の外部サーバー間のレプリケーションをサポートしていません。
リードレプリカ
リードレプリカを使用して Cloud SQL インスタンスから作業をオフロードします。リードレプリカとは、プライマリ インスタンスの正確なコピーです。プライマリ インスタンスのデータやその他の変更は、リードレプリカでほぼリアルタイムで更新されます。
リードレプリカは読み取り専用です。書き込みはできません。リードレプリカは、クエリ、読み取りリクエスト、アナリティクス トラフィックを処理し、プライマリ インスタンスの負荷を低減します。
レプリカの接続名と IP アドレスを使用して、レプリカに直接接続します。プライベート IP アドレスを使用してレプリカに接続している場合は、接続がプライマリ インスタンスから継承されるため、レプリカに追加の VPC プライベート接続を作成する必要はありません。
リードレプリカの作成方法の詳細については、リードレプリカの作成をご覧ください。リードレプリカの管理については、リードレプリカの管理をご覧ください。
プライマリ インスタンスで HA を使用する場合は、プライマリ インスタンスとは異なるゾーンにリードレプリカを配置することをおすすめします。これにより、プライマリ インスタンスが配置されたゾーンで障害が発生しても、リードレプリカのオペレーションを継続できます。詳細については、高可用性の概要をご覧ください。
適切なマシンタイプを選択する
リードレプリカのマシンタイプは、プライマリ マシンタイプと異なる場合があります。CPU とメモリの使用状況など、インスタンスの指標をモニタリングして、レプリカ インスタンスがワークロードに適したサイズになるようにしてください（特にプライマリ インスタンスよりも小さい場合）。レプリカ インスタンスのサイズが小さすぎると、メモリ不足（OOM）が頻繁に発生するなど、パフォーマンスが低下しやすくなります。
リードレプリカがプライマリよりもメモリが少ないマシンタイプである場合の max_connections フラグへの影響
PostgreSQL インスタンスでは、max_connections フラグを任意の値に設定しない場合、Cloud SQL がインスタンスのメモリ量に基づいて自動的にその値を設定します。詳細については、サポートされているフラグをご覧ください。PostgreSQL では、max_connections の値が少なくともプライマリのリードレプリカと同じ大きさでなければなりません。したがって、リードレプリカのプライマリよりもメモリが少なく、max_connections フラグを設定していない場合、リードレプリカはプライマリ インスタンスのサイズに基づいてより大きな値 max_connections を継承することがあります。この場合、max_connections 設定を使用してレプリカ インスタンスへの接続数を制限すると、インスタンスのマシンタイプに対して値が大きすぎるため、過負荷になる可能性があります。このような状況を避けるには、次のいずれかを行います。
- レプリカ インスタンスのサイズを大きくする。
- クライアント アプリケーションを構成して、
max_connectionsの値未満の接続数に制限する。 - プライマリとレプリカの
max_connectionsフラグを適切な値に設定する。
リードレプリカを使用したハッシュ インデックス オペレーション
ハッシュ インデックス オペレーションは、PostgreSQL 9.6 の write-ahead log 書き込みを使用しません。PostgreSQL 10 の場合、Cloud SQL で使用できるバージョンは 1 つだけです。このことは、PostgreSQL のリリースページにある黄色の警告ボックスに記載されています。これは Cloud SQL リードレプリカにも当てはまります。
PostgreSQL 9.6 では、ハッシュ インデックスの更新はリードレプリカに伝播されないため、この更新はレプリカで使用できません。回避策として、リードレプリカの使用を避けるか、PostgreSQL のメジャー バージョン（10 以降）にアップグレードします。
クロスリージョン リードレプリカ
クロスリージョン レプリケーションでは、プライマリ インスタンスとは異なるリージョンにリードレプリカを作成できます。クロスリージョン リードレプリカは、リージョン内のレプリカを作成するで説明した方法で作成します。
クロスリージョン レプリカ:
- レプリカをアプリケーションのリージョンのより近くで利用できるようにすることで、読み取りパフォーマンスを向上させます。
- リージョンの障害から保護するために、追加の障害復旧機能を提供します。
- リージョン間でデータを移行できます。
クロスリージョン レプリカの詳細については、リージョン移行または障害復旧のためにレプリカを昇格させるをご覧ください。
リードレプリカのカスケード
カスケード レプリケーションでは、同じリージョンまたは別のリージョンの別のリードレプリカの下にリードレプリカを作成できます。次のシナリオは、カスケード レプリカを使用するユースケースです。
- 障害復旧: リードレプリカのカスケード階層を使用して、プライマリ インスタンスとそのリードレプリカのトポロジをシミュレートできます。サービスが停止している間も、選択したリードレプリカがプライマリに昇格し、新しいプライマリのリードレプリカのレプリケーションが継続して、使用可能な状態になります。
- パフォーマンスの改善: レプリケーション作業を複数のリードレプリカにオフロードすることで、プライマリ インスタンスの負担を軽減します。
- 読み取りのスケーリング: レプリカを増やして読み取りの負荷を軽減できます。
- コスト削減: 他のリージョンでクロスリージョン レプリケーションを含む単一のカスケード レプリカを使用すると、ネットワーク費用を削減できます。
用語
- カスケード レプリカ: 独自のレプリカを持つリードレプリカ。
- レベル: カスケード レプリカの階層内に、レプリカのレベルを作成できます。たとえば、インスタンスに 4 つのレプリカを追加すると、これらのレプリカは同じレベルになります。
- 兄弟インスタンス: 同じプライマリ インスタンスから複製された複数のレプリカ。兄弟要素は、レプリカ階層の同じレベルにあります。1 つのレプリカには最大 8 個の兄弟要素を設定できます。
- リーフレプリカ: 独自のレプリカがないリードレプリカ。 マルチレベルのレプリケーション階層で最後のレベルにあるのがリーフレプリカです。
- プロモート: 階層の任意レベルのレプリカをプライマリ インスタンスに変換するアクション。プロモートするときに、レプリカのカスケード レプリカ階層は保持されます。
カスケード レプリカを構成する
カスケード レプリカを使用すると、既存のレプリカにリードレプリカを追加できます。プライマリ インスタンスを含む、最大 4 レベルまでのレプリカを追加できます。レプリカをカスケード レプリカ階層の最上位に昇格させると、そのレプリカがプライマリ インスタンスになり、カスケード レプリカのレプリケーションが継続します。
構成を計画するには、リードレプリカの想定動作を確認する必要があります。次の 2 つのセクションでは、障害復旧とマルチリージョン レプリケーションの構成について説明します。
障害復旧
停止時にカスケード レプリカによって迅速に回復する仕組みを理解するには、次のレプリケーション シナリオを検討してください。
構成
サービスの停止
Promotion
障害復旧構成でリージョン 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 では、PostgreSQL の論理レプリケーション機能を使用して独自のレプリケーション ソリューションを構成できます。論理レプリケーションは柔軟性の高いソリューションであり、以下のことが可能です。
- プライマリ インスタンスからレプリカへの標準的なレプリケーション
- 特定のテーブルまたは行のみの選択的なレプリケーション
- PostgreSQL のメジャー バージョンをまたがるレプリケーション
- PostgreSQL 以外のデータベースへのレプリケーション
- すべてのデータベースの変更がコンシューマにストリーミングされる変更データ キャプチャ（CDC）ワークフロー
詳細については、論理レプリケーションの設定をご覧ください。以下に関する情報が記載されています。
- 組み込み論理レプリケーション
- pglogical 拡張機能
レプリケーションのユースケース
次のユースケースは、レプリケーションのタイプごとに適用されます。
| 名前 | プライマリ | レプリカ | 利点と使用例 | 詳細 |
|---|---|---|---|---|
| リードレプリカ | Cloud SQL インスタンス | Cloud SQL インスタンス |
|
|
| クロスリージョン リードレプリカ | Cloud SQL インスタンス | Cloud SQL インスタンス |
|
|
| 論理レプリケーション | 任意の PostgreSQL インスタンス | 任意の PostgreSQL インスタンス、または外部コンシューマ |
|
課金
- リードレプリカは、標準 Cloud SQL インスタンスと同じレートで課金されます。データ レプリケーションには課金されません。
- クロスリージョン リードレプリカの料金は、リージョン内で新しい Cloud SQL インスタンスを作成する場合と同じです。Cloud SQL インスタンスの料金を参照して、適切なリージョンを選択します。インスタンスに関連する通常のコストに加えて、クロスリージョン レプリカでは、プライマリ インスタンスからレプリカ インスタンスに送信されるレプリケーション ログに対してリージョン間のデータ転送料金が発生します。詳しくは、ネットワーク下り（外向き）の料金をご覧ください。
Cloud SQL リードレプリカのクイック リファレンス
| トピック | ディスカッション |
|---|---|
| バックアップ | レプリカのバックアップは構成できません。 |
| コア数とメモリ | リードレプリカでは、プライマリ インスタンスとは異なる数のコアやメモリ量を使用できます。 |
| プライマリ インスタンスの削除 | プライマリ インスタンスを削除するには、まずすべてのリードレプリカをスタンドアロン インスタンスに昇格するか、リードレプリカを削除する必要があります。 |
| レプリカの削除 | レプリカを削除しても、プライマリ インスタンスのステータスには影響しません。 |
| write-ahead log 書き込みの無効化 | プライマリ インスタンスの write-ahead log 書き込みを無効にするには、その前にすべてのリードレプリカを昇格または削除する必要があります。 |
| フェイルオーバー | プライマリ インスタンスは、レプリカが DR レプリカの場合にのみレプリカにフェイルオーバーできます。リードレプリカは停止時にフェイルオーバーできません。 |
| 高可用性 | リードレプリカによって、レプリカの高可用性を実現できます。 |
| ロード バランシング | Cloud SQL では、レプリカ間のロード バランシングを行いません。Cloud SQL インスタンスのロード バランシングを実装することもできます。また、接続プールを使用すると、ロード バランシング設定を使用してレプリカ間でクエリを分散し、パフォーマンスを向上させることができます。 |
| メンテナンスの時間枠 | リードレプリカはプライマリ インスタンスとメンテナンスの時間枠を共有します。リードレプリカは、メンテナンスの時間枠、スケジュール変更、メンテナンス拒否期間などのプライマリ インスタンスのメンテナンス設定に従います。メンテナンス中、Cloud SQL はすべてのリードレプリカを更新してから、プライマリ インスタンスを更新します。 |
| 複数のリードレプリカ | Cloud SQL はカスケード レプリカをサポートしています。その結果、単一のプライマリ インスタンスに対して最大で 10 個のレプリカを作成できます。また、プライマリ インスタンスを含む最大 4 つのレベルでこれらのレプリカのレプリカを作成できます。 |
| プライベート IP | プライベート IP アドレスを使用してレプリカに接続している場合は、プライマリ インスタンスから継承されるため、レプリカに追加の VPC プライベート接続を作成する必要はありません。 |
| プライマリ インスタンスの復元 | レプリカのプライマリ インスタンスは、そのレプリカが存在する場合は復元できません。インスタンスをバックアップから復元する前や、インスタンスでポイントインタイム リカバリを実行する前に、すべてのレプリカを昇格または削除する必要があります。 |
| 設定 | postgres ユーザーのパスワードやユーザー テーブルの変更など、プライマリ インスタンスの設定はレプリカに伝播されます。 |
| レプリカの停止 | レプリカの stop は実行できません。restart、delete、disable replication は可能ですが、プライマリ インスタンスで行うように停止することはできません。 |
| レプリカのアップグレード | リードレプリカでは、中断を伴うアップグレードが時間に関係なく行われる可能性があります。 |
| ユーザー テーブル | レプリカに変更を加えることはできません。すべてのユーザー変更は、プライマリ インスタンスで行う必要があります。 |
次のステップ
- リードレプリカの作成方法を学習する。
- インスタンスの高可用性を構成する方法を確認する。