sql >> Base de Datos >  >> RDS >> MariaDB

Sugerencias para migrar de MySQL Replication a MySQL Galera Cluster 4.0

Anteriormente escribimos en un blog sobre las novedades de MySQL Galera Cluster 4.0, el manejo de grandes transacciones con Streaming Replication y MariaDB 10.4 y presentamos algunas guías sobre el uso de la nueva función de Streaming Replication en una serie de partes 1 y 2.

Mover su tecnología de base de datos de MySQL Replication a MySQL Galera Cluster requiere que tenga las habilidades adecuadas y una comprensión de lo que está haciendo para tener éxito. En este blog, compartiremos algunos consejos para migrar de una configuración de replicación de MySQL a una de MySQL Galera Cluster 4.0.

Las diferencias entre la replicación de MySQL y Galera Cluster

Si aún no está familiarizado con Galera, le sugerimos que revise nuestro Tutorial de Galera Cluster para MySQL. Galera Cluster utiliza un nivel de replicación completamente diferente basado en la replicación sincrónica, en contraste con MySQL Replication, que utiliza la replicación asíncrona (pero también se puede configurar para lograr una replicación semisincrónica).

Galera Cluster también es compatible con la replicación multimaestro. Es capaz de aplicar en paralelo sin restricciones (es decir, "replicación en paralelo"), replicación de multidifusión y aprovisionamiento automático de nodos.

El enfoque principal de Galera Cluster es la consistencia de los datos, mientras que con la replicación de MySQL, es propenso a la inconsistencia de los datos (que se puede evitar con las mejores prácticas y una configuración adecuada, como imponer solo lectura en los esclavos para evitar escrituras no deseadas dentro de los esclavos).

Aunque las transacciones recibidas por Galera se aplican a todos los nodos o no se aplican en absoluto, cada uno de estos nodos certifica el conjunto de escritura replicado en la cola del aplicador (confirmaciones de transacciones) que también incluye información sobre todas las bloqueos retenidos por la base de datos durante la transacción. Estos conjuntos de escritura, una vez que no se identifican bloqueos en conflicto, se aplican. Hasta este punto, las transacciones se consideran comprometidas y continúa aplicándolas al tablespace. A diferencia de la replicación asíncrona, este enfoque también se denomina replicación virtualmente síncrona, ya que las escrituras y las confirmaciones ocurren en un modo lógico síncrono, pero la escritura y la confirmación reales en el tablespace ocurren de forma independiente y son asíncronos en cada nodo.

A diferencia de la replicación de MySQL, un clúster de Galera es un verdadero esclavo multimaestro y multiproceso, un modo de espera en caliente puro, sin necesidad de conmutación por error maestra o división de lectura y escritura. Sin embargo, migrar a Galera Cluster no significa una respuesta automática a sus problemas. Galera Cluster solo admite InnoDB, por lo que podría haber modificaciones de diseño si está utilizando MyISAM o motores de almacenamiento de memoria.

Conversión de tablas que no son de InnoDB a InnoDB

Galera Cluster le permite usar MyISAM, pero esto no es para lo que fue diseñado Galera Cluster. Galera Cluster está diseñado para implementar estrictamente la consistencia de datos dentro de todos los nodos dentro del clúster y esto requiere un motor de base de datos compatible con ACID. InnoDB es un motor que tiene capacidades sólidas en esta área y se recomienda que use InnoDB; especialmente cuando se trata de transacciones.

Si está utilizando ClusterControl, puede beneficiarse fácilmente para determinar su(s) instancia(s) de base de datos para cualquier tabla MyISAM proporcionada por Performance Advisors. Puede encontrar esto en la pestaña Rendimiento → Asesores. Por ejemplo,

Si necesita tablas MyISAM y MEMORY, aún puede usarlas pero Asegúrese de que sus datos no necesitan ser replicados. Puede usar sus datos almacenados para solo lectura y usar "INICIAR TRANSACCIÓN DE SÓLO LECTURA" cuando corresponda.

Agregar claves primarias a sus tablas InnoDB

