Автоматизация на бази данни с Puppet:Разгръщане на MySQL и MariaDB репликация

Puppet е инструмент за управление на системи с отворен код за централизиране и автоматизиране на управлението на конфигурацията. Инструментите за автоматизация помагат да се сведат до минимум ръчните и повтарящи се задачи и могат да спестят много време.

Puppet работи по подразбиране в модел сървър/агент. Агентите извличат своя „каталог“ (крайно желано състояние) от капитана и го прилагат локално. След това те докладват обратно на сървъра. Каталогът се изчислява в зависимост от „фактите“, които машината изпраща на сървъра, въвеждането на потребителя (параметри) и модулите (изходен код).

В този блог ще ви покажем как да разгръщате и управлявате MySQL/MariaDB инстанции чрез Puppet. Има редица технологии около MySQL/MariaDB, като репликация (главен-подчинен, Galera или групова репликация за MySQL), SQL-съзнателни балансатори на натоварване като ProxySQL и MariaDB MaxScale, инструменти за архивиране и възстановяване и много други, които ще разгледаме в това блог серия. Също така има много модули, налични в Puppet Forge, изградени и поддържани от общността, които могат да ни помогнат да опростим кода и да избегнем преоткриването на колелото. В този блог ще се съсредоточим върху MySQL репликацията.

puppetlabs/mysql

Това е най-популярният Puppet модул за MySQL и MariaDB (и вероятно най-добрият на пазара) в момента. Този модул управлява както инсталирането, така и конфигурацията на MySQL, както и разширяването на Puppet, за да позволи управление на MySQL ресурси, като бази данни, потребители и грантове.

Модулът се поддържа официално от екипа на Puppet (чрез хранилището на puppetlabs Github) и поддържа всички основни версии на Puppet Enterprise 2019.1.x, 2019.0.x, 2018.1.x, Puppet>=5.5.10 <7.0.0 на RedHat, Ubunt Платформи Debian, SLES, Scientific, CentOS, OracleLinux. Потребителят има опции да инсталира MySQL, MariaDB и Percona Server чрез персонализиране на хранилището на пакети

Следващият пример показва как да разположите MySQL сървър. На puppet master инсталирайте модула MySQL и създайте файла на манифеста:

(puppet-master)$ puppet module install puppetlabs/mysql
(puppet-master)$ vim /etc/puppetlabs/code/environments/production/manifests/mysql.pp

Добавете следните редове:

node "db1.local" {
  class { '::mysql::server':
    root_password => 't5[sb^D[+rt8bBYu',
    remove_default_accounts => true,
    override_options => {
      'mysqld' => {
        'log_error' => '/var/log/mysql.log',
        'innodb_buffer_pool_size' => '512M'
      }
      'mysqld_safe' => {
        'log_error' => '/var/log/mysql.log'
      }
    }
  }
}

След това на възела на марионетния агент изпълнете следната команда, за да приложите конфигурационния каталог:

(db1.local)$ puppet agent -t

При първото стартиране може да получите следната грешка:

Info: Certificate for db1.local has not been signed yet

Просто изпълнете следната команда на Puppet master, за да подпишете сертификата:

(puppet-master)$ puppetserver ca sign --certname=db1.local
Successfully signed certificate request for db1.local

Опитайте отново с командата "puppet agent -t", за да инициирате повторно връзката с подписания сертификат.

Горната дефиниция ще инсталира стандартните пакети, свързани с MySQL, налични в хранилището за разпространение на ОС. Например в Ubuntu 18.04 (Bionic) ще получите инсталирани пакети MySQL 5.7.26:

(db1.local) $ dpkg --list | grep -i mysql
ii  mysql-client-5.7                5.7.26-0ubuntu0.18.04.1           amd64        MySQL database client binaries
ii  mysql-client-core-5.7           5.7.26-0ubuntu0.18.04.1           amd64        MySQL database core client binaries
ii  mysql-common                    5.8+1.0.4                         all          MySQL database common files, e.g. /etc/mysql/my.cnf
ii  mysql-server                    5.7.26-0ubuntu0.18.04.1           all          MySQL database server (metapackage depending on the latest version)
ii  mysql-server-5.7                5.7.26-0ubuntu0.18.04.1           amd64        MySQL database server binaries and system database setup
ii  mysql-server-core-5.7           5.7.26-0ubuntu0.18.04.1           amd64        MySQL database server binaries

