De la wiki de Linux

Configuración de la replicación

servidor maestro

mi.cnf en el servidor maestro:

[mysqld]# Identificación del servidor. Debe ser único en cada enlace de servidores (tanto maestros como esclavos). # Es un número en el rango de 1 a 4294967295 (2 ^32 -1 ) server-id = 1 # Ruta a los registros binarios donde se guardan todos los cambios en la base de datos del servidor maestro. Debe haber suficiente espacio para estos registros log-bin = /var/lib/mysql/mysql-bin # Cuántos días se deben mantener los registros binarios en el maestro. De alguna manera, esto también determina cuánto puede retrasarse el esclavo con respecto al maestro # expire_logs_days = 10 # Tamaño del archivo binlog (cada archivo individual) # max_binlog_size = 1024M # Habilitar la compresión de registros enviados al esclavo slave_compressed_protocol = 1 # Nombre de la base de datos para la que hacer la replicación. Si necesita replicar varias bases de datos, repita la opción con el nombre de la base de datos deseada replicate-do-db = testdb # Además de esta opción, hay más opciones "elección inversa"- para excluir la selección de bases de datos # replicate-ignore-db= nombre_de_base_de_datos # así como opciones para replicar tablas individuales (de manera similar - seleccione una / varias ; excluir uno/varios, así como la definición de nombres a través de comodines)# Esta opción es necesaria en caso de que este servidor maestro sea un esclavo de otro, de modo que el esclavo de este maestro (subesclavo del maestro principal) también reciba actualizaciones # Puede ser útil cuando se replica un maestro-maestro con un esclavo # registro -esclavo -actualizaciones

Otorgamos los derechos al servidor esclavo para replicar desde esto. Para ello, en la consola de mysql le damos al comando:

mysql> GRANT replication slave ON * .* TO "repluser" @"replhost" IDENTIFICADO POR "replpass" ;

repulsor- nombre de usuario para conectarse. El usuario se crea en el momento en que se ejecuta el comando.
replhost- Dirección IP o dominio de host del servidor esclavo que se conectará a este maestro e importará los cambios desde él.
replpass- contraseña de conexión

La restricción en la base para la replicación en la replicación de concesión no parece funcionar, es decir, permitimos todo, y en la configuración especificamos solo la base/bases que se necesitan

Reiniciamos el servidor, después de lo cual puede ejecutar el comando en la consola

mysql> MOSTRAR ESTADO DEL MAESTRO;

que mostrará el archivo de registro binario con el que está trabajando actualmente el maestro y la posición actual en el registro, así como las bases que se están replicando.

servidor esclavo

Agregue las opciones necesarias en la configuración. mi.cnf en el servidor esclavo:

[mysqld]# ID de servidor para este paquete de servidor: consulte la descripción anterior server-id = 2 # Registros de retransmisión: registros descargados del servidor maestro # Especifique la ruta para estos registros ; debe haber suficiente espacio para almacenarlos.#relevo-registro= /var/lib/mysql/mysql-relay-bin#relay-log-index= /var/lib/mysql/mysql-relay-bin.index# Nombre de la base de datos a replicar replicate-do-db = testdb # Habilitar la compresión de los registros enviados al Slave slave_compressed_protocol = 1

Reinicie el servidor para aplicar los cambios.

Iniciar replicación

En el maestro, bloqueamos las tablas de escritura para obtener un volcado completamente correcto:

mysql> TABLAS FLUSH CON BLOQUEO DE LECTURA; mysql> SET GLOBAL read_only = ON;

Fusionamos un volcado del servidor. En algunos lugares, generalmente escriben sobre el hecho de que es necesario mirar la posición y el nombre del registro en el maestro; esto no es necesario y se resuelve con la clave --datos maestros para mysqldump, que escribirá la información necesaria en el propio volcado:

mysqldump --master-data -hmasterhost -umasteruser -pmasterpass nombrebdb maestro > dump.sql

Después de eso, iniciamos el asistente para que funcione:

mysql> SET GLOBAL read_only = OFF;

(aunque surge la idea: ¿es realmente necesario bloquear la base de datos al realizar el volcado? Tan pronto como se comenzó a realizar el volcado con --master-data, el nombre del registro y la posición se incluyen en él, y las tablas se bloquean automáticamente para escritura, es decir, todo es igual, solo en modo automático)

mysql -hslavehost -uslaveuser -pslavepass nombrebb esclavo< dump.sql

