Zenn
レスキューナウテックブログPublicationへの投稿
📖

AWS EC2 にある MySQL から GCP Cloud SQL へのレプリケーションを構成する

yamada_kazumasa
2023/07/31に公開
AWS
GCP
MySQL
Cloud SQL
tech

はじめに

今回はAWS EC2にあるMySQLをマスター、GCP Cloud SQL for MySQLをスレーブとしてレプリケーションを構成します。AWSのEC2ではMySQLが稼働していて、GCP側は新規に作成するものとします。最終的な構成は以下の図になります。

概要

本記事は、
ネットワークの構築
データベースの準備
外部サーバーの確認
移行ジョブの作成
の構成となります。
また前提条件として、GCPの各APIが有効になっている必要があります。
各APIの詳細は、参考にあるGoogleCloudのドキュメントなどをご覧ください。
それでは、はじめていきましょう。

ネットワークの構築

先ずはAWSとGCP間を繋げる必要があります。接続はVPNを使用します。ネットワーク構築のため、AWSとGCPのそれぞれで操作する必要があります。詳細な手順は以前に解説した記事、GCEからVPNを利用してAWS EC2にあるMySQLへ接続するにありますので合わせてご確認ください。

データベースの準備

CloudSQLはユーザーのVPC内ではなく専用のVPCに構築されるため、先ほど作成したネットワーク構成のVPCより外にあります。CloudSQL専用のVPCとユーザーのVPCを繋げるには、VPC ピアリングを行います。

設定用インスタンスの作成

ネットワークの準備のため、適当なCloudSQLのインスタンスを新規作成します。

VPC ピアリングの設定

  • Cloud SQL のプライベートIPを有効にします
  • ネットワークの構築 にて構築したVPNネットワークを選択します
  • これにより、自動的にVPC ピアリングの設定が行われます

VPC ピアリングの確認

  • 「VPCネットワーク」- 「VPCネットワーク ピアリング」を選択します
  • 一覧にある、「servicenetworking-googleapis-com」を選択します
  • 「VPCネットワーク」とピアリングしているIPアドレス範囲を確認することができます

外部サーバーの確認

レプリケーションの元となる、AWS側のMySQLの設定を確認します。確認事項は以下の通りです。

  • MySQLのバージョン（バージョンを揃える必要があるため）
  • バイナリログが有効になっていること
  • GTIDが有効になっていること
  • レプリケーション用ユーザーを用意していること
    • GTID に基づくレプリケーションの場合は、REPLICATION SLAVE、EXECUTE、SELECT、SHOW VIEW、REPLICATION CLIENT、RELOAD 権限が必要です
    • バイナリログに基づくレプリケーションの場合は、REPLICATION SLAVE、EXECUTE、SELECT、SHOW VIEW、REPLICATION CLIENT、RELOAD 権限が必要です
    • 公式ガイドには上記が必要と記載されていましたが、TRIGGER 権限も必要でした
    • クエリ例：
      GRANT TRIGGER, REPLICATION SLAVE, EXECUTE, SELECT, SHOW VIEW, REPLICATION CLIENT, RELOAD ON . TO repluser;
  • 外部サーバーに DEFINER 句（ビュー、イベント、トリガー、ストアド プロシージャ）が含まれているか
  • データの処理読み込み用のダンプファイルが用意できているか
    • データレプリケーションの際、初期登録を行うために使用します
    • mysqldump 時に CHANGE MASTER TO を記録してもらう必要があるため、--master-data=1 オプションを追加します
    • ダンプコマンド例：
      mysqldump -u USER_NAME -p -h HOST_NAME DB_NAME --master-data=1 > OUTPUT_FILE_NAME

移行ジョブの作成

準備ができましたら、ようやくレプリケーションの設定となります。GCP側で操作します。

データの移行

  • コンソールより、SQL-「データを移行」をクリックします
  • 「移行ジョブを作成」をクリックします
  • ウィザードに沿って、移行ジョブを作成します
    • 途中、接続プロファイルがないため作成を促されるので作成します
      • 接続ユーザーには、外部サーバーの確認 にて作成したレプリケーション用ユーザーを指定します。
    • 「接続先の作成」で、「プライベートIP」接続設定にてエラーが出たときはエラー内容に沿って対応します。特にVPCネットワーク周りを確認します
    • 「接続方法の定義」では、「VPCピアリング」を選択します
    • 最後にテストを実行してみます

設定後の状態

移行ジョブ作成後のCloudSQLの状態は以下のようになります。外部プライマリからデータを取得するリードレプリカが設定されます。

また移行ジョブは以下の状態です。稼働時間などを確認することができます。

初期設定したCloudSQLの削除

データベースの準備にて設定したCloudSQLは不要なので削除します。

おわりに

いかがでしょうか。データをバックアップしてシステムの可用性を高めることは重要で、AWSとGCPにデータを置くことでより高い可用性を担保できます。ただ、複数のサービスを使用するとセキュリティなどのリスクも高まりますので、忘れずに対策を行いましょう。

参考

レスキューナウテックブログ
レスキューナウテックブログPublication

日本で唯一の危機管理情報を専門に取り扱う防災Techのスタートアップ、(株)レスキューナウです。当社で活躍するエンジニアの技術ブログを中心に公開していきます。

Discussion