Dado que Galera Cluster solo es compatible con InnoDB, es muy importante que todas sus tablas tengan un índice agrupado (también llamado clave principal o clave única). Para obtener el mejor rendimiento de las consultas, inserciones y otras operaciones de la base de datos, es muy importante que defina cada tabla con una(s) clave(s) única(s), ya que InnoDB usa el índice agrupado para optimizar las operaciones de búsqueda y DML más comunes para cada tabla. . Esto ayuda a evitar consultas de ejecución prolongada dentro del clúster y puede ralentizar las operaciones de lectura/escritura en el clúster.

En ClusterControl, hay asesores que pueden avisarle de esto. Por ejemplo, en su clúster maestro/esclavo de replicación de MySQL, verá una alarma o una vista de la lista de asesores. La siguiente captura de pantalla de ejemplo revela que no tiene tablas que no tengan clave principal:

Identificar un nodo maestro (o escritor activo)

Galera Cluster es puramente una verdadera replicación multimaestro. Sin embargo, eso no significa que todos sean libres de escribir cualquier nodo al que les gustaría apuntar. Una cosa que debe identificar es que, al escribir en un nodo diferente y se detectará una transacción en conflicto, tendrá un problema de interbloqueo como se muestra a continuación:

2019-11-14T21:14:03.797546Z 12 [Note] [MY-011825] [InnoDB] *** Priority TRANSACTION:

TRANSACTION 728431, ACTIVE 0 sec starting index read

mysql tables in use 1, locked 1

MySQL thread id 12, OS thread handle 140504401893120, query id 1414279 Applying batch of row changes (update)

2019-11-14T21:14:03.797696Z 12 [Note] [MY-011825] [InnoDB] *** Victim TRANSACTION:

TRANSACTION 728426, ACTIVE 3 sec updating or deleting

mysql tables in use 1, locked 1

, undo log entries 11409

MySQL thread id 57, OS thread handle 140504353195776, query id 1414228 localhost root updating

update sbtest1_success set k=k+1 where id > 1000 and id < 100000

2019-11-14T21:14:03.797709Z 12 [Note] [MY-011825] [InnoDB] *** WAITING FOR THIS LOCK TO BE GRANTED:

RECORD LOCKS space id 1663 page no 11 n bits 144 index PRIMARY of table `sbtest`.`sbtest1_success` trx id 728426 lock_mode X

Record lock, heap no 1 PHYSICAL RECORD: n_fields 1; compact format; info bits 0

 0: len 8; hex 73757072656d756d; asc supremum;;

El problema con la escritura de múltiples nodos sin identificar un nodo de escritor activo actual, terminará con estos problemas que son problemas muy comunes que he visto al usar Galera Cluster al escribir en múltiples nodos en al mismo tiempo. Para evitar esto, puede utilizar el enfoque de configuración de maestro único:

De la documentación,

Para relajar el control de flujo, puede usar la siguiente configuración:

wsrep_provider_options = "gcs.fc_limit = 256; gcs.fc_factor = 0.99; gcs.fc_master_slave = YES"

Lo anterior requiere reiniciar el servidor ya que fc_master_slave no es dinámico.

Habilitar el modo de depuración para registrar conflictos o interbloqueos

La depuración o el rastreo de problemas con su Galera Cluster es muy importante. Los bloqueos en Galera se implementan de manera diferente en comparación con la replicación de MySQL. Utiliza el bloqueo optimista cuando se trata de transacciones en todo el clúster. A diferencia de la replicación de MySQL, solo tiene un bloqueo pesimista que no sabe si se está ejecutando una transacción similar o conflictiva en un co-maestro en una configuración de múltiples maestros. Galera aún usa el bloqueo pesimista, pero en el nodo local, ya que lo administra InnoDB, que es el motor de almacenamiento compatible. Galera usa el bloqueo optimista cuando va a otros nodos. Esto significa que no se realizan comprobaciones con otros nodos del clúster cuando se obtienen bloqueos locales (bloqueo pesimista). Galera asume que, una vez que la transacción pasa la fase de compromiso dentro del motor de almacenamiento y se informa a los otros nodos, todo estará bien y no surgirán conflictos.

