Databaseautomatisering med Puppet:Implementering af MySQL &MariaDB Galera Cluster

I det forrige blogindlæg viste vi dig nogle grundlæggende trin til at implementere og administrere en selvstændig MySQL-server samt MySQL-replikeringsopsætning ved hjælp af MySQL Puppet-modulet. I denne anden installation vil vi dække lignende trin, men nu med en Galera Cluster-opsætning.

Galera-klynge med dukke

Som du måske ved, har Galera Cluster tre hovedudbydere:

• MySQL Galera Cluster (Codership)
• Percona XtraDB Cluster (Percona)
• MariaDB Cluster (indlejret i MariaDB Server af MariaDB)

En almindelig praksis med Galera Cluster-implementeringer er at have et ekstra lag på toppen af ​​databaseklyngen til belastningsbalanceringsformål. Det er dog en kompleks proces, som fortjener sit eget indlæg.

Der er en række Puppet-moduler tilgængelige i Puppet Forge, som kan bruges til at implementere en Galera Cluster. Her er nogle af dem..

• puppetlabs/mysql - kun MariaDB Galera
• fraenki/galera - Percona XtraDB Cluster og MySQL Galera fra Codership
• edestecd/mariadb - kun MariaDB-klynge
• filiadata/percona - Percona XtraDB Cluster

Da vores mål er at give en grundlæggende forståelse af, hvordan man skriver manifest og automatiserer implementeringen af ​​Galera Cluster, vil vi dække implementeringen af ​​MariaDB Galera Cluster ved hjælp af puppetlabs/mysql-modulet. For andre moduler kan du altid tage et kig på deres respektive dokumentation for instruktioner eller tips om, hvordan du installerer.

