La versión más reciente de MariaDB 10.4 es:
MariaDB 10.4.8 Descargar ahora
Descarga alternativa de mariadb.org

La versión más reciente de MariaDB 10.3 es:
MariaDB 10.3.18 Estable (GA) Descargar ahora
Descarga alternativa de mariadb.org

Las versiones actuales de la biblioteca de proveedores de wsrep de Galera son 26.4.2 para Galera 4 y 25.3.27 para Galera 3.
Para mayor comodidad, los paquetes que contienen estas bibliotecas se incluyen en MariaDB Repositorios de YUM y APT.

Actualmente, MariaDB Galera Cluster solo es compatible con el motor de almacenamiento InnoDB.

Un gran recurso para los usuarios de Galera es la lista de correo administrada por los desarrolladores de Codership. Se puede encontrar en Codificación en Grupos de Google. Si usa Galera, se recomienda que se suscriba.

Soporte de clúster de Galera en MariaDB Server

MariaDB Galera Cluster funciona con:

En MariaDB 10.1 y posteriores, el MySQL-wsrep El parche se ha fusionado con MariaDB Server. Esto significa que la funcionalidad de MariaDB Galera Cluster se puede obtener instalando los paquetes estándar de MariaDB Server y el Biblioteca de proveedores de wsrep de Galera paquete. La siguiente versión de Galera corresponde a cada versión de MariaDB Server:

Ver Descifrando los números de versión de Galera para obtener más información sobre cómo interpretar estos números de versión.

Consulte ¿Qué es MariaDB Galera Cluster ?: Versiones de Galera para obtener más información sobre qué versión específica de Galera se incluye en cada versión de MariaDB Server.

En las compilaciones admitidas, la funcionalidad de Galera Cluster se puede habilitar configurando algunas opciones de configuración que se mencionan a continuación. La funcionalidad de Galera Cluster no está habilitada en una instalación estándar de MariaDB Server a menos que esté explícitamente habilitada con estas opciones de configuración.

Prerrequisitos

Requisitos de tamaño de intercambio

Durante el funcionamiento normal, un nodo MariaDB Galera no consume mucha más memoria que un servidor MariaDB normal. Se consume memoria adicional para el índice de certificación y los conjuntos de escritura no confirmados, pero normalmente esto no debería notarse en una aplicación típica. Sin embargo, hay una excepción:

  1. Almacenamiento en caché de conjuntos de escritura durante la transferencia de estado. Cuando un nodo recibe una transferencia de estado, no puede procesar y aplicar escrituras entrantes porque todavía no tiene un estado al que aplicarlas. Dependiendo de un mecanismo de transferencia de estado (por ejemplo, mysqldump), es posible que el nodo que envía la transferencia de estado no pueda aplicar escrituras también. Por lo tanto, necesitan almacenar en caché esos conjuntos de escritura para una fase de actualización. Actualmente, las escrituras se almacenan en caché en la memoria y, si el sistema se queda sin memoria, la transferencia de estado fallará o el clúster se bloqueará esperando a que finalice la transferencia de estado.

Para controlar el uso de la memoria para el almacenamiento en caché de conjuntos de escritura, Parámetros de galera: gcs.recv_q_hard_limit, gcs.recv_q_soft_limit, y gcs.max_throttle.

Limitaciones

Antes de usar MariaDB Galera Cluster, recomendamos leer las limitaciones conocidas, para que pueda estar seguro de que es apropiado para su aplicación.

Instalación de MariaDB Galera Cluster

Para usar MariaDB Galera Cluster, hay dos paquetes principales que necesita instalar:

  1. Una versión de MariaDB Server que admita Galera Cluster.
  1. La biblioteca del proveedor de wsrep de Galera.

Como se mencionó en la sección anterior, en MariaDB 10.1 y superior, el soporte de Galera Cluster está incluido en los paquetes estándar de MariaDB Server. Eso significa que instalar el paquete MariaDB Galera Cluster es lo mismo que instalar el paquete MariaDB Server estándar en esas versiones. Sin embargo, también tendrá que instalar un paquete adicional para obtener la biblioteca del proveedor de wsrep de Galera.