EN este caso slavedbname = masterdbname, aunque si lo desea, puede hacer que la base de datos se replique con un nombre diferente.

Especifique la dirección del servidor maestro al esclavo:

mysql> CAMBIAR MAESTRO A MASTER_HOST = "masterip", MASTER_USER = "repluser", MASTER_PASSWORD = "replpass";

Dónde masterip- La dirección IP o dominio del servidor maestro, y el resto de opciones son las que se especificaron anteriormente al configurar el maestro. El nombre del archivo de registro y la posición se toman del volcado, pero si se desea, se pueden especificar manualmente a través de las opciones MASTER_LOG_FILE = "log_name", MASTER_LOG_POS = posición

Después de este comando, la información sobre el maestro se guarda en un archivo maestro.info en el directorio de la base de datos datos mysql-servidor. Si lo desea, puede especificar estas opciones en la configuración del servidor esclavo:

master-host=master-ip master-user=repluser master-password=replpass master-port=3306

Después de eso, iniciamos el servidor esclavo a través de la consola mysql:

mysql> INICIO ESCLAVO;

Ahora puede verificar el estado del servidor esclavo con el comando

mysql> MOSTRAR ESTADO DE ESCLAVO;

De información interesante puede haber campos:

Slave_IO_State: Esperando a que el maestro envíe el evento, Slave_IO_Running: Sí Y Slave_SQL_Running: Sí- todo funciona bien :)
Seconds_Behind_Master- qué tan lejos está el esclavo detrás del maestro. En modo normal, debería ser 0, pero en retraso real, también puede ser 0 si se realizan muchos cambios en el maestro y el canal entre el maestro y el esclavo es estrecho y este último no tiene tiempo para descargar binlogs del maestro. En este caso, "0" es correcto, pero solo para lo que se ha logrado descargar de los registros.

Y otra información actual como ausencia de errores, posición actual y nombre del registro del servidor, registro esclavo, etc.

Misceláneas

Hay 2 opciones para que mysqldump escriba el nombre y la posición del registro en el archivo de volcado: --datos maestros Y --dump-esclavo. El segundo no está en todas partes:

[correo electrónico protegido]:~# mysqldump --ayuda | grep "volcado-esclavo" [correo electrónico protegido]:~# mysqldump --version mysqldump Ver 10.13 Distrib 5.1.61, para portbld-freebsd8.2 (amd64)

Dump-slave[=value] Esta opción es similar a --master-data excepto que se usa para volcar un servidor esclavo de replicación para producir un archivo de volcado que se puede usar para configurar otro servidor como esclavo que tiene el mismo maestro como el servidor volcado. Hace que la salida del volcado incluya una instrucción CHANGE MASTER TO que indica las coordenadas del registro binario (nombre de archivo y posición) del maestro del esclavo volcado (en lugar de las coordenadas del servidor volcado, como lo hace --master- opción de datos). Estas son las coordenadas del servidor maestro desde las cuales el esclavo debe comenzar a replicar. Esta opción se agregó en MySQL 5.5.3.

En consecuencia, una opción es clonar un esclavo, la segunda es crear un subesclavo. En otras palabras, dump-slave le permite crear (utilizando slave1) otro slave1 en la cadena master-slave1-slave2 (la posición en el registro y el archivo de registro relativo a los registros maestros se escribirán en el volcado), master- Los datos le permiten crear Slave2: la posición/registro relativo a los binlogs de Slave1.

Errores de replicación

Cuando se ejecuta la replicación, pueden ocurrir errores, por cualquier motivo, por ejemplo, al ingresar datos manualmente en un servidor esclavo.

Opciones de solución.

Configuración de la replicación de MySQL sin detener el asistente.

1. Configuración del servidor maestro:

Miramos dónde debería estar la configuración.

# ps auxiliar | grep mi.cnf

mysql 51189 0.0 0.0 17064 1912 - Son las 6:35 p. m. 0:00.05 /bin/sh /usr/local/bin/mysqld_safe --defaults-extra-file= /var/db/mysql/my.cnf--usuario=mysql --datadir=/var/db/mysql

Si falta el archivo, puede copiarlo del ejemplo.

# cp /usr/local/share/mysql/my-small.cnf /var/db/mysql/my.cnf

O crea uno vacío.

# toque /var/db/mysql/my.cnf

A la configuración creada en la sección nosotros escribimos.

#ID de servidor único. El maestro debe estar debajo de la réplica y no duplicado

servidor - id = 1

#formato de registro

binlog - formato = mixto

