replicación - replicar base mysql

¿Cómo volver a sincronizar el Mysql DB si el maestro y el esclavo tienen una base de datos diferente en el caso de la replicación de Mysql? (12)

¡Creo que Maatkit utilits te ayuda! Puedes usar mk-table-sync. Por favor, consulte este enlace: http://www.maatkit.org/doc/mk-table-sync.html

Mysql Server1 se ejecuta como MASTER .
Mysql Server2 se ejecuta como ESCLAVO .

Ahora la replicación de DB está pasando de MASTER a SLAVE .

Server2 se elimina de la red y vuelve a conectarlo después de 1 día. Después de esto, hay una falta de coincidencia en la base de datos en maestro y esclavo.

¿Cómo volver a sincronizar el DB nuevamente como después de restaurar el DB tomado de Master a Slave tampoco resuelve el problema?

A menos que esté escribiendo directamente al esclavo (Servidor2), el único problema debería ser que al Servidor2 le falten actualizaciones que hayan ocurrido desde que se desconectó. Simplemente reiniciando el esclavo con "START SLAVE"; debe hacer que todo vuelva a la velocidad.

Agregando a la respuesta popular para incluir este error:

"ERROR 1200 (HY000): The server is not configured as slave; fix in config file or with CHANGE MASTER TO",

Replicación del esclavo en una sola toma:

En una ventana de terminal:

mysql -h <Master_IP_Address> -uroot -p

Después de conectar,

RESET MASTER; FLUSH TABLES WITH READ LOCK; SHOW MASTER STATUS;

El estado aparece de la siguiente manera: ¡tenga en cuenta que el número de posición varía!

¡Exporte el volcado de forma similar a como describió " usando otro terminal "!

Salga y conéctese a su DB (que es el esclavo):

mysql -u root -p

El tipo de comandos a continuación:

STOP SLAVE;

Importar el volcado como se menciona (en otro terminal, por supuesto!) Y escriba los siguientes comandos:

RESET SLAVE; CHANGE MASTER TO MASTER_HOST = ''Master_IP_Address'', MASTER_USER = ''your_Master_user'', // usually the "root" user MASTER_PASSWORD = ''Your_MasterDB_Password'', MASTER_PORT = 3306, MASTER_LOG_FILE = ''mysql-bin.000001'', MASTER_LOG_POS = 98; // In this case

Una vez registrado, configure el parámetro server_id (normalmente, para DB nuevos / no replicados, esto no está configurado por defecto),

set global server_id=4000;

Ahora, comienza el esclavo.

START SLAVE; SHOW SLAVE STATUS/G;

La salida debe ser la misma que él describió.

Slave_IO_Running: Yes Slave_SQL_Running: Yes

Nota: ¡Una vez replicado, el maestro y el esclavo comparten la misma contraseña!

Aquí hay una respuesta completa que con suerte ayudará a otros ...

Quiero configurar la replicación de MySQL usando maestro y esclavo, y como lo único que sé es que usa archivos de registro para sincronizar, si el esclavo se desconecta y no se sincroniza, en teoría solo debería conectarse de nuevo. a su maestro y sigue leyendo el archivo de registro desde donde lo dejó, como mencionó el usuario Malonso.

Así que aquí está el resultado de la prueba después de configurar el maestro y el esclavo como se menciona en: http://dev.mysql.com/doc/refman/5.0/en/replication-howto.html ...

Siempre que utilice la configuración de maestro / esclavo recomendada y no escriba en el esclavo, él y yo correctos (en lo que concierne a mysql-server 5.x). Ni siquiera necesité usar "START SLAVE;", simplemente alcanzó a su maestro. Pero hay un 88000 por defecto que reintenta cada 60 segundos, así que supongo que si agotas eso, quizás tengas que iniciar o reiniciar el esclavo. De todos modos, para aquellos como yo que querían saber si tener un esclavo fuera de línea y hacer una copia de seguridad de nuevo requiere intervención manual ... no, no es así.

Tal vez el cartel original tenía corrupción en el archivo de registro (s)? Pero lo más probable es que no solo un servidor se desconecte por un día.