Algunos métodos SST también pueden requerir la instalación de paquetes adicionales. los mariabackup El método SST es generalmente la mejor opción para clústeres grandes que esperan mucha carga.

Instalación de MariaDB Galera Cluster con un administrador de paquetes

MariaDB Galera Cluster se puede instalar a través de un administrador de paquetes en Linux. Para hacerlo, su sistema debe estar configurado para instalar desde uno de los repositorios de MariaDB.

Puede configurar su administrador de paquetes para instalarlo desde el repositorio de paquetes MariaDB de MariaDB Corporation utilizando el script de configuración del repositorio de paquetes MariaDB.

También puede configurar su administrador de paquetes para instalarlo desde MariaDB Foundation’s MariaDB Repository usando el Herramienta de configuración del repositorio MariaDB.

Instalación de MariaDB Galera Cluster con yum / dnf

En RHEL, CentOS, Fedora y otras distribuciones de Linux similares, se recomienda encarecidamente instalar los paquetes RPM relevantes del repositorio de MariaDB utilizando yum o dnf. Comenzando con RHEL 8 y Fedora 22, yum ha sido reemplazado por dnf, que es la próxima versión principal de yum. Sin embargo, yum los comandos todavía funcionan en muchos sistemas que utilizan dnf.

Para instalar MariaDB Galera Cluster con yum o dnf, siga las instrucciones en Instalación de MariaDB Galera Cluster con yum.

Instalación de MariaDB Galera Cluster con apt-get

En Debian, Ubuntu y otras distribuciones de Linux similares, se recomienda encarecidamente instalar los paquetes DEB relevantes del repositorio de MariaDB usando apt-get.

Para instalar MariaDB Galera Cluster con apt-get, siga las instrucciones en Instalación de MariaDB Galera Cluster con apt-get.

Instalación de MariaDB Galera Cluster con zypper

En SLES, OpenSUSE y otras distribuciones de Linux similares, se recomienda encarecidamente instalar los paquetes RPM relevantes del repositorio de MariaDB utilizando zypper.

Para instalar MariaDB Galera Cluster con zypper, siga las instrucciones en Instalación de MariaDB Galera Cluster con ZYpp.

Instalación de MariaDB Galera Cluster con un Tarball binario

Para instalar MariaDB Galera Cluster con un tarball binario, siga las instrucciones en Instalar MariaDB Binary Tarballs.

Clúster MariaDB Galera a partir de 10.0.24

Para hacer la ubicación del libgalera_smm.so biblioteca en archivos tar binarios más similar a su ubicación en otros paquetes, la biblioteca ahora se encuentra en lib/galera/libgalera_smm.so en los archivos tar binarios, y hay un enlace simbólico en el lib directorio que apunta a él.

Instalación de MariaDB Galera Cluster desde la fuente

Para instalar MariaDB Galera Cluster compilándolo desde la fuente, tendrá que compilar tanto MariaDB Server como la biblioteca del proveedor de wsrep de Galera. Para obtener información sobre cómo hacer esto, consulte las páginas en Instalación de Galera desde la fuente. Las páginas de Compilación de MariaDB desde la fuente y Documentación de Galera Cluster: Creación de Galera Cluster para MySQL también puede ser útil. Al compilar MariaDB 10.1 o anterior y desea habilitar el soporte de Galera Cluster, asegúrese de configurar set -DWITH_WSREP=ON y -DWITH_INNODB_DISALLOW_WRITES=ON al ejecutar cmake. Al compilar MariaDB 10.2 o posterior, está habilitado de forma predeterminada.

Configuración del clúster MariaDB Galera

Es necesario configurar una serie de opciones para que Galera Cluster funcione cuando se usa MariaDB. Consulte Configuración del clúster MariaDB Galera para obtener más información.

Bootstrapping de un nuevo clúster

El primer nodo de un nuevo clúster debe iniciarse iniciando mysqld en ese nodo con la opción --wsrep-new-cluster opción. Esta opción le dice al nodo que no hay ningún clúster al que conectarse. El nodo creará un nuevo UUID para identificar el nuevo clúster.