#Ruta donde se ubicará el binlog (Por defecto, el tamaño de un registro es 1g)

#Tiempo de almacenamiento de binlog

expire_logs_days = 30

replicar-do-db=database_1

replicar-do-db=database_2

replicar-do-db=database_3

replicar-do-db=database_4

#Registro de errores

En esto redondeamos con la edición y reiniciamos MySQL con una nueva configuración.

# /usr/local/etc/rc.d/mysql-server reiniciar

Ahora necesita agregar un usuario al maestro para el servidor esclavo.

Para la replicación bastarán los derechos de REPLICATION SLAVE. Inicie sesión como root en el servidor MySQL.

# mysql -uroot -p

Crear un usuario:

mysql> usa mysql;

mysql>CREATE USER 'replica'@'ip_address_slave_server';

mysql>CONCEDER ESCLAVO DE REPLICACIÓN EN*.* TO 'réplica'@'ip_address_slave_server' IDENTIFICADO POR 'contraseña_para_réplica_de_usuario';

Ahora puede reiniciar el servidor o decir

mysql>PRIVILEGIOS DE DESCARGA;

2. Cree un volcado de las bases de datos requeridas:

Todas las bases.

# mysqldump -uroot -p --skip-lock-tables --single-transaction --flush-logs --hex-blob --master-data=2 -A > /usr/home/Timur/dump.sql

ciertas bases.

# mysqldump -uroot -p --skip-lock-tables --single-transaction --flush-logs --hex-blob --master-data=2 -B BASE DE DATOS BASE DE DATOS1 BASE DE DATOS2 BASE DE DATOS3 > /usr/home/Timur/dump .sql

3. Nos fijamos en qué binlog usar y su posición:

# head -n80 /usr/home/Timuro/dump.sql | grep "MASTER_LOG_POS"

- CAMBIAR MAESTRO A MASTER_LOG_FILE=' mysql-bin.000049‘,MASTER_LOG_POS= 107 ;

¡¡¡Por favor escribelo!!!

4. Haga clic en el volcado y transfiéralo al servidor Esclavo:

# gzip /usr/home/Timuro/dump.sql

Transferimos

# scp /usr/home/Timur/dump.sql.gz _address_slave_server:/usr/home/Timur

5. Configuración del servidor Esclavo (my.cnf).

id-servidor=2

binlog - formato = mixto

log-bin=/var/log/mysql/mysql-bin

expire_logs_days = 30

#Binglog Esclavo

relé-registro = /var/log/mysql/mysql-relay.log
relé-registro-índice = /var/log/mysql/mysql-relay-bin.index

#Indica al servidor descendente que registre las actualizaciones que se producen en el servidor descendente en un registro binario. Esta opción está deshabilitada por defecto. Debe estar habilitado si desea conectar en cadena los servidores esclavos.

registro-esclavo-actualizaciones=1

#Establecer bases de datos en solo lectura. ¡¡¡Esta opción no aplica para superusuarios!!!

solo lectura = 1

#Omitir entradas duplicadas. Después de que Seconds_Behind_Master se convierta en 0, comente y reinicie SLAVE

esclavo-saltar-errores=todos

# Especificar qué bases de datos necesitamos replicar

replicar-do-db=database_1

replicar-do-db=database_2

replicar-do-db=database_3

replicar-do-db=database_4

#Registro de errores

log-error=/var/log/mysql/mysqld-error.log

#Para que el Slave no arranque cuando arranque el servidor. Puede iniciarlo manualmente START SLAVE;

skip-slave-start = Activado

Reinicie el servidor (MySQL).

6. Cargue el volcado en Slave e inicie la replicación:

Vamos a descomprimir.

# gunzip /usr/local/Timuro/dump.sql.gz

Cargando el basurero.

# mysql -uroot -p< /usr/local/Timur/dump.sql

Le decimos a Slave de dónde extraer los datos y comenzar. MASTER_LOG_FILE y MASTER_LOG_POS toman lo que escribimos al volcar bases en Master 😉

mysql>CAMBIAR MAESTRO A MASTER_HOST= ‘<>' , MASTER_USER = 'réplica' , MASTER_PASSWORD = 'contraseña_para_réplica_de_usuario', MASTER_LOG_FILE= ‘mysql-bin.000049‘ , MAESTRO_LOG_POS = 107 ; ESCLAVO DE INICIO;

Vemos como un equipo MOSTRAR ESTADO DE ESCLAVO\G ¿Todos hemos empezado?

