Google Cloud SQL para MySQL es un servicio de base de datos completamente administrado que lo ayuda a configurar, mantener, gestionar y administrar sus bases de datos relacionales MySQL en Google Cloud Platform. Sin embargo, existen diferencias entre Cloud SQL y la funcionalidad estándar de MySQL, como control limitado, recursos restringidos, localidad de datos, presupuesto y seguridad, que pueden influir en su decisión final de dejar las instancias de Google Cloud SQL y alojar el servicio de base de datos en el sitio web. infraestructura de las instalaciones en su lugar.
Esta publicación de blog lo guiará a través de cómo realizar una migración en línea de Google Cloud SQL a un servidor local. Nuestra base de datos de destino en el servidor local es un servidor Debian, pero los pasos y procedimientos se aplicarán en otras versiones de Linux siempre y cuando los paquetes estén correctamente instalados.
Nuestra instancia de Google Cloud MySQL se ejecuta en MySQL 5.7 y lo que necesitamos es:
- Un usuario esclavo de replicación creado en el maestro.
- El esclavo debe instalarse con la misma versión principal que el maestro.
- Se debe habilitar SSL para la replicación geográfica por motivos de seguridad.
Dado que Google Cloud habilita de manera predeterminada la replicación de GTID para MySQL, vamos a realizar una migración basada en este esquema de replicación. Por lo tanto, las instrucciones descritas en esta publicación también deberían funcionar en instancias de MySQL 8.0.
Creación de un usuario esclavo de replicación
En primer lugar, debemos crear un usuario esclavo de replicación en nuestra instancia de Google Cloud SQL. Inicie sesión en Google Cloud Platform -> Bases de datos -> SQL -> elija la instancia de MySQL -> Usuarios -> Agregar cuenta de usuario e ingrese los detalles requeridos:
La 202.187.194.255 es la dirección IP pública esclava ubicada en nuestro sitio web. premisas que se van a replicar a partir de esta instancia. Como puede ver, no hay configuración de privilegios ya que los usuarios creados desde esta interfaz tendrán los privilegios más altos que Google Cloud SQL puede ofrecer (casi todo excepto SUPER y FILE). Para verificar los privilegios, podemos usar el siguiente comando:
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 OPTIONParece que nuestro usuario esclavo tiene el permiso necesario para ejecutarse como esclavo (ESCLAVO DE REPLICACIÓN).
Realización de una copia de seguridad de mysqldump
Antes de crear una copia de seguridad externa de mysqldump, debemos configurar los certificados SSL del cliente debido al riesgo de conectar la instancia a través de una red pública. Para hacer esto, vaya a Conexiones -> Configurar certificados de cliente SSL -> Crear un certificado de cliente:
Descargue los archivos anteriores (server-ca.pem, client-cert. pem y client-key.pem) y almacenarlos dentro del servidor esclavo. Vamos a usar estos certificados para conectarnos al maestro de forma segura desde el servidor esclavo. Para simplificar el proceso, todos los certificados anteriores y el archivo de clave se colocarán en un directorio llamado "gcloud-certs":
$ mkdir -p /root/gcloud-certs # put the certs/key hereAsegúrese de que los permisos sean correctos, especialmente el archivo de clave privada, client-key.pem:
$ chmod 600 /root/gcloud-certs/client-key.pemAhora estamos listos para realizar una copia de seguridad de mysqldump desde nuestra instancia de Google Cloud SQL MySQL 5.7 de forma segura:
$ 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.sqlDebería recibir la siguiente advertencia:
"Advertencia:un volcado parcial de un servidor que tiene GTID incluirá de manera predeterminada los GTID de todas las transacciones, incluso aquellas que cambiaron partes suprimidas de la base de datos. Si no desea restaurar GTID, pase --set-gtid-purged=OFF. Para hacer un volcado completo, pase --all-databases --triggers --routines --events."
La advertencia anterior ocurre porque omitimos definir el indicador --events que requiere el privilegio SUPER. El usuario raíz creado para cada instancia de Google Cloud SQL no viene con privilegios de ARCHIVO y SUPER. Este es uno de los inconvenientes de usar este método, que los eventos de MySQL no se pueden importar desde Google Cloud SQL.
Configuración del servidor esclavo
En el servidor esclavo, instale MySQL 5.7 para 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-serverLuego, agregue las siguientes líneas debajo de la sección [mysqld] dentro de /etc/mysql/my.cnf (o cualquier otro archivo de configuración de MySQL relevante):
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 slaveReinicie el servidor MySQL para aplicar los cambios anteriores:
$ systemctl restart mysqlRestaurar la copia de seguridad de mysqldump en este servidor:
$ mysql -uroot -p < fullbackup.sqlEn este punto, la contraseña raíz de MySQL del servidor esclavo debe ser idéntica a la de Google Cloud SQL. Debe iniciar sesión con una contraseña raíz diferente a partir de ahora.
Tenga en cuenta que el usuario raíz en Google Cloud no tiene todos los privilegios. Necesitamos hacer algunas modificaciones en el lado esclavo, permitiendo que el usuario root tenga todos los privilegios dentro de MySQL, ya que tenemos más control sobre este servidor. Para hacer esto, necesitamos actualizar la tabla de usuarios de MySQL. Inicie sesión en el servidor MySQL del esclavo como usuario raíz de MySQL y ejecute la siguiente instrucción:
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: 0Vaciar la tabla de privilegios:
mysql> FLUSH PRIVILEGES;
Query OK, 0 rows affected (0.00 sec)Salga de la terminal actual y vuelva a iniciar sesión. Ejecute el siguiente comando para verificar que el usuario raíz ahora tiene el nivel más alto de privilegios:
mysql> SHOW GRANTS FOR [email protected];
+---------------------------------------------------------------------+
| Grants for [email protected] |
+---------------------------------------------------------------------+
| GRANT ALL PRIVILEGES ON *.* TO 'root'@'localhost' WITH GRANT OPTION |
+---------------------------------------------------------------------+Configuración del enlace de replicación
Por razones de seguridad, el usuario esclavo de replicación debe conectarse al host maestro (instancia de Google Cloud) a través de un canal cifrado SSL. Por lo tanto, debemos preparar la clave SSL y el certificado con el permiso correcto y accesible para el usuario de mysql. Copie el directorio de gcloud en /etc/mysql y asigne el permiso y la propiedad correctos:
$ mkdir -p /etc/mysql
$ cp /root/gcloud-certs /etc/mysql
$ chown -Rf mysql:mysql /etc/mysql/gcloud-certsEn el servidor esclavo, configure el enlace de replicación como se muestra a continuación:
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';Luego, inicie el esclavo de replicación:
mysql> START SLAVE;Verifique la salida de la siguiente manera:
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:Asegúrese de que los valores Slave_IO_Running y Slave_SQL_Running sean 'Sí', y que Seconds_Behind_Master sea 0, lo que significa que el esclavo ha alcanzado al maestro. Observe que Executed_Gtid_Set tiene dos GTID:
- 8539637e-14d1-11eb-ae3c-42010a94001a:1-5664
- b1dabe58-14e6-11eb-840f-0800278dc04d:1-2
El primer GTID representa los cambios provenientes del maestro actual (instancia de Google Cloud SQL), mientras que el segundo GTID representa los cambios que hicimos cuando modificamos los privilegios para el usuario root de MySQL en el host esclavo. Preste atención al primer GTID para ver si la base de datos se replica correctamente (la parte entera debe incrementarse durante la replicación).
Verificar si nuestro host esclavo es parte de la replicación desde el punto de vista del maestro. Inicie sesión en la instancia de SQL Cloud como 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.pemY ejecute la siguiente instrucción:
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-0800278dc04dEn este punto, puede planificar su próximo movimiento para redirigir la carga de trabajo de la base de datos de las aplicaciones a este servidor esclavo como el nuevo maestro y retirar el antiguo maestro en Google Cloud.
Reflexiones finales
Puede realizar una migración en línea desde Google Cloud SQL para MySQL a un servidor local sin muchas complicaciones. Esto le brinda la posibilidad de mover su base de datos fuera de los proveedores de la nube para tener privacidad y control cuando llegue el momento adecuado.