En la práctica, es mejor habilitar wsrep_logs_conflicts. Esto registrará los detalles de MDL en conflicto, así como los bloqueos de InnoDB en el clúster. La habilitación de esta variable se puede configurar dinámicamente, pero tenga cuidado una vez que esté habilitada. Completará detalladamente su archivo de registro de errores y puede llenar su disco una vez que el tamaño del archivo de registro de errores sea demasiado grande.

Tenga cuidado con sus consultas DDL

A diferencia de la replicación de MySQL, la ejecución de una declaración ALTER puede afectar solo las conexiones entrantes que requieren acceder o hacer referencia a la tabla objetivo de su declaración ALTER. También puede afectar a los esclavos si la tabla es grande y puede provocar un retraso del esclavo. Sin embargo, las escrituras en su maestro no se bloquearán siempre que sus consultas no entren en conflicto con el ALTER actual. Sin embargo, este no es el caso cuando se ejecutan instrucciones DDL como ALTER con Galera Cluster. Las declaraciones ALTER pueden generar problemas, como que Galera Cluster se atasque debido a un bloqueo en todo el clúster o que el control de flujo comience a relajar la replicación mientras algunos nodos se están recuperando de escrituras grandes.

En algunas situaciones, es posible que termine teniendo tiempo de inactividad en su Galera Cluster si esa tabla es demasiado grande y es una tabla principal y vital para su aplicación. Sin embargo, se puede lograr sin tiempo de inactividad. Como señaló Rick James en su blog, puedes seguir las siguientes recomendaciones:

RSU frente a TOI

  • Actualización continua del esquema =hacer manualmente un nodo (fuera de línea) a la vez
  • Aislamiento de pedido total =Galera sincroniza para que se realice al mismo tiempo (en la secuencia de replicación) en todos los nodos. RSU y TOI

Precaución:dado que no hay forma de sincronizar los clientes con el DDL, debe asegurarse de que los clientes estén satisfechos con el esquema antiguo o el nuevo. De lo contrario, es probable que deba eliminar todo el clúster mientras cambia simultáneamente el esquema y el código del cliente.

También se puede realizar un DDL "rápido" a través de TOI. Esta es una lista tentativa de tales:

  • CREAR/SOLTAR/CAMBIAR NOMBRE DE LA BASE DE DATOS/TABLA
  • ALTER para cambiar PREDETERMINADO
  • ALTER para cambiar la definición de ENUM o SET (ver advertencias en el manual)
  • Ciertos ALTER DE PARTICIÓN que son rápidos.
  • DROP INDEX (diferente a PRIMARY KEY)
  • ¿AGREGAR ÍNDICE?
  • Otros ALTER en tablas 'pequeñas'.
  • Con 5.6 y especialmente 5.7 con muchos casos ALTER ALGORITHM=INPLACE, verifique qué ALTER se deben hacer de qué manera.

De lo contrario, utilice RSU. Haga lo siguiente por separado para cada nodo:

SET GLOBAL wsrep_OSU_method='RSU';

Esto también saca el nodo del clúster.

ALTER TABLE
SET GLOBAL wsrep_OSU_method='TOI';

Se vuelve a colocar, lo que lleva a la resincronización (con suerte, una IST rápida, no una SST lenta)

Preserve la consistencia de su clúster

Galera Cluster no admite filtros de replicación como binlog_do_db o binlog_ignore_db ya que Galera no depende del registro binario. Se basa en el archivo de búfer de anillo, también llamado GCache, que almacena conjuntos de escritura que se replican a lo largo del clúster. No puede aplicar ningún comportamiento o estado incoherente de dichos nodos de base de datos.

Galera, por otro lado, implementa estrictamente la coherencia de datos dentro del clúster. Todavía es posible que pueda haber incoherencias donde no se pueden encontrar filas o registros. Por ejemplo, configurar su variable wsrep_OSU_method ya sea RSU o TOI para sus declaraciones DDL ALTER puede generar un comportamiento inconsistente. Consulte este blog externo de Percona que analiza la inconsistencia con Galera con TOI vs RSU.

