Google Cloud SQL за MySQL е напълно управлявана услуга за бази данни, която ви помага да настроите, поддържате, управлявате и администрирате вашите MySQL релационни бази данни в Google Cloud Platform. Въпреки това, има разлики между Cloud SQL и стандартната MySQL функционалност, като ограничен контрол, ограничени ресурси, локализиране на данни, бюджет и сигурност, които могат да повлияят на окончателното ви решение да излезете от екземплярите на Google Cloud SQL и да хоствате услугата за база данни в вместо това инфраструктура на помещенията.
Тази публикация в блога ще ви преведе през това как да извършите онлайн миграция от Google Cloud SQL към локален сървър. Нашата целева база данни на локалния сървър е Debian сървър, но стъпките и процедурите ще се прилагат за други версии на Linux, както и стига пакетите да са правилно инсталирани.
Нашият екземпляр на Google Cloud MySQL работи на MySQL 5.7 и това, от което се нуждаем, е:
- Подчинен потребител за репликация, създаден на главния.
- Подчинът трябва да бъде инсталиран със същата основна версия като главната.
- SSL трябва да бъде активиран за географска репликация от съображения за сигурност.
Тъй като Google Cloud по подразбиране активира GTID репликация за MySQL, ще направим миграция въз основа на тази схема за репликация. Следователно инструкциите, описани в тази публикация, трябва да работят и в екземпляри на MySQL 8.0.
Създаване на подчинен потребител на репликация
На първо място, трябва да създадем подчинен потребител на репликация в нашия екземпляр на Google Cloud SQL. Влезте в Google Cloud Platform -> Бази данни -> 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Изглежда, че нашият подчинен потребител има необходимото разрешение да работи като подчинен (РЕПЛИКАЦИОННО ДОБРЕНО).
Вземане на резервно копие на 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Сега сме готови да вземем сигурно резервно копие на mysqldump от нашия екземпляр на Google Cloud SQL MySQL 5.7:
$ 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."
Горното предупреждение се появява, защото пропуснахме дефинирането на флага --events, който изисква привилегията SUPER. Потребителят root, създаден за всеки екземпляр на Google Cloud SQL, не се предлага с привилегии FILE и SUPER. Това е един от недостатъците на използването на този метод, че MySQL събития не могат да бъдат импортирани от Google Cloud SQL.
Конфигуриране на подчинения сървър
На подчинения сървър инсталирайте MySQL 5.7 за Debian 10:
$ 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След това добавете следните редове под секцията [mysqld] в /etc/mysql/my.cnf (или всеки друг подходящ конфигурационен файл на MySQL):
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 slaveРестартирайте MySQL сървъра, за да приложите горните промени:
$ systemctl restart mysqlВъзстановете архива на mysqldump на този сървър:
$ mysql -uroot -p < fullbackup.sqlВ този момент основната парола на MySQL на подчинения сървър трябва да е идентична с тази в Google Cloud SQL. От сега нататък трябва да влизате с друга root парола.
Обърнете внимание, че root потребителят в Google Cloud няма пълни привилегии. Трябва да направим някои модификации на подчинената страна, като позволим на root потребителя да има всички привилегии в MySQL, тъй като имаме повече контрол върху този сървър. За да направим това, трябва да актуализираме потребителската таблица на MySQL. Влезте в MySQL сървъра на подчинения като root потребител на 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 |
+---------------------------------------------------------------------+Настройване на връзката за репликация
От съображения за сигурност подчинения потребител на репликация трябва да се свърже с главния хост (екземпляр на Google Cloud) чрез SSL криптиран канал. Следователно трябва да подготвим 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 са 'Да', както и Seconds_Behind_Master трябва да е 0, което означава, че подчинения е настигнал главния. Забележете, че Executed_Gtid_Set има два GTID:
- 8539637e-14d1-11eb-ae3c-42010a94001a:1-5664
- b1dabe58-14e6-11eb-840f-0800278dc04d:1-2
Първият GTID представлява промените, идващи от текущия главен (екземпляр на Google Cloud SQL), докато вторият GTID представлява промените, които сме направили, когато сме променили привилегиите за MySQL root потребител на подчинения хост. Обърнете внимание на първия GTID, за да видите дали базата данни се репликира правилно (целочислената част трябва да се увеличава по време на репликация).
Проверете дали нашият подчинен хост е част от репликацията от гледна точка на главната. Влезте в екземпляра на SQL Cloud като root:
$ 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В този момент можете да планирате следващия си ход за пренасочване на работното натоварване на базата данни от приложенията към този подчинен сървър като нов главен и извеждане от експлоатация на стария главен в Google Cloud.
Последни мисли
Можете да извършите онлайн миграция от Google Cloud SQL за MySQL към локален сървър без много проблеми. Това ви дава възможност да преместите базата си данни извън доставчиците на облак за поверителност и контрол, когато настъпи подходящият момент.