Можете да изберете други доставчици като Oracle, Percona или MariaDB с допълнителна конфигурация на хранилището (вижте раздела README за подробности). Следната дефиниция ще инсталира пакетите MariaDB от хранилището на MariaDB apt (изисква модул apt Puppet):

$ puppet module install puppetlabs/apt
$ vim /etc/puppetlabs/code/environments/production/manifests/mariadb.pp
# include puppetlabs/apt module
include apt

# apt definition for MariaDB 10.3
apt::source { 'mariadb':
  location => 'http://sgp1.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,
  },
}

# MariaDB configuration
class {'::mysql::server':
  package_name     => 'mariadb-server',
  service_name     => 'mysql',
  root_password    => 't5[sb^D[+rt8bBYu',
  override_options => {
    mysqld => {
      'log-error' => '/var/log/mysql/mariadb.log',
      'pid-file'  => '/var/run/mysqld/mysqld.pid',
    },
    mysqld_safe => {
      'log-error' => '/var/log/mysql/mariadb.log',
    },
  }
}

# Deploy on db2.local
node "db2.local" {
Apt::Source['mariadb'] ->
Class['apt::update'] ->
Class['::mysql::server']
}

Обърнете внимание на стойността на ключ->id, където има специален начин за извличане на 40-знаковия идентификатор, както е показано в тази статия:

$ sudo apt-key adv --recv-keys --keyserver hkp://keyserver.ubuntu.com:80 0xF1656F24C74CD1D8
$ apt-key adv --list-public-keys --with-fingerprint --with-colons
uid:-::::1459359915::6DC53DD92B7A8C298D5E54F950371E2B8950D2F2::MariaDB Signing Key <[email protected]>::::::::::0:
sub:-:4096:1:C0F47944DE8F6914:1459359915::::::e::::::23:
fpr:::::::::A6E773A1812E4B8FD94024AAC0F47944DE8F6914:

Където стойността на идентификатора е в реда, започващ с „fpr“, което е „A6E773A1812E4B8FD94024AAC0F47944DE8F6914“.

След като каталогът Puppet бъде приложен, можете директно да получите достъп до MySQL конзолата като root без изрична парола, тъй като модулът конфигурира и управлява ~/.my.cnf автоматично. Ако искаме да нулираме root паролата на нещо друго, просто променете стойността root_password в дефиницията на Puppet и приложите каталога към възела на агента.

Разгръщане на MySQL репликация

За да разгърнете настройка за MySQL репликация, трябва да създадете поне два типа конфигурация, за да разделите главната и подчинената конфигурация. Главният ще има деактивиран само четене, за да позволи четене/запис, докато подчинените ще бъдат конфигурирани с активирано само четене. В този пример ще използваме репликация, базирана на GTID, за да опростим конфигурацията (тъй като конфигурацията на всички възли ще бъде много сходна). Ще искаме да инициираме връзка за репликация към главната, веднага след като подчинената е включена.

Да предположим, че имаме 3 възела MySQL главен-подчинен репликация:

db1.local - главен
db2.local - подчинен номер 1
db3.local - подчинен номер 2

За да отговорим на горните изисквания, можем да запишем нашия манифест до нещо подобно:

# Puppet manifest for MySQL GTID-based replication MySQL 5.7 on Ubuntu 18.04 (Puppet v6.4.2) 
# /etc/puppetlabs/code/environments/production/manifests/replication.pp