mysql> MOSTRAR ESTADO DE ESCLAVO\G
****************************** Primera fila ****************** ** *******
Slave_IO_State: esperando que el maestro envíe el evento
Master_Host: esta es la dirección del servidor maestro
Usuario_maestro: réplica
Puerto_maestro: 3306
Conectar_Reintentar: 60
Archivo_de_registro_maestro: mysql-bin.000049
Read_Master_Log_Pos: 1919771
Relé_registro_archivo: mysql-relé.000050
Relé_Log_Pos: 253
Relay_Master_Log_Archivo: mysql-bin.000049
Slave_IO_Running: Sí
Slave_SQL_Running: Sí
Replicar_Do_DB: base de datos_1, base de datos_2, base de datos_3, base de datos_4, base de datos_1, base de datos_2, base de datos_3, base de datos_4
Replicar_Ignorar_DB:
Replicar_hacer_tabla:
Replicar_Ignorar_Tabla:
Replicar_Wild_Do_Table:
Replicar_Wild_Ignorar_Tabla:
Last_Errno: 0
Último_error:
Saltar_Contador: 0
Exec_Master_Log_Pos: 1919771
Relé_registro_espacio: 3125
Hasta_Condición: Ninguno
Hasta_archivo_de_registro:
Hasta_Log_Pos: 0
Maestro_SSL_Permitido: No
Maestro_SSL_CA_Archivo:
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
Segundos_detrás_del_maestro: 0
Master_SSL_Verify_Server_Cert: No
Last_IO_Errno: 0
Último_IO_Error:
Last_SQL_Errno: 0
Último_SQL_Error:
Replicate_Ignore_Server_Ids:
Maestro_Servidor_Id: 5
1 fila en conjunto (0.00 seg)

Todo se puso en marcha.

Debería crecer Exec_Master_Log_Pos: 1919771

Si ocurre un error, puede omitirlo ejecutando:

mysql> DETENER ESCLAVO;ESTABLECER GLOBAL SQL_SLAVE_SKIP_COUNTER = 1;INICIAR ESCLAVO;

Esta es una breve descripción de cómo configurar la replicación completa en su servidor MySQL. Se supone que todas las bases de datos se replicarán y que la replicación no se ha configurado previamente. Para completar los pasos aquí, necesitará un tiempo corto detener el servidor maestro.

Esta es la forma más fácil de instalar un servidor esclavo, pero no es la única. Por ejemplo, si ya tiene una imagen del servidor principal, la ID del servidor ya está configurada en el servidor principal y se está realizando el registro, el servidor esclavo se puede instalar sin detener el servidor principal o incluso establecer bloqueos de actualización (para obtener más información). información, consulte Consulte la sección 4.10.7 Preguntas frecuentes sobre la replicación frecuente.