extraído de /usr/share/doc/mysql-server-5.1/README.Debian.gz que también tiene sentido para los servidores que no son Debian:

* FURTHER NOTES ON REPLICATION =============================== If the MySQL server is acting as a replication slave, you should not set --tmpdir to point to a directory on a memory-based filesystem or to a directory that is cleared when the server host restarts. A replication slave needs some of its temporary files to survive a machine restart so that it can replicate temporary tables or LOAD DATA INFILE operations. If files in the temporary file directory are lost when the server restarts, replication fails.

puede usar algo parecido a sql: mostrar variables como ''tmpdir''; descubrir.

Creé un repositorio GitHub con un script para resolver este problema rápidamente. Simplemente cambie un par de variables y ejecútelo (Primero, el script crea una copia de seguridad de su base de datos).

Espero que esto te ayude a ti (y a otras personas también).

Cómo restablecer (volver a sincronizar) la replicación maestro-esclavo de MySQL

Este es el procedimiento completo paso a paso para resincronizar una replicación maestro-esclavo desde cero:

En el maestro

RESET MASTER; FLUSH TABLES WITH READ LOCK; SHOW MASTER STATUS;

Y copie los valores del resultado del último comando en alguna parte.

Sin cerrar la conexión al cliente (porque liberaría el bloqueo de lectura) emita el comando para obtener un volcado del maestro:

mysqldump -u root -p --all-databases > /a/path/mysqldump.sql

Ahora puede liberar el bloqueo, incluso si el volcado aún no ha finalizado. Para hacerlo, realice el siguiente comando en el cliente MySQL:

UNLOCK TABLES;

Ahora copie el archivo de volcado al esclavo usando scp o su herramienta preferida.

En el esclavo:

Abra una conexión a mysql y escriba:

STOP SLAVE;

Cargue el volcado de datos del maestro con este comando de consola:

mysql -uroot -p < mysqldump.sql

Sincronizar esclavos y registros maestros:

RESET SLAVE; CHANGE MASTER TO MASTER_LOG_FILE=''mysql-bin.000001'', MASTER_LOG_POS=98;

Donde los valores de los campos anteriores son los que ha copiado anteriormente.

Finalmente, escribe:

START SLAVE;

Para verificar que todo esté funcionando nuevamente, después de tipear:

SHOW SLAVE STATUS;

debería ver:

Slave_IO_Running: Yes Slave_SQL_Running: Yes

¡Eso es!

Esto es lo que hago normalmente cuando un esclavo mysql se desincroniza. Miré mk-table-sync, pero pensé que la sección de riesgos daba miedo.

En el Master:

SHOW MASTER STATUS

Las columnas enviadas (Archivo, Posición) nos serán útiles en un momento.

En esclavo:

STOP SLAVE

A continuación, vuelque el archivo maestro db e impórtelo al esclavo db.

Luego ejecuta lo siguiente:

CHANGE MASTER TO MASTER_LOG_FILE=''[File]'', MASTER_LOG_POS=[Position]; START SLAVE;

Donde [Archivo] y [Posición] son los valores emitidos desde "MOSTRAR ESTADO MAESTRO", ejecute arriba.

¡Espero que esto ayude!

La documentación para esto en el sitio de MySQL está lamentablemente desactualizada y plagada de pistolas (como interactive_timeout). La emisión de TABLAS DE FLUJO CON READ LOCK como parte de la exportación del maestro generalmente solo tiene sentido cuando se coordina con una instantánea de almacenamiento / sistema de archivos como LVM o zfs.

Si va a usar mysqldump, debe confiar en la opción --master-data para evitar errores humanos y liberar los bloqueos en el maestro lo más rápido posible.

Supongamos que el maestro es 192.168.100.50 y el esclavo es 192.168.100.51, cada servidor tiene una identificación de servidor distinta configurada, el maestro tiene inicio de sesión binario y el esclavo tiene solo lectura = 1 en mi.cnf

Para configurar el esclavo para que pueda iniciar la replicación justo después de importar el volcado, emita un comando CAMBIAR MAESTRO pero omita el nombre y la posición del archivo de registro:

slaveserver> CHANGE MASTER TO MASTER_HOST=''192.168.100.50'', MASTER_USER=''replica'', MASTER_PASSWORD=''asdmk3qwdq1'';

Emita el GRANT en el maestro para que el esclavo use:

masterserver> GRANT REPLICATION SLAVE ON *.* TO ''replica''@''192.168.100.51'' IDENTIFIED BY ''asdmk3qwdq1'';

Exporte el maestro (en pantalla) usando compresión y capturando automáticamente las coordenadas de registro binario correctas:

mysqldump --master-data --all-databases --flush-privileges | gzip -1 > replication.sql.gz

Copie el archivo replication.sql.gz al esclavo y luego impórtelo con zcat a la instancia de MySQL ejecutándose en el esclavo:

zcat replication.sql.gz | mysql

Comience la replicación emitiendo el comando al esclavo:

slaveserver> START SLAVE;

Opcionalmente actualice el /root/.my.cnf en el esclavo para almacenar la misma contraseña raíz que el maestro.

Si está en 5.1+, lo mejor es configurar primero binlog_format del maestro en MIXED o ROW. Tenga en cuenta que los eventos registrados en la fila son lentos para las tablas que carecen de una clave principal. Esto generalmente es mejor que la configuración alternativa (y predeterminada) de binlog_format = statement (en el maestro), ya que es menos probable que produzca datos incorrectos en el esclavo.

Si debe (aunque probablemente no debería) filtrar la replicación, hágalo con las opciones de esclavo replicate-wild-do-table = nombrebd.% O replicate-wild-ignore-table = badDB.% Y use binlog_format = fila únicamente

Este proceso mantendrá un bloqueo global en el maestro mientras dure el comando mysqldump, pero de lo contrario no afectará al maestro.

Si tiene la tentación de usar mysqldump --master-data --all-databases --single-transaction (porque solo está usando tablas InnoDB), quizás esté mejor servido usando MySQL Enterprise Backup o la implementación de código abierto llamada xtrabackup (cortesía de Percona)

Llego muy tarde a esta pregunta, sin embargo, encontré este problema y, después de mucho buscar, encontré esta información de Bryan Kennedy: plusbryan.com/mysql-replication-without-downtime

En Master toma una copia de seguridad como esta:
mysqldump --skip-lock-tables --single-transaction --flush-logs --hex-blob --master-data = 2 -A> ~ / dump.sql

Ahora, examine el encabezado del archivo y anote los valores para MASTER_LOG_FILE y MASTER_LOG_POS. Los necesitarás más tarde: head dump.sql -n80 | grep "MASTER_LOG"

Copie el archivo "dump.sql" en Slave y restaure: mysql -u mysql-user -p <~ / dump.sql

Conéctese a Slave mysql y ejecute un comando como este: CHANGE MASTER TO MASTER_HOST = ''master-server-ip'', MASTER_USER = ''replication-user'', MASTER_PASSWORD = ''slave-server-password'', MASTER_LOG_FILE = ''valor desde arriba'', MASTER_LOG_POS = valor desde arriba; INICIAR ESCLAVO;

Para verificar el progreso de Slave: SHOW SLAVE STATUS;

Si todo está bien, Last_Error estará en blanco, y Slave_IO_State informará "Esperando que el maestro envíe el evento". Busque Seconds_Behind_Master que indica qué tan atrás está. YMMV. :)

Siguiendo con la respuesta de David ...

Usar SHOW SLAVE STATUS/G dará salida legible para humanos.

a veces solo necesitas darle una patada al esclavo

tratar

detener esclavo;
restablecer el esclavo;
iniciar esclavo;
mostrar el estado del esclavo;

muy a menudo, esclavos, simplemente se quedan atrapados, muchachos :)

Reconstrucción del esclavo usando LVM

Aquí está el método que usamos para reconstruir esclavos MySQL usando Linux LVM. Esto garantiza una instantánea consistente al tiempo que requiere un tiempo de inactividad muy mínimo en su maestro.

Establezca innodb max páginas sucias por ciento en cero en el servidor maestro MySQL. Esto obligará a MySQL a escribir todas las páginas en el disco, lo que acelerará significativamente el reinicio.

