concepto
¿Qué es la separación de lectura y escritura?
El principio básico de la separación de lectura y escritura es permitir que la base de datos principal maneje las operaciones transaccionales de adición, modificación y eliminación (INSERT, UPDATE, DELETE), mientras que la base de datos esclava maneja las operaciones de consulta SELECT. La replicación de la base de datos se utiliza para sincronizar los cambios provocados por las operaciones transaccionales en las bases de datos esclavas del clúster.
¿Por qué leer y escribir la separación?
Porque la operación de "escritura" de la base de datos (puede tomar 3 minutos escribir 10,000 piezas de datos) requiere mucho tiempo.
Pero la "lectura" de la base de datos (puede tardar sólo 5 segundos en leer 10.000 datos);
Por lo tanto, la separación de lectura y escritura, la solución es que la escritura de la base de datos afecta la eficiencia de la consulta.
¿Cuándo leer y escribir separación?
La base de datos no necesariamente tiene que estar separada de lectura y escritura, si el programa usa mucho la base de datos, pero hay pocas actualizaciones y muchas consultas, se considerará. El uso de la sincronización maestro-esclavo de la base de datos, y luego a través de la separación de lectura y escritura, puede compartir la presión de la base de datos y mejorar el rendimiento.
Replicación maestro-esclavo y separación de lectura y escritura
En el entorno de producción real, la lectura y escritura de la base de datos están todas en el mismo servidor de base de datos, lo que no puede satisfacer las necesidades reales. Ya sea en términos de seguridad, alta disponibilidad o alta concurrencia, es completamente incapaz de satisfacer las necesidades reales.
Por lo tanto, los datos se sincronizan a través de la replicación maestro-esclavo y la capacidad de carga simultánea de la base de datos se mejora a través de la separación de lectura y escritura. Un poco similar a rsync (herramienta de sincronización de archivos), pero la diferencia es que rsync hace una copia de seguridad de los archivos del disco, mientras que la replicación maestro-esclavo de mysql hace una copia de seguridad de los datos y las declaraciones en la base de datos.
Tipos de replicación soportados por mysql
(1) DECLARACIÓN : replicación basada en declaraciones. Ejecute la sentencia SQL en el servidor y ejecute la misma sentencia en el servidor esclavo.Mysql utiliza la replicación basada en sentencias de forma predeterminada (antes de la versión 5.7), que tiene una alta eficiencia de ejecución. En el caso de alta concurrencia, pueden ocurrir errores en la secuencia de ejecución y bloqueos de transacciones.
(2) ROW : replicación basada en filas. Copie el contenido modificado en lugar de ejecutar el comando en el servidor esclavo. Preciso, pero ineficiente, y el archivo guardado será más grande. (Después de la versión 5.7, el modo ROW se usa de forma predeterminada)
(3) MIXTO : Copia de tipos mixtos. De manera predeterminada, se usa la replicación basada en declaraciones. Una vez que se determina que la replicación basada en declaraciones no se puede replicar con precisión, se usará la replicación basada en filas. Más inteligente, así que use MIXTO en la mayoría de los casos.
(3) Al mismo tiempo, el nodo maestro inicia un subproceso de volcado para cada subproceso de E/S para notificarle y enviarle eventos binarios.Después de que el subproceso de E/S recibe el contenido del registro bin, guarda el contenido en el local retransmisión del nodo esclavo En el registro (Retransmisión de registro ), el nodo Esclavo iniciará el subproceso SQL para leer eventos binarios del registro de retransmisión, reproducirlos localmente, es decir, analizarlos en declaraciones SQL y ejecutarlos uno por uno, de modo que que sus datos sean consistentes con los del nodo maestro. Finalmente, el subproceso de E/S y el subproceso de SQL se dormirán y esperarán la próxima activación.
Recuerde dos registros y tres hilos:
Dos registros: registro binario (registro bin) , registro de retransmisión (registro de retransmisión)
Tres subprocesos: subproceso de E/S , subproceso de volcado , subproceso SQL
Aviso:
- Los registros de retransmisión generalmente se encuentran en la memoria caché del sistema operativo, por lo que la sobrecarga de los registros de retransmisión es pequeña.
- El proceso de replicación tiene una limitación muy importante, es decir, la replicación se serializa en el Esclavo, es decir, la operación de actualización en paralelo en el Maestro no se puede operar en paralelo en el Esclavo.
- Para la replicación semisíncrona, habrá un subproceso de confirmación de acuse de recibo adicional (subproceso de recopilación de acuse de recibo), que se usa especialmente para recibir información de retroalimentación del esclavo (recopilar la información de acuse de recibo devuelta por el nodo esclavo)
Solución a la inconsistencia de datos maestro-esclavo de la base de datos
Método 1: después de ignorar el error, continúe sincronizando
Este método es adecuado para la situación en la que los datos de la base de datos maestra-esclava no son muy diferentes, o no se requiere que los datos estén completamente unificados, y los requisitos de datos no son estrictos.
Método 2: rehacer maestro-esclavo, sincronización completa
Este método es adecuado para la situación en la que los datos de la base de datos maestro-esclavo difieren mucho, o se requiere que los datos estén completamente unificados
¿Cómo garantizar la sincronización de datos después de que mysql se reanude desde el bloqueo del servidor?
- Método físico: sincronización de archivos de disco rsync. Para usar la recuperación de archivos, el nodo principal debe detener el servicio.
- Replicación maestro-esclavo: elimine la biblioteca original del nodo esclavo y vuelva a realizar la replicación maestro-esclavo a través del desplazamiento
¿En qué circunstancias se reducirá la replicación semisincrónica a la replicación asíncrona? ¿Cuándo se reanudará la replicación síncrona?
-
Cuando se agote el tiempo de espera de la replicación semisíncrona (controlado por el parámetro rpl_semi_sync_master_timeout, el valor predeterminado es 10000 ms, es decir, 10 s), la replicación semisíncrona se cerrará temporalmente y se utilizará en su lugar la replicación asíncrona, es decir, se reducirá automáticamente a trabajo asincrónico.
-
Después de que el subproceso de volcado malster envía todos los eventos de una transacción, si recibe una respuesta de la biblioteca esclava dentro de rpl_ semi_sync_master_ timeout, el maestro-esclavo reanuda la replicación semi-síncrona
MySQL razones de retraso de replicación maestro-esclavo y métodos de optimización
Motivos del retraso de la replicación maestro-esclavo:
- El servidor maestro tiene una alta concurrencia y forma una gran cantidad de transacciones.
- Latencia de conexion.
- Causado por dispositivos de hardware maestro-esclavo (frecuencia principal de CPU, E/S de memoria, E/S de disco duro).
- Es replicación síncrona, no replicación asíncrona.
Mejoramiento:
-
Optimice los parámetros de Mysql desde la biblioteca. Por ejemplo, aumente innodb_buffer_pool_size para permitir que se completen más operaciones en la memoria Mysql y reduzca las operaciones de disco.
-
Utilice un host de alto rendimiento de la biblioteca. Incluye potente cpu, mayor memoria. Evite el uso de hosts de nube virtual y use hosts físicos, lo que mejora el rendimiento de E/S.
-
Utilice el disco SSD de la biblioteca.
-
Optimización de la red para evitar la sincronización entre salas de ordenadores
1. Replicación asíncrona
La replicación predeterminada de MySQL es asíncrona. La biblioteca maestra devolverá inmediatamente los resultados al cliente después de ejecutar la transacción enviada por el cliente. No importa si la biblioteca esclava lo recibió y procesó, por lo que habrá un problema, principalmente un bloqueo. En este momento, las transacciones que ha enviado el maestro pueden no transmitirse al esclavo. Si en este momento, el esclavo es promovido a la fuerza a maestro, los datos en el nuevo maestro pueden estar incompletos.
2. Replicación totalmente síncrona
Significa que cuando la biblioteca principal ejecuta una transacción, todas las bibliotecas esclavas ejecutan la transacción antes de regresar al cliente. Debido a que es necesario esperar a que todas las bibliotecas esclavas ejecuten la transacción antes de regresar, el rendimiento de la replicación síncrona completa inevitablemente se verá seriamente afectado.
3. Replicación semisincrónica
Entre la replicación asíncrona y la replicación sincrónica completa, la biblioteca maestra no regresa al cliente inmediatamente después de ejecutar la transacción enviada por el cliente, sino que espera que al menos una biblioteca esclava reciba y escriba en el registro de retransmisión antes de regresar al cliente. En comparación con la replicación asíncrona, la replicación semi-sincrónica mejora la seguridad de los datos y también provoca un cierto grado de retraso, que es al menos un tiempo de ida y vuelta de TCP/IP. Por lo tanto, la replicación semisíncrona se utiliza mejor en redes de baja latencia.
Demostración de caso de replicación maestro-esclavo (replicación asíncrona)
entorno de laboratorio:
Servidor maestro: 192.168.137.50, mysql5.7
Servidor Slave1: 192.168.137.60, mysql5.7
Servidor Slave2: 192.168.137.70, mysql5.7
Experimentar ideas:
- Sincronización horaria del servidor maestro y esclavo.
- Configure el servidor maestro, modifique su archivo de configuración y cree una cuenta de sincronización en la base de datos maestra para autorizar el uso de la base de datos esclava.
- Configure la base de datos esclava, modifique su archivo de configuración y configure la sincronización en la base de datos esclava.
- Verifica que la sincronización sea exitosa
Pasos experimentales:
Apague el firewall y selinux en cada servidor
systemctl disable --now firewalld
setenforce 0
Sincronización de tiempo del servidor maestro-esclavo MYSQL
Sincronización de tiempo:
- Cada servidor mysql necesita configurar la sincronización de tiempo para evitar confusiones durante la sincronización de datos.
- Si no hay una red externa, use el servicio ntp. Si está conectado a la red externa, se puede utilizar la fuente de reloj de la red.
Lo siguiente demostrará que el nodo maestro usa la fuente de reloj local y el nodo esclavo realiza la sincronización de tiempo
El servidor maestro usa una fuente de reloj local
#安装时间同步工具（本地设置时钟源）
[root@yuji ~]# yum install -y ntp
#修改ntp配置文件，在末尾加入
[root@yuji ~]# vim /etc/ntp.conf
server 127.127.72.0 #设置本地时钟源，注意修改网段（72是网段）
fudge 127.127.72.0 stratum 8 #设置时间层级为8（限制在15以内）
#开启ntpd
[root@yuji ~]# systemctl start ntpd
Dos servidores esclavos sincronizan la hora del servidor maestro
#安装时间同步工具
yum install -y ntp
#开启ntpd
systemctl start ntpd
#和主服务器进行时间同步
/usr/sbin/ntpdate 192.168.137.50
#设置定时任务，每30分钟同步一次
crontab -e
*/30 * * * * /usr/sbin/ntpdate 192.168.137.50
configuración mysql del servidor maestro
Modifique el archivo de configuración y cree una cuenta de sincronización autorizada para usar desde la base de datos
[root@]# vim /etc/my.cnf
[mysqld]
......
server-id = 1 #指定服务ID号，master和两台slave都要不同
log-bin=mysql-bin #添加，主服务器开启二进制日志
binlog_format = MIXED #指定二进制日志(binlog)的记录格式为MIXED
log-slave-updates=true #添加，允许slave从master复制数据时可以写入到自己的二进制日志
expire_logs_days = 7 #设置二进制日志文件过期时间，默认值为0，表示logs不过期
max_binlog_size = 500M #设置二进制日志限制大小，如果超出给定值，日志就会发生滚动，默认值是1GB
#重启服务
[root@]# systemctl restart mysqld
[root@]# mysql -u root -pabc123
#给从服务器授权
grant replication slave on *.* to 'myslave'@'192.168.137.%' identified by '123123';
flush privileges; #刷新权限
show master status; #查看主服务器状态
//显示如下
+-------------------+----------+--------------+------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+-------------------+----------+--------------+------------------+
| mysql-bin.000006 | 603 | | |
+-------------------+----------+--------------+------------------+
1 row in set (0.00 sec)
#File 列显示日志名，Position 列显示偏移量
configuración de mysql desde el servidor
#修改配置文件
[root@s1 ~]# vim /etc/my.cnf
[mysqld]
......
server-id = 2 #修改，注意id与Master的不同，两个Slave的id也要不同
relay-log=relay-log-bin #添加，开启中继日志，从主服务器上同步日志文件记录到本地
relay-log-index=slave-relay-bin.index #添加，定义中继日志索引文件的位置和名称，一般和relay-log在同一目录
relay_log_recovery = 1 #选配项
#当 slave 从库宕机后，假如 relay-log 损坏了，导致一部分中继日志没有处理，则自动放弃所有未执行的 relay-log，并且重新从 master 上获取日志，这样就保证了 relay-log 的完整性。默认情况下该功能是关闭的，将 relay_log_recovery 的值设置为 1 时， 可在 slave 从库上开启该功能，建议开启。
#重启服务
[root@s1 ~]# systemctl restart mysqld
#登录数据库，进行同步设置
[root@s1 ~]# mysql -u root -p
CHANGE master to master_host='192.168.137.50',master_user='myslave',master_password='123123',master_log_file='mysql-bin.000001',master_log_pos=604;
#配置同步，注意 master_log_file 和 master_log_pos 的值要与Master查询的一致
start slave; #启动同步，如有报错执行 reset slave;
show slave status\G #查看 Slave 状态
##确保 IO 和 SQL 线程都是 Yes，代表同步正常。
Slave_IO_Running: Yes #负责与主机的IO通信
Slave_SQL_Running: Yes #负责自己的slave mysql进程
##一般 "Slave_IO_Running: No" 的可能原因：
1. 网络不通
2. my.cnf配置有问题（server-id重复）
3. 密码、file文件名、pos偏移量不对
4. 防火墙没有关闭
El servidor Slave2 también está configurado de la misma manera. Tenga en cuenta que el ID del servidor en el archivo de configuración es diferente de los dos anteriores. Lo configuré en "ID del servidor = 3" aquí
Consejos:
Posibles causas comunes de "Slave_IO_Running: No"
- problema de red
- Hay un problema con la configuración de my.cnf (id de servidor duplicado)
- La contraseña, el nombre de archivo y el desplazamiento pos son incorrectos
- El cortafuegos no está desactivado
Verificar el efecto de la replicación maestro-esclavo
Cree una nueva base de datos en el servidor maestro, ejecute create database cxk666;
Vaya al servidor esclavo para verificar si la sincronización es exitosa, ejecute show databases;
Demostración de caso de replicación maestro-esclavo (replicación semisincrónica)
entorno de laboratorio:
Servidor maestro: 192.168.137.50, mysql5.7
Servidor Slave1: 192.168.137.60, mysql5.7
Servidor Slave2: 192.168.137.70, mysql5.7
Operación experimental:
systemctl disable --now firewalld
setenforce 0
-------2、主数据库配置---------
vim /etc/my.cnf #在 [mysqld] 区域添加下面内容
......
plugin-load=rpl_semi_sync_master=semisync_master.so #加载mysql半同步复制的插件
rpl_semi_sync_master_enabled=ON #或者设置为"1"，即开启半同步复制功能
rpl-semi-sync-master-timeout=1000 #超时时间为1000ms，即1s
systemctl restart mysqld
-------3、从数据库配置-----------
vim /etc/my.cnf
......
plugin-load=rpl_semi_sync_slave=semisync_slave.so
rpl_semi_sync_slave_enabled=ON
systemctl restart mysqld
-------4、查看半同步是否在运行---------------
#主数据库执行
show status like 'Rpl_semi_sync_master_status';
show variables like 'rpl_semi_sync_master_timeout';
#从数据库执行（此时可能还是OFF状态，需要在下一步重启IO线程后，从库半同步状态才会为ON）
show status like 'Rpl_semi_sync_slave_status';
#重启从数据库上的IO线程
STOP SLAVE IO_THREAD;
START SLAVE IO_THREAD;
#在主库查询半同步状态
show status like '%Rpl_semi%';
参数说明：
Rpl_semi_sync_master_clients #半同步复制客户端的个数
Rpl_semi_sync_master_net_avg_wait_time #平均等待时间（默认毫秒）
Rpl_semi_sync_master_net_wait_time #总共等待时间
Rpl_semi_sync_master_net_waits #等待次数
Rpl_semi_sync_master_no_times #关闭半同步复制的次数
Rpl_semi_sync_master_no_tx #表示没有成功接收slave提交的次数
Rpl_semi_sync_master_status #表示当前是异步模式还是半同步模式，on为半同步
Rpl_semi_sync_master_timefunc_failures #调用时间函数失败的次数
Rpl_semi_sync_master_tx_avg_wait_time #事物的平均传输时间
Rpl_semi_sync_master_tx_wait_time #事物的总共传输时间
Rpl_semi_sync_master_tx_waits #事物等待次数
Rpl_semi_sync_master_wait_pos_backtraverse #可以理解为"后来的先到了，而先来的还没有到的次数"
Rpl_semi_sync_master_wait_sessions #当前有多少个session因为slave的回复而造成等待
Rpl_semi_sync_master_yes_tx #成功接受到slave事物回复的次数
当半同步复制发生超时（由rpl_semi_sync_master_timeout参数控制，默认为10000ms，即10s），会暂时关闭半同步复制，转而使用异步复制，也就是会自动降为异步工作。
当 master dump 线程发送完一个事务的所有事件之后，如果在 rpl_semi_sync_master_timeout 内，收到了从库的响应， 则主从又重新恢复为半同步复制。
Aviso:
1) En la arquitectura de un maestro y varios esclavos, si se va a habilitar la replicación semisíncrona, no se requiere que todos los esclavos sean semisíncronos.
2) MySQL 5.7 ha mejorado mucho el rendimiento de la replicación semisincrónica.
- En la replicación semi-síncrona de la versión 5.6, el subproceso de volcado realiza dos tareas diferentes y muy frecuentes: enviar binlog al esclavo y esperar la información de retroalimentación del esclavo, y estas dos tareas son en serie, y el subproceso de volcado debe esperar. para que el esclavo regrese. Solo entonces se transmitirá la siguiente transacción de eventos. El hilo de volcado se ha convertido en el cuello de botella para mejorar el rendimiento de toda la semisincronización. En escenarios comerciales de alta simultaneidad, dicho mecanismo afectará el rendimiento general del sistema (TPS) de la base de datos.
- En la replicación semisíncrona de la versión 5.7, un subproceso de recopilación de acuse de recibo es independiente, que se utiliza especialmente para recibir información de retroalimentación del esclavo. De esta manera, dos subprocesos en el maestro funcionan de forma independiente y pueden enviar binlog al esclavo y recibir comentarios del esclavo al mismo tiempo.
¿En qué circunstancias se reducirá la replicación semisincrónica a la replicación asíncrona? ¿Cuándo se reanudará la replicación síncrona?
- Cuando se agote el tiempo de espera de la replicación semisíncrona (controlado por el parámetro rpl_semi_sync_master_timeout, el valor predeterminado es 10000 ms, es decir, 10 s), la replicación semisíncrona se cerrará temporalmente y se utilizará en su lugar la replicación asíncrona, es decir, se reducirá automáticamente a trabajo asincrónico.
- Después de que el subproceso de volcado de malster envía todos los eventos de una transacción, si recibe una respuesta de la biblioteca esclava dentro del tiempo de espera de rpl_ semi_sync_master_, el maestro-esclavo reanuda la replicación semisíncrona.
El concepto de separación de lectura y escritura.
El principio de la separación de lectura y escritura de MySQL
- La separación de lectura y escritura significa solo escribir en el servidor maestro y leer solo en el servidor esclavo.
- El principio básico es dejar que la base de datos maestra maneje las operaciones transaccionales, mientras que la base de datos esclava maneja las consultas seleccionadas.
- La replicación de la base de datos se utiliza para sincronizar los cambios causados por las operaciones transaccionales en la base de datos principal con las bases de datos secundarias del clúster.
En la actualidad, la separación de lectura y escritura de MysQL más común se divide en los siguientes dos tipos
1) Basado en la implementación interna del código del programa
En el código, el enrutamiento se clasifica según seleccionar e insertar, este método también es el más utilizado en el entorno de producción.
La ventaja es que el rendimiento es mejor, porque está implementado en el código del programa, y no hay necesidad de agregar equipos adicionales para gastos de hardware; la desventaja es que necesita desarrolladores para implementar, y el personal de operación y mantenimiento no tiene forma para comenzar.
Sin embargo, no todas las aplicaciones son adecuadas para implementar la separación de lectura y escritura en el código del programa. Al igual que algunas aplicaciones Java complejas y de gran escala, si se implementa la separación de lectura y escritura en el código del programa, los cambios en el código serán relativamente grandes.
2) Implementación basada en la capa proxy intermedia
El agente generalmente se encuentra entre el cliente y el servidor. Después de recibir la solicitud del cliente, el servidor del agente la reenvía a la base de datos de back-end después de emitir el juicio. Se muestran los siguientes procedimientos representativos.
(1) Proxy MySQL. MySQL-Proxy es un proyecto de código abierto de MysQL y el juicio de SQL se realiza a través de su propio script 1ua.
(2) Atlas. Es un proyecto de capa intermedia de datos basado en el protocolo MysQL desarrollado y mantenido por el equipo de infraestructura del Departamento de Plataforma Web de Qihoo 360. Está basado en mysql-proxy versión 0.8.2, optimizado y agregado algunas características nuevas. 360 utiliza atlas internamente para ejecutar el negocio mysql, y la cantidad de solicitudes de lectura y escritura que realiza todos los días alcanza varios miles de barras. Admite cosas y procedimientos almacenados.
(3) Ameba. Desarrollado por Chen Siru, el autor trabajó una vez para Alibaba. El programa está desarrollado en lenguaje Java y Alibaba lo utiliza en el entorno de producción. Pero no admite transacciones ni procedimientos almacenados.
(4) mi gato. Es un popular middleware de base de datos escrito en lenguaje Java. Es un servidor que implementa el protocolo MySq1. Su función principal es dividir bases de datos y tablas. Junto con el modo maestro-esclavo de la base de datos, también se puede lograr la separación de lectura y escritura.
Dado que el uso de MysQLProxy requiere escribir una gran cantidad de secuencias de comandos ua, estos Lua no están listos, sino que debe escribirlos usted mismo. Esto es muy difícil para las personas que no están familiarizadas con las variables integradas de MysQLProxy y el protocolo MySQL.
Amoeba es un software muy fácil de usar y portátil. Por lo tanto, es ampliamente utilizado en la capa de proxy de la base de datos en el entorno de producción.
Caso de separación de lectura y escritura (usando Amoeba)
entorno de laboratorio
Servidor maestro: 192.168.137.50, mysql5.7, centos7-2
Servidor Slave1: 192.168.137.60, mysql5.7, centos7-6
Servidor Amoeba: 192.168.137.70, jdk1.6, Amoeba centos7-3
Cliente: 192.168.137.40, mysql5.7, centos7-4
Configuración del servidor Ameba
#因为 Amoeba 基于是 jdk1.5 开发的，所以官方推荐使用 jdk1.5 或 1.6 版本，高版本不建议使用。
#先将jdk的二进制文件上传到/opt/目录下，之后复制到/usr/local/目录下
[root@Amo ~]# cd /opt/
[root@Amo opt]# cp jdk-6u14-linux-x64.bin /usr/local/
[root@Amo opt]# cd /usr/local/
[root@Amo local]# chmod +x jdk-6u14-linux-x64.bin #为二进制文件增加执行权限
[root@Amo local]# ./jdk-6u14-linux-x64.bin
##按yes，按enter
[root@Amo local]# mv jdk1.6.0_14/ /usr/local/jdk1.6 #将jdk目录重命名
#添加环境变量
[root@Amo local]# vim /etc/profile
export JAVA_HOME=/usr/local/jdk1.6
export CLASSPATH=.:$JAVA_HOME/lib:$JAVA_HOME/jre/lib
export PATH=$JAVA_HOME/bin:$JAVA_HOME/jre/bin:$PATH
export AMOEBA_HOME=/usr/local/amoeba
export PATH=$PATH:$AMOEBA_HOME/bin
[root@Amo local]# source /etc/profile #刷新文件，使立即生效
[root@Amo local]# java -version #查看jdk版本
Instalar el software Amoeba
-------1、安装 Amoeba软件---------
#创建Amoeba的解压目录
[root@Amo ~]# mkdir /usr/local/amoeba/
#将Amoeba安装包上传到/opt/目录，解压安装包
[root@Amo opt]# cd /opt/
[root@Amo opt]# tar zxvf amoeba-mysql-binary-2.2.0.tar.gz -C /usr/local/amoeba/
#增加目录权限
[root@Amo opt]# chmod -R 755 /usr/local/amoeba/
#开启Amoeba
[root@Amo opt]# /usr/local/amoeba/bin/amoeba #如显示amoeba start|stop说明安装成功
-------2、配置 Amoeba读写分离，两个 Slave 读负载均衡----------
#先在Master、Slave1、Slave2 的mysql上开放权限给 Amoeba 访问。注意：这里授权的用户名和密码，会在下一步写入数据库配置文件。
grant all on *.* to yuji@'192.168.137.%' identified by '123123';
#再回到amoeba服务器配置amoeba服务：
[root@Amo opt]# cd /usr/local/amoeba/conf/
#备份配置文件，修改amoeba配置文件
[root@Amo conf]# cp amoeba.xml amoeba.xml.bak
[root@Amo conf]# vim amoeba.xml
--30行--
<property name="user">amoeba</property> #30行和32行，授权客户端用于登录amoeba的账号和密码
--32行--
<property name="password">123456</property>
--115行--
<property name="defaultPool">master</property> #设置默认服务器池
--117-去掉注释-
<property name="writePool">master</property> #定义写的服务器池名称
<property name="readPool">slaves</property> #定义读的服务器池名称
#备份数据库配置文件，之后修改数据库配置文件dbServers.xml
[root@Amo conf]# cp dbServers.xml dbServers.xml.bak
[root@Amo conf]# vim dbServers.xml
--23行--注释掉 作用：默认进入test库，注释掉以防mysql中没有test库时，会报错
<!-- <property name="schema">test</property> -->
##26-30行，此用户就是之前在3台主从服务器上授权的用户，授权amoeba服务器用来登录mysql数据库的用户和密码。
--26行--修改
<property name="user">yuji</property>
--28-30行--去掉注释
<property name="password">123123</property>
--45行--修改，设置主服务器的名称master和地址
<dbServer name="master" parent="abstractServer">
--48行--修改，设置主服务器的地址
<property name="ipAddress">192.168.137.50</property>
--52行--修改，设置从服务器1的名称slave1
<dbServer name="slave1" parent="abstractServer">
--55行--修改，设置从服务器1的地址
<property name="ipAddress">192.168.137.60</property>
--58行--复制上面6行粘贴，设置从服务器2的名称slave2和地址
<dbServer name="slave2" parent="abstractServer">
<property name="ipAddress">192.168.137.70</property>
--65行--修改
<dbServer name="slaves" virtual="true">
--71行--修改
<property name="poolNames">slave1,slave2</property>
[root@Amo conf]# /usr/local/amoeba/bin/amoeba start & #后台启动Amoeba软件，按ctrl+c 返回
[root@Amo conf]# netstat -anpt | grep java #查看8066端口是否开启，默认端口为TCP 8066
El cliente instala la base de datos mariadb
[root@ ~]# yum install -y mariadb-server mariadb #安装mariadb数据库
[root@ ~]# systemctl start mariadb.service #启动mariadb
#客户端通过amoeba服务器登录数据库，之后向库中写入数据：
mysql -u amoeba -pabc123 -h 192.168.137.50 -P8066
use yuji666;
create table class(id int,name char(10));
#通过amoeba服务器代理访问mysql ，再通过客户端连接mysql后写入的数据只有主服务会记录，然后同步给从--从服务器
Prueba de separación de lectura y escritura
//在两台slave服务器上，关闭同步：
stop slave; #关闭同步
use yuji666;
//在slave1上写入数据：
insert into class values('1','zhangsan');
//在slave2上写入数据：
insert into class values('2','lisi');
//在master服务器上写入数据：
insert into class values('3','wangwu');
//在客户端上查看数据：
use yuji666;
select * from class;
#客户端会分别向slave1和slave2读取数据（轮询），显示的只有在两个从服务器上添加的数据，没有在主服务器上添加的数据。说明读写是分离的，只从slave中读取数据。
insert into class values('4','qianqi',); //客户端插入数据，只有主服务器上有此数据
//在两个从服务器上执行 start slave; 即可实现同步主服务器中添加的数据
start slave; #开启同步
select * from class;
Resumen clave:
El proceso de trabajo de la replicación maestro-esclavo
El nodo maestro debe habilitar el registro binario y el nodo esclavo debe habilitar el registro de retransmisión.
(1) El nodo maestro registra los cambios de datos en un registro binario (registro bin) Cuando los datos en el maestro cambian (adición, eliminación, modificación), el cambio se escribe en el registro binario.
(2) El nodo esclavo detectará si el registro binario del maestro ha cambiado dentro de un cierto intervalo de tiempo y, si cambia, iniciará un subproceso de E/S para solicitar el evento binario del maestro. (solicitar datos binarios)
(3) Al mismo tiempo, el nodo maestro inicia un subproceso de volcado para cada subproceso de E/S , que se utiliza para enviarle eventos binarios y lo guarda en el registro de retransmisión local (registro de retransmisión ) del nodo esclavo. El nodo esclavo iniciará el subproceso SQL desde él Después de leer los eventos binarios en el registro, reprodúzcalos localmente, es decir, analícelos en declaraciones SQL y ejecútelos uno por uno, de modo que los datos sean consistentes con los del nodo maestro. Finalmente, el subproceso de E/S y el subproceso de SQL se dormirán y esperarán la próxima activación.
Aviso:
- Los registros de retransmisión generalmente se encuentran en la memoria caché del sistema operativo, por lo que la sobrecarga de los registros de retransmisión es pequeña.
- El proceso de replicación tiene una limitación muy importante, es decir, la replicación se serializa en el Esclavo, es decir, la operación de actualización en paralelo en el Maestro no se puede operar en paralelo en el Esclavo.
- Para la replicación semisíncrona, habrá un subproceso de confirmación de acuse de recibo adicional (subproceso de recopilación de acuse de recibo), que se usa especialmente para recibir información de retroalimentación del esclavo (recopilar la información de acuse de recibo devuelta por el nodo esclavo).
2. Solución a la inconsistencia de datos maestro-esclavo de la base de datos
Método 1: después de ignorar el error, continúe sincronizando
- Este método es adecuado para la situación en la que los datos de la base de datos maestra-esclava no son muy diferentes, o no se requiere que los datos estén completamente unificados, y los requisitos de datos no son estrictos.
Método 2: rehacer maestro-esclavo, sincronización completa
- Este método es adecuado para situaciones en las que los datos de la base de datos maestro-esclavo difieren mucho o se requiere que los datos estén completamente unificados.
3. ¿Cómo garantizar la sincronización de datos después de que mysql se reanude desde el servidor?
- Método físico: sincronización de archivos de disco rsync. Para usar la recuperación de archivos, el nodo principal debe detener el servicio.
- Replicación maestro-esclavo: elimine la biblioteca original del nodo esclavo y vuelva a realizar la replicación maestro-esclavo a través del desplazamiento.
4. ¿En qué circunstancias se reducirá la replicación semisincrónica a replicación asíncrona? ¿Cuándo se reanudará la replicación síncrona?
- Cuando se agote el tiempo de espera de la replicación semisíncrona (controlado por el parámetro rpl_semi_sync_master_timeout, el valor predeterminado es 10000 ms, es decir, 10 s), la replicación semisíncrona se cerrará temporalmente y se utilizará en su lugar la replicación asíncrona, es decir, se reducirá automáticamente a trabajo asincrónico.
- Después de que el subproceso de volcado de malster envía todos los eventos de una transacción, si recibe una respuesta de la biblioteca esclava dentro del tiempo de espera de rpl_ semi_sync_master_, el maestro-esclavo reanuda la replicación semisíncrona.
5. Razones del retraso de la replicación maestro-esclavo de MySQL y métodos de optimización
Motivos del retraso de la replicación maestro-esclavo:
- El servidor maestro tiene una alta concurrencia y forma una gran cantidad de transacciones.
- Latencia de conexion.
- Causado por dispositivos de hardware maestro-esclavo (frecuencia principal de CPU, E/S de memoria, E/S de disco duro).
- Es replicación síncrona, no replicación asíncrona.
Mejoramiento:
- Optimice los parámetros de Mysql desde la biblioteca. Por ejemplo, aumente innodb_buffer_pool_size para permitir que se completen más operaciones en la memoria Mysql y reduzca las operaciones de disco.
- Utilice un host de alto rendimiento de la biblioteca. Incluye potente cpu, mayor memoria. Evite el uso de hosts de nube virtual y use hosts físicos, lo que mejora el rendimiento de E/S.
- Utilice el disco SSD de la biblioteca.
- Optimización de la red para evitar la sincronización entre salas de ordenadores.
6. Precauciones
- Cada maestro puede tener varios esclavos.
- Cada esclavo solo puede tener un maestro.
-
Cada esclavo solo puede tener una ID de servidor única (ID de servidor).
-
El maestro debe habilitar la función de registro binario binlog; por lo general, para la seguridad de los datos, el esclavo también habilita la función binlog.