Databasautomatisering med Puppet:Implementering av MySQL &MariaDB Galera Cluster

I det tidigare blogginlägget visade vi dig några grundläggande steg för att distribuera och hantera en fristående MySQL-server samt MySQL-replikeringsinställning med MySQL Puppet-modulen. I den här andra installationen kommer vi att täcka liknande steg, men nu med en Galera Cluster-installation.

Galera-kluster med docka

Som du kanske vet har Galera Cluster tre huvudleverantörer:

• MySQL Galera Cluster (Codership)
• Percona XtraDB-kluster (Percona)
• MariaDB Cluster (inbäddad i MariaDB Server av MariaDB)

En vanlig praxis med Galera Cluster-distributioner är att ha ett extra lager ovanpå databasklustret för belastningsbalansering. Men det är en komplex process som förtjänar ett eget inlägg.

Det finns ett antal Puppet-moduler tillgängliga i Puppet Forge som kan användas för att distribuera ett Galera-kluster. Här är några av dem...

• puppetlabs/mysql - endast MariaDB Galera
• fraenki/galera - Percona XtraDB Cluster och MySQL Galera från Codership
• edestecd/mariadb - endast MariaDB-kluster
• filiadata/percona - Percona XtraDB-kluster

Eftersom vårt mål är att ge en grundläggande förståelse för hur man skriver manifest och automatiserar distributionen för Galera Cluster, kommer vi att täcka distributionen av MariaDB Galera Cluster med hjälp av puppetlabs/mysql-modulen. För andra moduler kan du alltid ta en titt på deras respektive dokumentation för instruktioner eller tips om hur du installerar.

