前回のブログ投稿では、スタンドアロンのMySQLサーバーをデプロイおよび管理するための基本的な手順と、MySQLPuppetモジュールを使用したMySQLレプリケーションのセットアップについて説明しました。この2番目のインストールでは、同様の手順を説明しますが、GaleraClusterのセットアップを使用します。
パペット付きガレラクラスター
ご存知かもしれませんが、GaleraClusterには3つの主要なプロバイダーがあります。
- MySQL Galera Cluster(Codership)
- Percona XtraDBクラスター(Percona)
- MariaDBクラスター(MariaDBによってMariaDBサーバーに組み込まれています)
Galera Clusterデプロイメントの一般的な方法は、負荷分散の目的でデータベースクラスターの上に追加のレイヤーを配置することです。ただし、それは独自の投稿に値する複雑なプロセスです。
Puppet Forgeには、GaleraClusterのデプロイに使用できる多数のPuppetモジュールがあります。ここにそれらのいくつかがあります。
- puppetlabs/mysql-MariaDBガレラのみ
- fraenki /galera-CodershipのPerconaXtraDBクラスターとMySQLガレラ
- edestecd/mariadb-MariaDBクラスターのみ
- filiadata /percona-PerconaXtraDBクラスター
私たちの目的は、マニフェストを記述し、Galera Clusterのデプロイメントを自動化する方法の基本的な理解を提供することであるため、puppetlabs/mysqlモジュールを使用したMariaDBGaleraClusterのデプロイメントについて説明します。その他のモジュールについては、インストール方法の手順やヒントについて、それぞれのドキュメントをいつでも確認できます。
Galera Clusterでは、ノードを開始するときの順序が重要です。新しいクラスターを適切に開始するには、1つのノードを参照ノードとして設定する必要があります。このノードは、クラスターを初期化するために空のホスト接続文字列(gcomm://)で開始されます。このプロセスはブートストラップと呼ばれます。
開始されると、ノードはプライマリコンポーネントになり、残りのノードは標準のmysql startコマンド( systemctl start mysql )を使用して開始できます。 またはservicemysql start )の後にフルホスト接続文字列(gcomm:// db1、db2、db3)が続きます。ブートストラップは、クラスター内の他のノードによって保持されているプライマリコンポーネントがない場合にのみ必要です( wsrep_cluster_status で確認してください) ステータス)。
クラスタの起動プロセスは、ユーザーが明示的に実行する必要があります。データ損失のリスクを回避するために、マニフェスト自体は最初の実行時にクラスターを開始(ノードをブートストラップ)してはなりません。 Puppetマニフェストは、可能な限りべき等になるように作成する必要があることを忘れないでください。すでに実行中のMySQLインスタンスに影響を与えることなく複数回実行するには、マニフェストが安全である必要があります。つまり、主にリポジトリの構成、パッケージのインストール、実行前の構成、およびSSTユーザーの構成に焦点を当てる必要があります。
Galeraには、次の構成オプションが必須です。
- wsrep_on :Galera ClusterのライトセットレプリケーションAPIをオンにするフラグ(MariaDBのみ)。
- wsrep_cluster_name :クラスター名。同じクラスターの一部であるすべてのノードで同一である必要があります。
- wsrep_cluster_address :Galera通信接続文字列。プレフィックスはgcomm://で、その後にノードリストが続き、コンマで区切られます。空のノードリストは、クラスターの初期化を意味します。
- wsrep_provider :Galeraライブラリが存在するパス。パスはオペレーティングシステムによって異なる場合があります。
- bind_address :MySQLは外部から到達可能である必要があるため、値「0.0.0.0」が必須です。
- wsrep_sst_method :MariaDBの場合、推奨されるSSTメソッドはmariabackupです。
- wsrep_sst_auth :スナップショット転送を実行するためのMySQLユーザーとパスワード(コロンで区切られています)。通常、完全バックアップを作成できるユーザーを指定します。
- wsrep_node_address :Galera通信およびレプリケーション用のIPアドレス。 Puppetfacterを使用して正しいIPアドレスを選択してください。
- wsrep_node_name :FQDNのホスト名。 Puppetfacterを使用して正しいホスト名を選択してください。
Debianベースのデプロイメントの場合、インストール後のスクリプトはMariaDBサーバーを自動的に起動しようとします。 wsrep_cluster_addressの完全なアドレスを使用してwsrep_on=ON(Galeraを有効にするフラグ)を構成した場合 変数の場合、サーバーはインストール中に失敗します。これは、接続する主要なコンポーネントがないためです。
Galeraでクラスターを適切に開始するには、最初のノード(ブートストラップノードと呼ばれる)を空の接続文字列(wsrep_cluster_address =gcomm://)で構成して、ノードをプライマリコンポーネントとして開始する必要があります。また、galera_new_clusterと呼ばれる提供されたブートストラップスクリプトを実行することもできます。このスクリプトは、基本的にバックグラウンドで同様のことを行います。
Galera Cluster(MariaDB)の導入
Galera Clusterをデプロイするには、優先するMariaDBバージョンリポジトリをインストールするには、APTソースで追加の構成が必要です。
GaleraレプリケーションはMariaDBサーバー内に埋め込まれており、追加のパッケージをインストールする必要がないことに注意してください。そうは言っても、wsrep_on=ONを使用してGaleraを有効にするには追加のフラグが必要です。このフラグがないと、MariaDBはスタンドアロンサーバーとして機能します。
Debianベースの環境では、wsrep_onオプションは、最初のデプロイメントが完了した後にのみマニフェストに表示できます(デプロイメントステップのさらに下に示されています)。これは、最初の最初の起動が、Galeraノードになる準備が完全に整う前にノードをプロビジョニングするためのPuppetのスタンドアロンサーバーとして機能することを保証するためです。
以下のようにマニフェストの内容を準備することから始めましょう(必要に応じてグローバル変数セクションを変更します):
# 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'は、wsrep_cluster_addressで宣言されたものと同じIPアドレスを指している必要があります。この環境では、ホストに2つのネットワークインターフェイスがあり、Galera通信(192.168.0.0/24ネットワークが接続されている場所)に2番目のインターフェイス(enp0s8と呼ばれる)を使用します。そのため、Puppet facterを使用してノードから情報を取得し、それを構成オプションに適用します。残りはかなり自明です。
すべてのMariaDBノードで、次のコマンドを実行して、カタログをrootユーザーとして適用します。
$ puppet agent -t
カタログは、インストールと準備のために各ノードに適用されます。完了したら、マニフェストの「override_options=>mysqld」セクションに次の行を追加する必要があります。
'wsrep_on' => 'ON',
上記は、MariaDBのGalera要件を満たします。次に、すべてのMariaDBノードにカタログをもう一度適用します。
$ puppet agent -t
完了すると、クラスターをブートストラップする準備が整います。これは新しいクラスターであるため、任意のノードを参照ノード(ブートストラップノード)として選択できます。 db1.local(192.168.0.161)を選択して、次のコマンドを実行してみましょう。
$ galera_new_cluster #db1
最初のノードが開始されると、標準の開始コマンドを使用して残りのノードを開始できます(一度に1つのノード):
$ systemctl restart mariadb #db2 and db3
開始したら、/ var / log / mysql / error.logにあるMySQLエラーログを確認し、ログが次の行で終わることを確認します。
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のみ)
- プラグインのインストール/アクティベーション
サービス制御
Puppetを使用してGaleraClusterをプロビジョニングする場合の最も安全な方法は、すべてのサービス制御操作を手動で処理することです(Puppetに処理させないでください)。単純なクラスターローリングリスタートの場合、標準のサービスコマンドで十分です。次のコマンドを一度に1ノードずつ実行します。
$ systemctl restart mariadb # Systemd
$ service mariadb restart # SysVinit
ただし、ネットワークパーティションが発生し、プライマリコンポーネントが利用できない場合は、 wsrep_cluster_statusで確認してください。 )、データを失うことなくクラスターを操作可能に戻すには、最新のノードをブートストラップする必要があります。上記の展開セクションに示されている手順に従うことができます。シナリオ例を使用したブートストラッププロセスの詳細については、このブログ投稿「MySQLまたはMariaDBGaleraClusterをブートストラップする方法」で詳しく説明しています。
データベースリソース
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']
}
ガレラクラスター内のすべてのノードがマスターであるため、上記の定義は任意のノードに割り当てることができます。
バックアップと復元
xtrabackupクラスを使用してSSTユーザーを作成したため、Puppetはバックアップジョブのすべての前提条件を構成します。バックアップユーザーの作成、宛先パスの準備、所有権と権限の割り当て、cronジョブの設定、および使用するバックアップコマンドオプションの設定です。提供されているバックアップスクリプトで。 crontabの出力からわかるように、すべてのノードは2つのバックアップジョブ(1つは週単位のフル用、もう1つは日単位の増分用)でデフォルトで午後11時5分に構成されます。
$ 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でバックアップスクリプトを構成し、毎日午後11時30分にスケジュールするように指示しています。すぐにバックアップを作成する場合は、次を呼び出します。
$ mysqlbackup.sh
復元の場合、モジュールはmysql::dbクラスを使用してSQLファイルをデータベースに直接インポートすることにより、mysqldumpバックアップメソッドを使用した復元のみをサポートします。例:
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が使用されていない限り、実行ごとではなく1回だけロードされます。
構成管理
この例では、manage_config_file => trueとoverride_optionsを使用して、後でPuppetによってプッシュされる構成行を構造化しました。マニフェストファイルへの変更は、ターゲットのMySQL構成ファイルの内容のみを反映します。このモジュールは、構成をランタイムにロードせず、変更を構成ファイルにプッシュした後にMySQLサービスを再起動しません。変更をアクティブ化するためにサービスを再起動するのは、システム管理者の責任です。
カスタムMySQL構成を追加するために、追加のファイルを「includedir」(デフォルトは/etc/mysql/conf.d)に配置できます。これにより、設定を上書きしたり、設定を追加したりできます。これは、mysql::serverクラスでoverride_optionsを使用しない場合に役立ちます。ここでは、Puppetテンプレートを使用することを強くお勧めします。カスタム構成ファイルをモジュールテンプレートディレクトリ(デフォルトは/ etc / puppetlabs / code / environment / product / 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')
}
データベース管理に関するSevereninesDevOpsガイドオープンソースデータベースを自動化および管理するために知っておくべきことを学ぶ無料でダウンロード Puppet vs ClusterControl
ClusterControlを使用してMySQLまたはMariaDBGaleraのデプロイを自動化することもできることをご存知ですか? ClusterControl Puppetモジュールを使用してインストールするか、当社のWebサイトからダウンロードするだけです。
ClusterControlと比較すると、次の違いが予想されます。
- マニフェストを作成する前に、Puppetの構文、フォーマット、構造を理解するための少しの学習曲線。
- マニフェストは定期的にテストする必要があります。特にカタログを初めて適用する場合は、コードでコンパイルエラーが発生することがよくあります。
- Puppetは、コードがべき等であると想定しています。テスト/チェック/検証の条件は、実行中のシステムを台無しにしないようにする作成者の責任になります。
- Puppetには管理対象ノードにエージェントが必要です。
- 後方互換性。一部の古いモジュールは、新しいバージョンでは正しく実行されませんでした。
- データベース/ホストの監視は個別に設定する必要があります。
ClusterControlのデプロイメントウィザードは、デプロイメントプロセスをガイドします:
または、「s9s」と呼ばれるClusterControlコマンドラインインターフェイスを使用して、同様の結果を得ることができます。次のコマンドは、3ノードの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のPuppetモジュール-既存のデータベースクラスターへの管理と監視の追加s9sCLIとChefDatabaseAutomationを使用してMySQLGaleraClusterのデプロイを自動化する方法:MySQLとMariaDBレプリケーションのデプロイ さらに、ClusterControlは、Galera Clusterのロードバランサー(HAproxy、ProxySQL、MariaDB MaxScale)と仮想IPアドレス(Keepalivedが提供)の展開をサポートし、データベースサービスの単一障害点を排除します。
展開後、ノード/クラスターは、自動障害検出、自動回復、バックアップ管理、ロードバランサー管理、非同期スレーブの接続、構成管理などを含め、ClusterControlによって監視および完全に管理できます。これらはすべて1つの製品にまとめられています。平均して、データベースクラスターは30分以内に稼働します。必要なのは、ターゲットノードへのパスワードなしのSSHだけです。
また、Puppet(またはその他の手段)によってデプロイされた、すでに実行中のGalera ClusterをClusterControlにインポートして、クラスターに付属するすべての優れた機能をクラスターに追加することもできます。コミュニティエディション(永久に無料です!)は、展開と監視を提供します。
次のエピソードでは、Puppetを使用したMySQLロードバランサーのデプロイについて説明します。しばらくお待ちください!