前のブログでは、システム管理者の観点から、MySQLサーバーを本番環境で使用できるように準備するためのヒントとコツについて説明しました。このブログ投稿は続きです...
すべてのバックアップツールには、独自の長所と短所があります。たとえば、Percona Xtrabackup（またはMariaDBの場合はMariaDB Backup）は、データベースをロックせずに物理的なホットバックアップを実行できますが、別のインスタンスで同じバージョンにのみ復元できます。 mysqldumpの場合、他のMySQLメジャーバージョンと相互互換性があり、部分バックアップの方がはるかに簡単ですが、大規模データベースのPerconaXtrabackupと比較すると復元中は比較的低速です。 MySQL 5.7には、ダンププロセスを高速化する並列処理機能を備えたmysqldumpと同様のmysqlpumpも導入されています。
これらのバックアップツールはすべて無料で利用でき、データ回復に非常に重要であるため、MySQLサーバーでこれらすべてのバックアップツールを構成することをお忘れなく。 mysqldumpとmysqlpumpはすでにMySQL5.7以降に含まれているため、Percona Xtrabackup（またはMariaDBの場合はMariaDB Backup）をインストールする必要がありますが、次の手順に示すように、いくつかの準備が必要です。
$ yum install -y epel-release
$ yum install -y socat pv percona-xtrabackupMariaDBサーバーの場合は、代わりにMariaDBバックアップを使用してください：
$ yum install -y socat pv MariaDB-Backupマスターにユーザー「xtrabackup」が存在しない場合は作成します：
mysql> CREATE USER 'xtrabackup'@'localhost' IDENTIFIED BY 'Km4z9^sT2X';
mysql> GRANT RELOAD, LOCK TABLES, PROCESS, REPLICATION CLIENT ON *.* TO 'xtrabackup'@'localhost';マスターに「mysqldump」という別のユーザーが存在しない場合は、それを作成します。このユーザーは、「mysqldump」および「mysqlpump」に使用されます：
mysql> CREATE USER 'mysqldump'@'localhost' IDENTIFIED BY 'Km4z9^sT2X';
mysql> GRANT SELECT, SHOW VIEW, EVENT, TRIGGER, LOCK TABLES, RELOAD, REPLICATION CLIENT ON *.* TO 'mysqldump'@'localhost';[xtrabackup]、[mysqldump]、[mysqlpump]ディレクティブの下のMySQL構成ファイル内にバックアップユーザーの資格情報を追加します：
$ cat /etc/my.cnf
...
[xtrabackup]
user=xtrabackup
password='Km4z9^sT2X'
[mysqldump]
user=mysqldump
password='Km4z9^sT2X'
[mysqlpump]
user=mysqldump
password='Km4z9^sT2X'上記の行を指定することにより、バックアップツールがメインの構成ファイルからこれらの構成オプションを自動的にロードするため、バックアップコマンドでユーザー名とパスワードを指定する必要はありません。
$ socat -u tcp-listen:9999,reuseaddr stdout 2>/tmp/netcat.log | xbstream -x -C /var/lib/mysql次に、ソースサーバーでバックアップを作成し、それを宛先サーバーのポート9999にストリーミングします。
$ innobackupex --socket=/var/lib/mysql/mysql.sock --stream=xbstream /var/lib/mysql/ | socat - TCP4:192.168.0.202:9999バックアップコマンドを実行した後、出力の連続ストリームを取得する必要があります。バックアップが成功したことを示す「CompletedOK」行が表示されるまで待ちます。
pvを使用すると、帯域幅の使用を抑制したり、プロセスがパイプ処理されているときに進行状況を確認したりできます。通常、スロットルが有効になっていない場合、ストリーミングプロセスはネットワークを飽和させます。これにより、他のサーバーが同じセグメント内の別のサーバーと対話する際に問題が発生する可能性があります。 pvを使用すると、socatやnetcatなどのストリーミングツールに渡す前に、ストリーミングプロセスを調整できます。次の例は、バックアップストリーミングが着信接続と発信接続の両方で約80 MB/sに抑制されることを示しています。
$ innobackupex --slave-info --socket=/var/lib/mysql/mysql.sock --stream=xbstream /var/lib/mysql/ | pv -q -L 80m | socat - TCP4:192.168.0.202:9999バックアップのストリーミングは、通常、スレーブをステージングしたり、バックアップを別のサーバーにリモートで保存したりするために使用されます。
mysqldumpおよびmysqlpumpの場合、次のコマンドでテストできます。
$ mysqldump --set-gtid-purged=OFF --all-databases
$ mysqlpump --set-gtid-purged=OFF --all-databasesデータベースサーバーのストレステストは、特定のサーバーで予想できる最大容量を理解するために重要です。これは、後の段階でしきい値またはボトルネックに近づいているときに役立ちます。 mysqlslap、DBT2、sysbenchなどの市場で入手可能な多くのベンチマークツールを使用できます。
この例では、sysbenchを使用して、データベースのワークロードが高い環境で実行しているときに、サーバーのピークパフォーマンス、飽和レベル、およびコンポーネントの温度を測定します。これにより、サーバーがどれだけ優れているかを理解し、サーバーが本番環境のアプリケーションで処理できるワークロードを予測できます。
sysbenchをインストールして構成するには、ソースからコンパイルするか、Perconaリポジトリからパッケージをインストールします。
$ yum install -y https://repo.percona.com/yum/percona-release-latest.noarch.rpm
$ yum install -y sysbenchmysql> CREATE DATABASE sbtest;
mysql> CREATE USER 'sbtest'@'localhost' IDENTIFIED BY 'sysbenchP4ss';
mysql> GRANT ALL PRIVILEGES ON sbtest.* TO [email protected]'localhost';$ sysbench \
/usr/share/sysbench/oltp_common.lua \
--db-driver=mysql \
--mysql-host=localhost \
--mysql-user=sbtest \
--mysql-password=sysbenchP4ss \
--tables=50 \
--table-size=100000 \
prepare次に、ベンチマークを1時間（3600秒）実行します。
$ sysbench \
/usr/share/sysbench/oltp_read_write.lua \
--report-interval=2 \
--threads=64 \
--max-requests=0 \
--db-driver=mysql \
--time=3600 \
--db-ps-mode=disable \
--mysql-host=localhost \
--mysql-user=sbtest \
--mysql-password=sysbenchP4ss \
--tables=50 \
--table-size=100000 \
runテストの実行中に、別の端末でiostat（sysstatパッケージで利用可能）を使用して、ディスク使用率、帯域幅、IOPS、およびI/O待機を監視します。
$ yum install -y sysstat
$ iostat -x 60
avg-cpu: %user %nice %system %iowait %steal %idle
40.55 0.00 55.27 4.18 0.00 0.00
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0.19 6.18 1236.23 816.92 61283.83 14112.44 73.44 4.00 1.96 2.83 0.65 0.34 69.29- 1秒あたりのクエリ数=SQL統計->[クエリ]->[1秒あたり]でテストが完了した後のSysbenchの概要
- クエリのレイテンシー=レイテンシー（ミリ秒）->95パーセンタイルでテストが完了した後のSysbenchの概要。
- ディスク使用率=％utilの平均
- ディスクIO待機=％iowaitの平均
- MySQLCPU使用率=topコマンドで報告された平均CPU使用率。
ClusterControlを使用すると、次のスクリーンショットに示すように、[ノードの概要]パネルから上記の情報を簡単に確認して取得できます。
さらに、ストレステスト中に収集された情報を使用してMySQLを調整できますそれに応じて、innodb_buffer_pool_size、innodb_io_capacity、innodb_io_capacity_max、innodb_write_io_threads、innodb_read_io_threads、max_connectionsなどのInnoDB変数。
sysbenchを使用したMySQLパフォーマンスベンチマークの詳細については、このブログ投稿「SysBenchを使用してMySQLとMariaDBのパフォーマンスをベンチマークする方法」を確認してください。
スキーマの変更は、リレーショナルデータベースでは避けられないものです。アプリケーションが成長し、時間の経過とともに要求が厳しくなるにつれて、データベースの構造を変更する必要があります。テーブルを再構築して他のDMLステートメントの実行をブロックするいくつかのDDL操作があり、巨大なテーブルで構造変更を実行している場合、これはデータベースの可用性に影響を与える可能性があります。ブロッキングDDL操作のリストを確認するには、このMySQLドキュメントページをチェックして、「PermitsConcurrentDML」=いいえの操作を探してください。
スキーマ変更を実行するときに本番サーバーでダウンタイムを許容できない場合は、初期段階でオンラインスキーマ変更ツールを構成することをお勧めします。この例では、Githubによって構築されたオンラインスキーマ変更であるgh-ostをインストールして構成します。 Gh-ostは、バイナリログストリームを使用してテーブルの変更をキャプチャし、それらをゴーストテーブルに非同期的に適用します。
CentOSボックスにgh-ostをインストールするには、次の手順に従ってください。
ステップ1
最新のgh-ostをここからダウンロードします：
$ wget https://github.com/github/gh-ost/releases/download/v1.0.48/gh-ost-1.0.48-1.x86_64.rpmパッケージをインストールします：
$ yum localinstall gh-ost-1.0.48-1.x86_64.rpm gh-ostが存在しない場合はデータベースユーザーを作成し、適切な権限を付与します。
mysql> CREATE USER 'gh-ost'@'{host}' IDENTIFIED BY 'ghostP455';
mysql> GRANT ALTER, CREATE, DELETE, DROP, INDEX, INSERT, LOCK TABLES, SELECT, TRIGGER, UPDATE ON {db_name}.* TO 'gh-ost'@'{host}';
mysql> GRANT SUPER, REPLICATION SLAVE ON *.* TO 'gh-ost'@'{host}';**{host}と{db_name}を適切な値に置き換えます。理想的には、{host}はオンラインスキーマ変更を実行するスレーブホストの1つです。詳細については、gh-ostのドキュメントを参照してください。
gh-ost構成ファイルを作成して、ユーザー名とパスワードを/root/.gh-ost.cnfに保存します。
[client]
user=gh-ost
password=ghostP455同様に、データベースサーバーでPercona Toolkitオンラインスキーマ変更（pt-osc）を構成できます。アイデアは、将来この操作を実行する可能性のあるデータベースサーバーで最初にこのツールを使用する準備ができていることを確認することです。
PerconaToolkitを利用する
Percona Toolkitは、Perconaによって開発された高度なオープンソースコマンドラインツールのコレクションであり、MySQL、MongoDB、PostgreSQLのさまざまなサーバーおよびシステムタスクを実行するように設計されています。手動で実行します。これらのツールは、MySQLおよびMariaDBサーバーで見つかった技術的な問題に対処または解決するために世界中のDBAによって使用される究極の救世主になりました。
Percona Toolkitをインストールするには、次のコマンドを実行するだけです。
$ yum install https://repo.percona.com/yum/percona-release-latest.noarch.rpm
$ yum install percona-toolkit次の例は、マスターでチェックサムクエリを実行することにより、オンラインレプリケーションの整合性チェックを実行できるツール（pt-table-checksum）の出力の1つを示しています。これにより、マスターと整合性のないレプリカで異なる結果が生成されます。
$ pt-table-checksum --no-check-binlog-format --replicate-check-only
Checking if all tables can be checksummed ...
Starting checksum ...
Differences on mysql2.local
TABLE CHUNK CNT_DIFF CRC_DIFF CHUNK_INDEX LOWER_BOUNDARY UPPER_BOUNDARY
mysql.proc 1 0 1
mysql.tables_priv 1 0 1
mysql.user 1 1 1上記の出力は、スレーブ（mysql2.local）にマスターと矛盾する3つのテーブルがあることを示しています。次に、pt-table-syncツールを使用して、マスターから欠落しているデータを修正するか、単にスレーブをもう一度再同期することができます。
最後に、構成と準備の段階が完了したら、データベースノードをパブリックネットワークから分離し、サーバーアクセスを既知のホストとネットワークに制限できます。ファイアウォール（iptables、firewalld、ufw）、セキュリティグループ、hosts.allow、hosts.denyを使用するか、複数のネットワークインターフェイスがある場合は、インターネットに面するネットワークインターフェイスを無効にすることができます。
iptablesの場合、「-mcomment--comment」フラグを使用してすべてのルールにコメントを指定することが重要です。
$ iptables -A INPUT -p tcp -s 192.168.0.0/24 --dport 22 -m comment --comment 'Allow local net to SSH port' -j ACCEPT
$ iptables -A INPUT -p tcp -s 192.168.0.0/24 --dport 3306 -m comment --comment 'Allow local net to MySQL port' -j ACCEPT
$ iptables -A INPUT -p tcp -s 192.168.0.0/24 --dport 9999 -m comment --comment 'Allow local net to backup streaming port' -j ACCEPT
$ iptables -A INPUT -p tcp -s 0.0.0.0/0 -m comment --comment 'Drop everything apart from the above' -j DROPUbuntuのファイアウォール（ufw）の場合と同様に、最初にデフォルトのルールを定義してから、次のようなMySQL/MariaDBの同様のルールを作成できます。
$ sudo ufw default deny incoming comment 'Drop everything apart from the above'
$ sudo ufw default allow outgoing comment 'Allow outgoing everything'
$ sudo ufw allow from 192.168.0.0/24 to any port 22 comment 'Allow local net to SSH port'
$ sudo ufw allow from 192.168.0.0/24 to any port 3306 comment 'Allow local net to MySQL port'
$ sudo ufw allow from 192.168.0.0/24 to any port 9999 comment 'Allow local net to backup streaming port'ファイアウォールを有効にする：
$ ufw enable次に、ルールが正しく読み込まれていることを確認します。
$ ufw status verbose
Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), disabled (routed)
New profiles: skip
To Action From
-- ------ ----
22 ALLOW IN 192.168.0.0/24 # Allow local net to SSH port
3306 ALLOW IN 192.168.0.0/24 # Allow local net to MySQL port
9999 ALLOW IN 192.168.0.0/24 # Allow local net to backup streaming port繰り返しになりますが、ルールをよりよく理解できるように、すべてのルールにコメントを指定することが非常に重要です。
リモートデータベースアクセス制限については、このブログ投稿「OpenVPNを使用してクラウド内のデータベースクラスターへのアクセスを保護する」に示されているように、VPNサーバーを使用することもできます。
本番サーバーの準備は、このブログシリーズで示したように、明らかに簡単な作業ではありません。失敗するのではないかと心配な場合は、ClusterControlを使用してデータベースクラスターをデプロイしてみませんか？ ClusterControlは、データベースのデプロイメントで非常に優れた実績があり、これまでにすべての環境で70,000を超えるMySQLおよびMariaDBのデプロイメントを可能にしました。