Google Cloud SQL for MySQLは、Google Cloud PlatformでMySQLリレーショナルデータベースを設定、維持、管理、管理するのに役立つフルマネージドデータベースサービスです。ただし、Cloud SQLと、制限された制御、制限されたリソース、データの局所性、予算、セキュリティなどの標準のMySQL機能には違いがあり、Google Cloud SQLインスタンスから移行して、データベースサービスをオンプレミスでホストする最終決定に影響を与える可能性があります。代わりにオンプレミスインフラストラクチャ。
このブログ投稿では、GoogleCloudSQLからオンプレミスサーバーへのオンライン移行を実行する方法について説明します。オンプレミスサーバー上のターゲットデータベースはDebianサーバーですが、手順と手順は、パッケージが適切にインストールされている限り、他のバージョンのLinuxにも適用されます。
Google CloudMySQLインスタンスはMySQL5.7で実行されており、必要なものは次のとおりです。
- セキュリティ上の理由から、地理的レプリケーションに対してSSLを有効にする必要があります。
Google CloudはデフォルトでMySQLのGTIDレプリケーションを有効にしているため、このレプリケーションスキームに基づいて移行を行います。したがって、この投稿で説明されている手順は、MySQL8.0インスタンスでも機能するはずです。
まず、GoogleCloudSQLインスタンスでレプリケーションスレーブユーザーを作成する必要があります。 Google CloudPlatformにログイン->データベース->SQL->MySQLインスタンスを選択->ユーザー->ユーザーアカウントを追加し、必要な詳細を入力します：
202.187.194.255は、オンプレミスにあるスレーブパブリックIPアドレスです。このインスタンスから複製する予定のオンプレミス。ご覧のとおり、このインターフェースから作成されたユーザーは、Google Cloud SQLが提供できる最高の特権（SUPERとFILEを除くほとんどすべて）を持つため、特権の構成はありません。特権を確認するには、次のコマンドを使用できます。
mysql> SHOW GRANTS FOR [email protected]\G
*************************** 1. row ***************************
Grants for [email protected]: GRANT SELECT, INSERT, UPDATE, DELETE, CREATE,
DROP, RELOAD, SHUTDOWN, PROCESS, REFERENCES, INDEX, ALTER, SHOW DATABASES,
CREATE TEMPORARY TABLES, LOCK TABLES, EXECUTE, REPLICATION SLAVE, REPLICATION CLIENT,
CREATE VIEW, SHOW VIEW, CREATE ROUTINE, ALTER ROUTINE, CREATE USER, EVENT, TRIGGER,
CREATE TABLESPACE ON *.* TO 'slave'@'202.187.194.255' WITH GRANT OPTIONスレーブユーザーがスレーブとして実行するために必要な権限を持っているようです（REPLICATIONSLAVE）。
mysqldumpバックアップの作成
外部のmysqldumpバックアップを作成する前に、パブリックネットワークを介してインスタンスに接続するリスクがあるため、クライアントのSSL証明書を構成する必要があります。これを行うには、「接続」->「SSLクライアント証明書の構成」->「クライアント証明書の作成」に移動します。
上記のファイル（server-ca.pem、client-cert）をダウンロードします。 pemおよびclient-key.pem）を作成し、それらをスレーブサーバー内に保存します。これらの証明書を使用して、スレーブサーブからマスターに安全に接続します。プロセスを簡素化するために、上記のすべての証明書とキーファイルは「gcloud-certs」というディレクトリに配置されます：
$ mkdir -p /root/gcloud-certs # put the certs/key here権限、特に秘密鍵ファイルclient-key.pemが正しいことを確認してください：
$ chmod 600 /root/gcloud-certs/client-key.pemこれで、Google Cloud SQLMySQL5.7インスタンスからmysqldumpバックアップを安全に取得する準備が整いました。
$ mysqldump -uroot -p \
-h 35.198.197.171 \
--ssl-ca=/root/gcloud-certs/server-ca.pem \
--ssl-cert=/root/gcloud-certs/client-cert.pem \
--ssl-key=/root/gcloud-certs/client-key.pem \
--single-transaction \
--all-databases \
--triggers \
--routines > fullbackup.sql"警告：GTIDを持つサーバーからの部分的なダンプには、デフォルトで、データベースの抑制された部分を変更したトランザクションも含め、すべてのトランザクションのGTIDが含まれます。 GTIDを復元するには、-set-gtid-purged =OFFを渡します。完全なダンプを作成するには、-all-databases --triggers--routines--eventsを渡します。"
上記の警告は、SUPER特権を必要とする--eventsフラグの定義をスキップしたために発生します。すべてのGoogleCloudSQLインスタンス用に作成されたrootユーザーには、FILEおよびSUPER権限が付属していません。これは、このメソッドを使用することの欠点の1つであり、MySQLイベントをGoogleCloudSQLからインポートできないことです。
スレーブサーバーに、Debian10用のMySQL5.7をインストールします。
$ echo 'deb http://repo.mysql.com/apt/debian/ buster mysql-5.7' > /etc/apt/sources.list.d/mysql.list
$ apt-key adv --keyserver pgp.mit.edu --recv-keys 5072E1F5
$ apt update
$ apt -y install mysql-community-server次に、/ etc / mysql / my.cnf（またはその他の関連するMySQL構成ファイル）内の[mysqld]セクションの下に次の行を追加します。
server-id = 1111 # different value than the master
log_bin = binlog
log_slave_updates = 1
expire_logs_days = 7
binlog_format = ROW
gtid_mode = ON
enforce_gtid_consistency = 1
sync_binlog = 1
report_host = 202.187.194.255 # IP address of this slaveMySQLサーバーを再起動して、上記の変更を適用します。
$ systemctl restart mysql$ mysql -uroot -p < fullbackup.sqlこの時点で、スレーブサーバーのMySQLルートパスワードはGoogleCloudSQLのパスワードと同じである必要があります。今後は別のrootパスワードでログインする必要があります。
GoogleCloudのrootユーザーには完全な権限がないことに注意してください。このサーバーをより詳細に制御できるため、rootユーザーがMySQL内のすべての特権を持つことを許可することにより、スレーブ側でいくつかの変更を加える必要があります。これを行うには、MySQLのユーザーテーブルを更新する必要があります。 MySQLルートユーザーとしてスレーブのMySQLサーバーにログインし、次のステートメントを実行します。
mysql> UPDATE mysql.user SET Super_priv = 'Y', File_priv = 'Y' WHERE User = 'root';
Query OK, 1 row affected (0.00 sec)
Rows matched: 1 Changed: 1 Warnings: 0特権テーブルをフラッシュします：
mysql> FLUSH PRIVILEGES;
Query OK, 0 rows affected (0.00 sec)現在のターミナルを終了し、再度ログインします。次のコマンドを実行して、rootユーザーが最高レベルの権限を持っていることを確認します。
mysql> SHOW GRANTS FOR [email protected];
+---------------------------------------------------------------------+
| Grants for [email protected] |
+---------------------------------------------------------------------+
| GRANT ALL PRIVILEGES ON *.* TO 'root'@'localhost' WITH GRANT OPTION |
+---------------------------------------------------------------------+レプリケーションリンクの設定
セキュリティ上の理由から、レプリケーションスレーブユーザーはSSL暗号化チャネルを介してマスターホスト（Google Cloudインスタンス）に接続する必要があります。したがって、SSLキーと証明書を正しい権限で準備し、mysqlユーザーがアクセスできるようにする必要があります。 gcloudディレクトリを/etc/ mysqlにコピーし、正しい権限と所有権を割り当てます：
$ mkdir -p /etc/mysql
$ cp /root/gcloud-certs /etc/mysql
$ chown -Rf mysql:mysql /etc/mysql/gcloud-certsスレーブサーバーで、レプリケーションリンクを次のように構成します。
mysql> CHANGE MASTER TO MASTER_HOST = '35.198.197.171',
MASTER_USER = 'slave',
MASTER_PASSWORD = 'slavepassword',
MASTER_AUTO_POSITION = 1,
MASTER_SSL = 1,
MASTER_SSL_CERT = '/etc/mysql/gcloud-certs/client-cert.pem',
MASTER_SSL_CA = '/etc/mysql/gcloud-certs/server-ca.pem',
MASTER_SSL_KEY = '/etc/mysql/gcloud-certs/client-key.pem';次に、レプリケーションスレーブを開始します：
mysql> START SLAVE;次のように出力を確認します。
mysql> SHOW SLAVE STATUS\G
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 35.198.197.171
Master_User: slave
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: mysql-bin.000003
Read_Master_Log_Pos: 1120160
Relay_Log_File: puppet-master-relay-bin.000002
Relay_Log_Pos: 15900
Relay_Master_Log_File: mysql-bin.000003
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Replicate_Do_DB:
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Exec_Master_Log_Pos: 1120160
Relay_Log_Space: 16115
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Master_SSL_Allowed: Yes
Master_SSL_CA_File: /etc/mysql/gcloud-certs/server-ca.pem
Master_SSL_CA_Path:
Master_SSL_Cert: /etc/mysql/gcloud-certs/client-cert.pem
Master_SSL_Cipher:
Master_SSL_Key: /etc/mysql/gcloud-certs/client-key.pem
Seconds_Behind_Master: 0
Master_SSL_Verify_Server_Cert: No
Last_IO_Errno: 0
Last_IO_Error:
Last_SQL_Errno: 0
Last_SQL_Error:
Replicate_Ignore_Server_Ids:
Master_Server_Id: 2272712871
Master_UUID: 8539637e-14d1-11eb-ae3c-42010a94001a
Master_Info_File: /var/lib/mysql/master.info
SQL_Delay: 0
SQL_Remaining_Delay: NULL
Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates
Master_Retry_Count: 86400
Master_Bind:
Last_IO_Error_Timestamp:
Last_SQL_Error_Timestamp:
Master_SSL_Crl:
Master_SSL_Crlpath:
Retrieved_Gtid_Set: 8539637e-14d1-11eb-ae3c-42010a94001a:5611-5664
Executed_Gtid_Set: 8539637e-14d1-11eb-ae3c-42010a94001a:1-5664,
b1dabe58-14e6-11eb-840f-0800278dc04d:1-2
Auto_Position: 1
Replicate_Rewrite_DB:
Channel_Name:
Master_TLS_Version:Slave_IO_RunningとSlave_SQL_Runningの値が「Yes」であり、Seconds_Behind_Masterが0であることを確認します。これは、スレーブがマスターに追いついたことを意味します。 Executed_Gtid_Setには2つのGTIDがあることに注意してください。
- 8539637e-14d1-11eb-ae3c-42010a94001a：1-5664
- b1dabe58-14e6-11eb-840f-0800278dc04d：1-2
最初のGTIDは、現在のマスター（Google Cloud SQLインスタンス）からの変更を表し、2番目のGTIDは、スレーブホスト上のMySQLrootユーザーの権限を変更したときに行った変更を表します。最初のGTIDに注意して、データベースが正しく複製されているかどうかを確認します（整数部分は複製中に増分する必要があります）。
マスターの観点から、スレーブホストがレプリケーションの一部であるかどうかを確認します。 rootとしてSQLCloudインスタンスにログインします：
$ mysql -uroot -p \
-h 35.198.197.171 \
--ssl-ca=/root/gcloud-certs/server-ca.pem \
--ssl-cert=/root/gcloud-certs/client-cert.pem \
--ssl-key=/root/gcloud-certs/client-key.pemそして、次のステートメントを実行します：
mysql> SHOW SLAVE HOSTS;
*************************** 1. row ***************************
Server_id: 1111
Host: 202.187.194.255
Port: 3306
Master_id: 2272712871
Slave_UUID: b1dabe58-14e6-11eb-840f-0800278dc04dこの時点で、データベースワークロードをアプリケーションからこのスレーブサーバーに新しいマスターとしてリダイレクトし、GoogleCloudの古いマスターを廃止する次の動きを計画できます。
Google Cloud SQLforMySQLからオンプレミスサーバーへのオンライン移行を簡単に実行できます。これにより、適切な時期が来たときにプライバシーと制御のためにデータベースをクラウドベンダーの外に移動することができます。