Para convertirse en un verdadero gurú de la replicación de MySQL, le recomendamos que primero aprenda, comprenda y pruebe todos los comandos mencionados en la sección 4.10.6 Comandos SQL relacionados con la replicación. Consulte la sección 4.10.5 Opciones de replicación en `my.cnf" .

Asegúrese de que los servidores maestro y esclavo tengan instalada la última versión de MySQL. Utilice la versión 3.23.29 o superior. Las versiones anteriores usaban un formato de registro binario diferente y contenían errores que se han solucionado en versiones más recientes. Gran solicitud: no envíe informes de errores sin verificar si este error está presente en la última versión.
Configure un solo usuario de replicación en el servidor maestro con privilegio de ARCHIVO (en versiones de MySQL anteriores a la 4.0.2) o privilegio de ESCLAVO DE REPLICACIÓN en versiones más recientes de MySQL. Este usuario también debe tener permiso para conectarse desde todos los servidores descendentes. Si el usuario solo realizará la replicación (recomendado), no es necesario que se le concedan privilegios adicionales. Por ejemplo, para crear un usuario llamado repl que pueda acceder al servidor principal desde cualquier host, puede usar el siguiente comando: mysql> GRANT FILE ON *.* TO repl@"%" IDENTIFIED BY " ";
Cierre MySQL en el servidor maestro. mysqladmin -u raíz -p apagado
Cree una imagen de todos los datos en el servidor maestro. La forma más fácil de hacer esto (en Unix) es crear con alquitrán un archivo de todo su directorio de datos. La ubicación exacta del directorio de datos depende de su instalación. tar -cvf /tmp/mysql-snapshot.tar /path/to/data-dir Los usuarios de Windows pueden usar WinZIP o un programa similar para crear un archivo de directorio de datos.
En my.cnf en el servidor maestro, agregue entradas a la sección de entrada log-bin y server-id=unique number a la sección y reinicie el servidor. Es muy importante que la ID del servidor esclavo sea diferente de la ID del servidor padre. Podemos pensar en el ID del servidor como una dirección IP: identifica de forma única el servidor entre los miembros de la replicación. log-bin server-id=1
Reinicie MySQL en el servidor maestro.
Agregue lo siguiente a my.cnf en los servidores esclavos: master-host= master-user= master-password= master-port= server-id= reemplazando los valores con los valores apropiados para su sistema . Los valores de ID de servidor deben ser diferentes en cada servidor involucrado en la replicación. Si la identificación del servidor no está definida, se establecerá en 1, si el host maestro tampoco está definido, se establecerá en 2. Tenga en cuenta que si se omite la identificación del servidor, el servidor maestro rechazará las conexiones a todos los esclavos. servidores y el servidor esclavo: para rechazar la conexión con el servidor principal. Por lo tanto, solo puede omitir la configuración del valor de ID del servidor si está realizando una copia de seguridad mediante un registro binario.
Copie los datos de la instantánea en el directorio de datos en los servidores esclavos. Asegúrese de que los permisos para archivos y directorios sean correctos. El usuario que ejecuta MySQL debe poder leer y escribir datos en ellos de la misma manera que en el servidor maestro.
Reinicie los servidores esclavos.

Una vez que se hayan completado estos pasos, los servidores descendentes deben conectarse al servidor ascendente y ajustar sus datos para reflejar cualquier cambio que haya ocurrido en el servidor ascendente desde que se tomó la imagen.

Si el servidor -id no está configurado para el servidor descendente, se registrará el siguiente error en el registro de errores:

Advertencia: se debe establecer server_id en un valor distinto de 0 si se establece master_host. El servidor no actuará como esclavo. (Advertencia: si se establece master_host, server_id debe establecerse en un valor distinto de cero. El servidor no actuará como un servidor esclavo).

Si no se establece la ID del servidor maestro, los servidores esclavos no podrán conectarse al servidor maestro.

Si un servidor descendente no puede replicar por algún motivo, los mensajes de error correspondientes se pueden encontrar en el registro de errores del servidor descendente.

Después de que el servidor esclavo comience a replicar, aparecerá un archivo `master.info" en el mismo directorio que el registro de errores. El servidor esclavo utiliza el archivo `master.info" para realizar un seguimiento de las entradas de registro binarias del servidor maestro. han sido procesados. No elimine ni edite este archivo a menos que esté seguro de que es necesario. Incluso si existe tal confianza, es mejor usar el comando CHANGE MASTER TO.

replicación- una técnica utilizada en la arquitectura de sistemas que operan bajo carga, cuyo resultado es la distribución de la carga cuando se trabaja con una base de datos en varios servidores. La replicación MySQL MASTER SLAVE se usa con más frecuencia, pero también se usa un segundo tipo de replicación: Master-Master.

¿Qué es la replicación MySQL MASTER SLAVE y para qué sirve?

replicación maestro-esclavo implica la duplicación de datos en un esclavo servidor mysql, dicha duplicación se lleva a cabo en su mayor parte para garantizar la fiabilidad. En caso de falla del servidor Maestro, sus funciones se cambian al Esclavo.

La replicación también se puede realizar para mejorar el rendimiento del sistema, pero aquí el rendimiento casi siempre es secundario.
Cuando una aplicación trabaja con una base de datos, las operaciones más frecuentes son operaciones SELECCIONAR- solicitudes de lectura de datos, modificación de datos - solicitudes BORRAR, INSERTAR, ACTUALIZAR, ALTERAR estadísticamente ocurre con mucha menos frecuencia.

Para evitar la pérdida de datos en caso de falla de uno de los servidores, las operaciones para cambiar la información en las tablas siempre son procesadas por el servidor Maestro. Luego, los cambios se replican en el Esclavo. La lectura se puede hacer desde el servidor haciendo el papel de Esclavo.
Debido a esto, puede obtener una ganancia de rendimiento junto con la confiabilidad.

La solución es popular, pero no siempre aplicable, ya que la replicación puede experimentar retrasos; si esto sucede, la información también debe leerse desde el servidor maestro.

La dirección de solicitudes de cierto tipo a un servidor de base de datos particular se implementa en cualquier caso a nivel de aplicación.