No use el --wsrep-new-cluster opción al conectarse a un clúster existente. Reiniciar el nodo con esta opción configurada hará que el nodo cree un nuevo UUID para identificar el clúster nuevamente, y el nodo no se volverá a conectar al clúster anterior. Consulte la siguiente sección sobre cómo volver a conectarse a un clúster existente.

Por ejemplo, si estuviera iniciando manualmente mysqld en un nodo, entonces podría arrancarlo ejecutando lo siguiente:

$ mysqld --wsrep-new-cluster

Sin embargo, tenga en cuenta que la mayoría de los usuarios no comenzarán mysqld a mano. En cambio, la mayoría de los usuarios utilizarán un administrador de servicios para comenzar mysqld. Consulte las siguientes secciones sobre cómo iniciar un nodo con los administradores de servicios más comunes.

Systemd y Bootstrapping

En los sistemas operativos que usan systemd, un nodo se puede arrancar de la siguiente manera:

$ galera_new_cluster

Este contenedor usa systemd para ejecutar mysqld con el --wsrep-new-cluster opción.

Si está utilizando el servicio systemd que admite el método del servicio systemd para interactuar con varios procesos del servidor MariaDB, puede iniciar una instancia específica especificando el nombre de la instancia como sufijo. Por ejemplo:

$ galera_new_cluster mariadb@node1

MariaDB comenzando con 10.1.8

El soporte de Systemd y el script galera_new_cluster se agregaron en MariaDB 10.1.

SysVinit y Bootstrapping

En los sistemas operativos que usan sysVinit, un nodo puede arrancarse de la siguiente manera:

$ service mysql bootstrap

Esto corre mysqld con el --wsrep-new-cluster opción.

Agregar otro nodo a un clúster

Una vez que tenga un clúster en ejecución y desee agregar / volver a conectar otro nodo, debe proporcionar una dirección de uno o más de los miembros del clúster existentes en el wsrep_cluster_address opción. Por ejemplo, si el primer nodo del clúster tiene la dirección 192.168.0.1, entonces puede agregar un segundo nodo al clúster configurando la siguiente opción en un grupo de opciones del servidor en un archivo de opciones:

[mariadb]
...
wsrep_cluster_address=gcomm://192.168.0.1  # DNS names work as well, IP is preferred for performance

El nuevo nodo solo necesita conectarse a uno de los nodos de clúster existentes. Una vez que se conecte a uno de los nodos del clúster existente, podrá ver todos los nodos del clúster. Sin embargo, generalmente es mejor enumerar todos los nodos del clúster en wsrep_cluster_address, para que cualquier nodo pueda unirse a un clúster conectándose a cualquiera de los otros nodos del clúster, incluso si uno o más de los nodos del clúster están inactivos. Incluso está bien listar la propia dirección IP de un nodo en wsrep_cluster_address, ya que Galera Cluster es lo suficientemente inteligente como para ignorarlo.

Una vez que todos los miembros estén de acuerdo con la membresía, se intercambiará el estado del clúster. Si el estado del nuevo nodo es diferente al del clúster, entonces solicitará un IST o SST para que sea coherente con los otros nodos.

Reiniciar el clúster

Si apaga todos los nodos al mismo tiempo, entonces efectivamente ha terminado el clúster. Por supuesto, los datos del clúster aún existen, pero el clúster en ejecución ya no existe. Cuando esto suceda, deberá iniciar el clúster de nuevo.

Si el clúster no se inicia y mysqld en el primer nodo se inicia normalmente, entonces el nodo intentará conectarse al menos a uno de los nodos enumerados en el wsrep_cluster_address opción. Si no hay ningún nodo en ejecución, esto fallará. Bootstrapping el primer nodo resuelve este problema.

Determinar el nodo más avanzado

En algunos casos, Galera se negará a iniciar un nodo si detecta que podría no ser el nodo más avanzado del clúster. Galera toma esta determinación si el nodo no fue el último en el clúster en cerrarse o si el nodo se bloqueó. En esos casos, es necesaria la intervención manual.

