Microsoft Azure MySQL サーバ 5.6 導入ガイド

MySQL Solution Company
Microsoft Azure
MySQL サーバ 5.6 導入ガイド
Published：2014/04
Publisher：株式会社スマートスタイル
注意事項
本ガイドに記述されている内容は、本ガイド作成時点（2013 年 12 月）の環境(東
アジア)を利用したものです。そのため、ご利用の環境によっては表示内容や結果
が異なる可能性があります。また、クラウド環境では、マルチテナントですので
オンプレミスや非クラウド環境に比べ性能に差が出る場合があります。「付録２
パフォーマンストピック」で性能向上のための方法を記述した内容がありますが、
性能を重視するシステムの場合には、あらかじめ設計段階においてこの点を充分
に考慮してください。
記載した内容は一切、性能保証などを意味するものではありません。
本資料中の技術的あるいは編集上の誤り、省略に対してはいかなる責任も負いか
ねます。
※ 商標、登録商標について
MySQL の名称及びロゴは、日本オラクル社の登録商標または商標です。その他記
載の会社名、製品名、各社の商標もしくは登録商標です。
本資料の一部または全部を著作権法の定める範囲を超え、無断で複写、複製、転
載、データ化、ファイルに落とすことを禁じます。
2014 年 4 月 4 日に「Windows Azure」から「Microsoft Azure」に名称が変更さ
れました。
1
目次
1. はじめに............................................................................................................................. 4
2. 本ガイドの目的.................................................................................................................. 6
3. Microsoft Azure 環境の構築 .............................................................................................. 8
3.1 Microsoft Azure インスタンスの選択 .......................................................................... 8
3.2 Microsoft Azure へのログイン ..................................................................................... 9
3.3 アフィニティグループの作成....................................................................................... 9
3.4 仮想ネットワークの作成.............................................................................................11
3.5 ストレージアカウントの作成......................................................................................11
4. Linux サーバの構築 ......................................................................................................... 13
4.1 Linux サーバの構築 .................................................................................................... 13
4.2 仮想マシンの設定....................................................................................................... 14
5. イメージキャプチャを使った仮想マシンの複製............................................................. 15
6. データディスクの追加..................................................................................................... 17
6.1 データディスクの追加 ............................................................................................... 17
6.2 データディスクの組込 ............................................................................................... 18
7. MySQL のインストール・設定....................................................................................... 19
7.1 MySQL のインストール・設定(シングル構成) ......................................................... 19
7.2 MySQL のインストール・設定(マスタ・スレーブ構成)........................................... 23
7.2.1 my.cnf の編集........................................................................................................ 23
7.2.2 レプリケーションを開始 ..................................................................................... 24
7.3 MySQL のインストール・設定(マルチマスタ構成) .................................................. 25
7.3.1 my.cnf の編集........................................................................................................ 25
7.3.2 レプリケーションを開始 ..................................................................................... 25
補足....................................................................................................................................... 28
1. MySQL 所要メモリ算出方法........................................................................................ 28
2. 仮想マシンサイズの変更方法 ...................................................................................... 28
3. swap ファイルの追加 ................................................................................................... 29
付録 1 バックアップとリカバリ.......................................................................................... 30
1.1 バックアップ方法 ...................................................................................................... 30
1.2 バックアップ保管用ディスクの設定 ......................................................................... 30
1.3 XtraBackup インストール ......................................................................................... 31
1.4 バックアップ.............................................................................................................. 31
1.5 バックアップからのリカバリ .................................................................................... 32
2
付録 2 パフォーマンストピック.......................................................................................... 34
2.1 チューニング概要 ...................................................................................................... 34
2.2 仮想ディスクの IOPS 性能........................................................................................ 35
2.3 パラメータチューニング ........................................................................................... 36
2.4 大規模パフォーマンスチューニングのヒント .......................................................... 39
付録 3 MySQL の高可用性と負荷分散................................................................................. 41
3.1 マスタ・スレーブ構成のレプリケーションの構築 ................................................... 44
3.1.1 レプリケーションの開始..................................................................................... 44
3.1.2 mysqlfailover 用のアカウント作成 ..................................................................... 45
3.2 監視サーバの構築(mysqlfailover 稼動)..................................................................... 46
3.3 mysqlfailover の動作検証 .......................................................................................... 47
付録 4 他社サービスと比較した MySQL の性能比較 ......................................................... 50
本稿の目的............................................................................................................................ 51
環境....................................................................................................................................... 52
調査内容 ............................................................................................................................... 54
調査結果 ............................................................................................................................... 55
結果考察 ............................................................................................................................... 58
環境構築手順 ........................................................................................................................ 59
lvm ボリュームの作成 ................................................................................................... 59
MySQL のインストール ............................................................................................... 60
tpcc-mysql のインストールと設定 ............................................................................... 60
3
1. はじめに
Executive Summary
▼ Microsoft Azure クラウドプラットフォームの利用
Microsoft 社のクラウドサービス「Microsoft Azure」は、オープンプラットフォ
ームと豊富なアプリケーションサービスと柔軟なオンデマンドサービスの上で、
スモールスタートから既存システムの移行や新規案件構築など状況に応じた適切
なクラウドプラットフォームが提供され、お客様は適切なサービスを選択できま
す。
▼ Microsoft Azure 上で Linux + MySQL の構築を行う
本ガイドでは Microsoft 社が提供する「Microsoft Azure」クラウドサービスを使
い、Linux サーバを導入し、オープンソースの代表的なデータベースである
MySQL の構築方法を説明します。
▼ MySQL の 3 つの代表的構成での導入をガイド
構築に関してはシンプルなシングルサーバ構成、信頼性やアクセス容易性を強化
する MySQL のレプリケーション構成、MySQL マルチマスタ構成の３つの代表的
な構成での構築方法を紹介します。
本ガイドには各手順の設定画面と必要な設定情報をわかりやすく示しております
ので、記述されている手順をすすめることで最終的な目的である MySQL の構築
を、初めてされるかたにも完了できるよう構成されています。
▼ 運用までカバーしているので安心してご利用可能
また、本ガイドでは MySQL の構築にとどまらず、日々の MySQL 運用を想定し
た、Microsoft Azure 環境でのデータバックアップ・リカバリの方法や、将来的に
ディスク I/O の性能劣化となった際の Microsoft Azure 環境で性能拡張する手法に
ついても記述しました。
以上、本ガイドでは導入から運用・システム拡張についてもカバーしております
ので、Microsoft Azure での MySQL を安心してご利用開始していただけるものと
考えます。
「付録 3」
、MySQL 高可用性と負荷分散では MySQL で一般的に利用している
MySQL レプリケーションの分散機能やアプリケーションと中継モジュールを利
4
用した負荷分散製品を紹介しています。さらに、高可用性構成として MySQL5.6
から追加された新規機能 mysqlfailover の設定、mysqlfailover 障害発生からの復
旧手順について記述しました。オンプレミス環境から移行するお客様や高可用性
の構成について関心のあるかたは一読をお願いいたします。
▼ 他社サービスとの比較
最後、
「付録４」は Microsoft Azure の DataBase As a Service が提供している
MySQL サービス「ClearDB」と他社クラウドが提供する MySQL サービスを使い、
負荷試験ツール tpcc-mysql を使った性能比較を株式会社 pnop が検証を行いまし
た。
本資料を加え他社との比較に関心のあるかたは一読をお願いいたします。
※株式会社 pnop のご紹介
Microsoft Azure のリリース当初より Microsoft Azure の導入コンサルティングや
Azure に最適化された Web サービスの開発、サーバ構築を中心としたサービスを
提供し、MySQL を始めとした OSS の Microsoft Azure での活用を積極的に支援
しています。
5
2. 本ガイドの目的
図１．にある構築手順に従い、図 2.のイメージ図で示す MySQL の構築を行いま
す。各サーバには、表１．のソフトウェアをインストールします。
また、運用に関わるいくつかのトピックス（バックアップとリカバリ、パフォー
マンストピック、新機能 mysqlfailover の設定とリカバリ手順）について付録に記
述します。
図 1 Microsoft Azure 環境での MySQL の構築手順
図 2 Microsoft Azure 環境での構築イメージ
6
表 1 サーバソフトウェア環境
製品名
OS
Open Logic CentOS 6.3
データベース
MySQL Community Server 5.6.14
ドライバ
perl-DBD-MySQL
MySQL-connector-python 1.0.12
ユーティリテイ
MySQL-utilities 1.3.4
バックアップツール
Xtrabackup
以降、以下の内容を順に追って説明します。
Microsoft Azure 環境の構築
Linux サーバの構築
イメージキャプチャを使ったサーバの複製
データディスクの追加
MySQL イストール・設定
シングルマスター構成
マスタ・スレーブ構成
マルチマスタ構成
付録１：バックアップとリカバリ
付録２：パフォーマンストピック
（VHD ストライピングを活用したディスク io 性能の向上）
付録３：MySQL の高可用性と負荷分散
付録４：他社サービスと比較した MySQL の性能比較
付録４は株式会社 pnop 様が検証した資料
7
3. Microsoft Azure 環境の構築
最初におこなう手順は Microsoft Azure 環境を構築することです。
以下の手順にしたがって進めてください。
3.1 Microsoft Azure インスタンスの選択
下記「表２」
「表３」に示す Microsoft Azure で提供されるサービスの全てのイン
スタンスが、MySQL 構築のために選択いただけます。要求される MySQL システ
ムの性能条件により適切なタイプを選択ください。なお、MySQL の所要メモリ容
量の計算方法については、
「補足１．MySQL 所要メモリ算出方法」を参照くださ
い。
表 2 標準インスタンス
サイズ
Extra Small
CPU
メモリ
コア
共有
最大データディスク数
最大 IOPS
(各ディスク 1 TB)
(各ディスク 500)
768 MB
1 1 x 500
Small
1
1.75 GB
2 2 x 500
Medium
2
3.5 GB
4 4 x 500
Large
4
7 GB
8 8 x 500
Extra Large
8
14 GB
16 16 x 500
表 3 メモリ集中型インスタンス
メモリ集中型インスタンス
サイズ
CPU
メモリ
コア
最大データディスク数
最大 IOPS
(各ディスク 1 TB)
(各ディスク 500)
A5
2
14 GB
4 4 x 500
A6
4
28 GB
8 8 x 500
A7
8
56 GB
16 16 x 500
8
3.2 Microsoft Azure へのログイン
Microsoft Azure ポータル（http://www.Microsoft Azure.com）画面にログインし、
以下の設定を実施します。
3.3 アフィニティグループの作成
Microsoft Azure インフラストラクチャは巨大なデータセンターで構築されている
ため、複数の仮想マシンやストレージで通信が発生するような構成では、それぞ
れの配置場所によってネットワークレイテンシー（遅延）が発生する可能性を考
慮すべきです。Microsoft Azure ではアフィニティグループを指定することで、仮
想マシンやストレージ（など）の配置をある程度制御することが出来ます。
手順1:
ポータル画面、左メニューの下部「設定」をクリックし、
「設定」画面の上部「ア
フィニティグループ」リンクを選択します。
9
手順2:
表示された「アフィニティグループ」の画面下にある「追加」ボタンよりアフィ
ニティグループを作成します。
10
3.4 仮想ネットワークの作成
クラウドとローカルマシンを 1:1 でシンプルに IPSec 接続した、クラウド/オンプ
レミスをまたいだ仮想プライベートネットワーク(VPN)を利用しセキュアな環境
で構築とシステム運用できるための設定をします。
Microsoft Azure ポータル画面の左下にある「＋新規」-「ネットワークサービス」
-「仮想ネットワーク」-「簡易作成」から、
「アフィニティグループ」に作成した
「アフィニティグループ」を指定して仮想ネットワークを作成します。
3.5 ストレージアカウントの作成
ストレージアカウントを使用すると、アプリケーションから、地理的な領域内に
置かれている Microsoft Azure の BLOB サービス、テーブルサービス、キュー
サービスにアクセスできます。Microsoft Azure ストレージを使用するには、スト
レージアカウントが必要です。
Microsoft Azure で MySQL を動作させる場合には、仮想マシン内のローカルディ
スクを使うことは推奨しません。
Microsoft Azure ストレージを使い、
ストレージを使い、データディレクトリ、ログディレクトリ、redo
ログ領域、テンポラリ領域等、必要な領域をわりあててください。
ログ領域、テンポラリ領域等、必要な領域をわりあててください。
Microsoft Azure ポータル画面の左下にある「＋新規」-「データサービス」-「ス
トレージ」より、
「簡易作成」-「アフィニティグループ」に作成した「アフィニテ
ィグループ」を指定してストレージを作成します。
11
12
4. Linux サーバの構築
4.1 Linux サーバの構築
Microsoft Azure ポータル画面の左下にある「＋新規」-「コンピューティング」「仮想マシン」-「ギャラリから」をクリックします。各項目に対して以下の情報
を設定してください。
表 4 仮想マシンの構成
イメージの選択
「OpenLogic CentOS6.3」を選択
クラウドサービス
「新しいクラウドサービスの作成」を選択
クラウドサービス DNS 名
任意の DNS 名を設定
地域/アフィニティグルー
前述で作成した仮想ネットワークを選択
プ/仮想ネットワーク
ストレージアカウント
前述で作成したストレージアカウントを設定
可用性セット
「可用性セットの作成」を選択し、任意の可用性セット
名を設定
・可用性セットについて
同一の可用性セットを指定する事で、２台の仮想マシンは異なるラックに配置さ
れます。これにより、異なる障害ドメイン(フォールトドメイン)となる為、一方の
仮想マシンが格納されたラックに障害が発生したとしても、もう一方の仮想マシ
ンは稼動し続ける事ができます。
複数の仮想マシンに MySQL サーバを構築する場合、同じ可用性セット内に異な
る役割のサーバを配置せずに、以下のように可用性セットを分けて下さい。
マスタサーバと、マスタ障害時にマスタ昇格予定のスタンバイサーバ
スレーブサーバ群
上記振り分けをする事により、ラックに障害が発生したとしても、
「マスタサーバと、マスタ障害時に昇格予定のスタンバイサーバ」
、及び「スレー
ブサーバ群」のそれぞれのリソース間で、必ず１台は稼動し続ける事となります。
・同一クラウドサービス内であればプライベート IP アドレスでアクセスが可能です。
13
4.2 仮想マシンの設定
Microsoft Azure ポータル画面で作成した仮想マシン（Cent OS）にログインし、
以下の手順で仮想マシンの設定を行います。
DNS サーバの設定、もしくは hosts ファイルにて、各サーバ間及び yum リポジト
リ等へのアクセスが可能である事を前提としています。
・以降コマンドラインでの入力は罫線内に例示します。
手順1: root パスワードの設定
$ sudo passwd root
手順2: SELinux の無効化
# vi /etc/selinux/config
・・・・
SELINUX= enforcing
↓
SELINUX=disabled
14
5. イメージキャプチャを使った仮想マシンの複製
2 台目以降の作成には「イメージキャプチャ」機能が大変便利です。この機能を使
って 2 台目以降のサーバを作成してゆきます。
1 台目のサーバと同様、Microsoft Azure ポータル画面の左下にある「＋新規」「コンピューティング」-「仮想マシン」-「ギャラリから」をクリックします。各
項目に対して以下の情報を設定してください。
表1: 仮想マシンの構成(2 台目以降)
イメージの選択
「登録したイメージキャプチャ」を選択
クラウドサービス
1 台目で作成したクラウドサービスを選択
クラウドサービス DNS 名
選択不可
地域/アフィニティグループ/
選択不可
仮想ネットワーク
ストレージアカウント
1 台目と同じストレージアカウントを設定
可用性セット
4-2-1-2.「可用性セットについて」を参照
・
作成方法は「linux を実現する仮想マシンのイメージをキャプチャする方法」を
参照してください。
URL
http://www.Microsoft
Azure.com/ja-jp/manage/linux/how-to-guides/capture-an-image/
・イメージキャプチャをとるタイミングは状況によって別タイミング（例えば、デ
ータディスクを追加せずに MySQL のインストールに進み、その手順を完了したタ
イミング）がよいこともあります。
15
16
6. データディスクの追加
前章までで作成したサーバに対して、データディスクを追加していきます。
以下の手順で進めてください。
6.1 データディスクの追加
データディスクを仮想マシンに接続してアプリケーションデータを保存できます。
データディスクは仮想ハードディスク(VHD)です。仮想マシンでデータディスク
を管理する方法は、オンプレミスのサーバで管理する方法と同じです。
・ MySQL が利用するディスクは全て「ホストキャッシュ設定：なし」を選択してく
ださい。
Microsoft Azure ポータル画面の左メニューの「仮想マシン」をクリック後、表示
された仮想マシンの一覧から対象の仮想マシンを選択状態にし、画面下の「ディ
スクの接続」-「空のディスクの接続」より、
「ホストキャッシュ設定：なし」を選
択してディスクを追加します。
・追加方法は Microsoft Azure が提供する「データディスクを仮想マシンに接続する
方法」を参照してください。
・参考 URL http://www.Microsoft
Azure.com/ja-jp/manage/windows/how-to-guides/attach-a-disk/
17
6.2 データディスクの組込
手順1: ディスクのフォーマット
「データディスクの追加」で追加したディスクへファイルシステムを作成します。
fdisk は、
「/dev/sdc」のディスクに対して実行して下さい
手順2: マウントポイントの作成
本検証ではデータ「/data/mysql」ディレクトリ名でマウントします。
# mkdir -m 755 -p /data/mysql
手順3: マウント情報の設定
「/etc/fstab」にマウント情報を設定します。
# vi /etc/fstab
～～～～～
/dev/sdc1
/data/mysql
ext4
defaults,nobarrier
手順4: マウント
「/etc/fstab」への設定が完了後、マウントします。
# mount /dev/sdc1
18
00
7. MySQL のインストール・設定
前章までで作成した仮想マシンに対して、いよいよ MySQL をインストールし設
定していきます。3 つの代表的構成（シングル、マスター・スレーブ、マルチマス
ター）についてそれぞれ節を分けて記述してありますので、必要な節へ進んでく
ださい。
7.1 MySQL のインストール・設定(シングル構成)
Microsoft Azure ポータル画面で作成した仮想マシン(Cent OS)にログインし、以
下の手順で MySQL のインストールと設定を行います。
手順1: MySQL-shared-compat のインストール
# rpm -ivh MySQL-shared-compat-5.6.14-1.el6.x86_64.rpm
Preparing...
############################ [100%]
1:MySQL-shared-compat ############################ [100%]
デフォルトで、異なるバージョンの「MySQL-libs」がインストールされており、
「MySQL-Server Ver5.6」とコンフリクトする為、デフォルトの「MySQL-libs」
を「MySQL-shared-compat」に置き換えます。
手順2: MySQL-libs のアンインストール
# rpm -e mysql-libs-5.1.67-1.el6_3.x86_64
手順3: MySQL-client のインストール
# rpm -ivh MySQL-client-5.6.14-1.el6.x86_64.rpm
Preparing...
1:MySQL-client
############################ [100%]
############################ [100%]
手順4: MySQL-server のインストール
# rpm -ivh MySQL-server-5.6.14-1.el6.x86_64.rpm
Preparing...
1:MySQL-server
############################ [100%]
############################ [100%]
2013-10-29 14:12:36 0 [Warning] TIMESTAMP with implicit DEFAULT value is
deprecated. Please use --explicit_defaults_for_timestamp server option (see
documentation for more details).
～～～～～～～～～～
Support MySQL by buying support/licenses at http://shop.mysql.com
19
New default config file was created as /usr/my.cnf and
will be used by default by the server when you start it.
You may edit this file to change server settings
手順5: MySQL の起動
# /etc/init.d/mysql start
Starting MySQL.
[ OK ]
手順6: MySQL の root ユーザのパスワードを確認
MySQL5.6 から MySQL サーバインストール時に MySQL へログインする root
ユーザのパスワードが「/root/.mysql_secret」ファイルに書き込まれます。MySQL
へ root ユーザでログインするには、以下の手順で仮パスワードを確認します。
# vi /root/.mysql_secret
# The random password set for the root user at Tue Oct 29 14:12:48 2013 (local
time): Z4Kystm9
手順7: mysql_secure_installation を実行
MySQL サーバのインストール中に匿名ユーザ等が登録されます。このツールを実
行しセキュアな環境を作ります。
# /usr/bin/mysql_secure_installation
～～～～～～～～～～
Enter current password for root (enter for none):
前述で確認しました root ユーザのパスワードを入力して Enter を押下します。
Change the root password? [Y/n]
root ユーザのパスワードを変更する場合は Y を、変更しない場合は n を入力して
Enter を押下します。
Remove anonymous users? [Y/n]
Y を入力して Enter を押下し、anonymous ユーザを削除します。
Disallow root login remotely? [Y/n]
Y を入力して Enter を押下し、root ユーザのリモートログインを許可しないよう
20
にします。
Remove test database and access to it? [Y/n]
Y を入力して Enter を押下し、test データベースを削除します。
Reload privilege tables now? [Y/n]
Y を入力して Enter を押下し、権限テーブルを再読み込みします。
手順8: MySQL を停止
# /etc/init.d/mysql stop
Shutting down MySQL......
[ OK ]
手順9: MySQL のファイル群を作成したディレクトリにコピー
MySQL のファイル群を OS 内部のディスク領域から仮想ディスク（VHD）へ移
行します。
# cp –pr /var/lib/mysql/* /data/mysql/
手順10: マウントディレクトリの権限設定
# chown mysql:mysql -R /data/mysql
手順11: my.cnf を編集
表 5 MySQL 構成パラメータ
設定パラメータ
設定値
[mysqld]
server_id
1000
datadir
/db/mysql
tmpdir
/mnt/resource/mysql
log_bin
binlog-hostname
innodb_flush_method
O_DIRECT
binlog_format
mixed
inodb_file_per_table
character-set-server
utf8
[mysqld_safe]
log-error
/db/mysql/mysqld.log
21
手順12: MySQL を起動
# /etc/init.d/mysql start
Starting MySQL.........
[ OK ]
上記手順により以下ができます。
図 3 Microsoft Azure 上のシングサーバの構成
・ MySQL Ver5.6 では、RPM インストール直後の my.cnf は「/usr/my.cnf」となっ
ております。必要に応じて、my.cnf のパスは適宜変更して下さい。
22
7.2 MySQL のインストール・設定(マスタ・スレーブ構成)
本節では、２台のマスタ・スレーブ構成の動作確認を行います。
２台の仮想マシンを作成し、MySQL のインストールを行います。
Microsoft Azure ポータル画面での「仮想マシンの作成」については、１台目と２
台目で作成パラメータが異なりますので、
「7.2.1 MySQL 構成パラメータの設定」
を参照して下さい。以下が Microsoft Azure 仮想マシン環境でのレプリケーション
環境の構成になります。
図 4 Microsoft Azure 上のマスタ・スレーブの構成
7.2.1 my.cnf の編集
「server_id」を除くパラメータは、全て前章のシングル構成と同じパラメータ設
定を行います。
「server_id」のみ、MySQL データベースサーバごとに異なる値を
設定して下さい。
23
7.2.2 レプリケーションを開始
手順1: レプリケーションユーザの作成
マスタサーバの MySQL にログインし、スレーブサーバからのレプリケーション
を行うユーザを作成します。
mysql> GRANT REPLICATION SLAVE ON *.* TO
レプリケーションユーザ名@'スレーブサーバの IP アドレス'
IDENTIFIED BY 'レプリケーションユーザパスワード';
手順2: スレーブサーバでレプリケーションの開始
マスタサーバで、
「SHOW MASTER STATUS;」より、マスタサーバのバイナリロ
グとバイナリログポジションを確認します。
mysql> SHOW MASTER STATUS;
+---------------------------+------------+---| File
| Position
| Bin
+---------------------------+------------+---| mysql-bin.000004
|
273
|
+---------------------------+------------+---1 row in set (0.00 sec)
スレーブサーバで、「CHANGE MASTE TO ~」を実行します。
mysql>CHANGE MASTER TO
MASTER_HOST='マスタサーバの IP アドレス',
MASTER_PORT=3306,
MASTER_USER='マスタサーバに作成したレプリケーションユーザ名',
MASTER_PASSOWRD='マスタサーバに作成したレプリケーションユーザパスワ
ード',
MASTER_LOG_FILE = 'mysql-bin.000004', // 確認したバイナリログファイル
// 確認したバイナリログポジション
MASTER_LOG_POS = 273;
スレーブサーバで、
「START SLAVE;」を実行し、レプリケーションを開始します。
これにより、マスタサーバへの更新は、スレーブサーバも更新されます。
24
7.3 MySQL のインストール・設定(マルチマスタ構成)
2 台のマルチマスタ構成のインストール・設定手順を記述します。
2 台の仮想マシンを作成し、MySQL のインストールを行います。
Microsoft Azure ポータル画面での仮想マシンの作成については、１台目と２台目
で作成パラメータが異なりますので、
「7.3.1MySQL 構成パラメータの設定」を参
照して下さい。以下が Microsoft Azure 環境のレプリケーション構成になります。
図 5 Microsoft Azure 上のマルチマスタ構成
7.3.1 my.cnf の編集
「server_id」を除くパラメータは、全て前章のシングル構成と同じパラメータ設
定を行います。
「server_id」のみ、MySQL データベースサーバごとに異なる値を
設定して下さい。
7.3.2 レプリケーションを開始
２台のデータベースサーバ、
「主マスタサーバをマスタサーバ A」
、
「副マスタサー
バをマスタサーバ B」として説明を記述します。
25
手順1: レプリケーションユーザの作成
マスタサーバ A の MySQL データベースサーバにログインし、マスタサーバ B か
らのレプリケーションを行うユーザを作成します。
mysql> GRANT REPLICATION SLAVE ON *.* TO
レプリケーションユーザ名@'マスタサーバ B の IP アドレス'
IDENTIFIED BY 'レプリケーションユーザパスワード';
マスタサーバ B の MySQL データベースサーバにログインし、マスタサーバ A か
らのレプリケーションを行うユーザを作成します。
mysql> GRANT REPLICATION SLAVE ON *.* TO
レプリケーションユーザ名@'マスタサーバ A の IP アドレス'
IDENTIFIED BY 'レプリケーションユーザパスワード';
手順2: マスタサーバ A でレプリケーションの開始
マスタサーバ B で、
「SHOW MASTER STATUS;」より、マスタサーバ B のバイ
ナリログとバイナリログポジションを確認します。
mysql> SHOW MASTER STATUS;
+---------------------------+------------+---| File
| Position
| Bin
+---------------------------+------------+---| mysql-bin.000003
|
191
|
+---------------------------+------------+---1 row in set (0.00 sec)
マスタサーバ A で、「CHANGE MASTER TO ~」を実行します。
mysql>CHANGE MASTER TO
MASTER_HOST='マスタサーバ B の IP アドレス',
MASTER_PORT=3306,
MASTER_USER='マスタサーバ B に作成したレプリケーションユーザ名',
MASTER_PASSOWRD='マスタサーバ B に作成したレプリケーションユーザパス
ワード',
MASTER_LOG_FILE = 'mysql-bin.000003', // 確認したバイナリログファイル
// 確認したバイナリログポジション
MASTER_LOG_POS = 191;
26
マスタサーバ A で、
「START SLAVE;」を実行し、
レプリケーションを開始します。
これにより、マスタサーバ B への更新は、マスタサーバ A も更新されます。
mysql>START SLAVE;
手順3: マスタサーバ B でレプリケーションの開始
マスタサーバ A で、
「SHOW MASTER STATUS;」より、マスタサーバ A のバイ
ナリログとバイナリログポジションを確認します。
mysql> SHOW MASTER STATUS;
+---------------------------+------------+---| File
| Position
| Bin
+---------------------------+------------+---| mysql-bin.000004
|
273
|
+---------------------------+------------+---1 row in set (0.00 sec)
マスタサーバ B で、「CHANGE MASTER TO ~」を実行します。
mysql>CHANGE MASTET TO
MASTER_HOST='マスタサーバ A の IP アドレス',
MASTER_PORT=3306,
MASTER_USER='マスタサーバ A に作成したレプリケーションユーザ名',
MASTER_PASSOWED='マスタサーバ A に作成したレプリケーションユーザパスワー
ド',
MASTER_LOG_FILE = 'mysql-bin.000004',
// 確認したバイナリログファイル
// 確認したバイナリログポジション
MASTER_LOG_POS = 273;
マスタサーバ B で、
「START SLAVE;」を実行し、
レプリケーションを開始します。
これにより、マスタサーバ A への更新は、マスタサーバ B も更新されます。
mysql>START SLAVE;
27
補足
1. MySQL 所要メモリ算出方法
スレッドで使用するメモリ計算、以下のパラメータを使い算出します。
スレッドで使用するメモリ＝ max_connections (MySQL へ接続可能な同時接続
数の最大値) × (sort_buffers_size + read_buffer_size + read_rnd_buffer_size +
join_buffer_siz)
プロセスで使用するメモリ計算、以下のパラメータを使い算出します。
プロセスで使用するメモリ = innodb_buffer_pool_size + key_buffer_size +
innodb_log_buffer + innodb_additional_mem_pool + query_cache_size
MySQL のメモリサイズ
MySQL メモリサイズ = スレッドで使用するメモリ + プロセスで使用するメモ
リ
※ MySQL 起動時に最大まで確保するものと、最大値が設定されたパラメータが
使用状況により増減するものがあるため、MySQL メモリサイズの算出値はあ
くまで限界まで使用した論理値です。この最大論理値を踏まえ Microsoft
Azure 仮想マシンのクラスを選択してください。仮想マシンのクラスを下げる
とスワップ等の発生する可能性があり性能が低下することとのトレードオフ
があります。
2. 仮想マシンサイズの変更方法
Microsoft Azure では簡単に仮想マシンサイズを変更する事ができます。クラスの
スケールアップ、スケールダウンは Microsoft Azure ポータルの機能、
「仮想マシ
ン」-「対象サーバを選択」
、対象サーバのダッシュボード画面から「構成」を選択、
「構成画面」から仮想マシンのサイズを簡単に変更することが出来ます。
28
3. swap ファイルの追加
Swap ファイルの追加はファイル名「/etc/waagent.conf」へ以下の箇所を変更後、
再起動すると反映されます。以下は、10G バイト設定した例です。
変更前
ResourceDisk.EnableSwap=n
# Create and use swapfile on resource disk.
ResourceDisk.SwapSizeMB=0
# Size of the swapfile.
変更後
ResourceDisk.EnableSwap=y
# Create and use swapfile on resource disk.
ResourceDisk.SwapSizeMB=10240
# Size of the swapfile.
29
付録1
付録1 バックアップとリカバリ
MySQL を実行する上で必要なファイルが、破損あるいは消失で読み書きできなくなること
をメディア障害といいます。メディア障害が、InnoDB データファイルや InnoDB ログフ
ァイルといったテーブル情報を構成するファイルで発生した場合、データベースの整合性
が維持できない致命的な状態となるため、データベースをリカバリする必要があります。
ここでは、以下の構成を前提として、バックアップ及びメディア障害が発生した際のリカ
バリ方法について紹介します。
1.1 バックアップ方法
オンラインバックアップツールには、MySQL 標準の mysqldump がありますが、
ここでは、リストア速度が高速な Percona 社の XtraBackup を使います。
XtraBackup は、オープンソースの MySQL バックアップツールで、InnoDB に対
し処理をブロックすることなくバックアップすることが可能です。以下のことを
前提として、XtraBackup のインストール及びバックアップ方法を記載します。
1.2 バックアップ保管用ディスクの設定
バックアップ保管用ディスクの設定
ファイル名（追加時）
任意
サイズ（追加時）
任意
ホストキャッシュ設定（追加・接続時）読み取り/書き込み
※ ディスクの追加は「6.データディスクの追加」を参照してください。
その他の設定
バックアップ保管用ディスク名
/dev/sdc1
マウントポイント（バックアップ先）
/backup
※ バックアップ保管用ディスク名は、仮想マシンにディスクを接続した時点で決
まります。
30
1.3 XtraBackup インストール
手順1:
PerconaYum リポジトリをインストールします。
# rpm –Uhv
http://www.percona.com/downloads/percona-release/percona-release-0.0-1.x86_64.rpm
手順2: XtraBackup をインストールします。
# yum install xtrabackup
1.4 バックアップ
バックアップ保管用ディスクをバックアップ対象の仮想マシンに接続します。
Microsoft Azure ポータル画面の左メニューの「仮想マシン」をクリック後、表示
された仮想マシンの一覧からバックアップ対象の仮想マシンを選択状態にし、画
面下の「ディスクの接続」-「ディスクの接続」より、バックアップ保管用ディス
クを選択し、
「ホストキャッシュ設定：読み取り／書き込み」でディスクを接続し
ます。
手順1: バックアップ保管用ディスクをマウントします。
# mount –o nobarrier /dev/sdc1 /backup
※ nobarrier：書き込みバリアを無効にします
手順2: バックアップを取得します。
# innobackupex --user=root --password=rootpassword --defaults-file=/usr/my.cnf
--no-timestamp /backup/bk
手順3: バックアップが作成されたことを確認します。
# ls –l /backup
手順4: バックアップをリカバリに使用できる状態にします。
# innobackupex --apply-log /backup/bk
手順5: バックアップ保管用ディスクをアンマウントします。
31
# umount /dev/sdc1
バックアップ保管用ディスクを切断します。
1.5 バックアップからのリカバリ
バックアップを取得してから障害が発生するまでのバイナリログが全て残ってい
る場合、障害発生直前の状態までデータを復旧することができます。
手順1: 既存データディレクトリ内のファイルを削除します。
# rm -rf /data/mysql/*
手順2: バックアップ保管用ディスクを接続します。
接続したバックアップ保管用ディスクをバックアップ先にマウントします。
# mount –o nobarrier /dev/sdc1 /backup
手順3: バックアップデータをデータディレクトリにコピーします。
# cp -rp /backup/bk/* /data/mysql/
手順4: データディレクトリ以下のファイルのオーナーを変更します。
# chown –R mysql:mysql /data/mysql
手順5: MySQL を起動します。
# /etc/init.d/mysql start
手順6: マスタと同期を開始するバイナリログファイル名とポジションを確
認します。
# cat /data/mysql/xtrabackup_binlog_info
手順7: 適用するバイナリログファイルを確認します。
前手順で確認したバイナリログファイル名以降が適用するファイルになります。
mysql> SHOW BINARY LOGS;
手順8: リカバリ用の SQL ファイルを作成します。
32
# mysqlbinlog /log/mysql/適用するバイナリログファイル
1 /log/mysql/適用するバイナリログファイル
2 ･･･ --start-position=同期を開始するポジション > /tmp/mybinlog.sql
手順9: リカバリ用 SQL ファイルを実行します。
# cat /tmp/mybinlog.sql | mysql -uroot –prootpassword
手順10: Microsoft Azure の管理ポータル画面で、バックアップ保管用ディ
スクを切断します。
33
付録2
付録2 パフォーマンストピック
Microsoft Azure で MySQL の業務システムを稼働させ、システムが順調に拡大す
ると性能面でスケールする必要が生じることになりますが、ここではディスク I/O
がボトルネックになった場合を想定し、その際に拡張する典型的な方法について
記述しました。パフォーマンスに関する一つのトピックとして参考にしてくださ
い。
2.1 チューニング概要
Microsoft Azure の仮想ディスク(VHD)を使った MySQL での IOPS 性能の向上を
ねらいとします。まず、fio ツールを使って、物理ディスク I/O をどの程度だせる
か確認します。ストライピングで１本のディスク（500IOPS）から 8 本のディス
ク（4000IOPS）までリニアにスケールアップできることが確認できました。
次に、卸売業における注文・支払いなどの処理を擬似的に再現した業務モデル、
TPC-C に準拠した tpcc-mysql 負荷ツールを使い、アプリケーションシステムと
しての拡張性をユーザ数の拡張、トランザクション量の拡張がどの程度できるか
確認します。同時接続数 500 ユーザで 10000TpmC を実現できることを確認しま
した。また、今回は「Microsoft Azure 仮想クラス A7」を使用しました。
※Microsoft Azure のディスクは 1 本あたり MAX 500 IOPS の制限があります。
※IOPS（Input/Output Per Second 1 秒間に読み込み/書き込み出来る回数）
図 6 環境イメージ
環境イメージ
34
図 7 チューニング結果
2.2 仮想ディスクの IOPS 性能
オープンソースディスク I/O ベンチマーク測定ツール「fio」を使って仮想ディス
ク(VHD)のストライピングのパフォーマンス測定とチューニング、チューニング
からディスクの特性を考察し最適なストライピング環境を確認します。
・ディスク I/O ベンチマーク測定ツール「fio」
「fio」とはディスク I/O のベンチマーク測定ツール、Linux 上でストレージのパ
フォーマンス測定ツールで以下の測定ができます
シーケンシャル Read/Write
ランダム Read/Write
※ファイルサイズの指定や、I/O エンジンの指定など、様々なベンチマーク条件が
設定可能です。
ソフトウェア RAID(RAID0)、ストライプ化論理ボリューム(LVM)を用いて、ディ
スク本数 2 から N 本の各ディスク本数をストライピングした時の IOPS を測定し
ます。
35
下記グラフは以下の条件で計測したデータです。
「fio.bin」
（設定ファイルの事）に測定パラメータを設定
# fio fio.bin (設定ファイル)を実行し各 IOPS を測定
ランダム Read/Write シーケンシャル Read/Write として I/O ベンチマーク
試験の対象は MySQL データディレクトリ「/db/mysql1」に 4GB のファイル
を転送。
fio 測定結果
4000
3500
3000
IOPS
2500
seqwrite
randwrite
seqread
randread
2000
1500
1000
500
0
2
3
4
5
6
7
8
ディスク本数
ソフトウェア RAID-0 の環境でデータディスク(IOPS500)の本数を増やすことで
リニアにスケールアップしました。
2.3 パラメータチューニング
負荷ツール tpcc-mysql は卸売業における注文・支払いなどの処理を擬似的に再現
した業務モデルをベースとして負荷ツールで 9 種類のテーブルに対してトランザ
クション処理を実行します。今回はそのうち注文処処理のスループットと 1 分間
36
のトランザクション処理数でスケールの可否を確認します。同時接続ユーザ数、
500 を基本に各ストライピングディスクを利用した 1 分間のトランザクション処
理数のスケールアップが確認できました。
tpc-load ツールを使い warehouse テーブルのデータサイズを元に
custmer,district,history,item,new_orders,order_line,orders,stock テーブルのデ
ータ数が決まりますが、この値をスケールのキーとします。
・ warehouse(以下 WH)あたりデータ容量が約 100MB 単位で増えます。本検証では
350 WH (35GB)のデータを warehouse 表へロードしました。
負荷ツール起動サーバから MySQL にリモート接続し負荷確認します
tpcc-stsrt -h IP アドレス -d データベース名 -u ユーザ名
-p パスワード
-w warehouse 生成データサイズ -c 同時接続数 -r 測定開始までの助走時間
(秒) -l 実行時間(秒)
実行例
tpcc-start –h 10.0.0.5 –d tpcc35 –u test –p test –w 350 –c 500 –r 10 –l 3600
・ Microsoft Azure ストレージの I/O 処理はシークタイムやサーチタイムが無くデー
タのポイントへブロック(512kbyte)単位で I/O を行う点が特徴のストレージです。
・データディスクの測定結果の考察からシーケンシャルアクセスおよびランダムア
クセスの値にさほど差がないことから、Microsoft Azure ストレージの性能特性は
SSD に類似と推定されますので SSD 向け設定値として以下、
「表 6 設定パラメ
ータ」のように変更しました。
・ SSD 向け設定値として、innodb_flush_nighbors を無効に設定後、TpmC 値が有
効前と比べ、10%以上の上昇を確認しました。
表 6 設定パラメータ
設定パラメータ
設定値
[mysqld]
server_id
1000
sysdate-is-now
datadir
/db/mysql1
tmpdir
/mnt/resource/mysql
log_bin
binlog-hostname
37
max_binlog_size
256M
innodb_flush_method
O_DIRECT
binlog_format
mixed
inodb_file_per_table
innodb_buffer_pool_size
38G
innodb_log_file_size
2G
innodb_log_buffer_size
16M
max_prepared_stmt_count
1000000
max_connections
512
thread_cache
512
character-set-server
utf8
innodb_open_files
300
sync_binlog
1
innodb_io_capacity
2000
innodb_flush_nighbors
0
[mysqld_safe]
log-error
/db/mysql1/mysqld.log
[client]
default-character-set
utf8
Microsoft Azure 環境ではシンプルなディスク構成 1 本からストライピングディス
クにデータディレクトリ、ログディレクトリ、Redo ログディレクトリを 1 本のス
トライプディスクに集約した環境で、約 4 倍の TpmC 値へスケールアップしまし
た。
38
2.4 大規模パフォーマンスチューニングのヒント
ユーザ数、更新数、検索数などがある程度想定可能な大規模、高負荷システムの
運用においてはデータ分散環境を構築してディスク分散配置を行い、分割したデ
ィスクの状況をみながら、チューニングを行えば大規模運用を上手にこなせるヒ
ントになると思います。
「図 8
データ分割環境イメージ」を記載しておりますの
で参考にして頂ければ幸いです。
図 8 データ分割
データ分割環境イメージ
分割環境イメージ
39
40
付録3
付録3 MySQL の高可用性と負荷分散
高可用性(High Availability)を考慮したデーベースサーバを冗長化させる構成を
HA 構成と呼びます。MySQL は MySQL レプリケーションを用いて MySQL を
HA 化することができます。負荷分散にはマスタ、スレーブのレプリケーション構
成をすることで性能向上を図ることが出来ます。
MySQL レプリケーションの紹介
HA を構成する最も一般的な MySQL レプリケーションによる HA レプリケーショ
ンについて紹介します。
1.
レプリケーションによる HA 構成
更新系、参照系に対して MySQL Sever を複数台用意することで、障害発生後のダ
ウンタイムを減らすことが出来ます。
更新系：マスタが停止後、スタンバイを新マスタとして切り換えサービスを継続
参照系：どちらかのスレーブが停止しても、残ったスレーブでサービスを継続
2.
レプリケーションを利用した負荷分散
スレーブを複数作成することで、参照負荷を分散します。
3.
MySQL で代表的な HA と負荷分散のご紹介として以下の製品があります。
MySQL Cluster
CLUSTERPRO
DRBD,HeartBeat,Pacemaker
※ ご利用する際、関係会社へお問い合わせください。
4.
負荷分散と高可用性環境について
参照系の負荷分散や更新系の切り替えにはアプリケーションサーバの利用やロー
ドバランス、仮想ネットワークの振り分け、死活監視の仕組みを利用してくださ
41
い。
※本ガイド作成時、Microsoft Azure 環境では一部の機能を工夫する必要がありま
す。
アプリケーションからの負荷分散
レプリケーション構成で負荷分散を行う場合、更新系処理はマスタに接続し参照
系はスレーブに接続するといったような、MySQL の接続先を振り分ける処理が必要
となります。そのため、初期段階ではシングルサーバ構成だったものがアプリケ
ーションの利用ユーザ数増大などの要因により負荷分散のためマスタ、スレーブ
のレプリケーション構成に変更する場合、アプリケーション側だけで管理する場
合は接続の振り分けなど煩雑な接続処理の変更が必要になります。
しかし、下記の接続ドライバーやソフトウェアを利用することでアプリケーショ
ン側の変更を最小限に押さえつつ、接続の振り分けやロードバランスなどの機能
も利用することができるようになります。
MySQL Proxy
MySQL サーバへのロードバランシングやフェィルオーバーをおこなってくれるソ
フトウェア軽量スクリプト言語 Lua を利用して任意の処理を記述することで、接
続先の制御を細かく指定することができます。
以下の資料を参考にしてください。
https://dev.mysql.com/doc/refman/5.6/en/mysql-proxy.html
Connector/J
MySQL の JDBC ドライバー。
複数の MySQL サーバに対して負荷分散を行う機能があります。
以下の資料を参考にしてください。
http://dev.mysql.com/doc/connector-j/en/index.html
mysqlnd_ms
php のレプリケーションおよびロードバランシング用プラグイン
読み込みと書き込みの分離機能やロードバランシングが行えます。
マスタとスレーブサーバの定義を JSON ファイルで指定します。
42
以下の資料を参考にしてください。
http://php.net/manual/ja/book.mysqlnd-ms.php
まとめ
Microsoft Azure は初期導入のシングルサーバ構成から利用ユーザ増大に向けた高
可用性、負荷分散に対してオンプレミス環境で構築するよりはるかに簡単にスケ
ールアウト、スケールアップすることが出来ます。Microsoft Azure はオンプレミ
スと同様に誰もが安心して利用できる環境を本検証で確認することが出来ました。
高可用性構成の検証
本ガイドでは高可用性構成として、MySQL5.6 から提供された mysqlfailover を使
い自動フェィルオーバーの動作検証を行いました。
mysqlfailover について
MySQL5.6 より使用可能である「MySQL Utilities」の「mysqlfailover」が Microsoft
Azure 環境で稼働できるかを確認します。
但し、本ガイド作成時に利用した Microsoft Azure 環境では仮想 IP アドレスの利
用が出来ない為、仮想 IP アドレス付け替える確認はできておりません。ここでは
レプリケーションのマスタサーバに障害発生した場合に、スレーブサーバをフェ
ィルオーバーしてマスタサーバに昇格させることができたことを以下に記述しま
す。
以降の手順は、マスタ・スレーブ構成のレプリケーションサーバ、及び
mysqlfailover を稼動させる監視サーバを用意する構築手順とします。以下、
Microsoft Azure 上の mysqlfailover 構成図は以下です。
43
図 9 Microsoft Azure 上の mysqlfailover 構成
3.1 マスタ・スレーブ構成のレプリケーションの構築
3.1.1 レプリケーションの開始
レプリケーションのインストール・設定方法については「7.2MySQL のインス
トール・設定(マスタ・スレーブ構成)」を参照して下さい。
・レプリケーションユーザの作成については、フェールオーバーする可能性のある
スレーブについてもユーザ作成する必要があります。
mysqlfailover を使用するには、GTID(Global Transaction Identifiers)を使用す
る等の my.cnf で必須となるパラメータがあります、my.cnf に追加設定を行います。
各パラメータは「表 7 構成パラメータ」を参照してください。
my.cnf
# for mysqlfailover
master_info_repository = TABLE
relay_log_info_repository = TABLE
gtid-mode=ON
enforce-gtid-consistency
log-slave-update
表 7 構成パラメータ
設定パラメータ
説明
Master_info_repository = TABLE
レプリケーションにおけるマスタへの接続
44
情報等をテーブルに書き込む。
relay_log_info_repository = TABLE
レプリケーションにおけるリレーログの実
行情報をテーブルに書き込む。
Gtid-mode=ON
レプリケーションを GTID モードで行う。
enforce-gtid-consistency
GTID モードでも、非トランザクションテー
ブルの更新を可能にする。
スレーブの SQL スレッドで実行された更
Log-slave-update
新を、スレーブのバイナリログに記録する。
3.1.2 mysqlfailover 用のアカウント作成
レプリケーションを開始している状態から、マスタサーバ上で、mysqlfailover 用
の監視サーバから接続可能なアカウントを作成します。
mysql> GRANT SUPER, REPLICATION SLAVE, INSERT, SELECT, RELOAD,
DROP, CREATE ON *.* TO failuser@'10.0.0.7' IDENTIFIED BY 'password' WITH
GRANT OPTION;
本検証では、以下のユーザを作りました。
表 8 ユーザ設定情報
追加ユーザ
failuser
ユーザパスワード
password
接続可能ホスト
10.0.0.7 (監視サーバ IP アドレス)
45
3.2 監視サーバの構築(mysqlfailover 稼動)
「５．イメージキャプチャを使ったサーバの複製」を参照し、Windows ポータル
画面から、仮想マシンを作成します。
（ディスクの追加は必要ありません。
）
作成した仮想マシンにログインし、以下の手順を行います。
手順1: MySQL-shared-compat のインストール
# rpm -ivh MySQL-shared-compat-5.6.14-1.el6.x86_64.rpm
Preparing...
############################ [100%]
1:MySQL-shared-compat ############################ [100%]
手順2: mysql-libs のアンインストール
# rpm -e mysql-libs-5.1.67-1.el6_3.x86_64
手順3: perl-DBD-MySQL のインストール
# yum -y install perl-DBD-MySQL
手順4: mysql-connector-python のインストール
# rpm -ivh mysql-connector-python-1.0.12-1.el6.noarch.rpm
rpm は http://dev.mysql.com/downloads/connector/python/ よりダウンロード。
手順5: MySQL Utilities のインストール
# rpm -ivh mysql-utilities-1.3.4-1.el6.noarch.rpm
rpm は http://dev.mysql.com/downloads/tools/utilities/ よりダウンロード。
手順6: mysqlfailover の起動
$ mysqlfailover --master=failuser:[email protected]
--slaves=failuser:[email protected], failuser:[email protected]
--candidates= failuser:[email protected]
--failover-mode=auto
--rpl-user=repl:replpassword
--log=/var/log/mysqlfailover.log
--daemon start
以降、マスタサーバがダウンした際は、
「candidates」オプションで指定したスレ
46
ーブサーバがフェールオーバーされます。
※ 「candidates」オプションを省略すると、スレーブサーバの中で一番レプリケ
ーションのデータ同期が進んでいるものがマスタサーバに昇格します。
・コマンドパラメータについては、
http://dev.mysql.com/doc/workbench/en/mysqlfailover.html を参照して下さい。
・「--log」オプションでのログの出力先には、mysqlfailover の起動ユーザで書き込
み可能とするよう、オーナー及び権限を適切に設定して下さ
終了する場合は、以下のコマンドで終了させて下さい。
$ mysqlfailover --daemon stop
3.3 mysqlfailover の動作検証
レプリケーション構成を起動させた状態で、以下の確認を行います。
スレーブからマスタへ昇格するサーバを本検証では「スレーブサーバ A」を指定し
「スレーブ」から「マスタ」へ昇格するか検証しました。
動作検証するために、以下の構成を用意し確認しました。
表 9 サーバ IP アドレス
サーバ
IP アドレス
監視サーバ
--
マスタサーバ
10.0.0.4
スレーブサーバ A
10.0.0.5
スレーブサーバ B
10.0.0.6
手順1: mysqlfailover の起動
監視サーバで mysqlfailover を起動させます。起動パラメータは以下の通りです。
$ mysqlfailover --master=failuser:[email protected]
--slaves=failuser:[email protected], failuser:[email protected]
--candidates= failuser:[email protected]
--failover-mode=auto
--rpl-user=repl:replpassword
--log=/var/log/mysqlfailover.log
--daemon start
47
手順2: マスタサーバの停止
# /etc/init.d/mysql stop
Shutting down MySQL.......
[ OK ]
手順3: スレーブサーバ A の確認
mysql> SHOW SLAVE STATUS \G
Empty set (0.00 sec)
マスタサーバに昇格した為、スレーブの状態を確認するコマンド「SHOW SLAVE
STATUS;」を実行しても何も表示されません。
手順4: スレーブサーバ B の確認
mysql> SHOW SLAVE STATUS \G
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 10.0.0.5
Master_User: repl
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: mysql-bin.000004
Read_Master_Log_Pos: 1715
Relay_Log_File: ssmart54-2-relay-bin.000003
Relay_Log_Pos: 1925
Relay_Master_Log_File: mysql-bin.000004
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
「Master_Host」が「10.0.0.5」に変更されます。
手順5: フェールオーバー後の動作確認
フェールオーバーでマスタサーバへ昇格したスレーブサーバ A にデータベースを
作成します。
mysql> create database test1;
Query OK, 1 row affected (0.10 sec)
mysql> show databases;
+--------------------+
| Database
|
+--------------------+
| information_schema |
| mysql
|
| performance_schema |
| test1
|
+--------------------+
48
手順6: スレーブサーバ
mysql> show databases;
+--------------------+
| Database
|
+--------------------+
| information_schema |
| mysql
|
| performance_schema |
| test1
|
B で確認
+----------------------------+
昇格したマスタサーバ A からスレーブサーバ B とのレプリケーションが出来たこ
とを確認することが出来ました。
49
付録4
付録4 他社サービスと比較した
他社サービスと比較した MySQL の性能比較
資料提供:
資料提供:株式会社 pnop
50
本稿の目的
本稿では、以下の環境の違いによる MySQL のパフォーマンスの違いを測定しました。
Microsoft Azure の東アジアリージョンと日本（東）リージョンの比較
仮想マシン（IaaS）上に構築した MySQL と Microsoft Azure 上でサードーパ
ーティから提供されている MySQL サービス（ClearDB）の比較
他社クラウドサービス（以下 A 社）の IaaS 上の MySQL および MySQL サービス
と Microsoft Azure の比較
Microsoft Azure 内の比較では同一条件下で、他社のクラウドサービスとの比較では、
Microsoft Azure の環境とできるだけ近いスペックでの比較を行いました。
51
環境
基本的な環境は以下の通り。
IaaS における共通の設定は以下の通り。
・ CentOS6.3
・ MySQL5.6
・ lvm ボリュームによるストライピング設定
・ my.cnf は以下の通り。
[mysqld]
max_connections=500
socket=/data/mysql/mysql.sock
datadir=/data/mysql
character-set-server=utf8
pid-file=/data/mysql/mysqltest2.pid
innodb_log_file_size = 256M
innodb_log_group_home_dir=/data/mysql/log
[mysql]
default-character-set=utf8
[client]
default-character-set=utf8
socket=/data/mysql/mysql.sock
52
Azure における比較環境は以下の通り。
MySQL 比較環境
備考
IaaS（XL）- 東アジア
仮想ディスクを 3GBx16 本追加し、LVM ボリュームを作成。
- 東日本
キャッシュはなし。
同一の仮想ネットワーク内から試験。
ClearDB（Large）
提供される MySQL5.6 を使用。
- 東アジア
A 社における比較環境は以下の通り。
MySQL 比較環境
備考
IaaS（Azure の XL とほぼ EBS を 3GBx16 本追加し、LVM ボリュームを作成。
同等）- 東京
同一の仮想ネットワーク内から試験。
RDBMS サービス（ClearDB 提供される MySQL5.6 を使用。
の Large とほぼ同等）- 東同一の仮想ネットワーク内から試験。
京
tpcc-mysql の実行環境は以下の通り。
環境
備考
Azure（S）
CentOS6.3、tpcc-mysql(rev48)
A 社（Azure S とほぼ同等）
CentOS6.3、tpcc-mysql(rev48)
53
調査内容
比較調査内容は以下の通り。
・ MySQL サーバとは異なるサーバから、tpcc-mysql を使用した TpmC（各 2 回取得）
・上記の状態で、MySQL サーバ上での iostat による IOPS の取得（Azure XL 及び A 社のほ
ぼ同等サイズのみ）
（各 2 回取得）
54
調査結果
tpcc-mysql、iostat は以下のように実施した。
# ./tpcc_start -h サーバー -u ユーザー -p パスワード -d DB 名 -c 500 -r 300 -l 2100
# iostat -x 5 500
実施結果は以下の通り。
環境
TpmC
iops
Azure IaaS（東アジア）
4037.457 TpmC
最小 155.6
4059.143 TpmC
最大 2001
平均 1116.1
Azure IaaS（東日本）
4587.400 TpmC
最小 271.6
4338.200 TpmC
最大 2478.8
平均 1304.5
ClearDB（東アジア）
638.571 TpmC（1 回目）
※ログインできないため未取得
エラーで測定不能（2 回目）
A 社 IaaS（東京）
3635.000 TpmC
最小 242.4
2922.914 TpmC
最大 5952.2
平均 1002.9
A 社 RDBMS サービス（東京）
2843.171 TpmC
2685.971 TpmC
55
※ログインできないため未取得
測定結果
経過時間(秒)
経過時間(秒)
経過時間(秒)
56
経過時間(秒)
57
結果考察
Azure IaaS（東日本）が一番良い結果となっている。
また、IaaS の方が用意された DB サービス（ClearDB、A 社 RDBMS サービス）よりパフォー
マンスが良い。ただし、A 社 RDBS サービスは有料の IO 性能向上オプションを利用すること
で性能が向上する可能性がある。
ClearDB は接続数が多いとエラーが頻発するなど、不安定である。
TpmC が低い理由は、ミラーリングの仕組みが組み込まれており、また、その性能もよくな
いためと考えられる。
58
環境構築手順
lvm ボリュームの作成
ディスク追加後の作成手順は以下の通り。
lvm 関連コマンドが無い場合はインストール
# yum install lvm2
物理ボリューム作成
# pvcreate /dev/sd*（AWS の場合は /dev/xvd*）
ボリュームグループ作成
# vgcreate グループ名 /dev/sdc /dev/sad
論理ボリューム作成
# lvcreate -n 論理ボリューム名 -l 100%FREE -i ストライプ数（ディスクの数）グループ名
フォーマット
# mkfs -t ext4 /dev/mapper/グループ名-論理ボリューム名
マウントポイント
# mkdir -p /data/mysql
fstab に追記
# vi /etc/fstab
/dev/mapper/グループ名-論理ボリューム名 /data/mysql ext4 defaults,nobarrier, 0 0
マウント
# mount /dev/mapper/グループ名-論理ボリューム名
59
MySQL のインストール
MySQL は Oracle で配布されているパッケージを使用して、以下の通りに導入。
#wget http://dev.mysql.com/get/Downloads/MySQL-5.6/MySQL-5.6.15-1.el6.x86_64.rpm-bundle.ta
r
# tar xvf MySQL-5.6.15-1.el6.x86_64.rpm-bundle.tar
# rpm -ihv MySQL-shared-compat-5.6.15-1.el6.x86_64.rpm
# rpm -e mysql-libs （※コンフリクトするので）
# rpm -ihv MySQL-client-5.6.15-1.el6.x86_64.rpm
# rpm -ihv MySQL-server-5.6.15-1.el6.x86_64.rpm
# rpm -ihv MySQL-shared-5.6.15-1.el6.x86_64.rpm
# service mysql start
# cat /root/.mysql_secret （root パスワードが書いてある w）
# mysql_secure_installation （もし必要なら）
# cp -pr /var/lib/mysql/* /data/mysql/
# chown -R mysql:mysql /data/mysql
# service mysql stop
# vi /usr/my.cnf
tpcc-mysql のインストールと設定
tpcc-mysql は以下の通りに導入。
# yum -y install bind-utils bzr male gcc
# bzr branch lp:~percona-dev/perconatools/tpcc-mysql
# cd tpcc-mysql/src
# make
# cd ../cat .mysq
# mysqladmin -u root -p create tpcc
# mysql -u root -p tpcc < create_table.sql
# ./tpcc_load ホスト tpcc ユーザ名パスワード 1
# mysql -u root -p tpcc < add_fkey_idx.sql
# ./tpcc_start -h ホスト -d tpcc -u ユーザ名 -p パスワード -c コネクション数 -l 実行時間
60