Si haces la división SELECCIONAR consultas y todo lo demás a nivel de programa, enviándolos al servidor deseado, si uno de ellos falla, la aplicación que da servicio a la infraestructura quedará inoperable. Para que esto funcione, debe proporcionar un esquema más complejo y reservar cada uno de los servidores.

La replicación es para tolerancia a fallas, no para escalar.

Replicación de MySQL MASTER SLAVE - configuración en Debian

Usaremos dos servidores con direcciones:

Servidor maestro 192.168.0.1
Servidor esclavo 192.168.0.2

Para la demostración, se utilizan VDS conectados a una red local.
Para saber siempre con certeza en qué servidor estamos ejecutando tal o cual comando, editaremos los archivos /etc/hosts en ambos servidores

192.168.0.1 maestro

192.168.0.2 esclavo

Reemplazaremos los valores existentes en /etc/hostname con maestro y esclavo, respectivamente, para que los cambios surtan efecto, reiniciaremos el servidor.

1. Realizamos configuraciones en el servidor maestro.

[correo electrónico protegido]:/#

Edición del archivo de configuración del servidor de la base de datos principal

mcedit /etc/mysql/my.cnf

Seleccione la ID del servidor; puede especificar cualquier número, el valor predeterminado es 1; simplemente elimine el comentario de la línea.

servidor-id = 1

Establezca la ruta al registro binario, también especificado de forma predeterminada, elimine el comentario

Establecemos el nombre de la base de datos que vamos a replicar a otro servidor

binlog_do_db = db1

Reinicie Mysql para que se vuelva a leer el archivo de configuración y los cambios surtan efecto:

/etc/init.d/mysql reiniciar

2. Establece al usuario los derechos necesarios

Vaya a la consola del servidor de la base de datos:

Damos al usuario en el servidor esclavo los derechos necesarios:

OTORGAR ESCLAVO DE REPLICACIÓN EN *.* A "slave_user"@"%" IDENTIFICADO POR "123";

Bloqueo de todas las tablas en la base de datos

MESAS DE LIMPIEZA CON BLOQUEO DE LECTURA;

Compruebe el estado del servidor maestro:

3. Cree un volcado de base de datos en el servidor

Crear un volcado de base de datos:

mysqldump -u raíz -p db1 > db1.sql

Desbloquear tablas en la consola mysql:

4. Transferir el volcado de la base de datos al servidor Esclavo

scp db1.sql [correo electrónico protegido]:/hogar

Realizamos más acciones en el servidor Esclavo

[correo electrónico protegido]:/#

5. Creando una base de datos

Cargando el volcado:

mysql -u raíz -p db1< db1.sql

6. Realizar cambios en my.cnf

mcedit /etc/mysql/my.cnf

Asigne una ID incrementando el valor establecido en el servidor maestro

servidor-id = 2

Establecer la ruta al registro de retransmisión

relé-registro = /var/log/mysql/mysql-relay-bin.log

y la ruta bin al registro en el servidor maestro

log_bin = /var/log/mysql/mysql-bin.log

especificar la base

binlog_do_db = db1

Reinicio del servicio

/etc/init.d/mysql reiniciar

7. Establecer la conexión con el servidor maestro

CAMBIAR MAESTRO A MASTER_HOST="192.168.0.1", MASTER_USER="slave_user", MASTER_PASSWORD="123", MASTER_LOG_FILE = "mysql-bin.000001", MASTER_LOG_POS = 327;

Empezamos la replicación en el servidor esclavo:

Puede comprobar el funcionamiento de la replicación en el Esclavo consultando:

****************************** Primera fila ****************** ** *******
Slave_IO_State: esperando que el maestro envíe el evento
Maestro_Host: 192.168.0.1
usuario_maestro: usuario_esclavo
Puerto_maestro: 3306
Conectar_Reintentar: 60
Archivo_de_registro_maestro: mysql-bin.000002
Read_Master_Log_Pos: 107
Relay_Log_File: mysql-relay-bin.000003
Relé_Log_Pos: 253
Relay_Master_Log_Archivo: mysql-bin.000002
Slave_IO_Running: Sí
Slave_SQL_Running: Sí
Replicar_Do_DB:
Replicar_Ignorar_DB:
Replicar_hacer_tabla:
Replicar_Ignorar_Tabla:
Replicar_Wild_Do_Table:
Replicar_Wild_Ignorar_Tabla:
Last_Errno: 0
Último_error:
Saltar_Contador: 0
Exec_Master_Log_Pos: 107
Relé_registro_espacio: 555
Hasta_Condición: Ninguno
Hasta_archivo_de_registro:
Hasta_Log_Pos: 0
Maestro_SSL_Permitido: No
Maestro_SSL_CA_Archivo:
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
Segundos_detrás_del_maestro: 0
Master_SSL_Verify_Server_Cert: No
Last_IO_Errno: 0
Último_IO_Error:
Last_SQL_Errno: 0
Último_SQL_Error:
Replicate_Ignore_Server_Ids:
Master_Server_Id: 1
1 fila en conjunto (0.00 seg)

