Database-automatisering met Puppet:MySQL- en MariaDB Galera-cluster implementeren

In de vorige blogpost hebben we u enkele basisstappen laten zien voor het implementeren en beheren van een zelfstandige MySQL-server en het instellen van MySQL-replicatie met behulp van de MySQL Puppet-module. In deze tweede installatie gaan we vergelijkbare stappen behandelen, maar nu met een Galera Cluster-opstelling.

Galera-cluster met pop

Zoals u wellicht weet, heeft Galera Cluster drie hoofdaanbieders:

• MySQL Galera-cluster (coderschap)
• Percona XtraDB-cluster (Percona)
• MariaDB Cluster (ingebed in MariaDB Server door MariaDB)

Een gebruikelijke praktijk bij Galera Cluster-implementaties is om een ​​extra laag bovenop het databasecluster te plaatsen voor taakverdelingsdoeleinden. Dat is echter een complex proces dat een eigen post verdient.

Er zijn een aantal Puppet-modules beschikbaar in de Puppet Forge die kunnen worden gebruikt om een ​​Galera-cluster in te zetten. Hier zijn er enkele..

• puppetlabs/mysql - alleen MariaDB Galera
• fraenki/galera - Percona XtraDB Cluster en MySQL Galera van Codership
• edestecd/mariadb - alleen MariaDB-cluster
• filiadata/percona - Percona XtraDB-cluster

Aangezien het ons doel is om een ​​basiskennis te verschaffen van het schrijven van manifesten en het automatiseren van de implementatie voor Galera Cluster, behandelen we de implementatie van de MariaDB Galera Cluster met behulp van de puppetlabs/mysql-module. Voor andere modules kun je altijd de respectievelijke documentatie raadplegen voor instructies of tips voor het installeren.