I Galera Cluster är ordningen vid start av nod kritisk. För att starta ett nytt nytt kluster på rätt sätt måste en nod ställas in som referensnod. Denna nod kommer att startas med en tom värdanslutningssträng (gcomm://) för att initiera klustret. Denna process kallas bootstrapping.

När noden väl har startat blir noden en primär komponent och de återstående noderna kan startas med standardkommandot mysql start (systemctl start mysql eller service mysql start ) följt av en anslutningssträng för full värd (gcomm://db1,db2,db3). Bootstrapping krävs bara om det inte finns några primära komponentspärrar av någon annan nod i klustret (kolla med wsrep_cluster_status status).

Klustrets startprocess måste utföras explicit av användaren. Själva manifestet får INTE starta klustret (bootstrap valfri nod) vid första körningen för att undvika risk för dataförlust. Kom ihåg att Puppet-manifestet måste skrivas för att vara så idempotent som möjligt. Manifestet måste vara säkert för att kunna köras flera gånger utan att påverka de MySQL-instanser som redan körs. Det betyder att vi primärt måste fokusera på lagringskonfiguration, paketinstallation, förkörningskonfiguration och SST-användarkonfiguration.

Följande konfigurationsalternativ är obligatoriska för Galera:

• wsrep_on :En flagga för att aktivera Writeset-replikerings-API för Galera Cluster (endast MariaDB).
• wsrep_cluster_name :Klustrets namn. Måste vara identisk på alla noder som ingår i samma kluster.
• wsrep_cluster_address :Galera-kommunikationsanslutningssträngen, prefix med gcomm:// och följt av nodlista, separerade med kommatecken. Tom nodlista betyder klusterinitiering.
• wsrep_provider :Stigen där Galera-biblioteket finns. Sökvägen kan vara olika beroende på operativsystem.
• bindningsadress :MySQL måste vara tillgänglig externt så värdet '0.0.0.0' är obligatoriskt.
• wsrep_sst_method :För MariaDB är den föredragna SST-metoden mariabackup.
• wsrep_sst_auth :MySQL-användare och lösenord (separerade med kolon) för att utföra ögonblicksbildöverföring. Vanligtvis anger vi en användare som har möjlighet att skapa en fullständig säkerhetskopia.
• wsrep_node_address :IP-adress för Galera-kommunikation och replikering. Använd Puppet facter för att välja rätt IP-adress.
• wsrep_node_name :värdnamn för FQDN. Använd Puppet facter för att välja rätt värdnamn.

För Debian-baserade distributioner kommer skriptet efter installationen att försöka starta MariaDB-servern automatiskt. Om vi ​​konfigurerade wsrep_on=ON (flagga för att aktivera Galera) med den fullständiga adressen i wsrep_cluster_address variabel, skulle servern misslyckas under installationen. Detta beror på att den inte har någon primär komponent att ansluta till.

För att korrekt starta ett kluster i Galera måste den första noden (kallad bootstrap-nod) konfigureras med en tom anslutningssträng (wsrep_cluster_address =gcomm://) för att initiera noden som den primära komponenten. Du kan också köra det medföljande bootstrap-skriptet, kallat galera_new_cluster, som i princip gör en liknande sak i men bakgrunden.

Distribution av Galera Cluster (MariaDB)

Distribution av Galera Cluster kräver ytterligare konfiguration på APT-källan för att installera det föredragna MariaDB-versionsförrådet.

Observera att Galera-replikering är inbäddad i MariaDB Server och kräver att inga ytterligare paket installeras. Med det sagt krävs en extra flagga för att aktivera Galera genom att använda wsrep_on=ON. Utan denna flagga kommer MariaDB att fungera som en fristående server.

I vår Debian-baserade miljö kan alternativet wsrep_on endast visas i manifestet efter att den första distributionen är klar (som visas längre ner i installationsstegen). Detta för att säkerställa att den första, första starten fungerar som en fristående server för Puppet att tillhandahålla noden innan den är helt redo att bli en Galera-nod.

Låt oss börja med att förbereda manifestinnehållet enligt nedan (ändra avsnittet med globala variabler om det behövs):

# 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';
}

Lite förklaring behövs vid det här laget. 'wsrep_node_address' måste pekas på samma IP-adress som den som deklarerades i wsrep_cluster_address. I denna miljö har våra värdar två nätverksgränssnitt och vi vill använda det andra gränssnittet (kallat enp0s8) för Galera-kommunikation (där 192.168.0.0/24-nätverket är anslutet till). Det är därför vi använder Puppet facter för att hämta informationen från noden och tillämpa den på konfigurationsalternativet. Resten är ganska självförklarande.

Kör följande kommando på varje MariaDB-nod för att tillämpa katalogen som rotanvändare:

$ puppet agent -t

Katalogen kommer att appliceras på varje nod för installation och förberedelse. När vi är klara måste vi lägga till följande rad i vårt manifest under avsnittet "override_options => mysqld":

      'wsrep_on'                 => 'ON',

Ovanstående kommer att uppfylla Galera-kravet för MariaDB. Använd sedan katalogen på varje MariaDB-nod en gång till:

$ puppet agent -t

När vi är klara är vi redo att starta upp vårt kluster. Eftersom detta är ett nytt kluster, kan vi välja vilken som helst av noderna som referensnod a.k. en bootstrap-nod. Låt oss välja db1.local (192.168.0.161) och köra följande kommando:

$ galera_new_cluster #db1

När den första noden har startat kan vi starta den återstående noden med standardstartkommandot (en nod i taget):

$ systemctl restart mariadb #db2 and db3

När du har startat, ta en titt på MySQL-felloggen på /var/log/mysql/error.log och se till att loggen hamnar på följande rad:

2019-06-10  4:11:10 2 [Note] WSREP: Synchronized with group, ready for connections

Ovanstående talar om för oss att noderna är synkroniserade med gruppen. Vi kan sedan verifiera statusen genom att använda följande kommando:

$ mysql -uroot -e 'show status like "wsrep%"'

Se till att wsrep_cluster_size på alla noder , wsrep_cluster_status och wsrep_local_state_comment är 3, "Primär" respektive "Synkroniserad".

MySQL-hantering

Den här modulen kan användas för att utföra ett antal MySQL-hanteringsuppgifter...

• konfigurationsalternativ (ändra, tillämpa, anpassad konfiguration)
• databasresurser (databas, användare, anslag)
• säkerhetskopiering (skapa, schemalägga, säkerhetskopiera användare, lagring)
• enkel återställning (endast mysqldump)
• installation/aktivering av plugin

Servicekontroll

Det säkraste sättet när du tillhandahåller Galera Cluster med Puppet är att hantera alla servicekontrolloperationer manuellt (låt inte Puppet hantera det). För en enkel rullande omstart av kluster skulle standardtjänstkommandot duga. Kör följande kommando en nod i taget.

$ systemctl restart mariadb # Systemd
$ service mariadb restart # SysVinit

Men i fallet med en nätverkspartition och ingen primär komponent är tillgänglig (kontrollera med wsrep_cluster_status ), måste den mest uppdaterade noden bootstrappas för att få klustret att fungera igen utan dataförlust. Du kan följa stegen som visas i installationsavsnittet ovan. För att lära dig mer om bootstrapping-processen med exempelscenario, har vi täckt detta i detalj i det här blogginlägget, How to Bootstrap MySQL eller MariaDB Galera Cluster.

Databasresurs

Använd klassen mysql::db för att säkerställa att en databas med tillhörande användare och privilegier finns, till exempel:

  # make sure the database and user exist with proper grant
  mysql::db { 'mynewdb':
    user          => 'mynewuser',
    password      => 'passw0rd',
    host          => '192.168.0.%',
    grant         => ['SELECT', 'UPDATE']
  } 

Ovanstående definition kan tilldelas vilken nod som helst eftersom varje nod i ett Galera-kluster är en master.

Säkerhetskopiera och återställa

Eftersom vi skapade en SST-användare med xtrabackup-klassen, kommer Puppet att konfigurera alla förutsättningar för säkerhetskopieringsjobbet - skapa backupanvändaren, förbereda destinationssökvägen, tilldela äganderätt och behörighet, ställa in cron-jobbet och ställa in alternativen för backupkommandot att använda i det medföljande säkerhetskopieringsskriptet. Varje nod kommer att konfigureras med två säkerhetskopieringsjobb (ett för veckovis fullt och ett för dagligt inkrementellt) som standard till 23:05 som du kan se från crontab-utgången:

$ 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` --backup

Om du istället vill schemalägga mysqldump, använd mysql::server::backup-klassen för att förbereda säkerhetskopieringsresurserna. Anta att vi har följande deklaration i vårt manifest:

  # 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'
  }

Ovanstående säger till Puppet att konfigurera säkerhetskopieringsskriptet på /usr/local/sbin/mysqlbackup.sh och schemalägga det klockan 23:30 varje dag. Om du vill göra en omedelbar säkerhetskopia, anropa helt enkelt:

$ mysqlbackup.sh

För återställningen stöder modulen endast återställning med mysqldump backup-metoden, genom att importera SQL-filen direkt till databasen med klassen mysql::db, till exempel:

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
}

SQL-filen laddas bara en gång och inte vid varje körning, om inte enforce_sql => true används.

Konfigurationshantering

I det här exemplet använde vi manage_config_file => true med override_options för att strukturera våra konfigurationslinjer som senare kommer att skjutas ut av Puppet. Alla ändringar av manifestfilen kommer endast att återspegla innehållet i målkonfigurationsfilen för MySQL. Denna modul kommer varken att ladda konfigurationen till runtime eller starta om MySQL-tjänsten efter att ha tryckt in ändringarna i konfigurationsfilen. Det är systemadministratörens ansvar att starta om tjänsten för att aktivera ändringarna.

För att lägga till anpassad MySQL-konfiguration kan vi placera ytterligare filer i "includedir", som standard är /etc/mysql/conf.d. Detta tillåter oss att åsidosätta inställningar eller lägga till ytterligare, vilket är användbart om du inte använder override_options i mysql::serverklassen. Att använda sig av Puppet-mall rekommenderas starkt här. Placera den anpassade konfigurationsfilen under modulmallkatalogen (standard till , /etc/puppetlabs/code/environments/production/modules/mysql/templates) och lägg sedan till följande rader i manifestet:

# 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')
}

Puppet vs ClusterControl

Visste du att du också kan automatisera MySQL- eller MariaDB Galera-distributionen genom att använda ClusterControl? Du kan använda ClusterControl Puppet-modulen för att installera den, eller helt enkelt ladda ner den från vår webbplats.

Jämfört med ClusterControl kan du förvänta dig följande skillnader:

• Lite av en inlärningskurva för att förstå marionettsyntaxer, formatering, strukturer innan du kan skriva manifest.
• Manifest måste testas regelbundet. Det är mycket vanligt att du får ett kompileringsfel på koden, särskilt om katalogen används för första gången.
• Puppet antar att koderna är idempotenta. Test-/kontroll-/verifieringsvillkoret faller under författarens ansvar för att undvika att störa ett körande system.
• Puppet kräver en agent på den hanterade noden.
• Bakåtinkompatibilitet. Vissa gamla moduler skulle inte fungera korrekt på den nya versionen.
• Databas-/värdövervakning måste ställas in separat.

ClusterControls distributionsguide vägleder distributionsprocessen:

Alternativt kan du använda ClusterControls kommandoradsgränssnitt som kallas "s9s" för att uppnå liknande resultat. Följande kommando skapar ett Percona XtraDB-kluster med tre noder (förutsatt att alla noder är konfigurerade utan lösenord):

$ 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' \
  --log

Dessutom stöder ClusterControl distribution av belastningsutjämnare för Galera Cluster - HAproxy, ProxySQL och MariaDB MaxScale - tillsammans med en virtuell IP-adress (tillhandahållen av Keepalived) för att eliminera varje enskild felpunkt för din databastjänst.

Efter distributionen kan noder/kluster övervakas och hanteras fullt ut av ClusterControl, inklusive automatisk feldetektering, automatisk återställning, backuphantering, lastbalanseringshantering, anslutning av asynkron slav, konfigurationshantering och så vidare. Alla dessa är samlade i en produkt. I genomsnitt kommer ditt databaskluster att vara igång inom 30 minuter. Vad den behöver är endast lösenordslös SSH till målnoderna.

Du kan också importera ett Galera Cluster som redan körs, distribuerat av Puppet (eller på något annat sätt) till ClusterControl för att överladda ditt kluster med alla coola funktioner som följer med det. Community-utgåvan (gratis för alltid!) erbjuder distribution och övervakning.

I nästa avsnitt kommer vi att gå igenom MySQL load balancer-distribution med Puppet. Håll utkik!