I Galera Cluster er rækkefølgen ved start af node kritisk. For at starte en ny klynge korrekt skal én node konfigureres som referenceknude. Denne node vil blive startet med en tom værtsforbindelsesstreng (gcomm://) for at initialisere klyngen. Denne proces kaldes bootstrapping.

Når den er startet, bliver noden en primær komponent, og de resterende noder kan startes ved hjælp af standard mysql start kommandoen (systemctl start mysql eller service mysql start ) efterfulgt af en fuld værtsforbindelsesstreng (gcomm://db1,db2,db3). Bootstrapping er kun påkrævet, hvis der ikke er nogen primær komponent-holds af nogen anden node i klyngen (tjek med wsrep_cluster_status status).

Klyngestartprocessen skal udføres eksplicit af brugeren. Selve manifestet må IKKE starte klyngen (bootstrap enhver node) ved første kørsel for at undgå risiko for datatab. Husk, at dukkemanifestet skal være skrevet for at være så idempotent som muligt. Manifestet skal være sikkert for at blive eksekveret flere gange uden at påvirke de allerede kørende MySQL-instanser. Det betyder, at vi primært skal fokusere på lagerkonfiguration, pakkeinstallation, forudgående konfiguration og SST-brugerkonfiguration.

Følgende konfigurationsmuligheder er obligatoriske for Galera:

• wsrep_on :Et flag til at aktivere skrivesætreplikerings-API for Galera Cluster (kun MariaDB).
• wsrep_cluster_name :Klyngenavnet. Skal være identisk på alle noder, der er en del af den samme klynge.
• wsrep_cluster_address :Galera-kommunikationsforbindelsesstrengen, præfiks med gcomm:// og efterfulgt af nodeliste, adskilt af komma. Tom nodeliste betyder klyngeinitialisering.
• wsrep_provider :Stien, hvor Galera-biblioteket ligger. Stien kan være anderledes afhængigt af operativsystemet.
• bindingsadresse :MySQL skal være tilgængelig eksternt, så værdien '0.0.0.0' er obligatorisk.
• wsrep_sst_method :For MariaDB er den foretrukne SST-metode mariabackup.
• wsrep_sst_auth :MySQL-bruger og adgangskode (adskilt af kolon) for at udføre snapshot-overførsel. Normalt angiver vi en bruger, der har mulighed for at oprette en fuld sikkerhedskopi.
• wsrep_node_address :IP-adresse til Galera-kommunikation og replikering. Brug Puppet facter til at vælge den korrekte IP-adresse.
• wsrep_node_name :værtsnavn på FQDN. Brug Puppet facter til at vælge det korrekte værtsnavn.

For Debian-baserede implementeringer vil post-installationsscriptet forsøge at starte MariaDB-serveren automatisk. Hvis vi konfigurerede wsrep_on=ON (flag for at aktivere Galera) med den fulde adresse i wsrep_cluster_address variabel, ville serveren fejle under installationen. Dette skyldes, at den ikke har nogen primær komponent at oprette forbindelse til.

For at starte en klynge korrekt i Galera skal den første node (kaldet bootstrap node) konfigureres med en tom forbindelsesstreng (wsrep_cluster_address =gcomm://) for at starte noden som den primære komponent. Du kan også køre det medfølgende bootstrap-script, kaldet galera_new_cluster, som dybest set gør en lignende ting i men baggrunden.

Implementering af Galera Cluster (MariaDB)

Implementering af Galera Cluster kræver yderligere konfiguration på APT-kilden for at installere det foretrukne MariaDB-versionslager.

Bemærk, at Galera-replikering er indlejret i MariaDB Server og kræver ingen yderligere pakker, der skal installeres. Når det er sagt, kræves der et ekstra flag for at aktivere Galera ved at bruge wsrep_on=ON. Uden dette flag vil MariaDB fungere som en selvstændig server.

I vores Debian-baserede miljø kan indstillingen wsrep_on kun præsenteres i manifestet, efter at den første implementering er fuldført (som vist længere nede i implementeringstrinene). Dette er for at sikre, at den første, indledende start fungerer som en selvstændig server for Puppet til at klargøre noden, før den er helt klar til at blive en Galera-node.

Lad os starte med at forberede manifestindholdet som nedenfor (rediger om nødvendigt afsnittet med globale variabler):

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

Der er brug for lidt forklaring på dette tidspunkt. 'wsrep_node_address' skal peges på den samme IP-adresse som den, der blev erklæret i wsrep_cluster_addressen. I dette miljø har vores værter to netværksgrænseflader, og vi ønsker at bruge den anden grænseflade (kaldet enp0s8) til Galera-kommunikation (hvor 192.168.0.0/24-netværket er forbundet til). Det er derfor, vi bruger Puppet facter til at hente informationen fra noden og anvende den til konfigurationsmuligheden. Resten er ret selvforklarende.

På hver MariaDB-node skal du køre følgende kommando for at anvende kataloget som root-bruger:

$ puppet agent -t

Kataloget vil blive anvendt på hver node til installation og klargøring. Når det er gjort, skal vi tilføje følgende linje i vores manifest under afsnittet "override_options => mysqld":

      'wsrep_on'                 => 'ON',

Ovenstående vil opfylde Galera-kravet for MariaDB. Anvend derefter kataloget på hver MariaDB-node igen:

$ puppet agent -t

Når det er gjort, er vi klar til at bootstrap vores klynge. Da dette er en ny klynge, kan vi vælge en hvilken som helst af noderne til at være referenceknuden også kaldet bootstrap node. Lad os vælge db1.local (192.168.0.161) og køre følgende kommando:

$ galera_new_cluster #db1

Når den første node er startet, kan vi starte den resterende node med standardstartkommandoen (én node ad gangen):

$ systemctl restart mariadb #db2 and db3

Når du er startet, kan du tage et kig på MySQL-fejlloggen på /var/log/mysql/error.log og sikre dig, at loggen ender med følgende linje:

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

Ovenstående fortæller os, at noderne er synkroniseret med gruppen. Vi kan derefter bekræfte status ved at bruge følgende kommando:

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

Sørg for, at wsrep_cluster_size på alle noder , wsrep_cluster_status og wsrep_local_state_comment er henholdsvis 3, "Primær" og "Synkroniseret".

MySQL Management

Dette modul kan bruges til at udføre en række MySQL-administrationsopgaver...

• konfigurationsmuligheder (ændre, anvende, tilpasset konfiguration)
• databaseressourcer (database, bruger, bevillinger)
• sikkerhedskopiering (opret, planlæg, sikkerhedskopier bruger, lagring)
• simpel gendannelse (kun mysqldump)
• installation/aktivering af plugins

Servicekontrol

Den sikreste måde, når du klargør Galera Cluster med Puppet, er at håndtere alle servicekontroloperationer manuelt (lad ikke Puppet håndtere det). For en simpel rullende genstart af klynge ville standardservicekommandoen duge. Kør følgende kommando én node ad gangen.

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

Men i tilfælde af, at der sker en netværkspartition, og ingen primær komponent er tilgængelig (tjek med wsrep_cluster_status ), skal den mest opdaterede node bootstrappes for at bringe klyngen tilbage til drift uden tab af data. Du kan følge trinene som vist i installationsafsnittet ovenfor. For at lære mere om bootstrapping-processen med eksempler på scenarier, har vi dækket dette i detaljer i dette blogindlæg, How to Bootstrap MySQL eller MariaDB Galera Cluster.

Databaseressource

Brug klassen mysql::db for at sikre, at en database med tilhørende bruger og privilegier er til stede, for eksempel:

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

Ovenstående definition kan tildeles enhver node, da hver node i en Galera Cluster er en master.

Sikkerhedskopiering og gendannelse

Da vi oprettede en SST-bruger ved hjælp af xtrabackup-klassen, vil Puppet konfigurere alle forudsætningerne for backup-jobbet - oprettelse af backup-brugeren, forberede destinationsstien, tildele ejerskab og tilladelse, indstille cron-jobbet og opsætte backup-kommandoindstillingerne til brug i det medfølgende backupscript. Hver node vil blive konfigureret med to backupjob (et for ugentligt fuld og et andet for dagligt trinvis) standard til 23:05, som du kan se fra crontab-outputtet:

$ 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

Hvis du i stedet vil planlægge mysqldump, skal du bruge mysql::server::backup-klassen til at forberede backup-ressourcerne. Antag, at vi har følgende erklæring i vores 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'
  }

Ovenstående fortæller Puppet at konfigurere backup-scriptet på /usr/local/sbin/mysqlbackup.sh og planlægge det kl. 23:30 hver dag. Hvis du vil lave en øjeblikkelig backup, skal du blot påberåbe:

$ mysqlbackup.sh

Til gendannelsen understøtter modulet kun gendannelse med mysqldump backup-metoden, ved at importere SQL-filen direkte til databasen ved hjælp af mysql::db-klassen, for eksempel:

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 vil kun blive indlæst én gang og ikke ved hver kørsel, medmindre enforce_sql => true bruges.

Konfigurationsstyring

I dette eksempel brugte vi manage_config_file => true med override_options til at strukturere vores konfigurationslinjer, som senere vil blive skubbet ud af Puppet. Enhver ændring af manifestfilen vil kun afspejle indholdet af MySQL-målkonfigurationsfilen. Dette modul vil hverken indlæse konfigurationen i runtime eller genstarte MySQL-tjenesten efter at have skubbet ændringerne ind i konfigurationsfilen. Det er systemadministratorens ansvar at genstarte tjenesten for at aktivere ændringerne.

For at tilføje brugerdefineret MySQL-konfiguration kan vi placere yderligere filer i "includedir", som standard er /etc/mysql/conf.d. Dette giver os mulighed for at tilsidesætte indstillinger eller tilføje yderligere, hvilket er nyttigt, hvis du ikke bruger override_options i mysql::serverklassen. Det anbefales stærkt at gøre brug af Puppet-skabelonen her. Placer den tilpassede konfigurationsfil under modulskabelonbiblioteket (standard til , /etc/puppetlabs/code/environments/production/modules/mysql/templates) og tilføj derefter følgende linjer 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

Vidste du, at du også kan automatisere MySQL- eller MariaDB Galera-implementeringen ved at bruge ClusterControl? Du kan bruge ClusterControl Puppet-modulet til at installere det, eller blot ved at downloade det fra vores hjemmeside.

Sammenlignet med ClusterControl kan du forvente følgende forskelle:

• Lidt af en indlæringskurve til at forstå marionetsyntakser, formatering, strukturer, før du kan skrive manifester.
• Manifest skal testes regelmæssigt. Det er meget almindeligt, at du får en kompileringsfejl på koden, især hvis kataloget anvendes for første gang.
• Puppet antager, at koderne er idempotente. Test/tjek/bekræft tilstanden falder ind under forfatterens ansvar for at undgå at rode med et kørende system.
• Puppet kræver en agent på den administrerede node.
• Inkompatibilitet bagud. Nogle gamle moduler ville ikke køre korrekt på den nye version.
• Database-/værtsovervågning skal konfigureres separat.

ClusterControls implementeringsguide guider implementeringsprocessen:

Alternativt kan du bruge ClusterControl-kommandolinjegrænsefladen kaldet "s9s" for at opnå lignende resultater. Følgende kommando opretter en Percona XtraDB-klynge med tre noder (forudsat adgangskodefri til alle noder er blevet konfigureret på forhånd):

$ 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

Derudover understøtter ClusterControl implementering af belastningsbalancere til Galera Cluster - HAproxy, ProxySQL og MariaDB MaxScale - sammen med en virtuel IP-adresse (leveret af Keepalved) for at eliminere ethvert enkelt fejlpunkt for din databasetjeneste.

Efter implementeringen kan noder/klynger overvåges og administreres fuldt ud af ClusterControl, inklusive automatisk fejldetektion, automatisk gendannelse, backupstyring, belastningsbalancestyring, tilknytning af asynkron slave, konfigurationsstyring og så videre. Alle disse er samlet i ét produkt. I gennemsnit vil din databaseklynge være oppe og køre inden for 30 minutter. Det, den har brug for, er kun adgangskodefri SSH til målknuderne.

Du kan også importere en allerede kørende Galera Cluster, implementeret af Puppet (eller på anden måde) til ClusterControl for at overlade din klynge med alle de fede funktioner, der følger med den. Fællesskabsudgaven (gratis for evigt!) tilbyder implementering og overvågning.

I den næste episode vil vi guide dig gennem MySQL load balancer-implementering ved hjælp af Puppet. Hold dig opdateret!