Si sabe con certeza qué nodo es el más avanzado, puede editar el grastate.dat archivo en el datadir. Puedes configurar safe_to_bootstrap=1 en el nodo más avanzado.

Puede determinar qué nodo es el más avanzado marcando grastate.dat en cada nodo y buscando el nodo con la mayor seqno. Si el nodo falla y seqno=-1, luego puede encontrar el nodo más avanzado recuperando el seqno en cada nodo con el wsrep_recover opción. Por ejemplo:

$ mysqld --wsrep_recover

Recuperación de Systemd y Galera

En sistemas operativos que usan systemd, la posición de un nodo se puede recuperar ejecutando el galera_recovery texto. Por ejemplo:

$ galera_recovery

Si está utilizando el systemd servicio que admite el método del servicio systemd para interactuar con múltiples procesos del servidor MariaDB, luego puede recuperar la posición de una instancia específica especificando el nombre de la instancia como un sufijo. Por ejemplo:

$ galera_recovery mariadb@node1

los galera_recovery El script recupera la posición de un nodo ejecutando mysqld con el wsrep_recover opción.

Cuando el galera_recovery la secuencia de comandos se ejecuta mysqld, no escribe en el registro de errores. En cambio, redirige mysqld registrar la salida en un archivo nombrado con el formato /tmp/wsrep_recovery.XXXXXX, dónde XXXXXX se reemplaza con caracteres aleatorios.

Cuando Galera está habilitado, MariaDB’s systemd el servicio ejecuta automáticamente el galera_recovery script antes de iniciar MariaDB, de modo que MariaDB comience con la posición correcta de Galera.

MariaDB comenzando con 10.1.8

Apoyo para systemd y el galera_recovery Se agregaron secuencias de comandos en MariaDB 10.1.

Transferencias de instantáneas de estado (SST)

En una transferencia de instantáneas de estado (SST), el clúster aprovisiona los nodos transfiriendo una copia de datos completa de un nodo a otro. Cuando un nuevo nodo se une al clúster, el nuevo nodo inicia una Transferencia de instantánea de estado para sincronizar sus datos con un nodo que ya es parte del clúster.

Consulte Introducción a las transferencias de instantáneas de estado (SST) para obtener más información.

Transferencias estatales incrementales (IST)

En una transferencia de estado incremental (SST), el clúster aprovisiona los nodos transfiriendo las escrituras faltantes de un nodo de un nodo a otro. Cuando un nuevo nodo se une al clúster, el nuevo nodo inicia una Transferencia de estado incremental para sincronizar sus datos con un nodo que ya es parte del clúster.

Si un nodo solo ha estado fuera de un clúster por un tiempo, entonces un IST es generalmente más rápido que un SST.

Cifrado de datos en reposo

En MariaDB 10.1 y superior, MariaDB Galera Cluster admite el cifrado de datos en reposo. Consulte SST y Cifrado de datos en reposo para conocer algunas exenciones de responsabilidad sobre cómo se ven afectadas las SST cuando se configura el cifrado.

Algunos datos aún no se pueden cifrar:

Vigilancia

Variables de estado

Las variables de estado de Galera Cluster se pueden consultar con el estándar SHOW STATUS mando. Por ejemplo:

SHOW GLOBAL STATUS LIKE 'wsrep_%';

Notificaciones de cambio de clúster

Los nodos del clúster se pueden configurar para invocar un comando cuando cambia la membresía del clúster o el estado del nodo. Este mecanismo también se puede utilizar para comunicar el evento a algún agente de supervisión externo. Esto se configura estableciendo wsrep_notify_cmd. Ver Documentación de Galera Cluster: Comando de notificación para más información.

Ver también

Notas al pie

El contenido reproducido en este sitio es propiedad de sus respectivos dueños, y MariaDB no revisa este contenido con anticipación. Los puntos de vista, la información y las opiniones expresadas por este contenido no representan necesariamente las de MariaDB o de cualquier otra parte.