- Se incorporó
- 3 Enero 2006
- Mensajes
- 7.425
Hola!
Hoy en cocinando con galansinchance, les cuento una guía de algo que tuve que hacer hace poco, y que me pareció interesante compartirlo con ustedes:
Me refiero a montar un servidor con una réplica esclava de base de datos, lo que nos permite, por ejemplo, distribuir la carga de lectura entre una o varias máquinas de la misma base de datos, mantener un backup en caliente (ojo, como buena práctica nunca reemplazar los respaldos periódicos con esto!), dar continuidad operacional, etc etc.
Para este caso la máquina principal o maestra escribe las transacciones efectuadas en su sus BDs en un log binario, el que es replicado hacia una o más máquinas esclavas, las que se actualizan de forma asincrónica.
Ahora, esto es unidireccional, es decir, todas las cosas que ocurren en el maestro se replica hacia los otros servidores, pero lo que ocurre en estos últimos no se hacen efectivas en el maestro, si desean hacerlo bidireccional, el esquema debe ser circular, es decir, cada servidor, es maestro y esclavo del otro al mismo tiempo.
Imaginemos 2 equipos con la siguiente configuración:
IP servidor maestro: 10.0.0.10
IP servidor esclavo: 10.0.0.11
Configurando el servidor maestro:
Se edita el archivo de configuración del servicio
buscar en el archivo y editar, descomentar o añadir en caso que no estén los siguientes parámetros de configuración (la dirección del server maestro, el id del servicio y dónde se guardarán los registros):
Reiniciamos el servicio mysql
Creamos un usuario usuario para replicación
Bloqueamos temporalmente las tablas
Registramos la posición de estado del servicio de base de datos de la máquina maestra para indicarle al server de base de datos esclava qué archivo y desde dónde debe comenzar a sincronizarse
Ahora, guardamos la información anterior y volcamos la base de datos a un archivo
Desbloqueamos las tablas de la base de datos maestra para que puedan seguir usándose
Configurando el servidor esclavo
Desde el servidor maestro, copiamos el respaldo de la base de datos al servidor esclavo
Cambiamos la configuración del servidor esclavo en el archivo mysqld.cnf
buscamos en el archivo y editamos, descomentamos o añadimos en caso que no estén los siguientes parámetros de configuración (la dirección del server esclavo, el id del servicio y dónde se guardarán los registros):
Reiniciamos los servicios del servidor esclavo
Importamos el backup que copiamos del servidor maestro en el servidor esclavo
Configuramos al interior del servidor esclavo para que se sincronice con el maestro, fíjense que en MASTER_LOG_FILE y MASTER_LOG_POS deben ir los valores del archivo y posición de la última transacción registrada en el server maestro antes del respaldo que realizamos, el server esclavo desde esa posición en adelante se sincronizará
Podremos probar la configuración insertando algo o modificando una tabla o base de datos en el servidor maestro, y comprobar que la acción se refleje en el servidor esclavo.
También podemos ver el estado del servidor esclavo con:
Si no hay errores les aparecería un response como este, indicando en el estado que está esperando información desde el master y sin errores IO o SQL, por otro lado, hay un indicador que es Seconds_Behind_Master, que indica el tiempo en segundos de desface que tiene respecto del server, este tiempo va disminuyendo en la medida que todos los registros que ocurren en el maestro se van cargando en el esclavo.
Dónde podrían tener problemas:
1.- Los equipos no se ven en red
2.- El firewall tiene filtrado el acceso a los servidores
3.- Se equivocaron con el nombre del archivo o la posición de la transacción en el log.
4.- Selinux podría en algún caso poner problemas, aunque no me ha pasado.
Saludos!
Hoy en cocinando con galansinchance, les cuento una guía de algo que tuve que hacer hace poco, y que me pareció interesante compartirlo con ustedes:
Me refiero a montar un servidor con una réplica esclava de base de datos, lo que nos permite, por ejemplo, distribuir la carga de lectura entre una o varias máquinas de la misma base de datos, mantener un backup en caliente (ojo, como buena práctica nunca reemplazar los respaldos periódicos con esto!), dar continuidad operacional, etc etc.
Para este caso la máquina principal o maestra escribe las transacciones efectuadas en su sus BDs en un log binario, el que es replicado hacia una o más máquinas esclavas, las que se actualizan de forma asincrónica.
Ahora, esto es unidireccional, es decir, todas las cosas que ocurren en el maestro se replica hacia los otros servidores, pero lo que ocurre en estos últimos no se hacen efectivas en el maestro, si desean hacerlo bidireccional, el esquema debe ser circular, es decir, cada servidor, es maestro y esclavo del otro al mismo tiempo.
Imaginemos 2 equipos con la siguiente configuración:
IP servidor maestro: 10.0.0.10
IP servidor esclavo: 10.0.0.11
Configurando el servidor maestro:
Se edita el archivo de configuración del servicio
Código:
# vi /etc/mysql/mysql.conf/mysqld.cnf #(para el caso de mysql)
# vi /etc/mysql/mariadb.conf.d/50-server.cnf #(para el caso de mariadb)buscar en el archivo y editar, descomentar o añadir en caso que no estén los siguientes parámetros de configuración (la dirección del server maestro, el id del servicio y dónde se guardarán los registros):
Código:
bind-address = 10.0.0.10
server-id = 1
log_bin = /var/log/mysql/mysql-bin.logReiniciamos el servicio mysql
Código:
# systemctl restart mysqlCreamos un usuario usuario para replicación
Código:
# mysql -u root -p
mysql> CREATE USER 'backup'@'%' IDENTIFIED BY 'backuppasswd';
mysql> GRANT REPLICATION SLAVE ON *.* TO 'backup'@'%';
mysql> FLUSH PRIVILEGES;Bloqueamos temporalmente las tablas
Código:
mysql> FLUSH TABLES WITH READ LOCK;Registramos la posición de estado del servicio de base de datos de la máquina maestra para indicarle al server de base de datos esclava qué archivo y desde dónde debe comenzar a sincronizarse
Código:
mysql> SHOW MASTER STATUS;
+-------------------------+-----------+---------------------+-------------------------+---------------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+-------------------------+----------+---------------------+-------------------------+---------------------------+
| mysql-bin.000001 |613 | | | |
+-------------------------+----------+---------------------+-------------------------+---------------------------+Ahora, guardamos la información anterior y volcamos la base de datos a un archivo
Código:
$ mysqldump -u root -p --all-databases --master-data > dbdump.sqlDesbloqueamos las tablas de la base de datos maestra para que puedan seguir usándose
Código:
mysql> UNLOCK TABLES;Configurando el servidor esclavo
Desde el servidor maestro, copiamos el respaldo de la base de datos al servidor esclavo
Código:
$ scp [email protected]:/ubicacion/de/respaldo/dbdump.sql /home/usuario_esclavo/Cambiamos la configuración del servidor esclavo en el archivo mysqld.cnf
Código:
# vi /etc/mysql/mysql.conf/mysqld.cnf #(para el caso de mysql)
# vi /etc/mysql/mariadb.conf.d/50-server.cnf #(para el caso de mariadb)buscamos en el archivo y editamos, descomentamos o añadimos en caso que no estén los siguientes parámetros de configuración (la dirección del server esclavo, el id del servicio y dónde se guardarán los registros):
Código:
bind-address = 10.0.0.11
server-id = 2
log_bin = /var/log/mysql/mysql-bin.logReiniciamos los servicios del servidor esclavo
Código:
# systemctl restart mysqlImportamos el backup que copiamos del servidor maestro en el servidor esclavo
Código:
$ mysql -u root -p < /home/usuario/dbdump.sqlConfiguramos al interior del servidor esclavo para que se sincronice con el maestro, fíjense que en MASTER_LOG_FILE y MASTER_LOG_POS deben ir los valores del archivo y posición de la última transacción registrada en el server maestro antes del respaldo que realizamos, el server esclavo desde esa posición en adelante se sincronizará
Código:
$ mysql -u root -p
mysql> STOP SLAVE;
mysql> CHANGE MASTER TO
-> MASTER_HOST='10.0.0.10',
-> MASTER_USER='backup',
-> MASTER_PASSWORD='backuppasswd',
-> MASTER_LOG_FILE='mysql-bin.000001',
-> MASTER_LOG_POS=613;
mysql> START SLAVE;Podremos probar la configuración insertando algo o modificando una tabla o base de datos en el servidor maestro, y comprobar que la acción se refleje en el servidor esclavo.
También podemos ver el estado del servidor esclavo con:
Código:
MariaDB [(none)]> SHOW SLAVE STATUS\G;
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 10.0.0.10
Master_User: backup
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: mysql-bin.000001
Read_Master_Log_Pos: 936
Relay_Log_File: mysqld-relay-bin.000003
Relay_Log_Pos: 4
Relay_Master_Log_File: mysql-bin.000001
Slave_IO_Running: No
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: 936
Relay_Log_Space: 249
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Master_SSL_Allowed: No
Master_SSL_CA_File:
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
Seconds_Behind_Master: 231
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: 1
Master_SSL_Crl:
Master_SSL_Crlpath:
Using_Gtid: No
Gtid_IO_Pos:
Replicate_Do_Domain_Ids:
Replicate_Ignore_Domain_Ids:
Parallel_Mode: conservativeSi no hay errores les aparecería un response como este, indicando en el estado que está esperando información desde el master y sin errores IO o SQL, por otro lado, hay un indicador que es Seconds_Behind_Master, que indica el tiempo en segundos de desface que tiene respecto del server, este tiempo va disminuyendo en la medida que todos los registros que ocurren en el maestro se van cargando en el esclavo.
Dónde podrían tener problemas:
1.- Los equipos no se ven en red
2.- El firewall tiene filtrado el acceso a los servidores
3.- Se equivocaron con el nombre del archivo o la posición de la transacción en el log.
4.- Selinux podría en algún caso poner problemas, aunque no me ha pasado.
Saludos!
Última modificación:
