Me estoy preparando para configurar una relación maestro-esclavo o maestro-maestro de MySQL. En este momento tengo un único servidor de producción MySQL y, por supuesto, no quiero mucho tiempo de inactividad mientras conecto el esclavo.
¿No hay manera de que pueda conectar un esclavo vacío y dejar que sincronice "lentamente" los datos del maestro, hasta que sean idénticos?
He notado que puedo tomar un volcado transaccional con mysqldump en el maestro y luego importarlo al esclavo, pero para cuando el esclavo haya importado el volcado, se habrán escrito muchas filas nuevas y ¿cómo las obtendrá el esclavo? ?
Espero estar perdiendo algo obvio aquí, pero una búsqueda exhaustiva en Google ofrece consejos como "dado que esto resultará en menos tiempo de inactividad en el futuro, algo de tiempo de inactividad ahora tal vez no sea tan malo". Pero realmente me gustaría evitar eso.
Relacionadopregunta para MyISAM, pero yo uso InnoDB.
Respuesta1
Si estás utilizando 100% InnoDB entonces estás de suerte. Puedes usarXtraCopia de seguridadpara realizar una copia de seguridad completa de su base de datos maestra sin ningún tiempo de inactividad ni bloqueo de tabla. Esta será una copia de seguridad consistente de estilo instantánea, igual que la que obtienes cuando utilizas las opciones FLUSH TABLES WITH READ LOCKo --master-data.
La herramienta XtraBackup también coloca un archivo adicional en el directorio de respaldo que contiene la información MASTER_LOG_POS y MASTER_LOG_FILE que necesita para iniciar la replicación en el esclavo.
Una vez que haya terminado de realizar la copia de seguridad, deberá ejecutar --preparela opción de XtraBackup en la copia de seguridad, cargarla en el esclavo, iniciar el proceso de copia de seguridad de MySQL esclavo e indicarle los nuevos valores MASTER_LOG_POS y MASTER_LOG_FILE que necesita.
Querrá skip-slave-startsu my.cnf antes de iniciar el esclavo.
También tenga en cuenta que el mysqlesquema es MyISAM de forma predeterminada (y si la memoria funciona correctamente solo puede ser MyISAM), por lo que deberá tener cuidado de no realizar ningún cambio en ninguna de esas tablas mientras ejecuta la copia de seguridad. Siempre que cumpla con esa regla, la información maestra seguirá siendo correcta.
A menudo es una buena ideaignora el mysqlesquema en tu my.cnfen el esclavo y solo cree usuarios con privilegios SELECT. Los esclavos inconsistentes y no sincronizados son difíciles de detectar y difíciles de manejar, incluso cuando se utilizan las herramientas que Percona (y Maatkit antes que ellos) proporcionan para esto.
Editar:
Aunque dijiste que estás usando InnoDB, para completar hay otra manera si estás usando tablas MyISAM. Si tiene un administrador de volúmenes con captura de instantáneas (comoZFSoLVM), puede ejecutar FLUSH TABLES WITH READ LOCKseguido de a SHOW MASTER STATUS, crear una instantánea y ejecutar UNLOCK TABLES. El tiempo de inactividad debería ser bastante mínimo. A modo de comparación, el trabajo cron de anoche que hizo esto para respaldar una de nuestras bases de datos tomó 6 segundos para crear la instantánea, que es el bit donde la base de datos está "inactiva" y 27 minutos para copiar los archivos de la instantánea al servidor de respaldo.
Respuesta2
No es posible iniciar una replicación de MySQL "desde cero".
En su lugar, podrías usar mysqldump con el --master-data=2parámetro al descargar tus bases de datos, es decir, así:
mysqldump --master-data=2 --all-databases --opt -p > myinitialdump.sql
Este comando bloqueará todas las tablas dentro de las bases de datos afectadas durante el volcado y escribirá las coordenadas de replicación en el encabezado del volcado de forma comentada como esta:
-- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000018', MASTER_LOG_POS=106;
Una vez completada la importación, puede ejecutar manualmente el comando "cambiar maestro a" con el nombre de host de su maestro y los datos de autenticación; la replicación se iniciará en el punto del volcado.
Tenga en cuenta que el proceso mysqldump incurrirá en "tiempo de inactividad" debido a la contención de bloqueo: coloca bloqueos de lectura en todas las tablas (similar a lo que haría un comando FLUSH TABLES CON READ LOCK) durante todo el volcado. Por lo tanto, no se devolverá ninguna solicitud que escriba en ninguna de las tablas a menos que se complete el volcado. Además, las solicitudes de escritura probablemente también bloquearían cualquier solicitud de lectura posterior a menos que haya especificadoactualizaciones_de_baja_prioridaden su configuración de MySQL o haya emitido SET GLOBAL LOW_PRIORITY_UPDATES=1 antes del volcado.