En la publicación de blog anterior, le mostramos algunos pasos básicos para implementar y administrar un servidor MySQL independiente, así como la configuración de la replicación MySQL utilizando el módulo MySQL Puppet. En esta segunda instalación, cubriremos pasos similares, pero ahora con una configuración de Galera Cluster.
Racimo Galera con Marioneta
Como sabrá, Galera Cluster tiene tres proveedores principales:
- Clúster MySQL Galera (codificador)
- Clúster Percona XtraDB (Percona)
- Clúster MariaDB (integrado en el servidor MariaDB por MariaDB)
Una práctica común con las implementaciones de Galera Cluster es tener una capa adicional sobre el clúster de la base de datos para equilibrar la carga. Sin embargo, ese es un proceso complejo que merece su propia publicación.
Hay una serie de módulos Puppet disponibles en Puppet Forge que se pueden usar para implementar un Galera Cluster. Éstos son algunos de ellos..
- puppetlabs/mysql:solo MariaDB Galera
- fraenki/galera - Percona XtraDB Cluster y MySQL Galera de Codership
- edestecd/mariadb:solo clúster de MariaDB
- filiadata/percona - Clúster Percona XtraDB
Dado que nuestro objetivo es proporcionar una comprensión básica de cómo escribir el manifiesto y automatizar la implementación de Galera Cluster, cubriremos la implementación de MariaDB Galera Cluster utilizando el módulo de puppetlabs/mysql. Para otros módulos, siempre puede echar un vistazo a su documentación respectiva para obtener instrucciones o consejos sobre cómo instalar.
En Galera Cluster, el orden al iniciar el nodo es crítico. Para iniciar correctamente un nuevo clúster, se debe configurar un nodo como nodo de referencia. Este nodo se iniciará con una cadena de conexión de host vacía (gcomm://) para inicializar el clúster. Este proceso se llama arranque.
Una vez iniciado, el nodo se convertirá en un componente principal y los nodos restantes se pueden iniciar mediante el comando de inicio mysql estándar (systemctl start mysql o servicio mysql start ) seguido de una cadena de conexión de host completo (gcomm://db1,db2,db3). El arranque solo es necesario si ningún otro nodo del clúster retiene ningún componente principal (compruébelo con wsrep_cluster_status estado).
El usuario debe realizar explícitamente el proceso de inicio del clúster. El manifiesto en sí NO debe iniciar el clúster (arrancar ningún nodo) en la primera ejecución para evitar cualquier riesgo de pérdida de datos. Recuerde, el manifiesto de Puppet debe escribirse para que sea lo más idempotente posible. El manifiesto debe ser seguro para ejecutarse varias veces sin afectar las instancias de MySQL que ya se están ejecutando. Esto significa que debemos centrarnos principalmente en la configuración del repositorio, la instalación del paquete, la configuración previa a la ejecución y la configuración del usuario de SST.
Las siguientes opciones de configuración son obligatorias para Galera:
- wsrep_en :una marca para activar la API de replicación de conjunto de escritura para Galera Cluster (solo MariaDB).
- wsrep_cluster_name :el nombre del clúster. Debe ser idéntico en todos los nodos que forman parte del mismo clúster.
- wsrep_cluster_address :La cadena de conexión de comunicación de Galera, con el prefijo gcomm:// y seguido de la lista de nodos, separados por comas. La lista de nodos vacía significa inicialización del clúster.
- proveedor_wsrep :El camino donde reside la biblioteca Galera. La ruta puede ser diferente según el sistema operativo.
- bind_address :MySQL debe ser accesible externamente, por lo que el valor '0.0.0.0' es obligatorio.
- método_wsrep_sst :Para MariaDB, el método SST preferido es mariabackup.
- wsrep_sst_auth :usuario y contraseña de MySQL (separados por dos puntos) para realizar la transferencia de instantáneas. Por lo general, especificamos un usuario que tiene la capacidad de crear una copia de seguridad completa.
- dirección_nodo_wsrep :Dirección IP para comunicación y replicación de Galera. Use Puppet facter para elegir la dirección IP correcta.
- wsrep_node_name :nombre de host de FQDN. Use Puppet facter para elegir el nombre de host correcto.
Para implementaciones basadas en Debian, el script posterior a la instalación intentará iniciar el servidor MariaDB automáticamente. Si configuramos wsrep_on=ON (marca para habilitar Galera) con la dirección completa en wsrep_cluster_address variable, el servidor fallaría durante la instalación. Esto se debe a que no tiene un componente principal al que conectarse.
Para iniciar correctamente un clúster en Galera, el primer nodo (llamado nodo de arranque) debe configurarse con una cadena de conexión vacía (wsrep_cluster_address =gcomm://) para iniciar el nodo como componente principal. También puede ejecutar el script de arranque provisto, llamado galera_new_cluster, que básicamente hace algo similar pero en segundo plano.
Despliegue de Galera Cluster (MariaDB)
La implementación de Galera Cluster requiere una configuración adicional en la fuente APT para instalar el repositorio de la versión MariaDB preferida.
Tenga en cuenta que la replicación de Galera está integrada dentro del servidor MariaDB y no requiere la instalación de paquetes adicionales. Dicho esto, se requiere una bandera adicional para habilitar Galera usando wsrep_on=ON. Sin esta bandera, MariaDB actuará como un servidor independiente.
En nuestro entorno basado en Debian, la opción wsrep_on solo puede presentarse en el manifiesto después de que se completa la primera implementación (como se muestra más abajo en los pasos de implementación). Esto es para garantizar que el primer inicio actúe como un servidor independiente para que Puppet aprovisione el nodo antes de que esté completamente listo para ser un nodo de Galera.
Comencemos por preparar el contenido del manifiesto como se muestra a continuación (modifique la sección de variables globales si es necesario):
# Puppet manifest for Galera Cluster MariaDB 10.3 on Ubuntu 18.04 (Puppet v6.4.2)
# /etc/puppetlabs/code/environments/production/manifests/galera.pp
# global vars
$sst_user = 'sstuser'
$sst_password = 'S3cr333t$'
$backup_dir = '/home/backup/mysql'
$mysql_cluster_address = 'gcomm://192.168.0.161,192.168.0.162,192.168.0.163'
# node definition
node "db1.local", "db2.local", "db3.local" {
Apt::Source['mariadb'] ~>
Class['apt::update'] ->
Class['mysql::server'] ->
Class['mysql::backup::xtrabackup']
}
# apt module must be installed first: 'puppet module install puppetlabs-apt'
include apt
# custom repository definition
apt::source { 'mariadb':
location => 'http://sfo1.mirrors.digitalocean.com/mariadb/repo/10.3/ubuntu',
release => $::lsbdistcodename,
repos => 'main',
key => {
id => 'A6E773A1812E4B8FD94024AAC0F47944DE8F6914',
server => 'hkp://keyserver.ubuntu.com:80',
},
include => {
src => false,
deb => true,
},
}
# Galera configuration
class {'mysql::server':
package_name => 'mariadb-server',
root_password => '[email protected]#',
service_name => 'mysql',
create_root_my_cnf => true,
remove_default_accounts => true,
manage_config_file => true,
override_options => {
'mysqld' => {
'datadir' => '/var/lib/mysql',
'bind_address' => '0.0.0.0',
'binlog-format' => 'ROW',
'default-storage-engine' => 'InnoDB',
'wsrep_provider' => '/usr/lib/galera/libgalera_smm.so',
'wsrep_provider_options' => 'gcache.size=1G',
'wsrep_cluster_name' => 'galera_cluster',
'wsrep_cluster_address' => $mysql_cluster_address,
'log-error' => '/var/log/mysql/error.log',
'wsrep_node_address' => $facts['networking']['interfaces']['enp0s8']['ip'],
'wsrep_node_name' => $hostname,
'innodb_buffer_pool_size' => '512M',
'wsrep_sst_method' => 'mariabackup',
'wsrep_sst_auth' => "${sst_user}:${sst_password}"
},
'mysqld_safe' => {
'log-error' => '/var/log/mysql/error.log'
}
}
}
# force creation of backup dir if not exist
exec { "mkdir -p ${backup_dir}" :
path => ['/bin','/usr/bin'],
unless => "test -d ${backup_dir}"
}
# create SST and backup user
class { 'mysql::backup::xtrabackup' :
xtrabackup_package_name => 'mariadb-backup',
backupuser => "${sst_user}",
backuppassword => "${sst_password}",
backupmethod => 'mariabackup',
backupdir => "${backup_dir}"
}
# /etc/hosts definition
host {
'db1.local': ip => '192.168.0.161';
'db2.local': ip => '192.169.0.162';
'db3.local': ip => '192.168.0.163';
}Se necesita un poco de explicación en este punto. 'wsrep_node_address' debe apuntar a la misma dirección IP que se declaró en wsrep_cluster_address. En este entorno, nuestros hosts tienen dos interfaces de red y queremos usar la segunda interfaz (llamada enp0s8) para la comunicación de Galera (donde está conectada la red 192.168.0.0/24). Es por eso que usamos Puppet facter para obtener la información del nodo y aplicarla a la opción de configuración. El resto se explica por sí mismo.
En cada nodo de MariaDB, ejecute el siguiente comando para aplicar el catálogo como usuario raíz:
$ puppet agent -tEl catálogo se aplicará a cada nodo para su instalación y preparación. Una vez hecho esto, debemos agregar la siguiente línea en nuestro manifiesto en la sección "override_options => mysqld":
'wsrep_on' => 'ON',Lo anterior satisfará el requisito de Galera para MariaDB. Luego, aplique el catálogo en cada nodo de MariaDB una vez más:
$ puppet agent -tUna vez hecho esto, estamos listos para arrancar nuestro clúster. Dado que este es un nuevo clúster, podemos elegir cualquiera de los nodos para que sea el nodo de referencia, también conocido como nodo de arranque. Elijamos db1.local (192.168.0.161) y ejecutemos el siguiente comando:
$ galera_new_cluster #db1Una vez que se inicia el primer nodo, podemos iniciar el nodo restante con el comando de inicio estándar (un nodo a la vez):
$ systemctl restart mariadb #db2 and db3Una vez iniciado, eche un vistazo al registro de errores de MySQL en /var/log/mysql/error.log y asegúrese de que el registro termine con la siguiente línea:
2019-06-10 4:11:10 2 [Note] WSREP: Synchronized with group, ready for connectionsLo anterior nos dice que los nodos están sincronizados con el grupo. Luego podemos verificar el estado usando el siguiente comando:
$ mysql -uroot -e 'show status like "wsrep%"'Asegúrese de que en todos los nodos, wsrep_cluster_size , wsrep_cluster_status y wsrep_local_state_comment son 3, "Principal" y "Sincronizado" respectivamente.
Administración de MySQL
Este módulo se puede utilizar para realizar una serie de tareas de gestión de MySQL...
- opciones de configuración (modificar, aplicar, configuración personalizada)
- recursos de la base de datos (base de datos, usuario, subvenciones)
- copia de seguridad (crear, programar, usuario de copia de seguridad, almacenamiento)
- restauración simple (solo mysqldump)
- instalación/activación de complementos
Control de Servicios
La forma más segura de aprovisionar Galera Cluster con Puppet es manejar todas las operaciones de control de servicios manualmente (no dejar que Puppet las maneje). Para un reinicio continuo de clúster simple, el comando de servicio estándar sería suficiente. Ejecute el siguiente comando un nodo a la vez.
$ systemctl restart mariadb # Systemd
$ service mariadb restart # SysVinitSin embargo, en el caso de que ocurra una partición de red y no haya ningún componente principal disponible (compruébelo con wsrep_cluster_status ), se debe arrancar el nodo más actualizado para que el clúster vuelva a estar operativo sin pérdida de datos. Puede seguir los pasos que se muestran en la sección de implementación anterior. Para obtener más información sobre el proceso de arranque con escenarios de ejemplos, hemos cubierto esto en detalle en esta publicación de blog, Cómo Arrancar MySQL o MariaDB Galera Cluster.
Recurso de base de datos
Use la clase mysql::db para asegurarse de que esté presente una base de datos con usuarios y privilegios asociados, por ejemplo:
# make sure the database and user exist with proper grant
mysql::db { 'mynewdb':
user => 'mynewuser',
password => 'passw0rd',
host => '192.168.0.%',
grant => ['SELECT', 'UPDATE']
} La definición anterior se puede asignar a cualquier nodo ya que cada nodo en un Galera Cluster es un maestro.
Copia de seguridad y restauración
Dado que creamos un usuario SST usando la clase xtrabackup, Puppet configurará todos los requisitos previos para el trabajo de respaldo:crear el usuario de respaldo, preparar la ruta de destino, asignar la propiedad y el permiso, configurar el trabajo cron y configurar las opciones de comando de respaldo para usar en el script de copia de seguridad proporcionado. Cada nodo se configurará con dos tareas de copia de seguridad (una completa semanalmente y otra incremental diaria) predeterminadas a las 11:05 p. m., como puede ver en el resultado de crontab:
$ crontab -l
# Puppet Name: xtrabackup-weekly
5 23 * * 0 /usr/local/sbin/xtrabackup.sh --target-dir=/home/backup/mysql --backup
# Puppet Name: xtrabackup-daily
5 23 * * 1-6 /usr/local/sbin/xtrabackup.sh --incremental-basedir=/home/backup/mysql --target-dir=/home/backup/mysql/`date +%F_%H-%M-%S` --backupSi desea programar mysqldump en su lugar, utilice la clase mysql::server::backup para preparar los recursos de copia de seguridad. Supongamos que tenemos la siguiente declaración en nuestro manifiesto:
# Prepare the backup script, /usr/local/sbin/mysqlbackup.sh
class { 'mysql::server::backup':
backupuser => 'backup',
backuppassword => 'passw0rd',
backupdir => '/home/backup',
backupdirowner => 'mysql',
backupdirgroup => 'mysql',
backupdirmode => '755',
backuprotate => 15,
time => ['23','30'], #backup starts at 11:30PM everyday
include_routines => true,
include_triggers => true,
ignore_events => false,
maxallowedpacket => '64M'
}Lo anterior le dice a Puppet que configure el script de respaldo en /usr/local/sbin/mysqlbackup.sh y lo programe a las 11:30 p. m. todos los días. Si desea realizar una copia de seguridad inmediata, simplemente invoque:
$ mysqlbackup.shPara la restauración, el módulo solo admite la restauración con el método de copia de seguridad mysqldump, importando el archivo SQL directamente a la base de datos utilizando la clase mysql::db, por ejemplo:
mysql::db { 'mydb':
user => 'myuser',
password => 'mypass',
host => 'localhost',
grant => ['ALL PRIVILEGES'],
sql => '/home/backup/mysql/mydb/backup.gz',
import_cat_cmd => 'zcat',
import_timeout => 900
}El archivo SQL se cargará solo una vez y no en cada ejecución, a menos que se use enforce_sql => true.
Gestión de la configuración
En este ejemplo, usamos manage_config_file => true con override_options para estructurar nuestras líneas de configuración que luego serán enviadas por Puppet. Cualquier modificación del archivo de manifiesto solo reflejará el contenido del archivo de configuración de MySQL de destino. Este módulo no cargará la configuración en el tiempo de ejecución ni reiniciará el servicio MySQL después de introducir los cambios en el archivo de configuración. Es responsabilidad del administrador del sistema reiniciar el servicio para activar los cambios.
Para agregar una configuración personalizada de MySQL, podemos colocar archivos adicionales en "includedir", predeterminado en /etc/mysql/conf.d. Esto nos permite anular configuraciones o agregar configuraciones adicionales, lo cual es útil si no usa override_options en mysql::server class. Aquí se recomienda encarecidamente utilizar la plantilla Puppet. Coloque el archivo de configuración personalizado en el directorio de plantillas del módulo (por defecto, /etc/puppetlabs/code/environments/production/modules/mysql/templates) y luego agregue las siguientes líneas en el manifiesto:
# Loads /etc/puppetlabs/code/environments/production/modules/mysql/templates/my-custom-config.cnf.erb into /etc/mysql/conf.d/my-custom-config.cnf
file { '/etc/mysql/conf.d/my-custom-config.cnf':
ensure => file,
content => template('mysql/my-custom-config.cnf.erb')
}Marioneta vs ClusterControl
¿Sabía que también puede automatizar la implementación de MySQL o MariaDB Galera utilizando ClusterControl? Puede usar el módulo ClusterControl Puppet para instalarlo, o simplemente descargándolo de nuestro sitio web.
En comparación con ClusterControl, puede esperar las siguientes diferencias:
- Una pequeña curva de aprendizaje para comprender la sintaxis, el formato y las estructuras de Puppet antes de poder escribir manifiestos.
- El manifiesto debe probarse con regularidad. Es muy común que obtenga un error de compilación en el código, especialmente si el catálogo se aplica por primera vez.
- Puppet supone que los códigos son idempotentes. La condición de prueba/comprobación/verificación cae bajo la responsabilidad del autor para evitar estropear un sistema en ejecución.
- Puppet requiere un agente en el nodo administrado.
- Incompatibilidad hacia atrás. Algunos módulos antiguos no se ejecutarían correctamente en la nueva versión.
- La supervisión de la base de datos/host debe configurarse por separado.
El asistente de implementación de ClusterControl guía el proceso de implementación:
Alternativamente, puede usar la interfaz de línea de comandos de ClusterControl llamada "s9s" para lograr resultados similares. El siguiente comando crea un clúster Percona XtraDB de tres nodos (siempre que se haya configurado sin contraseña para todos los nodos de antemano):
$ s9s cluster --create \
--cluster-type=galera \
--nodes='192.168.0.21;192.168.0.22;192.168.0.23' \
--vendor=percona \
--cluster-name='Percona XtraDB Cluster 5.7' \
--provider-version=5.7 \
--db-admin='root' \
--db-admin-passwd='$ecR3t^word' \
--logAdemás, ClusterControl admite la implementación de balanceadores de carga para Galera Cluster (HAproxy, ProxySQL y MariaDB MaxScale) junto con una dirección IP virtual (proporcionada por Keepalived) para eliminar cualquier punto único de falla para su servicio de base de datos.
Después de la implementación, ClusterControl puede monitorear y administrar completamente los nodos/clústeres, incluida la detección automática de fallas, la recuperación automática, la administración de copias de seguridad, la administración del equilibrador de carga, la conexión de esclavos asíncronos, la administración de configuración, etc. Todos estos están agrupados en un solo producto. En promedio, su clúster de base de datos estará en funcionamiento en 30 minutos. Lo que necesita es solo SSH sin contraseña para los nodos de destino.
También puede importar un Galera Cluster ya en ejecución, implementado por Puppet (o cualquier otro medio) en ClusterControl para potenciar su clúster con todas las características geniales que lo acompañan. La edición comunitaria (¡gratis para siempre!) ofrece implementación y supervisión.
En el próximo episodio, lo guiaremos a través de la implementación del balanceador de carga de MySQL usando Puppet. ¡Estén atentos!