Configurar wsrep_on=OFF y luego ejecutar consultas DML o DDL puede ser peligroso para su clúster. También debe revisar sus procedimientos almacenados, disparadores, funciones, eventos o vistas si los resultados no dependen del estado o entorno de un nodo. Cuando cierto(s) nodo(s) puede(n) ser inconsistente(s), potencialmente puede hacer que todo el clúster se caiga. Una vez que Galera detecta un comportamiento incoherente, Galera intentará abandonar el clúster y finalizar ese nodo. Por lo tanto, es posible que todos los nodos sean inconsistentes, dejándolo en un estado de dilema.

Si un nodo de Galera Cluster también experimenta un bloqueo, especialmente en un período de mucho tráfico, es mejor no iniciar el nodo de inmediato. En su lugar, realice un SST completo o traiga una nueva instancia lo antes posible o una vez que el tráfico sea bajo. Es posible que el nodo traiga un comportamiento inconsistente que podría haber dañado los datos.

Segregar transacciones grandes y determinar si se debe usar la replicación de transmisión 

Vamos directo a esto. Una de las características de cambios más grandes, especialmente en Galera Cluster 4.0, es la replicación de transmisión. Las versiones anteriores de Galera Cluster 4.0 limitan las transacciones <2GiB, que normalmente se controlan mediante las variables wsrep_max_ws_rows y wsrep_max_ws_size. Desde Galera Cluster 4.0, puede enviar> 2GiB de transacciones, pero debe determinar el tamaño de los fragmentos que deben procesarse durante la replicación. Debe configurarse por sesión y las únicas variables que debe tener en cuenta son wsrep_trx_fragment_unit y wsrep_trx_fragment_size. Deshabilitar Streaming Replication es simple, ya que configurar wsrep_trx_fragment_size =0 lo hará. Tenga en cuenta que la replicación de una transacción grande también conlleva una sobrecarga en los nodos esclavos (nodos que se replican contra el nodo maestro/escritor activo actual) ya que los registros se escribirán en la tabla wsrep_streaming_log en la base de datos MySQL.

Otra cosa para agregar, ya que se trata de una transacción grande, es considerable que su transacción pueda tardar algún tiempo en finalizar, por lo que debe tenerse en cuenta la configuración alta de la variable innodb_lock_wait_timeout. Establezca esto a través de la sesión según el tiempo que estime, pero más grande que el tiempo que estima que terminará; de lo contrario, genere un tiempo de espera.

Le recomendamos que lea este blog anterior sobre la replicación de transmisión en acción.

Replicación de declaraciones GRANT

Si está utilizando GRANT y operaciones relacionadas, actúe sobre las tablas MyISAM/Aria en la base de datos `mysql`. Las instrucciones GRANT se replicarán, pero las tablas subyacentes no. Esto significa que INSERT INTO mysql.user... no se replicará porque la tabla es MyISAM.

Sin embargo, es posible que lo anterior ya no sea cierto ya que Percona XtraDB Cluster (PXC) 8.0 (actualmente experimental) ya que las tablas de esquema mysql se han convertido a InnoDB, mientras que en MariaDB 10.4, algunas de las tablas todavía están en formato Aria pero otros están en CSV o InnoDB. Debe determinar qué versión y proveedor de Galera tiene, pero es mejor evitar el uso de declaraciones DML que hagan referencia al esquema mysql. De lo contrario, podría obtener resultados inesperados a menos que esté seguro de que se trata de PXC 8.0.

Las transacciones XA, BLOQUEAR/DESBLOQUEAR TABLAS, GET_LOCK/RELEASE_LOCK no son compatibles

Galera Cluster no admite transacciones XA, ya que las transacciones XA manejan la reversión y las confirmaciones de manera diferente. Las declaraciones LOCK/UNLOCK o GET_LOCK/RELEASE_LOCK son peligrosas para ser aplicadas o utilizadas con Galera. Es posible que experimente un bloqueo o bloqueos que no se pueden eliminar y permanecen bloqueados. Por ejemplo,

