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

В предишната публикация в блога ви показахме някои основни стъпки за разполагане и управление на самостоятелен MySQL сървър, както и настройка на MySQL Replication с помощта на модула MySQL Puppet. В тази втора инсталация ще покрием подобни стъпки, но сега с настройка на Galera Cluster.

Galera Cluster с кукла

Както може би знаете, Galera Cluster има три основни доставчици:

• MySQL Galera Cluster (Codership)
• Percona XtraDB Cluster (Percona)
• Клъстер MariaDB (вграден в MariaDB сървър от MariaDB)

Обичайна практика при внедряването на Galera Cluster е да има допълнителен слой, разположен върху клъстера на базата данни за целите на балансиране на натоварването. Това обаче е сложен процес, който заслужава своя собствена публикация.

В Puppet Forge има редица модули Puppet, които могат да се използват за разгръщане на клъстер Galera. Ето някои от тях...

• puppetlabs/mysql – само MariaDB Galera
• fraenki/galera - Percona XtraDB Cluster и MySQL Galera от Codership
• edestecd/mariadb – само MariaDB клъстер
• filiadata/percona - Percona XtraDB Cluster

Тъй като нашата цел е да предоставим основно разбиране за това как да напишем манифест и да автоматизираме разгръщането за Galera Cluster, ние ще покрием внедряването на MariaDB Galera Cluster с помощта на модула puppetlabs/mysql. За други модули винаги можете да разгледате съответната им документация за инструкции или съвети как да инсталирате.