set global innodb_max_dirty_pages_pct = 0;

Para controlar el número de páginas sucias, ejecute el comando

mysqladmin ext -i10 | grep dirty

Una vez que el número se detiene, ha llegado al punto de continuar. A continuación, reinicie el maestro para borrar los registros de registros / registros de retransmisión anteriores:

RESET MASTER;

Ejecute lvdisplay para obtener LV Path

lvdisplay

La salida se verá así

--- Logical volume --- LV Path /dev/vg_mysql/lv_data LV Name lv_data VG Name vg_mysql

Apagar la base de datos maestra con el comando

service mysql stop

Luego tome una instantánea, mysql_snapshot será el nuevo nombre de volumen lógico. Si los binlogs están ubicados en la unidad del sistema operativo, también deben ser instantáneas.

lvcreate --size 10G --snapshot --name mysql_snapshot /dev/vg_mysql/lv_data

Comience de nuevo con el comando master

service mysql start

Restaure la configuración de páginas sucias por defecto

set global innodb_max_dirty_pages_pct = 75;

Ejecute lvdisplay nuevamente para asegurarse de que la instantánea esté allí y sea visible

lvdisplay

Salida:

--- Logical volume --- LV Path /dev/vg_mysql/mysql_snapshot LV Name mysql_snapshot VG Name vg_mysql

Montar la instantánea

mkdir /mnt/mysql_snapshot mount /dev/vg_mysql/mysql_snapshot /mnt/mysql_snapshot

Si tiene un esclavo MySQL existente ejecutándose, necesita detenerlo

service mysql stop

A continuación, debe borrar la carpeta de datos MySQL

cd /var/lib/mysql rm -fr *

De vuelta al maestro Ahora rsync la instantánea al esclavo MySQL

rsync --progress -harz /mnt/mysql_snapshot/ targethostname:/var/lib/mysql/

Una vez que rsync se haya completado, puedes desmontar y eliminar la instantánea

umount /mnt/mysql_snapshot lvremove -f /dev/vg_mysql/mysql_snapshot

Crear usuario de replicación en el maestro si el usuario de replicación anterior no existe o la contraseña es desconocida

GRANT REPLICATION SLAVE on *.* to ''replication''@''[SLAVE IP]'' identified by ''YourPass'';

Verifique que los archivos de datos / var / lib / mysql sean propiedad del usuario mysql, de ser así, puede omitir el siguiente comando:

chown -R mysql:mysql /var/lib/mysql

A continuación, registre la posición de binlog

ls -laF | grep mysql-bin

Verás algo así como

.. -rw-rw---- 1 mysql mysql 1073750329 Aug 28 03:33 mysql-bin.000017 -rw-rw---- 1 mysql mysql 1073741932 Aug 28 08:32 mysql-bin.000018 -rw-rw---- 1 mysql mysql 963333441 Aug 28 15:37 mysql-bin.000019 -rw-rw---- 1 mysql mysql 65657162 Aug 28 16:44 mysql-bin.000020

Aquí el archivo de registro maestro es el número de archivo más alto en secuencia y la posición de registro de depósito es el tamaño del archivo. Registre estos valores:

master_log_file=mysql-bin.000020 master_log_post=65657162

A continuación, inicie el esclavo MySQL

service mysql start

Ejecute el comando maestro de cambio en el esclavo ejecutando lo siguiente:

CHANGE MASTER TO master_host="10.0.0.12", master_user="replication", master_password="YourPass", master_log_file="mysql-bin.000020", master_log_pos=65657162;

Finalmente, comienza el esclavo

SLAVE START;

Verifica el estado del esclavo:

SHOW SLAVE STATUS/G

Asegúrese de que Slave IO se esté ejecutando y no haya errores de conexión. ¡Buena suerte!

BR, Juha Vehnia

Hace poco escribí esto en mi blog que se encuentra aquí ... Hay algunos detalles más pero la historia es la misma.

http://www.juhavehnia.com/2015/05/rebuilding-mysql-slave-using-linux-lvm.html