Dado que no se produjeron errores, podemos concluir que la replicación está configurada correctamente.

Es buena herramienta escalado, pero como principal desventaja tiene la desincronización de la copia de datos y los retrasos, que pueden ser críticos.

Se pueden evitar por completo usando más solución moderna. Es fácil de configurar, confiable y elimina la necesidad de copiar manualmente los volcados de la base de datos.

En estos días, la base de datos MySQL se usa en casi todas partes, siempre que sea posible. Es imposible imaginar un sitio que funcione sin MySQL. Por supuesto, hay algunas excepciones, pero este sistema de base de datos ocupa la mayor parte del mercado. Y la implementación más popular es MariaDB. Cuando el proyecto es pequeño, basta un solo servidor para ejecutarlo, en el que se encuentran todos los servicios: un servidor web, un servidor de base de datos y servidor de correo. Pero cuando el proyecto crece, puede ser necesario dedicar un servidor separado para cada servicio, o incluso dividir un servicio en varios servidores, como MySQL.

Para mantener un estado sincrónico de las bases de datos en todos los servidores, la replicación debe usarse simultáneamente. En este artículo, veremos cómo se configura la replicación de MySQL usando MariaDB Galera Cluster.

¿QUÉ ES MARIADB GALERA?

MariaDB Galera es un sistema de clúster maestro-maestro para MariaDB. Desde MariaDB 10.1 software Galera Server y MariaDB Server vienen en un solo paquete, por lo que obtiene todo el software que necesita de inmediato. En este momento MariaDB Galera solo puede funcionar con motores de base de datos InnoDB y XtraDB. Uno de los beneficios de usar la replicación es la adición de redundancia a la base de datos del sitio. Si una de las bases de datos falla, puede cambiar inmediatamente a otra. Todos los servidores mantienen un estado sincronizado entre sí y garantizan que no se pierdan transacciones.

Características principales de MariaDB Galera:

Replicación con sincronización constante;
Fusión automática de nodos;
Capacidad para conectar múltiples nodos maestros;
Soporte para escribir en cualquiera de los nodos;
Replicación paralela transparente;
Escalabilidad de lectura y escritura, latencia mínima;
Los nodos fallidos se desconectan automáticamente del clúster;
No puede bloquear el acceso a las tablas.

CONFIGURAR LA REPLICACIÓN DE MYSQL

En este tutorial, usaremos Ubuntu 16.04 y MariaDB versión 10.1 para el ejemplo. Antes de comenzar, actualice completamente el sistema:

sudo apt-obtener actualización-y
sudo apt-get upgrade-y

Dado que implementaremos nuestra configuración en varios nodos, debemos realizar operaciones de actualización en todos ellos. Si el servidor de la base de datos MariaDB aún no está instalado, debe instalarse. Primero, agregue el repositorio y su clave:

sudo apt-key adv --recv-keys --keyserver hkp://keyserver.ubuntu.com:80 0xF1656F24C74CD1D8

sudo add-apt-repository "deb http://ftp.utexas.edu/mariadb/repo/10.1/ubuntu xenial main"

sudo apt-get update-y

Cuando se complete la actualización de la lista de paquetes, instale MariaDB con el comando:

sudo apt install mariadb-servidor rsync -y

Necesitamos el paquete rsync para realizar la sincronización directa. Una vez completada la instalación, debe proteger la base de datos mediante el script mysql_secure_installation:

sudo mysql_secure_installation

De forma predeterminada, se permite el inicio de sesión de invitados, hay una base de datos de prueba y no se establece una contraseña para el usuario raíz. Todo esto necesita ser corregido. Lea más en el artículo. En resumen, tendrás que responder algunas preguntas:

Ingrese la contraseña actual para root (ingresar para ninguno):
¿Cambiar la contraseña de root? norte
¿Eliminar usuarios anónimos? Y
¿Deshabilitar el inicio de sesión raíz de forma remota? Y
¿Eliminar la base de datos de prueba y acceder a ella? Y
¿Recargar tablas de privilegios ahora? Y