# node's configuration
class mysql {
  class {'::mysql::server':
    root_password           => '[email protected]#',
    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',
        'server-id'               => $mysql_server_id,
        'read_only'               => $mysql_read_only,
        'gtid-mode'               => 'ON',
        'enforce_gtid_consistency'=> 'ON',
        'log-slave-updates'       => 'ON',
        'sync_binlog'             => 1,
        'log-bin'                 => '/var/log/mysql-bin',
        'read_only'               => 'OFF',
        'binlog-format'           => 'ROW',
        'log-error'               => '/var/log/mysql/error.log',
        'report_host'             => ${fqdn},
        'innodb_buffer_pool_size' => '512M'
      },
      'mysqld_safe' => {
        'log-error'               => '/var/log/mysql/error.log'
      }
    }
  }
  
  # create slave user
  mysql_user { "${slave_user}@192.168.0.%":
      ensure        => 'present',
      password_hash => mysql_password("${slave_password}")
  }

  # grant privileges for slave user
  mysql_grant { "${slave_user}@192.168.0.%/*.*":
      ensure        => 'present',
      privileges    => ['REPLICATION SLAVE'],
      table         => '*.*',
      user          => "${slave_user}@192.168.0.%"
  }

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

  # executes change master only if $master_host is defined
  if $master_host {
    exec { 'change master':
      path    => '/usr/bin:/usr/sbin:/bin',
      command => "mysql --defaults-extra-file=/root/.my.cnf -e \"CHANGE MASTER TO MASTER_HOST = '$master_host', MASTER_USER = '$slave_user', MASTER_PASSWORD = '$slave_password', MASTER_AUTO_POSITION = 1; START SLAVE;\"",
      unless  => "mysql --defaults-extra-file=/root/.my.cnf -e 'SHOW SLAVE STATUS\G' | grep 'Slave_SQL_Running: Yes'"
    }
  }
}

## node assignment

# global vars
$master_host = undef
$slave_user = 'slave'
$slave_password = 'Replicas123'

# master
node "db1.local" {
  $mysql_server_id = '1'
  $mysql_read_only = 'OFF'
  include mysql
}

# slave1
node "db2.local" {
  $mysql_server_id = '2'
  $mysql_read_only = 'ON'
  $master_host = 'db1.local'
  include mysql
}

# slave2
node "db3.local" {
  $mysql_server_id = '3'
  $mysql_read_only = 'ON'
  $master_host = 'db1.local'
  include mysql
}

Принуди агента да приложи каталога:

(all-mysql-nodes)$ puppet agent -t

На главния (db1.local) можем да проверим всички свързани подчинени устройства:

mysql> SHOW SLAVE HOSTS;
+-----------+-----------+------+-----------+--------------------------------------+
| Server_id | Host      | Port | Master_id | Slave_UUID                           |
+-----------+-----------+------+-----------+--------------------------------------+
|         3 | db3.local | 3306 |         1 | 2d0b14b6-8174-11e9-8bac-0273c38be33b |
|         2 | db2.local | 3306 |         1 | a9dfa4c7-8172-11e9-8000-0273c38be33b |
+-----------+-----------+------+-----------+--------------------------------------+

Обърнете допълнително внимание на секцията "exec { 'change master':", където това означава, че MySQL команда ще бъде изпълнена за иницииране на връзката за репликация, ако условието е изпълнено. Всички "exec" ресурси, изпълнявани от Puppet, трябва да са идемпотентни, което означава, че операцията ще има същия ефект, независимо дали я стартирате веднъж или 10 001 пъти. Има редица атрибути на условие, които можете да използвате като "освен", "само ако" и "създаване", за да защитите правилното състояние и да предотвратите объркането на Puppet с вашата настройка. Можете да изтриете/коментирате този раздел, ако искате да инициирате ръчно връзката за репликация.

Управление на MySQL

Този модул може да се използва за изпълнение на редица задачи за управление на MySQL:

опции за конфигуриране (промяна, прилагане, персонализирана конфигурация)
ресурси на база данни (база данни, потребител, безвъзмездни средства)
резервно копие (създаване, планиране, архивиране на потребител, съхранение)
просто възстановяване (само за mysqldump)
инсталиране/активиране на плъгини

Ресурс за база данни

