Backups en un Cluster MySQL (PXC 5.6)

datacenterDespués de montar un clúster PXC o Galera Cluster (versión 5.6 en servidores CentOS 6.5), igualmente querremos hacer backups de nuestros datos. Para ello, bastará con realizar un backup de uno de los nodos, puesto que todos los nodos contendrán exactamente la misma información. Aunque en realidad no es tan fácil…

Problemas con los backups en un cluster Galera

Hemos de tener en cuenta que los backups, en algún punto, realizarán un FLUSH TABLES WITH READ LOCK, que hará que ese nodo no permita escrituras y por tanto, no se podrán realizar escrituras en el cluster durante ese tiempo [Fuente 1 y Fuente 2]. La explicación es que una escritura al cluster devolverá ok cuando se haya replicado a todos los nodos del mismo. Por tanto, si un nodo no puede escribir, todo el cluster no podrá escribir.

A ésto hay que sumarle que por defecto un backup en PXC/Galera no guardará los «Global Transaction ID«, necesarios para poder dar de alta nuevos nodos de forma rápida (ahorrándonos el SST inicial) a raíz de ese backup. [Fuente, transp. 44]

Continuar leyendo «Backups en un Cluster MySQL (PXC 5.6)»

Instalar y configurar MySQL Percona XtraDB Clúster

clusterPercona XtraDB Clúster, es la solución de alta disponibilidad y balanceo de carga multi-máster del fork de MySQL «Percona». La solución recomendada para un cluster necesita un mínimo de 3 nodos, pero siempre un número impar de nodos. En este post, sin embargo, montaremos un cluster Percona con 2 nodos y un árbitro -todo con Percona XtraDB Cluster 5.5 y wsrep_provider_version 2.6(r152)- puesto que supondremos que únicamente disponemos de dos servidores dedicados para el clúster. Más adelante se explicará qué es y para qué sirve un árbitro.

Percona Master-Slave vs XtraDB Clúster

Master-slave consta de un único servidor que permite escrituras, mientras que resto de nodos (slaves) únicamente permiten lecturas. Los slaves replicarán los datos del único master, y se mantendrá así los mismos datos en todos los nodos de la solución. En este caso, si se dispone de un balanceador para los slaves, tendremos un balanceo de carga para las lecturas, lo cual hace de esta solución una solución ideal para entornos con un alto volumen de lecturas. Además, se conseguirá un entorno de alta disponibilidad para las lecturas, pero no así para las escrituras.

Con XtraDB Clúster tendremos múltiples servidores corriendo varios MySQL (basados en Percona) con los mismos datos, permitiendo a los clientes escribir en cualquiera de los servidores, y replicando los datos al resto de nodos del clúster. Ésto es ideal para entornos donde hay un gran volumen de escrituras, pero también de lecturas, o donde necesitemos tener alta disponibilidad, también de los nodos «master» (que permiten escrituras).

Limitaciones

Percona XtraDB Cluster, está basado en Galera Cluster (igual que MariaDB Cluster), y por tanto, a día de hoy, tiene un seguido de limitaciones  de entre las que destacan:

  • La replicación sólo funcionará con las tablas InnoDB. Puede haber otras tablas pero no se replicarán, lo cual significa que no se encontrarán en todo el clúster, únicamente existirán en ese nodo.
  • La velocidad de escritura de todo el clúster, viene delimitado por el nodo más lento. Si un nodo tiene problemas y se vuelve lento, el clúster entero será lento.
  • Puede darse el caso de que dos clientes estén modificando la misma celda al mismo tiempo. Si ésto ocurriera, únicamente uno de los dos tendría éxito, mientras que el otro recibiría un error de MySQL.
  • Se recomienda un mínimo de 3 nodos, aunque en la documentación oficial también confirman que se puede montar con 2 nodos. En entornos con dos nodos es altamente recomendable montar un árbitro (que es lo que haremos).
  • Ver listado completo.

Continuar leyendo «Instalar y configurar MySQL Percona XtraDB Clúster»