---TRANSACTION 728448, ACTIVE (PREPARED) 13356 sec

mysql tables in use 2, locked 2

3 lock struct(s), heap size 1136, 5 row lock(s), undo log entries 5

MySQL thread id 67, OS thread handle 140504353195776, query id 1798932 localhost root wsrep: write set replicated and certified (13)

insert into sbtest1(k,c,pad) select k,c,pad from sbtest1_success limit 5

Esta transacción ya se desbloqueó e incluso se eliminó, pero fue en vano. Le sugerimos que tenga que rediseñar su aplicación cliente y deshacerse de estas funciones al migrar a Galera Cluster.

¡La estabilidad de la red es IMPRESCINDIBLE!

Galera Cluster puede funcionar incluso con topología inter-WAN o topología intergeográfica sin ningún problema (consulte este blog sobre la implementación de topología intergeográfica con Galera). Sin embargo, si la conectividad de su red entre cada nodo no es estable o se cae intermitentemente por un tiempo insospechado, puede ser problemático para el clúster. Es mejor que tenga un clúster ejecutándose en una red privada y local donde cada uno de estos nodos esté conectado. Cuando diseñe un nodo como una recuperación ante desastres, planee crear un clúster si se encuentran en una región o geografía diferente. Puede comenzar a leer nuestro blog anterior, Uso de la replicación de clúster de MySQL Galera para crear un clúster distribuido geográficamente:primera parte, ya que esto podría ayudarlo a decidir mejor su topología de clúster de Galera.

Otra cosa que agregar sobre la inversión en el hardware de su red, sería problemático si la tasa de transferencia de su red le brinda una velocidad más baja durante la reconstrucción de una instancia durante IST o peor en SST, especialmente si su conjunto de datos es masivo . Puede tomar muchas horas de transferencia de red y eso podría afectar la estabilidad de su clúster, especialmente si tiene un clúster de 3 nodos mientras que 2 nodos no están disponibles donde estos 2 son un donante y un ensamblador. Tenga en cuenta que, durante la fase SST, los nodos DONOR/JOINER no se pueden usar hasta que finalmente se puedan sincronizar con el clúster principal.

En la versión anterior de Galera, cuando se trataba de la selección de nodos donantes, el donante State Snapshot Transfer (SST) se seleccionaba al azar. En Glera 4, ha mejorado mucho más y tiene la capacidad de elegir el donante correcto dentro del clúster, ya que favorecerá a un donante que pueda proporcionar una transferencia de estado incremental (IST) o elegir un donante en el mismo segmento. Alternativamente, puede establecer la variable wsrep_sst_donor en el donante correcto que le gustaría elegir siempre.

Copia de seguridad de sus datos y realización de pruebas estrictas durante la migración y antes de la producción

Una vez que esté preparado y haya decidido intentar migrar sus datos a Galera Cluster 4.0, asegúrese de tener siempre su copia de seguridad preparada. Si probó ClusterControl, hacer copias de seguridad será más fácil.

Asegúrese de que está migrando a la versión correcta de InnoDB y no olvide siempre aplicar y ejecutar mysql_upgrade antes de realizar la prueba. Asegúrese de que todas sus pruebas superen el resultado deseado que la replicación de MySQL puede ofrecerle. Lo más probable es que no haya ninguna diferencia entre el motor de almacenamiento InnoDB que está utilizando en un clúster de replicación de MySQL en comparación con el clúster de Galera de MySQL, siempre que las recomendaciones y los consejos se hayan aplicado y preparado de antemano.

Conclusión

Es posible que la migración a Galera Cluster 4.0 no sea la solución de tecnología de base de datos deseada. Sin embargo, no lo alejará de utilizar Galera Cluster 4.0 siempre que se puedan preparar, configurar y proporcionar sus requisitos específicos. Galera Cluster 4.0 ahora se ha convertido en una opción viable muy poderosa, especialmente en una plataforma y solución de alta disponibilidad. También le sugerimos que lea estos blogs externos sobre las advertencias de Galera o las limitaciones de Galera Cluster o este manual de MariaDB.