Cuando todo esté listo, puede proceder a configurar los nodos entre los que se replicarán las bases de datos mysql. Primero, veamos cómo configurar el primer nodo. Puede poner todas las configuraciones en my.cnf, pero sería mejor crear archivo separado para estos fines en la carpeta /etc/mysql/conf.d/.

Añade estas líneas:

binlog_format=FILA

innodb_autoinc_lock_mode=2
dirección de enlace = 0.0.0.0

wsrep_on=ON

wsrep_sst_method=rsync
# Configuración del nodo Galera
wsrep_node_address="192.168.56.101"
wsrep_node_name="Nodo1"

Aquí la dirección 192.168.56.101 es la dirección del nodo actual. Luego vaya a otro servidor y cree el mismo archivo allí:

sudo vi /etc/mysql/conf.d/galera.cnf

binlog_format=FILA
predeterminado-motor-de-almacenamiento=innodb
innodb_autoinc_lock_mode=2
dirección de enlace = 0.0.0.0
# Configuración del proveedor de Galera
wsrep_on=ON
proveedor_wsrep=/usr/lib/galera/libgalera_smm.so
# Configuración del clúster de Galera
wsrep_cluster_name="galera_cluster"
wsrep_cluster_address="gcomm://192.168.56.101,192.168.56.102"
# Configuración de sincronización de Galera
wsrep_sst_method=rsync
# Configuración del nodo Galera
wsrep_node_address="192.168.56.102"
wsrep_node_name="Nodo2"

De manera similar, aquí la dirección del nodo es 192.168.0.103. Detengámonos en el ejemplo con dos servidores, ya que esto es suficiente para demostrar el funcionamiento del sistema, y puede agregar otro servidor ingresando una dirección IP adicional en el campo wsrep_cluster_address. Ahora considere qué significan los valores de los parámetros principales y proceda al lanzamiento:

binlog_formato- el formato del registro en el que se guardarán las solicitudes, el valor de la fila indica que los datos binarios se almacenarán allí;
motor de almacenamiento predeterminado- motor tablas SQL que usaremos;
innodb_autoinc_modo_bloqueo- Modo de funcionamiento del generador de valores AUTO_INCREMENT;
dirección de enlace- dirección IP donde el programa escuchará las conexiones, en nuestro caso, todas las direcciones IP;
wsrep_on- incluye replicación;
proveedor_wsrep- biblioteca con la que se realizará la replicación;
wsrep_cluster_name - nombre del clúster, debe coincidir en todos los nodos;
wsrep_cluster_address- lista de direcciones de servidores entre los cuales se replicarán las bases de datos mysql, separados por comas;
wsrep_sst_método- el transporte que se utilizará para la transmisión de datos;
dirección_nodo_wsrep- dirección IP del nodo actual;
nombre_nodo_wsrep- el nombre del nodo actual.

Configuración replicación MySQL casi completo. El último toque que queda antes del lanzamiento es la configuración del firewall. Primero, habilite la herramienta de administración de reglas de iptables en Ubuntu - UFW:

Luego abre estos puertos:

sudo ufw permite 3306/tcp
sudo ufw permite 4444/tcp
sudo ufw permite 4567/tcp
sudo ufw permite 4568/tcp
sudo ufw permite 4567/udp

LANZAMIENTO MARIADB GALERA

Después de configurar con éxito todos los nodos, solo tenemos que iniciar el clúster de Galera en el primer nodo. Antes de que podamos iniciar el clúster, debe asegurarse de que el servicio MariaDB esté detenido en todos los servidores:

sudo galera_nuevo_cluster

Puede verificar si el clúster se está ejecutando y cuántas máquinas están conectadas con el comando:

Ahora solo hay una máquina allí, ahora ve a otro servidor y ejecuta el nodo allí:

sudo systemctl iniciar mysql

Puede verificar si el lanzamiento fue exitoso y si hubo algún error con el comando:

sudo systemctl estado mysql

Luego, al ejecutar el mismo comando, verificará que el nuevo nodo se haya agregado automáticamente al clúster:

mysql -u root -p -e "mostrar estado como "wsrep_cluster_size""

Para verificar cómo funciona la replicación, simplemente cree una base de datos en el primer nodo y vea si realmente se ha agregado a todos los demás:

mysql -u raíz -p

MariaDB [(ninguno)]> crear base de datos test_db;
MariaDB [(ninguno)]> mostrar bases de datos;