Както можете да видите в примерния манифест по-горе, ние сме дефинирали два MySQL ресурса - mysql_user и mysql_grant - за създаване на потребител и съответно предоставяне на привилегии за потребителя. Можем също да използваме класа mysql::db, за да гарантираме наличието на база данни със свързани потребители и привилегии, например:

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

Обърнете внимание, че при репликацията на MySQL всички записи трябва да се извършват само на главния. Така че, уверете се, че горният ресурс е назначен на главния. В противен случай може да възникне грешна транзакция.

Архивиране и възстановяване

Обикновено се изисква само един резервен хост за целия клъстер (освен ако не копирате подмножество от данни). Можем да използваме класа mysql::server::backup, за да подготвим резервните ресурси. Да предположим, че имаме следната декларация в нашия манифест:

  # 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',
    optional_args     => ['--set-gtid-purged=OFF'] #extra argument if GTID is enabled
  }

Puppet ще конфигурира всички предпоставки, преди да стартира архивиране - създаване на потребителя за архивиране, подготовка на пътя на дестинацията, присвояване на собственост и разрешение, настройка на заданието на cron и настройка на опциите на командите за архивиране, които да се използват в предоставения скрипт за архивиране, намиращ се на /usr/local /sbin/mysqlbackup.sh. След това зависи от потребителя да стартира или планира скрипта. За да направите незабавно резервно копие, просто извикайте:

$ mysqlbackup.sh

Ако извлечем действителната команда mysqldump въз основа на горното, ето как изглежда тя:

$ mysqldump --defaults-extra-file=/tmp/backup.NYg0TR --opt --flush-logs --single-transaction --events --set-gtid-purged=OFF --all-databases

За тези, които искат да използват други инструменти за архивиране като Percona Xtrabackup, MariaDB Backup (само MariaDB) или MySQL Enterprise Backup, модулът предоставя следните частни класове:

mysql::backup::xtrabackup (Percona Xtrabackup и MariaDB Backup)
mysql::backup::mysqlbackup (MySQL Enterprise Backup)

Примерна декларация с Percona Xtrabackup:

  class { 'mysql::backup::xtrabackup':
    xtrabackup_package_name => 'percona-xtrabackup',
    backupuser     => 'xtrabackup',
    backuppassword => 'passw0rd',
    backupdir      => '/home/xtrabackup',
    backupdirowner => 'mysql',
    backupdirgroup => 'mysql',
    backupdirmode  => '755',
    backupcompress => true,
    backuprotate   => 15,
    include_routines  => true,
    time              => ['23','30'], #backup starts at 11:30PM
    include_triggers  => true,
    maxallowedpacket  => '64M',
    incremental_backups => true
  }

Горното ще планира две резервни копия, едно пълно архивиране всяка неделя в 23:30 часа и едно постепенно архивиране всеки ден с изключение на неделя по едно и също време, както е показано от изхода на заданието на cron след прилагане на горния манифест:

(db1.local)$ crontab -l
# Puppet Name: xtrabackup-weekly
30 23 * * 0 /usr/local/sbin/xtrabackup.sh --target-dir=/home/backup/mysql/xtrabackup --backup
# Puppet Name: xtrabackup-daily
30 23 * * 1-6 /usr/local/sbin/xtrabackup.sh --incremental-basedir=/home/backup/mysql/xtrabackup --target-dir=/home/backup/mysql/xtrabackup/`date +%F_%H-%M-%S` --backup

За повече подробности и опции, налични за този клас (и други класове), вижте справката за опции тук.

Що се отнася до аспекта на възстановяването, модулът поддържа възстановяване само с mysqldump метод за архивиране, като импортира SQL файла директно в базата данни с помощта на класа mysql::db, например:

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 файлът ще се зарежда само веднъж, а не при всяко изпълнение, освен ако не се използва enforce_sql => true.

Опции за конфигуриране

В този пример използвахме manage_config_file => true с override_options, за да структурираме нашите конфигурационни редове, които по-късно ще бъдат изтласкани от Puppet. Всяка промяна на файла на манифеста ще отразява само съдържанието на целевия конфигурационен файл на MySQL. Този модул няма нито да зареди конфигурацията във времето за изпълнение, нито да рестартира услугата MySQL след натискане на промените в конфигурационния файл. Отговорност на системния администратор е да рестартира услугата, за да активира промените.