In Galera Cluster is de volgorde bij het starten van de node van cruciaal belang. Om een ​​fris nieuw cluster op de juiste manier te starten, moet één knooppunt worden ingesteld als het referentieknooppunt. Dit knooppunt wordt gestart met een lege hostverbindingsreeks (gcomm://) om het cluster te initialiseren. Dit proces wordt bootstrapping genoemd.

Eenmaal gestart, wordt het knooppunt een primaire component en kunnen de resterende knooppunten worden gestart met behulp van het standaard mysql start-commando (systemctl start mysql of service mysql start ) gevolgd door een volledige hostverbindingsreeks (gcomm://db1,db2,db3). Bootstrapping is alleen vereist als er geen primaire component is die wordt vastgehouden door een ander knooppunt in het cluster (controleer met wsrep_cluster_status status).

Het opstartproces van het cluster moet expliciet door de gebruiker worden uitgevoerd. Het manifest zelf mag het cluster NIET starten (bootstrap elk knooppunt) bij de eerste run om elk risico op gegevensverlies te voorkomen. Onthoud dat het Puppet-manifest zo idempotent mogelijk moet zijn geschreven. Het manifest moet veilig zijn om meerdere keren te kunnen worden uitgevoerd zonder de reeds actieve MySQL-instanties te beïnvloeden. Dit betekent dat we ons voornamelijk moeten concentreren op de configuratie van de repository, de pakketinstallatie, de pre-running configuratie en de SST-gebruikersconfiguratie.

De volgende configuratie-opties zijn verplicht voor Galera:

• wsrep_on :Een vlag om de schrijfset-replicatie-API voor Galera Cluster in te schakelen (alleen MariaDB).
• wsrep_cluster_name :De clusternaam. Moet identiek zijn op alle knooppunten die deel uitmaken van hetzelfde cluster.
• wsrep_cluster_address :De Galera-communicatieverbindingsreeks, voorvoegsel met gcomm:// en gevolgd door een lijst met knooppunten, gescheiden door een komma. Lege knooppuntenlijst betekent clusterinitialisatie.
• wsrep_provider :Het pad waar de Galera-bibliotheek zich bevindt. Het pad kan verschillen, afhankelijk van het besturingssysteem.
• bind_address :MySQL moet extern bereikbaar zijn, dus waarde '0.0.0.0' is verplicht.
• wsrep_sst_methode :Voor MariaDB is de geprefereerde SST-methode mariabackup.
• wsrep_sst_auth :MySQL-gebruiker en wachtwoord (gescheiden door dubbele punt) om snapshotoverdracht uit te voeren. Gewoonlijk specificeren we een gebruiker die de mogelijkheid heeft om een ​​volledige back-up te maken.
• wsrep_node_address :IP-adres voor Galera-communicatie en -replicatie. Gebruik Puppet Facter om het juiste IP-adres te kiezen.
• wsrep_node_name :hostnaam van FQDN. Gebruik Puppet Facter om de juiste hostnaam te kiezen.

Voor op Debian gebaseerde implementaties zal het post-installatiescript proberen de MariaDB-server automatisch te starten. Als we wsrep_on=ON (vlag om Galera in te schakelen) hebben geconfigureerd met het volledige adres in wsrep_cluster_address variabele, zou de server tijdens de installatie uitvallen. Dit komt omdat het geen primaire component heeft om mee te verbinden.

Om een ​​cluster correct te starten in Galera, moet het eerste knooppunt (genaamd bootstrap-knooppunt) worden geconfigureerd met een lege verbindingsreeks (wsrep_cluster_address =gcomm://) om het knooppunt als de primaire component te starten. Je kunt ook het meegeleverde bootstrap-script uitvoeren, genaamd galera_new_cluster, dat in feite hetzelfde doet op de achtergrond.

Inzet van Galera Cluster (MariaDB)

Implementatie van Galera Cluster vereist aanvullende configuratie op de APT-bron om de MariaDB-versierepository van voorkeur te installeren.

Merk op dat Galera-replicatie is ingebed in MariaDB Server en dat er geen extra pakketten hoeven te worden geïnstalleerd. Dat gezegd hebbende, is een extra vlag vereist om Galera in te schakelen met wsrep_on=ON. Zonder deze vlag zal MariaDB fungeren als een zelfstandige server.

In onze op Debian gebaseerde omgeving kan de optie wsrep_on alleen aanwezig zijn in het manifest nadat de eerste implementatie is voltooid (zoals verderop in de implementatiestappen wordt getoond). Dit is om ervoor te zorgen dat de eerste, initiële start fungeert als een zelfstandige server voor Puppet om het knooppunt in te richten voordat het helemaal klaar is om een ​​Galera-knooppunt te worden.

Laten we beginnen met het voorbereiden van de inhoud van het manifest zoals hieronder (wijzig de sectie met globale variabelen indien nodig):

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

Een beetje uitleg is op dit punt nodig. 'wsrep_node_address' moet verwijzen naar hetzelfde IP-adres als wat is gedeclareerd in het wsrep_cluster_address. In deze omgeving hebben onze hosts twee netwerkinterfaces en we willen de tweede interface (genaamd enp0s8) gebruiken voor Galera-communicatie (waar het 192.168.0.0/24-netwerk op is aangesloten). Daarom gebruiken we Puppet Facter om de informatie van het knooppunt te krijgen en deze toe te passen op de configuratie-optie. De rest is vrij duidelijk.

Voer op elk MariaDB-knooppunt de volgende opdracht uit om de catalogus als rootgebruiker toe te passen:

$ puppet agent -t

De catalogus wordt toegepast op elk knooppunt voor installatie en voorbereiding. Als we klaar zijn, moeten we de volgende regel toevoegen aan ons manifest onder de sectie "override_options => mysqld":

      'wsrep_on'                 => 'ON',

Het bovenstaande zal voldoen aan de Galera-vereiste voor MariaDB. Pas vervolgens de catalogus nogmaals toe op elke MariaDB-node:

$ puppet agent -t

Als we klaar zijn, zijn we klaar om ons cluster op te starten. Aangezien dit een nieuw cluster is, kunnen we elk knooppunt kiezen als het referentieknooppunt, ook wel een bootstrap-knooppunt genoemd. Laten we db1.local (192.168.0.161) kiezen en het volgende commando uitvoeren:

$ galera_new_cluster #db1

Zodra het eerste knooppunt is gestart, kunnen we het resterende knooppunt starten met het standaard startcommando (één knooppunt tegelijk):

$ systemctl restart mariadb #db2 and db3

Eenmaal gestart, neem een ​​kijkje in het MySQL-foutlogboek op /var/log/mysql/error.log en zorg ervoor dat het logboek eindigt met de volgende regel:

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

Het bovenstaande vertelt ons dat de knooppunten zijn gesynchroniseerd met de groep. We kunnen dan de status verifiëren door het volgende commando te gebruiken:

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

Zorg ervoor dat op alle knooppunten de wsrep_cluster_size , wsrep_cluster_status en wsrep_local_state_comment zijn respectievelijk 3, "Primair" en "Gesynchroniseerd".

MySQL-beheer

Deze module kan worden gebruikt om een ​​aantal MySQL-beheertaken uit te voeren...

• configuratie-opties (wijzigen, toepassen, aangepaste configuratie)
• databasebronnen (database, gebruiker, subsidies)
• back-up (maken, plannen, back-up gebruiker, opslag)
• eenvoudig herstel (alleen mysqldump)
• installatie/activering van plug-ins

Servicecontrole

De veiligste manier bij het inrichten van Galera Cluster met Puppet is om alle servicecontrolehandelingen handmatig af te handelen (laat Puppet dit niet doen). Voor een eenvoudige cluster-rolling-restart zou de standaard serviceopdracht voldoende zijn. Voer de volgende opdracht één knooppunt tegelijk uit.

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

Als er echter een netwerkpartitie plaatsvindt en er geen primaire component beschikbaar is (controleer met wsrep_cluster_status ), moet het meest up-to-date knooppunt worden opgestart om het cluster weer operationeel te maken zonder gegevensverlies. U kunt de stappen volgen zoals weergegeven in de bovenstaande implementatiesectie. Voor meer informatie over het bootstrapping-proces met voorbeelden van scenario's, hebben we dit in detail besproken in deze blogpost, How to Bootstrap MySQL of MariaDB Galera Cluster.

Databasebron

Gebruik de klasse mysql::db om ervoor te zorgen dat er een database met bijbehorende gebruiker en privileges aanwezig is, bijvoorbeeld:

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

De bovenstaande definitie kan aan elk knooppunt worden toegewezen, aangezien elk knooppunt in een Galera-cluster een master is.

Back-up maken en terugzetten

Aangezien we een SST-gebruiker hebben gemaakt met behulp van de xtrabackup-klasse, zal Puppet alle vereisten voor de back-uptaak ​​configureren:de back-upgebruiker maken, het bestemmingspad voorbereiden, eigendom en toestemming toewijzen, de cron-taak instellen en de te gebruiken back-opdrachtopties instellen in het meegeleverde back-upscript. Elk knooppunt wordt geconfigureerd met twee back-uptaken (een voor wekelijks vol en een ander voor dagelijks incrementeel) standaard ingesteld op 23:05 uur, zoals je kunt zien aan de crontab-uitvoer:

$ 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

Als u in plaats daarvan mysqldump wilt plannen, gebruikt u de klasse mysql::server::backup om de back-upbronnen voor te bereiden. Stel dat we de volgende verklaring in ons manifest hebben:

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

Het bovenstaande vertelt Puppet om het back-upscript te configureren op /usr/local/sbin/mysqlbackup.sh en het elke dag om 23:30 uur in te plannen. Als u onmiddellijk een back-up wilt maken, roept u eenvoudig:

$ mysqlbackup.sh

Voor het herstel ondersteunt de module alleen herstel met de back-upmethode mysqldump, door het SQL-bestand rechtstreeks in de database te importeren met behulp van de mysql::db-klasse, bijvoorbeeld:

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
}

Het SQL-bestand wordt slechts één keer geladen en niet bij elke run, tenzij force_sql => true wordt gebruikt.

Configuratiebeheer

In dit voorbeeld hebben we manage_config_file => true met override_options gebruikt om onze configuratieregels te structureren die later door Puppet naar buiten zullen worden gepusht. Elke wijziging aan het manifestbestand geeft alleen de inhoud van het MySQL-doelconfiguratiebestand weer. Deze module laadt de configuratie niet in runtime en start de MySQL-service ook niet opnieuw nadat de wijzigingen in het configuratiebestand zijn doorgevoerd. Het is de verantwoordelijkheid van de systeembeheerder om de service opnieuw te starten om de wijzigingen te activeren.

Om een ​​aangepaste MySQL-configuratie toe te voegen, kunnen we extra bestanden in "includedir" plaatsen, standaard in /etc/mysql/conf.d. Dit stelt ons in staat om instellingen te overschrijven of extra toe te voegen, wat handig is als u override_options niet gebruikt in de mysql::server-klasse. Het gebruik van het Puppet-sjabloon wordt hier ten zeerste aanbevolen. Plaats het aangepaste configuratiebestand onder de modulesjabloonmap (standaard , /etc/puppetlabs/code/environments/production/modules/mysql/templates) en voeg vervolgens de volgende regels toe aan het manifest:

# 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

Wist u dat u de implementatie van MySQL of MariaDB Galera ook kunt automatiseren met ClusterControl? U kunt de ClusterControl Puppet-module gebruiken om deze te installeren, of u kunt deze eenvoudig downloaden van onze website.

In vergelijking met ClusterControl kunt u de volgende verschillen verwachten:

• Een beetje een leercurve om Puppet-syntaxis, opmaak en structuren te begrijpen voordat je manifesten kunt schrijven.
• Het manifest moet regelmatig worden getest. Het is heel gebruikelijk dat u een compilatiefout krijgt op de code, vooral als de catalogus voor de eerste keer wordt toegepast.
• Puppet gaat ervan uit dat de codes idempotent zijn. De test/controleer/verifieer voorwaarde valt onder de verantwoordelijkheid van de auteur om te voorkomen dat een draaiend systeem wordt verstoord.
• Puppet vereist een agent op het beheerde knooppunt.
• Achterwaartse incompatibiliteit. Sommige oude modules zouden niet correct werken op de nieuwe versie.
• Database/host-monitoring moet apart worden ingesteld.

De implementatiewizard van ClusterControl begeleidt het implementatieproces:

U kunt ook de opdrachtregelinterface van ClusterControl met de naam "s9s" gebruiken om vergelijkbare resultaten te bereiken. Met de volgende opdracht wordt een Percona XtraDB-cluster met drie knooppunten gemaakt (waarvan vooraf geen wachtwoord is geconfigureerd voor alle knooppunten):

$ 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

Bovendien ondersteunt ClusterControl de implementatie van load balancers voor Galera Cluster - HAproxy, ProxySQL en MariaDB MaxScale - samen met een virtueel IP-adres (geleverd door Keepalive) om een ​​enkel storingspunt voor uw databaseservice te elimineren.

Na de implementatie kunnen knooppunten/clusters worden bewaakt en volledig worden beheerd door ClusterControl, inclusief automatische foutdetectie, automatisch herstel, back-upbeheer, load balancer-beheer, het koppelen van asynchrone slave, configuratiebeheer, enzovoort. Al deze zijn gebundeld in één product. Gemiddeld is uw databasecluster binnen 30 minuten operationeel. Wat het nodig heeft, is alleen SSH zonder wachtwoord naar de doelknooppunten.

Je kunt ook een reeds draaiende Galera-cluster importeren, geïmplementeerd door Puppet (of op een andere manier) in ClusterControl om je cluster een boost te geven met alle coole functies die ermee gepaard gaan. De community-editie (voor altijd gratis!) biedt implementatie en monitoring.

In de volgende aflevering zullen we u door de implementatie van MySQL load balancer leiden met behulp van Puppet. Blijf op de hoogte!