В Galera Cluster подреждането при стартиране на възел е от решаващо значение. За да стартирате правилно нов нов клъстер, един възел трябва да бъде настроен като референтен възел. Този възел ще бъде стартиран с низ за връзка с празен хост (gcomm://), за да инициализира клъстера. Този процес се нарича bootstrapping.

Веднъж стартиран, възелът ще стане основен компонент, а останалите възли могат да бъдат стартирани с помощта на стандартната команда mysql start (systemctl start mysql или Стартиране на mysql ), последван от низ за връзка с пълен хост (gcomm://db1,db2,db3). Bootstrapping се изисква само ако няма първичен компонент, задържан от друг възел в клъстера (проверете с wsrep_cluster_status състояние).

Процесът на стартиране на клъстер трябва да се изпълнява изрично от потребителя. Самият манифест НЕ трябва да стартира клъстера (зареждане на всеки възел) при първото изпълнение, за да се избегне всякакъв риск от загуба на данни. Не забравяйте, че манифестът на Puppet трябва да бъде написан, за да бъде възможно най-идемпотентен. Манифестът трябва да е безопасен, за да бъде изпълнен няколко пъти, без да засяга вече работещите MySQL екземпляри. Това означава, че трябва да се съсредоточим основно върху конфигурацията на хранилището, инсталирането на пакети, конфигурацията преди стартиране и конфигурацията на потребителя на SST.

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

• wsrep_on :Флаг за включване на API за репликация на набор за запис за Galera Cluster (само MariaDB).
• wsrep_cluster_name :Името на клъстера. Трябва да е идентичен на всички възли, които са част от един и същ клъстер.
• wsrep_cluster_address :низът за комуникационна връзка Galera, префикс с gcomm:// и последван от списък с възли, разделени със запетая. Празен списък с възли означава инициализация на клъстера.
• wsrep_provider :Пътеката, където се намира библиотеката Галера. Пътят може да е различен в зависимост от операционната система.
• адрес_на_свързване :MySQL трябва да бъде достъпен външно, така че стойността '0.0.0.0' е задължителна.
• wsrep_sst_method :За MariaDB предпочитаният SST метод е mariabackup.
• wsrep_sst_auth :MySQL потребител и парола (разделени с двоеточие) за извършване на прехвърляне на моментна снимка. Обикновено ние посочваме потребител, който има способността да създаде пълен архив.
• wsrep_node_address :IP адрес за комуникация и репликация на Galera. Използвайте Puppet facter, за да изберете правилния IP адрес.
• wsrep_node_name :име на хост на FQDN. Използвайте Puppet facter, за да изберете правилното име на хост.

За базирани на Debian разгръщания, скриптът след инсталиране ще се опита да стартира сървъра на MariaDB автоматично. Ако сме конфигурирали wsrep_on=ON (флаг за активиране на Galera) с пълния адрес в wsrep_cluster_address променлива, сървърът ще се провали по време на инсталацията. Това е така, защото няма основен компонент за свързване.

За да стартирате правилно клъстер в Galera, първият възел (наречен bootstrap node) трябва да бъде конфигуриран с празен низ за връзка (wsrep_cluster_address =gcomm://), за да инициира възела като основен компонент. Можете също да стартирате предоставения скрипт за стартиране, наречен galera_new_cluster, който по същество прави подобно нещо само във фонов режим.

Разгръщане на Galera Cluster (MariaDB)

Разгръщането на Galera Cluster изисква допълнителна конфигурация на източника на APT, за да инсталирате предпочитаното хранилище на версията на MariaDB.

Имайте предвид, че репликацията на Galera е вградена в MariaDB Server и не изисква инсталиране на допълнителни пакети. Като се има предвид това, е необходим допълнителен флаг, за да активирате Galera чрез използване на wsrep_on=ON. Без този флаг MariaDB ще действа като самостоятелен сървър.

В нашата базирана на Debian среда, опцията wsrep_on може да присъства в манифеста само след завършване на първото внедряване (както е показано по-долу в стъпките за внедряване). Това е, за да се гарантира, че първото, първоначално стартиране действа като самостоятелен сървър за Puppet, за да осигури възела, преди той да е напълно готов да бъде възел на Galera.

Нека започнем с подготовката на съдържанието на манифеста, както е показано по-долу (променете раздела за глобални променливи, ако е необходимо):

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

На този етап е необходимо малко обяснение. 'wsrep_node_address' трябва да бъде насочен към същия IP адрес като този, който е деклариран в wsrep_cluster_address. В тази среда нашите хостове имат два мрежови интерфейса и ние искаме да използваме втория интерфейс (наречен enp0s8) за комуникация на Galera (където е свързана мрежа 192.168.0.0/24). Ето защо използваме Puppet facter, за да получим информацията от възела и да я приложим към опцията за конфигурация. Останалото е доста разбираемо.

На всеки възел на MariaDB изпълнете следната команда, за да приложите каталога като root потребител:

$ puppet agent -t

Каталогът ще бъде приложен към всеки възел за инсталиране и подготовка. След като приключим, трябва да добавим следния ред в нашия манифест в секцията "override_options => mysqld":

      'wsrep_on'                 => 'ON',

Горното ще удовлетвори изискването на Galera за MariaDB. След това приложете каталога на всеки възел на MariaDB още веднъж:

$ puppet agent -t

След като приключим, ние сме готови да стартираме нашия клъстер. Тъй като това е нов клъстер, можем да изберем всеки възел да бъде референтен възел, известен още като начален възел. Нека изберем db1.local (192.168.0.161) и изпълним следната команда:

$ galera_new_cluster #db1

След като първият възел бъде стартиран, можем да стартираме останалия възел със стандартната команда за стартиране (един възел в даден момент):

$ systemctl restart mariadb #db2 and db3

След като започнете, надникнете в регистъра за грешки на MySQL в /var/log/mysql/error.log и се уверете, че дневникът завършва със следния ред:

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

Горното ни казва, че възлите са синхронизирани с групата. След това можем да проверим състоянието, като използваме следната команда:

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

Уверете се, че на всички възли wsrep_cluster_size , wsrep_cluster_status и wsrep_local_state_comment са 3, „Основно“ и „Синхронизирано“ съответно.

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

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

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

Управление на услугите

Най-сигурният начин при обезпечаване на Galera Cluster с Puppet е да обработвате всички операции за контрол на услугите ръчно (не позволявайте на Puppet да ги обработва). За просто рестартиране на клъстера, стандартната команда за обслужване би свършила работа. Изпълнете следната команда един възел в даден момент.

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

Въпреки това, в случай на мрежов дял и няма наличен основен компонент (проверете с wsrep_cluster_status ), най-актуалният възел трябва да бъде стартиран, за да върне клъстера обратно работещ без загуба на данни. Можете да следвате стъпките, както е показано в горния раздел за внедряване. За да научите повече за процеса на стартиране с примерен сценарий, ние разгледахме това подробно в тази публикация в блога, Как да стартирате MySQL или MariaDB Galera Cluster.

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

Използвайте класа 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']
  } 

Горната дефиниция може да бъде присвоена на всеки възел, тъй като всеки възел в клъстер Galera е главен.

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

Тъй като създадохме SST потребител, използвайки класа xtrabackup, Puppet ще конфигурира всички предпоставки за заданието за архивиране - създаване на потребител за архивиране, подготовка на пътя на дестинацията, присвояване на собственост и разрешение, настройка на заданието за cron и настройка на опциите за резервно копиране, които да се използват в предоставения резервен скрипт. Всеки възел ще бъде конфигуриран с две задачи за архивиране (едно за седмично пълно и друго за ежедневно нарастващо) по подразбиране на 23:05, както можете да разберете от изхода на 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` --backup

Ако вместо това искате да насрочите mysqldump, използвайте класа 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'
  }

Горното казва на Puppet да конфигурира архивния скрипт в /usr/local/sbin/mysqlbackup.sh и да го планира в 23:30 часа всеки ден. Ако искате да направите незабавно резервно копие, просто извикайте:

$ mysqlbackup.sh

За възстановяването модулът поддържа само възстановяване с 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')
}

Puppet срещу ClusterControl

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

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

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

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

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

$ 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

Освен това, ClusterControl поддържа внедряване на балансьори на натоварване за Galera Cluster – HAproxy, ProxySQL и MariaDB MaxScale – заедно с виртуален IP адрес (предоставен от Keepalived), за да елиминира всяка една точка на отказ за вашата услуга за база данни.

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

Можете също така да импортирате вече работещ Galera Cluster, разгърнат от Puppet (или по друг начин) в ClusterControl, за да заредите своя клъстер с всички страхотни функции, които идват с него. Изданието на общността (безплатно завинаги!) предлага внедряване и наблюдение.

В следващия епизод ще ви преведем през разгръщането на балансиране на натоварването на MySQL с помощта на Puppet. Останете на линия!