За да добавим персонализирана конфигурация на MySQL, можем да поставим допълнителни файлове в "includedir", по подразбиране /etc/mysql/conf.d. Това ни позволява да заменим настройките или да добавим допълнителни, което е полезно, ако не използвате override_options в клас mysql::server. Използването на шаблон Puppet е силно препоръчително тук. Поставете персонализирания конфигурационен файл в директорията на шаблоните на модула (по подразбиране на , /etc/puppetlabs/code/environments/production/modules/mysql/templates) и след това добавете следните редове в манифеста:

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

За да приложите специфични за версията параметри, използвайте директивата за версията, например [mysqld-5.5]. Това позволява една конфигурация за различни версии на MySQL.

Puppet срещу ClusterControl

Знаете ли, че можете също така да автоматизирате внедряването на репликация на MySQL или MariaDB с помощта на ClusterControl? Можете да използвате модула ClusterControl Puppet, за да го инсталирате или просто като го изтеглите от нашия уебсайт.

В сравнение с ClusterControl, можете да очаквате следните разлики:

Малко крива на обучение, за да разберете синтаксиса, форматирането, структурите на Puppet, преди да можете да пишете манифести.
Манифестът трябва да се тества редовно. Много често ще получите грешка при компилация на кода, особено ако каталогът се прилага за първи път.
Puppet предполага, че кодовете са идемпотентни. Условието тест/проверка/проверка попада под отговорността на автора, за да избегне забъркването на работеща система.
Puppet изисква агент на управлявания възел.
Обратна несъвместимост. Някои стари модули няма да работят правилно в новата версия.
Наблюдението на базата данни/хост трябва да се настрои отделно.

Помощникът за внедряване на ClusterControl ръководи процеса на внедряване:

Като алтернатива можете да използвате интерфейса на командния ред на ClusterControl, наречен "s9s", за да постигнете подобни резултати. Следната команда създава клъстер за репликация на MySQL с три възела (при условие, че всички възли без парола са били конфигурирани предварително):

$ s9s cluster --create \
  --cluster-type=mysqlreplication \
      --nodes=192.168.0.41?master;192.168.0.42?slave;192.168.0.43?slave;192.168.0.44?master; \
  --vendor=oracle \
  --cluster-name='MySQL Replication 8.0' \
  --provider-version=8.0 \
  --db-admin='root' \
  --db-admin-passwd='$ecR3t^word' \
  --log

Свързани ресурси Puppet Module за ClusterControl – Добавяне на управление и наблюдение към вашите съществуващи клъстери от база данни Как да автоматизирате внедряването на MySQL Galera Cluster с помощта на s9s CLI и Chef Ръководство за DevOps за автоматизация на инфраструктурата на базата данни за електронна търговия – Повторение и слайдове

Поддържат се следните настройки за репликация на MySQL/MariaDB:

Репликация главен-подчинен (базирана на файл/позиция)
Репликация главен-подчинен с GTID (MySQL/Percona)
Репликация главен-подчинен с MariaDB GTID
Репликация главен-главен (полусинхронизирана/асинхронна)
Репликация на веригата главен-подчинен (полусинхронно/асинхронно)

След внедряването възлите/клъстерите могат да бъдат наблюдавани и напълно управлявани от ClusterControl, включително автоматично откриване на неизправност, главен отказ, промоция на подчинен, автоматично възстановяване, управление на архивиране, управление на конфигурацията и т.н. Всичко това е обединено в един продукт. Изданието на общността (безплатно завинаги!) предлага внедряване и наблюдение. Средно клъстерът ви от база данни ще бъде готов и работи в рамките на 30 минути. Това, от което се нуждае, е само SSH без парола към целевите възли.

В следващата част ще ви преведем през разгръщането на Galera Cluster с помощта на същия модул Puppet. Останете на линия!