Google Cloud SQL for MySQL to w pełni zarządzana usługa baz danych, która pomaga konfigurować, utrzymywać, zarządzać i administrować relacyjnymi bazami danych MySQL w Google Cloud Platform. Istnieją jednak różnice między Cloud SQL a standardowymi funkcjami MySQL, takie jak ograniczona kontrola, ograniczone zasoby, lokalizacja danych, budżet i bezpieczeństwo, które mogą wpłynąć na ostateczną decyzję o przeniesieniu się z instancji Google Cloud SQL i hostowaniu usługi bazy danych w zamiast infrastruktury.
W tym poście na blogu dowiesz się, jak przeprowadzić migrację online z Google Cloud SQL na serwer lokalny. Naszą docelową bazą danych na serwerze lokalnym jest serwer Debiana, ale kroki i procedury mają zastosowanie w innych wersjach Linuksa, o ile pakiety są prawidłowo zainstalowane.
Nasza instancja Google Cloud MySQL działa na MySQL 5.7 i potrzebujemy:
- Użytkownik podrzędny replikacji utworzony na urządzeniu głównym.
- Slave musi być zainstalowany z tą samą główną wersją co master.
- SSL musi być włączony do replikacji geograficznej ze względów bezpieczeństwa.
Ponieważ Google Cloud domyślnie włączył replikację GTID dla MySQL, zamierzamy przeprowadzić migrację w oparciu o ten schemat replikacji. Dlatego instrukcje opisane w tym poście powinny również działać w instancjach MySQL 8.0.
Tworzenie użytkownika podrzędnego replikacji
Przede wszystkim musimy stworzyć użytkownika podrzędnego replikacji na naszej instancji Google Cloud SQL. Zaloguj się do Google Cloud Platform -> Bazy danych -> SQL -> wybierz instancję MySQL -> Użytkownicy -> Dodaj konto użytkownika i wprowadź wymagane dane:
202.187.194.255 to publiczny adres IP urządzenia podrzędnego znajdujący się w naszym lokale, które będą replikowane z tej instancji. Jak widać, nie ma konfiguracji uprawnień, ponieważ użytkownicy utworzeni z tego interfejsu będą mieli najwyższe uprawnienia, jakie może zaoferować Google Cloud SQL (prawie wszystko oprócz SUPER i FILE). Aby zweryfikować uprawnienia, możemy użyć następującego polecenia:
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 OPTIONWygląda na to, że nasz użytkownik slave ma wymagane uprawnienia do działania jako slave (RELACJA SLAVE).
Tworzenie kopii zapasowej mysqldump
Zanim stworzymy zewnętrzną kopię zapasową mysqldump, musimy skonfigurować certyfikaty SSL klienta ze względu na ryzyko połączenia instancji przez sieć publiczną. Aby to zrobić, przejdź do Połączenia -> Konfiguruj certyfikaty klienta SSL -> Utwórz certyfikat klienta:
Pobierz powyższe pliki (server-ca.pem, client-cert. pem i client-key.pem) i przechowuj je na serwerze podrzędnym. Zamierzamy użyć tych certyfikatów, aby bezpiecznie połączyć się z masterem z serwera slave. Aby uprościć proces, wszystkie powyższe certyfikaty i plik klucza zostaną umieszczone w katalogu o nazwie „gcloud-certs”:
$ mkdir -p /root/gcloud-certs # put the certs/key hereUpewnij się, że uprawnienia są prawidłowe, zwłaszcza plik klucza prywatnego, client-key.pem:
$ chmod 600 /root/gcloud-certs/client-key.pemTeraz jesteśmy gotowi do bezpiecznego wykonania kopii zapasowej mysqldump z naszej instancji 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.sqlPowinieneś otrzymać następujące ostrzeżenie:
"Ostrzeżenie:częściowy zrzut z serwera, który ma identyfikatory GTID, będzie domyślnie zawierał identyfikatory GTID wszystkich transakcji, nawet tych, które zmieniły wyłączone części bazy danych. Jeśli nie chcesz przywróć identyfikatory GTID, przekaż --set-gtid-purged=OFF. Aby wykonać kompletny zrzut, przekaż --all-databases --triggers --routines --events."
Powyższe ostrzeżenie pojawia się, ponieważ pominęliśmy definiowanie flagi --events, która wymaga uprawnienia SUPER. Użytkownik root utworzony dla każdej instancji Google Cloud SQL nie ma uprawnień FILE i SUPER. Jest to jedna z wad korzystania z tej metody, ponieważ zdarzenia MySQL nie mogą być importowane z Google Cloud SQL.
Konfiguracja serwera podrzędnego
Na serwerze podrzędnym zainstaluj MySQL 5.7 dla Debiana 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-serverNastępnie dodaj następujące wiersze w sekcji [mysqld] wewnątrz /etc/mysql/my.cnf (lub dowolnego innego odpowiedniego pliku konfiguracyjnego 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 slaveZrestartuj serwer MySQL, aby zastosować powyższe zmiany:
$ systemctl restart mysqlPrzywróć kopię zapasową mysqldump na tym serwerze:
$ mysql -uroot -p < fullbackup.sqlW tym momencie hasło root MySQL serwera podrzędnego powinno być takie samo jak hasło w Google Cloud SQL. Od teraz powinieneś logować się przy użyciu innego hasła roota.
Pamiętaj, że użytkownik root w Google Cloud nie ma pełnych uprawnień. Musimy dokonać pewnych modyfikacji po stronie slave, pozwalając użytkownikowi root na posiadanie wszystkich uprawnień w MySQL, ponieważ mamy większą kontrolę nad tym serwerem. Aby to zrobić, musimy zaktualizować tabelę użytkowników MySQL. Zaloguj się do serwera MySQL urządzenia podrzędnego jako użytkownik root MySQL i uruchom następującą instrukcję:
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: 0Opróżnij tabelę uprawnień:
mysql> FLUSH PRIVILEGES;
Query OK, 0 rows affected (0.00 sec)Wyjdź z bieżącego terminala i zaloguj się ponownie. Uruchom następujące polecenie, aby sprawdzić, czy użytkownik root ma teraz najwyższy poziom uprawnień:
mysql> SHOW GRANTS FOR [email protected];
+---------------------------------------------------------------------+
| Grants for [email protected] |
+---------------------------------------------------------------------+
| GRANT ALL PRIVILEGES ON *.* TO 'root'@'localhost' WITH GRANT OPTION |
+---------------------------------------------------------------------+Konfigurowanie łącza replikacji
Ze względów bezpieczeństwa użytkownik podrzędny replikacji musi połączyć się z hostem głównym (instancją Google Cloud) za pośrednictwem kanału szyfrowanego SSL. Dlatego musimy przygotować klucz i certyfikat SSL z odpowiednimi uprawnieniami i dostępnymi dla użytkownika mysql. Skopiuj katalog gcloud do /etc/mysql i przypisz odpowiednie uprawnienia i własność:
$ mkdir -p /etc/mysql
$ cp /root/gcloud-certs /etc/mysql
$ chown -Rf mysql:mysql /etc/mysql/gcloud-certsNa serwerze podrzędnym skonfiguruj łącze replikacji jak poniżej:
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';Następnie uruchom niewolnika replikacji:
mysql> START SLAVE;Sprawdź dane wyjściowe w następujący sposób:
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:Upewnij się, że wartości Slave_IO_Running i Slave_SQL_Running mają wartość „Yes”, a Seconds_Behind_Master powinno wynosić 0, co oznacza, że slave dogonił mastera. Zauważ, że Executed_Gtid_Set ma dwa identyfikatory GTID:
- 8539637e-14d1-11eb-ae3c-42010a94001a:1-5664
- b1dabe58-14e6-11eb-840f-0800278dc04d:1-2
Pierwszy GTID reprezentuje zmiany pochodzące z bieżącego mastera (instancji Google Cloud SQL), podczas gdy drugi GTID reprezentuje zmiany, które wprowadziliśmy, gdy zmodyfikowaliśmy uprawnienia użytkownika root MySQL na hoście slave. Zwróć uwagę na pierwszy identyfikator GTID, aby sprawdzić, czy baza danych replikuje się prawidłowo (część całkowita powinna zwiększać się podczas replikacji).
Sprawdź, czy nasz host slave jest częścią replikacji z punktu widzenia mastera. Zaloguj się do instancji SQL Cloud jako 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.pemI uruchom następującą instrukcję:
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-0800278dc04dW tym momencie możesz zaplanować kolejny krok, aby przekierować obciążenie bazy danych z aplikacji na ten serwer podrzędny jako nowy master i zlikwidować stary master w Google Cloud.
Ostateczne myśli
Możesz przeprowadzić migrację online z Google Cloud SQL for MySQL na serwer lokalny bez większych problemów. Daje to możliwość przeniesienia bazy danych poza dostawców chmury w celu zachowania prywatności i kontroli, gdy nadejdzie odpowiedni czas.
