エンタープライズ環境で稼動する mysqlapサーバ（apache、tomcat、php、perl...

エンタープライズ環境で稼動するMySQL

株式会社ビーグッド・テクノロジー

2009年6月24日

2

アジェンダ

１．MySQL Enterpriseとは

２．Oracleとの比較

３．MySQLのバックアップリカバリ

４．高可用性 MySQL

５．MySQLパフォーマンスチューニングの紹介

６．MySQL ロードマップ

７．MySQLソリューションのご紹介

８．開発者視点でみたMySQL

１．MySQL Enterpriseとは

１－１． MySQL Enterpriseとは１－２．無償版との違い１－３． MySQL Enterpriseのスケーラビリティ

１－３－１．主キーで一致検索１－３－２．非ユニークIndexで一致検索１－３－３．主キーで範囲検索（範囲の最小値取得）１－３－４．主キーで範囲検索（ヒット件数取得）１－３－５．非ユニークIndexで範囲検索１－３－６．Index無カラムの最小値取得（フルスキャン）１－３－７．INSERT処理方式別のパフォーマンス

１－４． MySQL Enterpriseの信頼性１－５． MySQL 大手企業における実績

3

APサーバ

（Apache、Tomcat、PHP、Perl 等）

１－１． MySQL Enterpriseとは

高可用性高可用性

高性能高性能

コスト削減

コスト削減

エンタープライズ環境

でも安心して利用

MySQL Enterpriseは、OSS DBのMySQLの有償版ライセンスです。エンタープライズ利用に特化したMySQL Enterpriseで低コストかつ安定したシステム導入が可能になります。

モニタリングツール

モニタリングツール

メーカーサポート

メーカーサポート

認定版安定バイナリ

認定版安定バイナリ

DBサーバ（MySQL Enterprise）

ECサイト、ブログ、業務アプリケーション、

データウェアハウス等利用場面は多岐にわたる

MySQL Enterpriseはエンタープライズ環境でも安心して利用可能なプロダクトです

LAMPスタック

（Linux、Apache、MySQL、Php/Perl/Pythion）

サーバ

モニタリング

サポート

MySQLの特徴

MySQL Enterpriseの利点

MｙSQL Enterprise Server ソフトウェア (Download)月次ラピッドアップデート四半期サービスパックホットフィックスプログラム延長ライフサイクルポリシー

MySQL Enterprise Monitor 複数のMySQLサーバを一括監視するトラブルを未然に防ぐアドバイザリー機能Webベースダッシュボード低速クエリを改善するクエリアドバイザ

24 × 7 × 365 製品サポート（日本語は平日9-17）ナレッジベースエキスパートアドバイススケールアウト構成のサポート

4

１－２．無償版との違い

無償版であるMySQL Community Serverとの相違点を示します。有償版であるMySQL Enterpriseは安定したシステム稼働と、運用者が安心して運用できる環境を提供します。

有償版と無償版の比較

ソースコードも同時に配布する事で可能不可能（配布する場合、OEM版が主となる。）再配布の可否

GPL（GNU General Public License）Server ライセンスは、サービスレベルの異なるBasic、Silver、Gold、Plutinum、Unlimited より選択可能。課金単位はCPU単位でなく物理サーバ単位（仮想環境では仮想OS単位）組込み用OEM版有

ライセンス形態

月1回アップデート，四半期に1回サービス・パック

公開されている各種ツール、商用ツールの他に下記ツールが利用可能モニタリングツール Enterprise Monitor ※Silver以上クエリ解析ツール MySQL Query Analyzer ※Gold以上スキーマアドバイザ ※Plutinum以上

Enterprise版（※MySQL公式リリース）

ライセンスフィーがかかる。

安定稼動用にビルドされた商用版のバイナリ運用サポートの強力なツール有償版購入者のみに公開されるナレッジベースサポート窓口致命的なバグに対する緊急ホットフィックスの提供

MySQL Enterprise（有償版）

年２回

一般公開されている各種ツール（phpmyadmin、mysqladministrator 等）商用ツール（InnoDB Hot Backup、

community版もしくはソースコードから独自でビルド

運用ツールも含め、自己責任での利用致命的なバグに対する修正は保障されない。

ライセンスコストがゼロ先進性を重視しており、新機能をいち早く試せる

MySQL Community Server（無償版）

Binaryの種類

メリット

リリース間隔

利用可能なツール

デメリット

5

6

１－３．MySQL Enterpriseの検索性能とスケーラビリティ

【サーバ環境】Server ： DELL PowerEdge860 (1U）CPU ： Intel(R) Xeon(R) CPU 3050 @ 2.13GHz 2coresMEM ： 4GDISK ： SEAGATE Model: ST373455SS (SAS,15000rpm,キャッシュ16M）

※ローカルディスク、NO RAIDで利用OS ： CentOS5.2 x86_64 （Red Hat Enterprise Linux 互換OS)カーネル： 2.6.18-92.el5 #1 SMP Tue Jun 10 18:51:06 EDT 2008 FileSystem : ext3 (LVM )

弊社検証環境でベンチマークを実施しましたのでご紹介します。 MySQL5.0系と5.1系それぞれのMyISAMとInnoDBの速度を計測しました。

ベンチマーク環境

【テーブル定義】CREATE TABLE IF NOT EXISTS normal(ìd` int(10) unsigned NOT NULL auto_increment,`name` varchar(64) NOT NULL default ”,èmail` varchar(64) NOT NULL default ”,`password` varchar(64) NOT NULL default ”,`dob` date default NULL,àddress` varchar(128) NOT NULL default ”,`city` varchar(64) NOT NULL default ”,`state_id` tinyint(3) unsigned NOT NULL default ‘0′,`zip` varchar(8) NOT NULL default ”,`country_id` smallint(5) unsigned NOT NULL default ‘0′,PRIMARY KEY (ìd`),UNIQUE KEY èmail` (èmail`),KEY `country_id` (`country_id`,`state_id`,`city`)) ENGINE=innoDB; もしくは MyISAM;

※ENGINE（ストレージエンジン）はInnoDBとMyISAMの2種類で計測

【MySQL バージョン】

MySQL Enterprise Server 5.0.79 SP1 x86_64-glibc23MySQL Enterprise Server 5.1.30 x86_64-glibc23

上記２バージョンで計測

【MySQL 初期化パラメータ】 ※一部抜粋skip-lockingkey_buffer = 1250Mmax_allowed_packet = 16Mtable_cache = 1024sort_buffer_size = 2Mread_buffer_size = 2Mread_rnd_buffer_size = 8Mmyisam_sort_buffer_size = 64Mthread_cache_size = 64query_cache_size = 128Mquery_cache_type = 0 (OFF)thread_concurrency = 4max_connections=1500net_read_timeout=30net_write_timeout=30back_log=128innodb_buffer_pool_size = 1250Minnodb_additional_mem_pool_size = 50Minnodb_log_buffer_size = 4Minnodb_thread_concurrency=8sync_binlog=1

【計測方法】・100万件が登録されたテーブルに対して、1分間のアイドリング検索を実施後、1分間×3回のクエリ数計測を実施し、その平均値を取得した。・同時実行数（Concurrent Threads)別に計測を実施。複数同時実行の値は、それぞれThreadで実行したクエリの合計値となる。・ベンチマークプログラムはPHP製。MySQLクライアントは、PHPのmysqliエクステンションを利用。・純粋なクエリ実行数の計測であり、DBサーバへの接続コストは含まれていない。

7

１－３－１．主キーで一致検索

※現時点では２コアサーバでしか検証できていませんが今後、よりコア数の多いサーバで検証していく予定です。

READ PK POINT ：主キーで一件検索

主キーによる一致検索で「秒間25,000クエリ以上！」の検索性能を実現しています。また、同時実行数が増えてもほぼ性能劣化しておらず、コア数である2tread 同時実行までは性能がスケールしています。若干InnoDBのほうがMyISAMより性能が上回っていますが、InnoDBのクラスターIndex（クラスターIndexについては後述）の効果と想定されます。

READ PK POINT

0

5,000

10,000

15,000

20,000

25,000

30,000

35,000

１thread 2threads 4threads 8threads 16threadsConcurrent Thread

Queries / Second

5.1.30 InnoDB5.1.30 MyISAM5.0.79 InnoDB5.0.79 MyISAM

8

１－３－２．非ユニークIndexで一致検索

READ KEY POINT_LIMIT ：非ユニーク Indexで一件検索し、そのうち10件を抽出

非ユニークIndex検索は主キーと比較して50%程度の性能となりましたが、これでも十分高速と思われます。尚、実際の抽出件数によりブレがありますので、今回は検索条件にHitしたものから10件を抽出として比較しました。若干MySQL5.0.79のInnoDBが他と比較して高速となっています。

READ_KEY_POINT_LIMIT

0

5,000

10,000

15,000


Queries / Second


9

１－３－３．主キーで範囲検索（範囲の最小値取得）

READ PK RANGE ：主キーで範囲検索し、その最小値を取得

範囲検索においても、高い数字をマークしています。InnoDBはクラスタインデックス方式（※）ですので、主キーによる検索が特に強いです。一般的に検索系はMyISAMといわれますが、主キーで検索した場合、InnoDBも十分速度がでています。（※）InnoDBとMyISAMの違いは後述します。

READ PK RANGE

0

5,000

10,000

15,000

１thread 2threads 4threads 8threads 16threads

Concurrent Thread

Queries / Second


10

１－３－４．主キーで範囲検索（ヒット件数取得）

検索範囲内の件数カウント（カウント対象カラムはIndex有）も高速です。

READ PK RANGE INDEX：主キーで範囲検索し、そのヒット件数を取得

READ PK RANGE INDEX

0

3,000

6,000

9,000

12,000

15,000


Queries / Second


11

１－３－５．非ユニークIndexで範囲検索

READ KEY RANGE_LIMIT ：非ユニーク Indexで範囲検索し、そのうち50件を抽出

非ユニークIndexにおける範囲検索においても、高い数字をマークしています。非ユニークIndex検索の場合、MySQL5.0.79のInnoDBが他と比較して若干高速となっています。

READ_KEY_RANGE_LIMIT

0

2,000

4,000

6,000

１thread 2threads 4threads 8threads 16threadsConcur rent Thread

Queries / Second


12

１－３－６．Index無カラムの最小値取得（フルスキャン）

READ FTS ：Indexのないカラムの最小値を取得

非Indexカラムの最小値取得はテーブルのフルスキャンとなり低速です。但し、MySQL機能であるクエリキャッシュを有効（query_cache_type=ON)にする事で再発行時の検索コストを抑える事は可能です。

READ FTS

0

2

4

6

8

１thread 2threads 4threads 8threads 16threads

Concurrent Thread

Queries / Second


13

１－３－７．INSERT処理方式別のパフォーマンス

バルクロード：可変長データ（CSV等）、固定長データからのデータロードmysql> LOAD DATA INFILE “import_data.csv” INTO TABLE tableA FIELDS TERMINATED BY ‘,’ ENCLOSED BY ‘”’;

マルチプルInsert（MySQL独自構文）：Insert文１発行で複数行セットを挿入するInsert文mysql> INSERT INTO emp (empid,name,country) VALUES(1,’taro’,’jpn’),(2,’jiro’,’usa’),(3,’saburo’,’ita’),(4,’shiro’,’chu’);※１Insert文のサイズは、初期化パラメータ max_allowed_packet以内となる事が条件

通常Insert ：Insert文１発行で１行を挿入するInsert文mysql> INSERT INTO emp (empid,name,country) VALUES(1,’taro’,’jpn’);mysql> INSERT INTO emp (empid,name,country) VALUES(2,’jiro’,’usa’);

Insert方式は用途に応じて各種選択が可能です。大量データの一括ロード時は、SQL文のパースが必要ないバルクロードを利用する事が効果的です。アプリケーション仕様上、登録行セットをまとめる事が可能であれば、MySQL独自構文であるマルチプルInsert文（１回のInsert文発行で複数行セットをInsertする）を利用する事が効果的です。

28,284.00

370.88

132.01

95.39

37.79

InnoDB

MySQL 5.1.30

29,797.00

3,393.88

2,392.40

2,048.20

31.51

MyISAM

--2,560.96102.88500行

25,459.00

300.38

78.86

31.99

InnoDB

MySQL 5.0.79

27,887.00

3,554.03

2,104.75

31.24

MyISAM

【参考】1,000万件ロード時

( MySQL 5.0.79 ／ MySQL 5.1.30 )

１Insertの

行セット数

Insert

処理方式

-

-

-

805.78 ／ 864.08

InnoDB

1行

100行

1,000行 -マルチプルInsert

366.28 ／ 371.06バルクロード

-

-

MyISAM

通常Insert ※1000件分を計測し ×1000で算出

Row長約２００bytes、100万件（約200Mbytes）のデータを投入した場合の比較（単位：秒）

（サーバ環境とMySQLパラメータは前項目と同一。NO RAID、元データは同じローカルDISKよりロード）処理時間比較

※InnoDBのトランザクションはAuto Commitで実施。

14

１－３．MySQL Enterpriseのスケーラビリティまとめ（１）

２コアサーバにおいてはコア数までスケールし、同時実行数があがっても、性能劣化しなかった。

日本MySQL会木下氏（元NTTcomware社）の検証によると、MySQL5.0.27までは4コアまでしかスケールしなかったがMySQL5.0.30では（排他制御の改善により）4コア以上8コアまでスケールすることが検証されている。http://conferences.oreillynet.com/presentations/mysql07/InnoDB_kinoshita.pdf

※現時点では２コアサーバでしか検証できていないが、今後、よりコア数の多いサーバで検証していく予定

尚、木下氏は現在USのMySQLソリューションベンダーPercona社に転職して、さらに多コアでもスケールするパッチを開発しているhttp://www.mysqlperformanceblog.com/2008/11/01/yasufumi-kinoshita-joins-percona/

15

１－３．MySQL Enterpriseのスケーラビリティまとめ（２）

MySQL5.1系と比較して、MySQL5.0系が若干高速

MySQL5.1系は昨年末リリースされたばかりで、パーティショニング機能や、行ベースレプリケーション機能等にバグが残っているため、導入前に入念な検証が必要となる。【参考】公開中のバグ

http://dev.mysql.com/doc/refman/5.1/en/open-bugs.html

InnoDBの主キー検索は非常に高速。検索重視のMyISAMにも劣らない。

尚、MySQL5.1系の導入を検討する場合、注意が必要です。

弊社といたしましては、安定版であるMySQL5.0を推奨します。

InnoDBの特徴であるクラスターIndexは、主キー(B-tree)のリーフページにデータが直接格納されています。従って、主キーと行データの紐付けにかかるI/Oコストが少ないです。

InnoDB、MyISAM共にMySQL5.0系が若干パフォーマンスが出ており、安定版として枯れてきている事が想定される。

バッチ処理等による大量データのInsert時、またMyISAM利用時はバルクロードが高速

アプリケーションによるInsert処理は、InnoDBでは可能な限りマルチプルInsertが望ましい。（※MyISAMではマルチプルInsertでも劇的には速くはならない。）

注意点として、ロード対象がレプリケーションのMasterで、ステートメントベースレプリケーションの場合、Slave側にもロード用のデータが必要となる。（行ベースレプリケーションでは必要ないが、代わりにログ出力のオーバーヘッドがある。）

16

１－４．MySQL Enterpriseの信頼性

弊社検証環境において、MySQL Enterpriseを高負荷の状態で3日間連続稼動させました。また、必要ファイルの削除等を実施し、サーバ強制終了がかかるかをテストしました。

高負荷状態での長期稼動においてもサーバが停止することない信頼性の高いシステム構築が可能です。

Insert、Update、Selectクエリを同時に絶間なく発行しましたが、 CPU使用率が100%近い状態が続いてもMySQLサーバは停止することなく動作しました。

【実行条件】

・１－３の検証環境と同一の環境

・InnoDB、MyISAMのテーブルに対して、Insert文、Update文のループ実行を絶え間なく実行

・Insert、Update文の実行中にSelect系クエリも同時に絶間なく実行。

（最大 InnoDB 8threads、MyISAM 8threads 同時実行）

17

１－５． MySQL 大手企業における実績

大手SNSサイト運営

株式会社ミクシィhttp://mixi.co.jp/

「LAMP（OSのLinux、WebサーバのApache、DBMSのMySQL、開発言語のPerl、PHP、Python）」と呼ばれるWebシステム向けの標準的なオープンソースソフトウェア（以下、OSS）でシステムを自社開発し、安価なPCサーバを1000台以上連ねる超分散構成でmixiのサービスを支えている（広告配信など周辺機能では、パッケージ製品を採用している部分もある）。このmixiのケースは、MySQLを採用するWebシステムとして、間違いなく世界有数の規模といえる。

3年半でユーザー数が1000万人を超えたmixiのサービスのシステム拡張事例が以下で紹介されている。http://techtarget.itmedia.co.jp/tt/news/0709/12/news01.html

また、MySQL公式ページに大規模なスケールアウトの例として紹介されている。http://www.mysql.com/why-mysql/scaleout/mixi.html

MySQLは大手企業のコアシステムにも採用されています。

18

１－５． MySQL 大手企業における実績

大手ナレッジコミュニティサイト運営

株式会社はてなhttp://www.hatena.ne.jp/

主にナレッジコミュニティサービス「人力検索はてな」やブログホスティングサービス「はてなダイアリー」、ソーシャルブックマークサービス「はてなブックマーク」などの開発・運営を行っている。基幹サービスでMySQLを利用。レプリケーションで負荷分散している。

http://bloghackers.net/~naoya/ppt/081108huge_data.ppt

大手銀行

新生銀行http://www.shinseibank.com/

基幹システムをメインフレームからオープン系システムへ移行。自社のCRM（カスタマー・リレーションシップ・マネジメント）システムをMySQL とSugarCRM で標準化。従来のメインフレームと商用パッケージソフトウェアを使用した場合と比較して、90%のコスト削減を実現。

http://japan.zdnet.com/news/devsys/story/0,2000056182,20383346,00.htm

２．Oracleとの比較

２－１アーキテクチャの違い

２－２ストレージエンジンについて

２－３各種機能の違い

19

mysqld

20

２－１．アーキテクチャの違い（インスタンス）

MySQLとOracleは同じサーバクライアント方式ですが、アーキテクチャには違いがあります。

MySQL Oracle

MyISAM

プロセスを複数起動（マルチプロセ

ス）。プロセス間で連携を図る

サーバプロセス

※ テーブル毎にストレージエンジンを選択可能

Oracleはマルチプロセス形式、MySQLはマルチスレッド形式。マルチスレッド形式はマルチプロセス形式と比較してメモリ使用率が低い。MySQLはストレージエンジンという概念がある。

InnoDB

プロセスメモリ

Key Buffer

プロセス

PMON（プロセスモニタ）

SMON（システムモニタ）

メモリ

Join Buffer

Read Buffer

Sort Buffer

Bin-log Cache

InnoDB Log Buffer

サーバプロセスは１つ。プロセスが

スレッドを生成して動作する。

シグナル管理スレッド

サーバスレッド

※ クライアント接続毎にサーバスレッド生成

テーブルストレージエンジン

監視スレッド

汎用スレッド

非同期ファイルI/Oスレッド

サーバスレッド

InnoDBバックグランドスレッド

テーブル

インスタンス

バイナリログ

Redoログ

Ctlファイル SPファイルmy.cnf

インスタンス

InnoDB Buffer Pool

Query Cache

Table Cache

Thread Cache

SGA

バッファキャッシュ

Javaプール

PGA

ラージ・プール

共有プール

Redoバッファ

ストリーム・プール

バックグランドプロセス

DBWn（データベースライタ）

LOGWR（ログライタ）

CKPT（チェックポイント）

ARCn（アーカイバ）

RECO（リカバラ）

サーバプロセス

※ クライアント接続毎にサーバプロセス生成（専用サーバ接続の場合）

21

２－１．アーキテクチャの違い（ユーザとスキーマ）

Oracleは「ユーザ≒スキーマ」という形をとりますが、MySQLはユーザとスキーマは完全に分離されています。（スキーマの所有者という概念がありません。）またMySQLは接続元クライアントによる権限設定が可能です。

MySQL Oracle

MｙSQLは接続元のアクセスコントロールが可能。ユーザとスキーマが完全に分離しているため、スキーマの追加が容易

ユーザA ユーザB@Localhost

ユーザC

スキーマ A スキーマ Cスキーマ Bスキーマ X

ユーザA ユーザB ユーザC

スキーマ Y スキーマ Z

ユーザ[email protected]

ユーザが所有するオブジェクトやスキーマ領域がない。「ユーザID + 接続元（どのホストからの接続か）」で権限設定が可能。スキーマ単位、テーブル単位、カラム単位、ルーチン単位等で設定可能新規スキーマ追加も容易に行うことが可能。

「ユーザID＋接続元＋スキーマ」で、アクセスコントロールが可能

ユーザは自スキーマと、そこで所有するオブジェクトを持つ他ユーザの所有オブジェクトにアクセスする場合に権限が必要自スキーマであっても、コネクトやリソース権限は必要新規スキーマを作成するにはユーザ作成が必要。

スキーマ所有者以外が参照・更新する場合に権限設定が必要

ダミーテーブル用

複数のMyISAMテーブルをマージしたもの

メモリ上にテーブルを配置する。

MySQL Cluster専用のストレージエンジン（MySQL Cluseterについては後述）

InnoDBの発展版（トランザクション、行レベルロック等をサポート）まだ技術的に枯れておらず普及はしていない。

MyISAMの圧縮版

リモートのデータベース参照用。OracleのDB LINKに違いが、セキュリティ面に課題がある

22

２－２．ストレージエンジンについて（１）

MySQLの特徴的な機能として、ストレージエンジンというテーブル単位でデータ格納方法や機能を選択できる仕組があります。 SQLインターフェースとストレージエンジンが完全に分離されていますので、 SQL実行命令は同じでも、ストレージエンジンによりページングやDISK I/Oの動作が異なります。また物理ファイルのロストレージエンジンはAlter Table文で動的に変更する事も可能です。

各種ストレージエンジンの概要

MyISAM

InnoDB

Oracleの機能に近いストレージエンジンはInnoDBです。

Memory

NDB

Falcon

archive

アプリケーション

クライアントインターフェース（mysql、connecter/J、JDBC、ODBC他）

SQL文解析

実行計画実行

MyISAM InnoDB Memory NDBストレージエンジン層

MySQLインターフェース層

アプリケーション層

Federated

Merge

MySQL標準のストレージエンジン

行ロック、トランザクション、外部キー、自動クラッシュリカバリ等をサポートするストレージエンジン

Blackhole

23

２－２．ストレージエンジンについて（２）

一般的によく利用されるInnoDBとMyISAMの機能と特徴について説明します。

代表的なストレージエンジンの機能と特徴

MyISAM

InnoDB

Oracle感覚で使うにはInnoDBを選択する事をお勧めします。Mixi事例では、大半がInnoDBで、ログ系がMyISAMといった形で運用されています。

・トランザクション機能、外部キー、行レベルロック、自動クラッシュリカバリ機能を有する。

・MyISAMより低速と言われるが、MyISAMでテーブルロックが頻発するようなアプリケーションの場合、こちらがのほうが速い。よほどの検索要件でない限りInnoDBで十分使える。・データおよびIndexは全テーブル共通のデータファイルに格納される。（一定のファイルサイズで分割や、テーブル毎に分割も可能）

・主キーがクラスターインデックス形式（クラスターインデックスは次頁参照）

・文字型は固定長列より可変長列のほうが速い

・更新頻度的にMyISAMでは難しい場合、またトランザクションが必要となるアプリ実装時にはInnoDBが適している。

・MySQL標準のストレージエンジン。根幹テーブルである権限テーブル、キャラクタセット情報テーブル、Collation情報テーブルはMyISAM形式となる。

・MyISAMはトランザクションに未対応であり、また行ロックができない。（テーブルロックレベルまで）

・１テーブルは、３ファイル（テーブル定義、インデックス、データ）で構成される。

・文字型は固定長列で揃えたほうが速い

・データ格納方式がシンプルで一般的に検索が高速と言われるが、テーブルロックがボトルネックとなりうる為、更新頻度が10%未満、もしくはトランザクションを必要としていないログ系テーブルのような場合に有効となる。

24

２－２．ストレージエンジンについて（３）

Oracle感覚で使えるInnoDBは、クラスターインデックスというアーキテクチャを採用しています。

InnoDBで押さえるべきポイント

InnoDBは主キーがクラスターインデックス。クラスターインデックスでは、主キー(B-tree)のリーフページにデータが直接格納されています。

主キー以外のインデックス（副次インデックス）はリーフページに主キーの値を格納

副次キーでのアクセスはユニークキーであったとしても、主キーでのアクセスに比べて、倍近くのI/Oが発生するデータを連続してアクセスする場合、同一ページに存在する確率が高いのでバッファが有効に使用される主キーの昇順等でアクセスする場合に性能が高い主キーでアクセスした場合、データにアクセスする事になる為、全件カウント時は副次キーのヒントをつける。主キーの値を変更する場合に、データ自体の格納場所を変更するためにコストが高い副次インデックスのリーフページ全てに主キーが格納される為、主キーの項目長が長くなった場合の悪影響が大きい。

クラスターインデックスが意味することは

RAW :2000バイト

LONG RAW:2Gバイト

CLOB :4Gバイト

BLOB :4Gバイト

NCLOB :4Gバイト

BINARY :255バイト

VARVINARY :65532バイト

TINYBLOB :255バイト

BLOB :64Kバイト

MEDIUMBLOB :16Mバイト

LONGBLOB :4GB

バイナリ型、ラージオブジェクト型

日付／時刻型

数値型

TEXT型

Varchar型

Char型

年：YEAR

年月日：DATE

時分秒：TIME/TIMESTAMP

年月日時分秒：DATETIME/TIMESTAMP

年月日時分秒ミリ秒：なし

期間：INTERVAL

NUMERICTINY INT :1バイトSMALLINT ：2バイトMEDIUMINT：3バイトINTEGER ：4バイトBIGINT ：8バイト

TINY TEXT ：255バイトTEXT ：64KBMIDIUM TEXT：16MBLONG TEXT ：4GB

65532バイト（1テーブルでの上限が64KB（TEXT、Blob除く））

255文字

MySQL

NUMBER

LONG：2Gバイト

年：DATE

年月日：DATE

時分秒：DATE

年月日時分秒：DATE

年月日時分秒ミリ秒：TIMESTAMP

期間：INTERVAL

最大長： 4000バイト

最大長：2000バイト

Oracle

主なデータ型と最大サイズ

２－３．各種機能の違い（１）

その他のMySQLとOracleの機能の違いを記載する。

25

２－３．各種機能の違い（２）

有り有り（但し、ステートメントレベルのバイナリログ出力時、非決定性の動作（例：order by句無しのlimit句update 、ランダム関数利用等）は不整合が起こる可能性がある。

ストアドファンクション

RowレベルInnoDB ：Rowレベル

MyISAM：テーブルレベル

ロック可能最小レベル

有り有り２相コミット

有り有りトランザクション

有り有りシーケンス

有り有り（MySQL 5.1以降）パーティション

有り有りビュー

有り有り（但し、ステートメントレベルのバイナリログ出力時、非決定性の動作（例：order by句無しのlimit句update 、ランダム関数利用等）は不整合が起こる可能性がある。

トリガ

有り有り（但し、ステートメントレベルのバイナリログ出力時、非決定性の動作（例：order by句無しのlimit句更新や、ランダム関数利用等）は不整合が起こる可能性がある。

ストアドプロシージャ機能の有無

ローカル接続はSIDを指定して接続する。リモート接続はTNS LISNTERを経由して接続する。

UNIX系サーバのローカル接続は、ソケットファイルとポートを指定して接続する。リモート接続はTCP/IP＋接続ポート指定の接続となる。

クライアント接続方式

外部結合の（＋）はOracle特有の表現。MySQLではLeft OUTER JOIN または RIGHT OUTER JOINを使う。

SQL

論理演算子のXOR無し集合演算子の INTERSECT、MINUS 無し演算子

OracleMySQL

26

２－３．各種機能の違い【補足】

ストアドプロシージャ、ストアドファンクション、トリガ利用時の注意点について

「ステートメントベース」のトランザクションログ（OracleではRedoログ）を出力している場合、非決定性のストアドプロシージャ、ストアドファンクション、トリガに注意が必要となる。(これは非決定性のクエリも該当する。）

・ UPDATE T SET id = UUID() WHERE ...; ⇒ UUID()の値がランダム。

・ Insert Into T （id,name,address)

values(load_file(‘C:¥id.data’), load_file(‘C:¥name.data’), load_file(‘C:¥address.data’) ) ⇒ 読込むファイルが常にあると限らない。

・ UPDATE T SET col = 1 LIMIT 10; ⇒ ORDER BY句がない場合は、対象行が保障されない。

・上記構文を含むもの、もしくは実行タイミングなどの別ファクターにより値が変わるストアドプロシージャ、ストアドファンクション、トリガ等

○ステートメントベース：トランザクションをステートメント（SQL文）として記録○行ベース：トランザクションで更新された行そのものを記録

・ステートメントベースのトランザクションログでは、更新結果そのものは保存されず、実行ステートメントがログに保存される。

・従って上記の非決定性のクエリや、それらを含むプロシージャやファンクション実行時は、リカバリ時、レプリケーション時に同じ結果となることが保障されない。

・行ベースのトランザクションログ出力であれば問題ないが、MySQL5.1以降の機能でバグが残っているのでお勧めできない。

【非決定性のクエリの例】

27

３．MySQLのバックアップリカバリ

３－１．バックアップ手法別比較３－２．リカバリ手法別比較３－３． MySQLバックアップリカバリ推奨手順（LINUX環境）３－4． MySQLバックアップリカバリ所要時間３－５．トランザクションログ３－６．バックアップリカバリのポイント

28

３－１．バックアップ手法別比較

Colｄバックアップ

オンラインバックアップ

物理バックアップ

物理バックアップ

論理バックアップ

特徴MySQL

実現手法

Oracle

実現手法

OSコマンドによるファイルコピー

ストレージ製品の遠隔ミラー機能（EMC MirrorView/AやSnapMirror）による取得

MySQLも他の商用RDBMSと同様に様々なバックアップ手法が用意されています。Oracleとの比較例を以下に記載します。

構成ファイルそのものをバックアップ

サーバ停止無しでバックアップ取得が可能

通常、論理バックアップより高速

全体で一貫したバックアップを行うには、全テーブルをロックする必要がある。もしくは差分をトランザクションログで補完する。

構成ファイルそのものをバックアップ

データベース全体で一貫性のあるバックアップ取得が容易

バックアップ中はDBサーバの停止が必要

Exportユーティリティ

DataPumpユーティリティ

※全体で一貫性を保つにはCONSISTENT=Yオプションや全体へのロックが必要

バックアップ時点までの復旧しかできない。（ロールフォワード不可能）

その他

レプリケーション

（スタンバイデータベース）

増分バックアップ

（トランザクションログ）

アーカイブログバイナリログ

Data Guard

（アーカイブブログ適用による同期処理）

オンライン中に取得が可能で速度が速い、オンライン物理バックアップのニーズが高いと考えます。MｙSQLもOracleと同じように多様なバックアップ選択肢があり、運用スタイルあったバックアップを選択できます。

テーブル定義やデータを、SQLやCSVファイルとして論理的に取得。

サーバ停止無しでバックアップ取得が可能

全体で一貫したバックアップを行うには、全テーブルをロックする必要がある。

通常、物理バックアップより低速。

ﾚﾌﾟﾘｹｰｼｮﾝ側をﾊﾞｯｸｱｯﾌﾟDBとして扱う

ロックが不要、リカバリ所要時間が早い

同構成のスタンバイ機が必要


ストレージ製品の機能（EMC MirrorView/AやSnapMirror）による取得


ストレージ製品の遠隔ミラー機能による取得

スナップショット（LVM Snapshot等）＋OSコピーによる取得

Read Table With Read Lock

Zmanda（他社製品）

InnoDB HotBackup（他社製品）


ストレージ製品の遠隔ミラー機能による取得

スナップショット（LVM Snapshot等）＋OSコピーによる取得

Begin Backup文

Recovery Manager（RMAN)

Mysqldumpコマンド

Select into OUT FILE コマンド

バックアップ時点からのロールフォワードが可能

バックアップ時点からのトランザクションログを、増分バックアップとして扱う。

Master-Slaveレプリケーション

（バイナリログ適用による同期処理）

29

論理バックアップ時点までの復旧

３－２．リカバリ手法別比較

物理ファイルバックアップ時点までの復旧

リカバリ方式について特徴と、実現手法を記載する。

障害時点までの復旧

（ロールフォワード）

特徴MySQL

実現手法

Oracle

実現手法

クラッシュリカバリ

スタンバイデータベースのマスター化

バックアップメディアからのファイルリストア

バックアップボリュームマウントとOSコピーによるリストア

論理バックアップのリストアより速い

論理ファイルのインポートユーティリティが必要

物理ファイルバックアップのリストアより遅い

Oracleではこの方式ではロールフォワードが不可能

トランザクションログを用いて、障害直前までの回復

ある時刻への復旧（ポイントタイムリカバリ）

障害直前まで早期回復が可能となる、物理ファイル復元＋ロールフォワードがMySQLでもお勧めです。

データベースの強制終了時の不整合における自動リカバリ機能

Myisamchk

InnoDBログによるサーバ起動時の自動リカバリ

Redoログによるサーバ起動時の自動リカバリ

バイナリログによる同期処理

Slave → Masterへの変更

フラッシュバックデータベースフラッシュバックデータベース

バイナリログ

MysqlbinlogコマンドとMySQLクライアントでの反映

アーカイブログ

alter database recoverコマンド

物理バックアップファイル

OSコピー物理バックアップファイル

OSコピー

論理バックアップファイル

権限チェック無しでサーバを起動

Mysqlクライアントによる適用

復旧後ロールフォワードが可能

論理バックアップファイル

Impユーティリティ

DataPumpユーティリティ

復旧後のロールフォワードはできない。

ｽﾀﾝﾊﾞｲﾃﾞｰﾀﾍﾞｰｽを更新可能なﾏｽﾀﾃﾞｰﾀﾍﾞｰｽに変更する。

復旧速度が速い

同構成のスタンバイ機が必要

オペレーションミスやアプリケーション不具合による変更をフラッシュバックする

専用のフラッシュバック領域が必要

機能なし

アーカイブログによる同期処理

スタンバイ→プライマリの変更

30

Snapshot

ボリューム

31

３－３． MySQLバックアップリカバリ推奨手順（LINUX環境）

MySQLオンラインバックアップ手順概要

MｙSQLのバックアップリカバリの推奨手順として、物理ファイルのオンラインバックアップリカバリの実例を示します。環境はLINUX＋ローカルディスクを想定しています。

LVM Snapshot用領域

●バックアップ対象データ

・全テーブルを共有ロック・LVM snapshotを作成

・バイナリログのスイッチ・バイナリログポジションの確認・テーブルロックの解除・snapshot ボリュームのマウント

１～２秒程度

稼働中

・データディレクトリ（データベースディレクトリ、*.frm,*. MYD,*.MYI ファイル）・InnoDBデータディレクトリ（InnoDBデータファイル）・InnoDBログファイル・バイナリログファイル・初期化パラメータファイル・エラーログファイル

●スナップショット取得時点のファイル群

・データディレクトリ（データベースディレクトリ、*.frm,*. MYD,*.MYI ファイル）・InnoDBデータディレクトリ（InnoDBデータファイル）・InnoDBログファイル・バイナリログファイル・初期化パラメータファイル・エラーログファイル

① ➁

２～３秒程度

① ➁

③・バックアップメディアにデータを保管・snapshot ボリュームのアンマウント・snapshotの削除

LVM Snapshotはオンラインバックアップ時にボトルネックとなるロック時間を圧縮します。

・約4.5GBのデータ量・データテーブル平均Row長 200Bytes

【補足】Oracleのオンラインバックアップ優位点としてロックをかけずに取得可能（Redoログ出力量は増える）

テープ又は、バックアップストレージ

32


オンラインバックアップ手順

オンラインバックアップの手順詳細

①MySQLサーバに接続し、データベースの全テーブルに対する共有ロックを取得

②LVM Snapshotの作成

[mysql@SERVER ~]$mysql -u root –prootpassWelcome to the MySQL monitor. Commands end with ; or ¥g.

Your MySQL connection id is 3

Server version: 5.0.79-enterprise-gpl-log MySQL Enterprise Server (GPL)

Type 'help;' or '¥h' for help. Type '¥c' to clear the buffer.

mysql>flush tables with read lock;

[mysql@SERVER ~]$ sudo /usr/sbin/lvcreate --snapshot -L4G -n snapLV02 ¥

/dev/VolGroup00/LogVol02

Logical volume "snapLV02" created

※sudoの実行には事前にvisudo でsudoersを設定が必要

/dev/VolGroup00/LogVol02 は、MySQLのバックアップ対象ファイルが保存されたボリュームです。複数ボリュームに対象ファイルが存在する場合は、複数スナップショットを作成してください。

flush tables with read lock文は、バッファキャッシュ上のデータが全てファイルにフラッシュし、MySQLサーバの全テーブルに共有ロックをかけます。

33


③バイナリログのスイッチとポジションの確認

※①～③の操作中にクライアント接続を切断するとロックが解除されてしまう為、スクリプト等で自動化する場合は、以下のように実行します。

[mysql@SERVER ~]$ mysql -u root -prootpass -e ‘flush tables with read lock;system ¥

sh LVsnap.sh ; flush logs; show master status ; unlock tables;'

mysql>FLUSH LOGS;

mysql>SHOW MASTER STATUS;

+------------------+----------+--------------+------------------+

| File | Position | Binlog_Do_DB | Binlog_Ignore_DB |

+------------------+----------+--------------+------------------+

| mysql-bin.000002 | 98 | | |

+------------------+----------+--------------+------------------+

FLUSH LOGSを実行すると、バイナリログ（バイナリログについては3-5で説明します）がスイッチされます。リカバリ後のロールフォワードは、ここでスイッチされたものから適用する事になります。この際、SHOW MASTER STATUSで、スイッチされた後のバイナリログファイル名とポジションを確認する事をお勧めします。

④テーブルの共有ロックを解除

mysql>unlock tables;

Unlock tables文を発行する事で、①で取得した全テーブルへの共有ロックを解除します。

34


⑤Snapshotボリュームを読取専用でマウント

[mysql@SERVER ~]$ sudo /bin/mount -o ro /dev/VolGroup00/snapLV02 /snapLV02

⑥バックアップ対象ファイルをアーカイブ

[mysql@SERVER ~]$ cd /snapLV02/mysql/;tar cvf /backup/mysql/Hotbk20090428.tar ./*

この例では、/snapLV2/mysql/ 配下に必要な対象ファイルが全て存在する事とします。また、バックアップ先ボリュームは /backup/mysql となります。

⑦snapshotボリュームをアンマウントし、snapshotを削除

[mysql@SERVER ~]$ sudo /bin/umount /dev/VolGroup00/snapLV02

[mysql@SERVER ~]$ sudo /usr/sbin/lvremove -f /dev/VolGroup00/snapLV02

Logical volume "snapLV02" successfully removed

⑧バックアップ済みのバイナリログを削除

mysql>PURGE MASTER LOGS TO mysql-bin.000002

③で確認したバイナリログファイル以前のファイルがバックアップ済みである前提です。 mysql-bin.000002より以前のバイナリログファイルは全て削除されます。

35


オンラインバックアップファイルリカバリ手順

①MySQLサーバが停止していない場合は停止

③バックアップファイルを対象ディレクトリにリストア

[mysql@SERVER ~]$ sudo /sbin/service mysql stop

Shutting down MySQL.. [ OK ]

[mysql@SERVER ~]$ tar -C /data/mysql/ -xvf Hotbk20090428.tar

前回バックアップ以降に更新されたデータのロールフォワードリカバリ用

➁ 未バックアップのバイナリログファイルをバックアップ

[mysql@SERVER ~]$ cp –p /data/mysql/blog/mysql-bin.* /backup/mysql/blog/

④初期化パラメータファイルのバイナリログ出力設定を停止し、リモート接続禁止状態でMySQLサーバを起動

[mysql@SERVER ~]$ vi /data/mysql/cnf/my.cnf

# Replication Master Server (default)

# binary logging is required for replication

#log-bin=/data/mysql/blog/mysql-bin

[mysql@SERVER ~]$ sudo /sbin/service mysql start --skip-networking

Password:

Starting MySQL [ OK ]

※Serviceコマンドによる起動停止は事前に要設定

ロールフォワードリカバリ中のバイナリログ出力を避け、リカバリ中のクライアント接続を防ぎます。

36


⑤前回バックアップ以降に出力されたバイナリログから、ロールフォワードリカバリ用のSQLを作成

[mysql@SERVER ~]$ mysqlbinlog --disable-log-bin mysql-bin.000002 mysql-bin.000003 > ¥

recover20090429_2.sql

⑥ロールフォワードリカバリ用SQLをMySQLクライアントから適用

[mysql@SERVER ~]$ mysql -u root -prootpass --default-character-set=cp932 < ¥

recover20090429_2.sql

[mysql@SERVER ~]$ mysqlbinlog --disable-log-bin --stop-datetime="2009-04-29 17:38:15" ¥

mysql-bin.000002 mysql-bin.000003 > recover20090429.sql

前回バックアップ以降に出力されたバイナリログが「mysql-bin.000002」、「mysql-bin.000003」の前提です。「--disable-log-bin」はロールフォワードリカバリ中のバイナリログ出力を抑止します。リカバリ用SQLは「recover20090429_2.sql」に出力されます。

尚、上記は障害直前まで復旧するSQLを出力しますが、ポイントタイムリカバリを行う場合は以下のように指定します。

上記例では2009年4月29日の17時38分15秒までに更新されたデータがリカバリ用SQLファイルに出力されます。

37


⑦初期化パラメータファイルのバイナリログ出力設定を戻し、MySQLサーバを再起動

[mysql@SERVER ~]$ vi /data/mysql/cnf/my.cnf

# Replication Master Server (default)

# binary logging is required for replication

log-bin=/data/mysql/blog/mysql-bin

[mysql@SERVER ~]$ sudo /sbin/service mysql restart

Password:

Shutting down MySQL.. [ OK ]

Starting MySQL.. [ OK ]

以上がLINUX環境でローカルディスクで運用している場合のバックアップリカバリ手順となります。共有ストレージ製品が利用可能な場合は、LVM Snapshotではなく、ストレージ製品のスナップショット機能や遠隔ミラー機能のsync-split等で同等のオペレーションが可能です。

38

３－４．バックアップリカバリ所要時間

弊社検証環境でのバックアップリカバリ時間を参考までに紹介します。

テーブルが１０００万件程度の環境では高価な共有ストレージ機能を利用しなくてもバックアップは十分に可能Mysqldumpのリストアにはある程度時間を要する

1秒程度1秒程度1秒程度ロールフォワードSQL作成

25秒程度

35分2秒

-

1分20秒

-

-

-

Mysqldump

25秒程度

-

6分15秒

-

4秒程度

1分41秒

5秒程度

Flush tables with read lock + snapshot

6分程度ファイルリストア

2分程度物理ファイルコピー

25秒程度ロールフォワード（100万件テーブルの反映）

-FLUSH TABLES With Read Lock＋Lvcreate～snapshotのマウント

-

-

-

Coldバックアップ

Mysqldump反映

Snapshotのアンマウントと削除

Mysqldumpコマンド

検証環境情報「１－３．MySQL Enterpriseの検索性能とスケーラビリティ」と同等。但し、高価用性ソリューションであるDRBD上で実施しているため、5～10%程度通常より遅くなっています。（DRBDはOSブロックレベルの遠隔ミラーリングソリューションです。後ほどご紹介します。）

バックアップファイルサイズトータル：4.5GB

900万件テーブル（InnoDB)×１、 100万件テーブル（InnoDB)×１、100万件テーブル（MyISAM)×２

ファイルサイズとテーブル量

39

３－５．トランザクションログ

MySQL バイナリログについて

ミッションクリティカルな環境ではバイナリログの出力及び「sync_binlog = 1 」を推奨

MySQLのバイナリログは、OracleでいうRedoログ、アーカイブログに該当し、バックアップリカバリやレプリケーションにおいて、非常に重要な役割を持ちます。

起動パラメータ「sync_binlog = 1 」を推奨します。このパラメータを指定することでCommit時のバイナリログ同期書込みが保障されます。但し、Ext3ファイルシステムでは更新系パフォーマンスの影響があるため、パフォーマンスとトレードオフの関係となります。

Alter system switch log文発行時ログが1Gを超えた時点。MySQLサーバの起動時、Flush Log文発行時にログスイッチが発生する。

ログスイッチ

バイナリファイル

（ロールフォワードリカバリ時は対象ディレクトリに配置。LogMinerにより解析可能）

バイナリファイル

（ロールフォワードリカバリ時はMysqlbinlogコマンドにより、SQL文に変換）

ファイル形式

ノーアーカイブログモードが可能。Redoログは必須出力無し設定可能。出力制御

ロールフォワードリカバリ

クラッシュリカバリ

スタンバイデータベース（DR サイト等）

ロールフォワードリカバリ

スタンバイデータベース（DRサイト、レプリケーション）

（InnoDBのクラッシュリカバリにはInnoDBログが利用される。InnoDBログは物理論理ロギング方式）

用途

ログスイッチ時に新規ファイルに書込みが開始される。ログファイルの再利用（カレントのローテート）はしない。

「sync_binlog=1」指定でCommitと同時。

指定しないと非同期書込み

論理ロギング

（SQL文レベルのロギング）

MySQL バイナリログ

オンラインRedoログがローテーションする。アーカイブログモード時は、オンラインRedoログのスイッチ時にアーカイブする。

ログローテーションとアーカイブ

Commit時

Redoログバッファの1/3を消費した場合

物理論理ロギング

（SQL文レベル＋更新ブロックレベルのロギング）

Oracle Redoログ

ロギング方式

書込みタイミング

MySQLのトランザクションログはバイナリログと呼ばれます。

Enterprise環境での利用には

40

３－６． MySQLバックアップリカバリのポイント

サーバ停止する事が可能であれば、手順が簡素なColdバックアップが効率が良い

MyISAMも更新が頻繁に起こるような場合は、Flush TABLE WITH READ LOCK 文によるバックアップを選択したほうが無難。

Mysqldumpは、論理バックアップなので、バックアップ、リカバリは遅い

Mysqldumpは、InnoDB取得用と考えたほうが良い。MyISAMテーブルも取るのであれば、ロック時間を覚悟するか、バックアップ中にはMyISAMテーブルを更新しない

障害時点まで、もしくは指定時間までの回復が必要であればバイナリログの取得が必須

ロック時間を極力短くするため、スナップショットやストレージ製品のミラーリングボリューム機能を利用する。

システム全体で一貫性のあるバックアップ取得には全テーブルにロックをかける必要がある。（Oracleはロックなしで取得可能）数秒のロックがクリティカル事象となる場合、条件的に厳しくなる可能性がある。

４．高可用性 MySQL

４－１．レプリケーション構成（Master-Slave）４－２． Active/Standby （HA）構成（DRDB＋Heartbeat）４－３． Active/Standby ＋レプリケーション構成

（DRDB＋Heartbeat＋Master-Slave）４－４． Active/Active構成（MySQL Cluster）４－５． Active/Active構成（uni/cluster for MySQL）４－６．構成別比較

41

42

４－１．レプリケーション構成(Master-Slave)

MySQLは、強力なレプリケーション機能を持っています。検索系サーバのスケールアウトや、更新系サーバの検索負荷を減らす目的としてかなり有用となります。安価な機器で比較容易に構築が可能です。DR用のスタンバイデータベース用途として活用する事もできます。非同期な連携となるため、Write-Writeクラスター環境には向いていません。（但し、アプリケーションの書込制御次第で、双方向レプリケーションという構成も可能ではあります。）

レプリケーション構成は検索系サーバを簡単にスケールアウトできます

Master Node

レプリケーション

Slave Node群

バイナリログ

更新系として利用

IOスレッド

MasterSlave１ Slave2

➁Master更新時にバイナリログ

を取得し、リレーログに変換する

レプリケーションの仕組み

①MasterノードにMySQLクライ

アントとして定期的に接続。

リレーログ

SQLスレッド

検索系として利用

③リレーログを反映する

バイナリログ

Slaveを他Slaveの

Masterとする事も可能

（主にNW帯域の関係）

IOスレッド

リレーログ

SQLスレッド

１つのMasterに複数

Slaveを持つ事も可能

IOスレッド

リレーログ

Slave3

SQLスレッド

Slaveにも更新負荷はかかりますがバイナリログ出力を停止すれば、I/O負荷が下ります。

43

４－２． Active/Standby（HA）構成（DR：BD+Heratbeat）

OSSプロダクトである、「DR：BD」と「Heartbeat」を組合わせることで、共有ディスク無しの、安価なHAクラスターの構築が可能となります。HeartbeatとDRBDは相性がよく、セットソリューションとして扱われる事が多いです。HeartbeatクラスタにMySQLリソースを登録する事で、MySQLのHAシステムが構築できます。（弊社検証環境にて動作を確認しております。）

DR:BD + Heartbeat 構成は安価に２４×３６５システムが構築可能となる。

疎通確認

（ハートビート）

DR：BD Primary DR：BD Secondary

DR：BDはPrimary Nodeのみ書込（Mount）

可能。クラスター構成時も Split Brainを防ぐ

Active

Eth1 Eth1

StandbyIPリソース

mysqld

VIP ：eth0:0

FS リソース

MySQL リソース

ブロックレベルで

ミラーリング

リソースグループ

MySQL リソース

IPリソース

FS リソース


Heartbeat

Heartbeatが疎通確認とリソースの死活監視、Failoverを実現する

ノードに異常を検知すると

リソースグループをFailoverする

Fs0 (drbd0)

Heartbeat

※DR:DBは同期書込の性質上、データの更新時

に多少のオーバーヘッドがあります。

（弊社環境での確認時は5～10%程度の速度ダウン）

44

４－３． Active/Standby ＋レプリケーション構成（DRDB＋HertBeat＋Master-Slave）

「DR：BD」と「Heartbeat」のHAクラスタをレプリケーションMasterとする事で、更新系サーバの可用性を確保しつつ、検索系サーバの可用性とスケーラビリティを確保する高可用性MySQLシステムの構築が可能となります。

２４×３６５対応でReadノードのスケールも可能な本構成が弊社のお勧め構成となります。

DR：BD Primary DR：BD Secondary

Active

Eth1 Eth1

StandbyIPリソース

mysqld

VIP ：eth0:0

FS リソース

MySQL リソース


MySQL リソース

IPリソース

FS リソース


Heartbeat

Fs0 (drbd0)

Heartbeat

Master node

Slave Node群レプリケーション

MasterのActiveノードがFailoverした場合

自動的に接続先を切り替える

（VIPとリソースグループの設定が必須）

Failover時に自動的に切替

Aplication server

45

４－４． Active/Active構成（MySQLCluster）

MySQL Cluster は非共有システム (shared-nothing system) での in-memory データベース（NDBストレージエンジン）のクラスタを可能にするテクノロジです。メモリ資源やストレージを一切共有せず、データベースの全てのデータがメモリ上に展開されるので高速です。但し、最小５ノードからの構成となりますので多少敷居が高いです。MySQL Clusterの最新バージョンではディスクに保存する事が可能となっていますが、ディスクで構成した場合はパフォーマンスが期待できなくなる可能性があります。また、構成変更時のシステム停止が必要になります。

MySQL Clusterは重度のクリティカル環境で十分なコストを投資できる場合に有用です。

Storage(Data) Node1 Storage(Data)Node2

SQL Node1 SQL Node2

最小で５台構成

ndbd

データノード層

MySQL層

Management Node

NDB Cluster

ndbd

mysqldmysqld

ndb_mgmd

アプリケーション層

MySQL Cluster

App App App

各層単位でスケールアウト可能

メモリ内容を同期

クラスタリングされたデータノード

へアクセスするMySQLサーバ。

Non-Cluster時と同様のMySQL

インターフェースをAppに提供する。

システム構成を行うノード

起動時、設定変更時に動作

インメモリDBとしてデータを格納し、全てのトランザクションを処理する。（NDBストレージエンジン）

疎通確認（ハートビート）は

それぞれのNodeが実施■耐障害性について

MySQL Cluster は複数のデータノード障害に対する耐障害性があり、すぐに自らを再設定することで、その障害を解決することができます。MySQL Cluster には自己修正機能があり、またデータの配置やパーティショニングをアプリケーションで意識しなくてもすみます。

46

４－５． Active/Active構成（uni/cluster for MySQL）

SmartStyle社の提供する商用プロダクトuni/cluster for MySQL（※）は、MySQLのActive-Activeクラスターの実現を可能にします。（※）開発元はContinuent社

Writeノードをクラスター化する事が可能。MySQL Clusterよりは安価に構築できます。

uni/clusterはMySQL DBを2台～最大16台までActive環境で構築することができる。

モジュールが必要

- APサーバーにuni/cluster Driver

- MySQL DBサーバにuni/cluster ontroller

スケールアウトとしてMySQL DBサーバを構築する要領となる。（Active）

【障害時の切替】

MySQL DB(A)が障害でアクセスができ無くなる

⇒uni/clusterがMySQL DB(A)の障害を検知する。

⇒uni/clusterがMySQL DB(A)からMySQL DB(B)へ切り替える。

⇒MySQL DB(A)のアクセスはMySQL DB(B)へ自動的にデータを引き継ぎ、継続させる。

47

４－５．構成別比較

機能比較

やや低い○○△○Active/Standby （HA）構成（DRDB＋Heartbeat）

やや低い○◎○○Active/Standby ＋レプリケーション構成（DRDB＋Heartbeat＋Master-Slave）

高い×◎○◎Active/Active構成（uni/cluster for MySQL）

高い△○◎◎Active/Active構成（MySQLCluster）

低い◎◎○△レプリケーション構成（Master-Slave）

導入コスト運用の容易さ

拡張性パフォーマンス

高可用性

[主な選定条件における比較一覧]

DR：BD＋Heartbeat＋Master-Slave 構成が弊社のお勧め構成となります。

５． MySQLパフォーマンスチューニングの紹介

５－１．デフォルトパラメータファイルとの性能差

５－２．パフォーマンスチューニングのポイント

５－３．パフォーマンスチューニングサービス

48

49


MySQLインストール時「support-files」配下に設定テンプレートファイルがいくつか用意してあります

my-small.cnf ：64Mバイト以下のメモリしか搭載できないサーバ向けmy-medium.cnf ：128Mバイト程度のメモリを搭載したさまざまな用途の共有サーバで、MySQLに32M

～64Mバイト程度のメモリ領域を使用できるサーバ向けmy-large.cnf ：512Mバイトのメモリを搭載したMySQL専用サーバ向けmy-huge.cnf ：1G～2Gバイトのメモリを搭載したMySQL専用サーバ向けmy-innodb-heavy-4G.cnf：4Gバイトのメモリを搭載したMySQL専用サーバでInnoDBのみ利用し、接続が少な

く重いクエリを実行するMySQL

比較的大きめなシステム用のmy-huge.cnfのテンプレートにおけるパラメータ値を利用した場合と、パラメータをチューニングした場合のベンチマーク結果を示します。ベンチマーク環境については「１－３．MySQL Enterpriseのスケーラビリティ（１）」と同一です。尚、構成ファイルやログ配置先に関してのみ、デフォルトファイルを変更しておりますが、比較前後で変更していません。

50


【チューニング後のパラメータ】 ※一部抜粋変更箇所は赤字で記載skip-lockingkey_buffer = 1250Mmax_allowed_packet = 16Mtable_cache = 1024sort_buffer_size = 2Mread_buffer_size = 2Mread_rnd_buffer_size = 8Mmyisam_sort_buffer_size = 64Mthread_cache_size = 64thread_concurrency = 4max_connections=1500net_read_timeout=30net_write_timeout=30back_log=128innodb_buffer_pool_size = 2250Minnodb_additional_mem_pool_size = 50Minnodb_log_buffer_size = 4Minnodb_thread_concurrency=8sync_binlog=1

【my-huge.cnf パラメータ】 ※一部抜粋skip-lockingkey_buffer = 384Mmax_allowed_packet = 1Mtable_cache = 512sort_buffer_size = 2Mread_buffer_size = 2Mread_rnd_buffer_size = 8Mmyisam_sort_buffer_size = 64Mthread_cache_size = 8thread_concurrency = 8innodb_buffer_pool_size = 384Minnodb_additional_mem_pool_size = 20Minnodb_log_file_size = 100Minnodb_log_buffer_size = 8Minnodb_flush_log_at_trx_commit = 1sync_binlog=1

変更

READ PK POINT

0

10,000

20,000

30,000

１thread 2threads 4threads 8threads 16threadsConcur rent Thread

Queries / Second

Non Tune InnoDBNon Tune MyISAMTuned InnoDBTuned MyISAM

READ KEY POINT_LIMIT

0

4,000

8,000

12,000


Queries / Second

Non Tune InnoDBNon Tune MyISAMTuned InnoDBTuned MyISAM

主キーほど顕著な差はない。非ユニークキーの場合、データのムラに左右される。

MyISAM、InnoDB

共に大幅な性能改善

51

５－２．パフォーマンスチューニングのポイント

パフォーマンスチューニングを効率よく行うにあたり、気をつけるべきポイントを記載します。

MySQLパフォーマンスチューニング向上の１０のポイント

詳細は別途お問合せください。

バッファ系パラメータチューニング

ディスクIO関連のチューニング

Explain文によるSQLチューニング

Show Statusによるメモリチューニング

Slow Query Logによる問題SQLの発見

MySQLサブクエリーのチューニング

InnoDBログサイズチューニング

クエリキャッシュチューニング

ネクストキーロック問題

クラスタインデックスを原因とするボトルネックSQL

52

５－３． MySQLパフォーマンスチューニングサービス

弊社では以下のプロセスでパフォーマンスチューニングサービスを提供します。

ヒアリング「診断サービス」

データベース診断

「診断サービス」お見積もり

ご発注

診断結果のご報告

改善提案

「改善サービス」お見積もり

ご発注

改善サービス実施

実施後の判定等

「診断サービス」・チューニングテスト用のscriptを用意 → 動作項目のLOGを取り、スクリプトを掛けて診断する・解析を行い、CPU使用率、ロードアベレージ、サーバのディスクI/O、MySQLに関する(myconfなど）値について、現在値と推奨値をレポートする。

「診断サービス」・チューニングテスト用のscriptを用意 → 動作項目のLOGを取り、スクリプトを掛けて診断する・解析を行い、CPU使用率、ロードアベレージ、サーバのディスクI/O、MySQLに関する(myconfなど）値について、現在値と推奨値をレポートする。

■日数の想定・５～１０営業日（１、２週間）作業内容により、変動。

■日数の想定・５～１０営業日（１、２週間）作業内容により、変動。

■費用の想定・対応技術者２名で５０万～作業内容により、変動。

■費用の想定・対応技術者２名で５０万～作業内容により、変動。

６． MySQLロードマップ

６－１ MySQL ロードマップ

53

54

６－１.MySQL ロードマップ

MySQL は時代のニーズ取入れ、継続的に進化しています。

MySQL4.1機能

ﾊﾟｰﾃｨｼｮﾆﾝｸﾞ行ﾍﾞｰｽﾚﾌﾟﾘｹｰｼｮﾝｲﾍﾞﾝﾄｽｹｼﾞｭｰﾗXPath ｻﾎﾟｰﾄﾀﾞｲﾅﾐｯｸ一般/ｽﾛｰｸｴﾘﾛｸﾞﾊﾟﾌｫｰﾏﾝｽ/負荷ﾃｽﾄﾕｰﾃｨﾘﾃｨ

MySQL 5.0

（2005年10月 GA）

継続的な新機能の拡充

カーソルストアドプロシージャトリガビューXAトランザクション

Falconｽﾄﾚｰｼﾞｴﾝｼﾞﾝ4バイトUTF-8Optimizerの強化ｵﾝﾗｲﾝﾊﾞｯｸｱｯﾌﾟの機能強化

InnoDBのｽｹｰﾗﾋﾞﾘﾃｨ改善SHOW ENGINE INNODB STATUSの拡張ｻﾌﾞｸｴﾘとJOINの性能改善ｽﾄｱﾄﾞﾌﾟﾛｼｰｼﾞｬにおけるSIGNAL機能。

MySQL 5.1

（2008年11月GA）

MySQL 6.0

（2008年12月 Alpha）

MySQL 5.4

（2009年4月 Beta ）

７． MySQLソリューションのご紹介

７－１ MySQL 障害監視・運用保守サービス

７－２運用・管理ツール Navicat

７－３ Oracleとの混合ソリューション

55

56

７－１．障害監視・運用保守サービス

弊社では2時間365日の障害監視・運用保守サービスを提供しています。

弊社スタッフのみ入室可能

保守チームのみ入室可能

担当者のみ利

用可能

作業用リモート端末利用（セキュリティ：指紋認証）

保守ルーム入室（セキュリティ：指紋認証）

フロア入室（セキュリティ：指紋認証）

弊社スタッフのみ入室可能

保守チームのみ入室可能

担当者のみ利

用可能

作業用リモート端末利用（セキュリティ：指紋認証）

保守ルーム入室（セキュリティ：指紋認証）

フロア入室（セキュリティ：指紋認証）

MySQL Enterpriseの障害監視・運用保守も弊社で提供可能です。

57


弊社の提供するMySQL 障害監視項目メニューです。MySQL運用保守も合わせて提供可能です。ご提案のサポートに関しましても弊社にて全力でバックアップできるよう準備しておりますので、ターゲットスコープの合致するエンドユーザ様には是非MySQLをご提案頂ければと思います。

■MySQL監視サービス監視項目例（１）

１＋～３1分～5分程度

SHOW SLAVE STATUS ;Slave_IO_Running（IOスレッドの動作）、Slave_SQL_Running（SQLスレッドの動作）が稼働中Last_Error（処理エラー）がない事Seconds_Behind_Master （マスターからの遅れ時間）が一定値よりも大きくない事等を監視

各種レプリケーションステータス（Slaveのレプリケーション状況）を監視

レプリケーション監視

２～４1日

該当ディレクトリに対する lsコマンド等で確認運用上定められた定期的なバックアップが正常に取得できているかを監視

バックアップ取得状況監視

１＋～３1分

起動パラメータ log_error= で指定したファイルを監視。以下のキーワードでトラップを設定。エラーキーワード：「Fatal error」「error:」起動停止キーワード：「Starting」「shutdown」（キーワードは要調整）

Mysqlサーバのエラーログ（サーバの起動停止ログ含む）監視

エラーログ監視

１＋１分mysqladmin ping -u [ユーザ名] -p [パスワード] -host [ホスト名]Mysqlサーバ（プロセス）

の死活監視サーバプロセス死活監視

障害監視

小項目中項目大項目

Priority※２

監視間隔※１

実現手段説明監視項目

58


■MySQL監視サービス監視項目例（２）

２～４1時間SHOW STATUS LIKE 'Qcache%'; から以下を算出Qcache_hits ÷ （Qcache_hits + Qcache_inserts + Qcache_not_cached）

クエリキャッシュのヒット率を監視

クエリキャッシュヒット率監視

２～４1時間

SHOW STATUS Binlog_cache_disk_use;SHOW STATUS Binlog_cache_use;の比率よりテンポラリファイルを使用した回数率を監視。

バイナリログキャッシュ溢れ（トランザクションからステートメントを保存するためにテンポラリファイルを使用したもの）を監視

バイナリログキャッシュ監視

1 ～４1時間SHOW ENGINE InnoDB STATUS ¥Gにて各種値を確認

各種InnoDB Statusの確認InnoDB関連監視

２～４1時間SHOW STATUS LIKE 'Key_read%'の 1 - ( Key_reads ÷ Key_read_requests) でヒット率を計算また、Key_blocks_unused で使われていない量を監視

MyISAM用のKeyバッファヒット率の監視

キーバッファヒット率監視

２～４1時間

SHOW STATUS Opened_tables;と table_open_cache パラメータの値の比率を監視

いままでOpenされたテーブルに対して、Table_cacheの値が小さすぎないかを監視

テーブルキャッシュ適正監視

MYISAM関連監視

２～４5分

SHOW STATUS Max_used_connections ;パラメータ thread_cache_size の比率を監視

Max_used_connectionsに対して、スレッドキャッシュの値が小さすぎないかを監視

スレッドキャッシュ適正監視

１～３5分SHOW STATUS Threads_connected;現在の接続している同時

スレッド数の監視スレッド数監視

１～３5分SHOW PROCESSLIST;State が Locked の数を監視※PROCESS権限が必要

別のクエリによってロックされているプロセスの監視

ロックプロセス数監視

１＋～３5分SHOW STATUS Max_used_connections ;パラメータ max_connections（最大可能接続数）との比率で監視

現在までの最大同時接続数を監視

最大同時接続数監視プロセス・スレッド・セッション監視

リソース監視


Priority※２

監視間隔※１


59


■MySQL監視サービス監視項目例（３）

２～４10分

log-queries-not-using-indexesパラメータを指定。上記スロークエリログと同じファイルに出力される。mysqldumpslowによるスロークエリログ解析等のサービス化を検討

インデックスを使っていないクエリの監視

not_using_indexes

２～４10分

log_slow_queries[ファイル名] パラメータを指定し、該当ファイルを監視long_query_timeに「遅いクエリの時間」を定義mysqldumpslowによるスロークエリログ解析等のサービス化を検討

slowクエリログの監視slow_queriesスロークエリの監視

チューニングオプション


Priority※２

監視間隔※１


■Priority

Priority １＋：Emergency （緊急）

Priority １：Highest （最優先）

Priority ２：High（優先）

Priority ３：Warning（警告）

Priority ４：notice（注意）

※１監視間隔は標準設定値。導入時は項目ごとにユーザ様と協議。

※２ Priorityレベルは標準設定値。ユーザ様と協議。

閾値でTrapを飛ばす場合、閾値毎にレベル設定。

60

７－２．運用・管理ツール Navicat

SmartStyle社の提供するMySQLの運用・管理ツールです。NavicatはMySQLの運用管理ツールで世界で一番導入実績のあるツールです。海外ではFedexをはじめ多くの企業に導入されています。国内でも既に500ライセンス以上、400以上の企業／団体(学校法人等)への導入実績があります。

GUIによる管理で開発効率アップ効果も期待できます。

61

７－３． Oracleとの混合ソリューション

一般的なOracleのエンタープライズ利用を想定するとライセンスフィー、ハードウェアコストが高価になりがちです。

Oracleのみで構成した場合、ライセンスやハードウェアコストがどうしても高価になりがちです。

Oracle Enterprise Edition RAC

Oracle Application Server

スケールできるノード数にある程度制限有。

場合によっては高価なRacSet追加となる。

この状況を打開するには！？

高価なハードウェアと

M/Wライセンス

次頁

62

７－３． Oracleとの混合ソリューション

MySQL EnterpriseとOracleを組合わせたソリューションを実装することで提案時のコストを下げる事が可能です。

Write NodeをOracleのSE RACで構成する事で、EERAC構成と比較してTCOを削減する。

Write系ノード

検索系ノード

MySQL Enterprise

安価なサーバ、ストレージで容易にスケール

Apache TomcatやWebLogic

定期的なデータコピー

Oracle Standard Edition RAC

検索系はMySQLで

平均Row長 200bytes

100万件

→ロードは30秒～40秒程度

WriteノードとしてのOracle RAC

８．開発者視点でみたMySQL

８－１ Oracle開発者向けポイント

８－２ MySQL コネクタ

８－３ MySQL全文検索

63

64

８－１． Oracle開発者向けポイント（１／２）

SQL標準（JIS／ANSI／ISO準拠）にのっとっていない、Oracle特有のSQLがMySQLには通りません。（外部結合の（+）記号、Merge文、Decode関数等）

Oracleは「空文字（’’）」と「NULL」が同じ扱いですが、MySQLは違うものとして扱われます。

MySQLはデータベース名とテーブル名の大文字小文字を区別する（Case Sensitive) 設定があります。Unix系OSの場合、デフォルトでは区別する設定（lower_case_table_names =0）となっていますので注意が必要です。尚、他のオブジェクト（カラム名やSP名等）は常に区別されません。Oracleでは全て区別されません。

①外部結合の（+）記号は、Left Outer Join句で代替可能です。②Merge文はReplace文で代替可能です。（厳密にはDelete＞Insertとなり若干動作が異なります。）③Decode関数はCase文で代替する事が可能です。

【解決策】

【解決策】

大文字小文字を同一として扱いたい場合、「lower_case_table_names =１」を指定してください。尚、ディスク上のテーブルファイル名等は小文字で保存されます。

【解決策】

特に区別する要件がない場合は、アプリケーション全体で、「NULL」もしくは「空文字列（’’）」のどちらかに統一する事で混乱が回避できます。

65

８－１． Oracle開発者向けポイント（２／２）

MySQLは数値型のPrimaryキーがない場合、Rowidが参照できません。

デフォルトのトランザクション分離レベルが異なります。Oracleは「Read Commited」、MySQL（InnoDB)は「Repeatable Read」。

MySQL（InnoDB)は行ロックをサポートしますが、Update時のWhere句カラムにIndex張られていない場合、テーブルロックとなるので注意が必要です。

MySQLアプリケーション開発や、マイグレーション時に、上記のような軽微な違いがクリティカルとなる場合があるので注意が必要です。

【解決策】

Primaryキーは可能な限り数値型で設定してください。

【解決策】

MySQLの初期化パラメータ「transaction-isolation = READ-COMMITTED」を設定する事で標準分離レベルを「Read Commited」とすることが可能です。また単一セッション内のみ変更する場合は、MySQLクライアントから「SET TRANSACTION ISOLATION LEVEL READ COMMITTED」を発行する事で可能です。

【解決策】

Where句となりうるカラムには全てIndexを作成してください。（総件数が少ないものはこの限りではないです。）

66

８－２．MySQL コネクタ

Connector/J

Connector/NET

Connector/PHP

クライアントプログラムから MySQLサーバへ接続するドライバである、MySQL コネクタについてご紹介します。

Connector/ODBC

MｙSQL用JDBCドライバです。JDBC APIを利用してMySQLへアクセスします。GPLライセンスのオープンソースソフトウェアとして提供されています。HibernateやSpringのようなフレームワークと連携して利用できます。

MｙSQL用ODBCドライバです。ODBC APIを利用してMySQLへアクセスします。MS ACCESSからの利用も可能です。

.NET アプリケーション用のADO.NET ドライバです。ADO.NET インターフェイスを実装し、ADO.NET 対応ツールを統合します。100% 純粋な C# で書かています。また、MySQL Visual Studio プラグインも用意されていますので、Visual Studioにデータベース保守ツールを組込む事も可能です。

PHP用の MySQL APIです。２つの異なるものを利用できます。（両方を同時に利用する事も可能）Mysqlエクステンション : MySQL 4.1より前のバージョンで使用することを目的としたものです。Mysqliエクステンション: MySQL 4.1以降のバージョンで使用でき、mysqlエクステンションよりオブ

ジェクト指向のプログラムインターフェースとなります。

67

８－３．MySQL 全文検索

「含む検索」（where col like ‘%keyword%’）はIndexが利用できないため、全表検索となり速度低下の原因となります。MySQLが標準で持つFull TEXT Indexを利用する事（但しMyISAMのみ）で、全文検索が可能となりますが、標準では日本語をサポートしていません。MySQLで日本語全文検索を利用したい場合、Tritonnを導入する事で可能となります。

3table結合時(300万件＋ 900万件＋900件)条件table単体（300万件）参考処理速度 Mysql 5.0.67

0.17 sec0.09 sec検索キーワード１文字

0.00 sec

0.01 sec

0.00 sec

0.02 sec検索キーワード２文字

検索キーワード４文字

検索対象キーワードは、 Wikipediaのタイトル１００万語から頭９文字を切り出し登録。3倍に増幅（３００万件）してN-gram方式でIndex登録した。登録テーブルに対して、全文検索を行い、５行をランダムで抽出した場合の速度。ハードウェア環境については「１－３．」と同様の環境となります。

参考速度（Tritonn利用時）

Tritonn （SennaのMySQLバインディング）について

全文検索エンジンである「Senna」をMySQLに組込みこんだTritonnを利用する事で、標準のFull Text Index検索用SQLで日本語全文検索が可能となります。日本語全文検索は主に2つの方式があります。

形態素解析方式：辞書登録された形態素（単語）で分ち書きを行う方式です。「MeCab」エンジンを利用します。辞書のメンテが必要となります。形態素に一致しない単語は検索されませんが、適合率が高いです。（ユーザの意図しない検索結果が出にくい）

N-Gram方式：単語を「N文字」ずつ分割してIndex登録する方式です。検索時の条件も同じように分割してIndexスキャンするため全て検索されますが、ユーザが意図しないキーワードが検索結果として表示される可能性があります。（例：「京都」で検索した場合に、「東京都」も検索される。）

Tritonnプロジェクト URL:http://qwik.jp/tritonn/

※速度はMySQL クライント上の表示秒数を記載しております。

68

【参考資料】その他サードパーティ製品

InnoDB Hot BackupInnoDB のホットバックアップ用ツール－ソフトウェアライセンスとサポートサービス

Sunより購入可能（SLAはInnobase社の定義）

http://www.innodb.com/wp/products/hot-backup/

ZRM － Zmanda Recovery Manager

Web管理コンソールを備えたバックアップユーティリティソフトウェア

ストレージエンジン毎に最適なバックアップ方法を選択

バックアップ時の圧縮・暗号化にも対応

Sunより購入可能

http://www-jp.mysql.com/products/backup/zrm.html

DRBD Plus

DRBDの拡張パッケージで有償版。

最大3台までのコンピュータのディスク内容をリアルタイムでミラーする、

Linux向けのソフトウェアソリューション。比較的低速なWAN回線でのミラーリング

に対する最適化機能も備えており、ローコストにディザスタリカバリ・システムを

構築できます。

SmartStyleより購入可能

http://www.s-style.co.jp/mysql_support_service/mysql_ha/drbd.html

【参考資料】MySQLライセンスの比較

Knowledge

Base

Enterprise

Monitor課金単位

ライセンスへの同梱

専用バイナリInnoDBライセンス

課金単位

商用

ライセンス

○○サーバ同梱○○（サーバ）

※1○MySQL Enterprise

○○サーバ同梱○○（サーバ）

※1×

MySQL Enterprise

（GPL）

追加機能/サービス年間サポートバイナリライセンス

69

※1 MySQL Enterpriseは技術サポートとライセンスが一体の年間サブスクリプションです。

標準ではGPLライセンスのバイナリを提供する。追加費用なしでGPLを外す事も可能（商用ライセンスのバイナリの利用）

GPLを外す場合、手続きに３～４週程度の期間がかかる。

・VMwareなど、仮想で複数OSを持つサーバでは、MySQLが動作する仮想OS毎にライセンス購入が必要。

・ブレードサーバは１台（１エンクロージャ）につき、１ライセンスとなる。但し、上記の仮想OSの考え方と同様に、MySQLが動作する

OSがブレードサーバ内に複数稼動していれば、稼動OS分だけライセンスが必要となる。

・Coldスタンバイ、Hotスタンバイにかかわらず、物理的に１サーバであれば、１ライセンスとしてカウントする。

・仮想環境、またはブレードサーバにおいては、Coldスタンバイ分はカウントされない。同時稼動するOS数分だけライセンスが必要となる。

MySQL Enterprise Server・有償顧客専用バイナリ※SUN：「標準はGPLライセンス → 無償で商用ライセンスに変更可能」

MySQL Enterprise Monitor （日本語版あり） MySQL統合監視ツール技術サポート・英語・・・レベル分けにより24×7 対応・日本語・・・２００８年４月９日より、日本法人にて日本語で応対開始（平日9:00～17:00）メンテナンスアップデートアップデートアラート・テクニカルアラートKnowledge Base ：ナレッジベースIndemnification ：知財（著作権や商標が管理されているため）訴訟に関する補償基本価格体系・サーバー数・年単位

商用ライセンスを選択した場合でも、契約期間終了時点で契約を更新していなければ、

ライセンスは自動的にGPLに切り替わるので注意ください。

【参考資料】MySQL Enterprise 詳細

Webアプリやエンタープライズ環境向けサービスの年間サブスクリプション契約。サブスクリプションのサービスレベルはBasic, Silver, Gold, Plutinumの４種類

70

【参考資料】ライセンス単位課金の計算方式について（2009年４月確認）

サーバ単位課金ライセンスの計算方法について①サーバに搭載されるCPU数及びコア数についての考え方１サーバあたりのコア数やCPU数に制限はない。但し、複数CPUを積んでもリニアにスケールとは限らない。

②仮想環境（VMWare、Xen、HyperV等）の考え方１サーバホスト上に、MySQLが稼動する複数の仮想OSがある場合、MySQLが稼動する仮想OSの数分カウントする。

但し、Coldスタンバイ用の仮想OSのように通常稼動していない仮想OSの考え方は、同時に稼動している仮想OS数となる。

（Hotスタンバイ機は「同時に稼動している仮想OS」に含まれる。）

例： 1サーバホストに、仮想OSとして以下が稼動している場合、5ライセンスの購入が必要

Windows2000server × １ ⇒１ライセンス

Windows2003server × １ ⇒１ライセンス

RHEL5.2 × ２（Coldスタンバイが１） ⇒１ライセンス

SUSE Linux Enterprise 11 ×２（Hotスタンバイが１） ⇒２ライセンス

③ブレードサーバの考え方ブレード1枚単位ではなく、エンクロージャ単位で１サーバとする。

但し、１サーバ内で稼動OSが複数ある場合は、上記の仮想環境と同じ考え方が適用される。

⇒同時に稼動しているOS数分のライセンス購入

④スタンバイ機についてColdスタンバイ、Hotスタンバイにかかわらず、物理的に１サーバであれば、１ライセンスとしてカウントする。

この場合、上記仮想環境の考え方と異なり、同時に稼動しているOS数とはならない。

但し、スタンバイ機用の価格割引ライセンスが存在する。

現在変更されている可能性もありますので、ご購入検討時に再確認いたします。

【参考資料】ライセンス単位課金の計算方式について（2009年４月確認）

⑤1サーバで複数のMySQLインスタンスが稼動する場合の考え方インスタンス数、また構成するMySQL Enterpriseのバージョンにかかわらず１ライセンスとなる。

例： 1サーバホストにMySQL Enterprise 5.1インスタンス × ２

⇒ 1ライセンス

1サーバホストにMySQL Enterprise 5.1インスタンス × 1 とMySQL Enterprise 5.0インスタンス × 1


⑥1サーバで複数のMySQLインスタンスが、複数のエンドユーザ向け稼動する場合について・インスタンス数、また構成するMySQL Enterpriseのバージョンにかかわらず１ライセンスでよいか？

・各インスタンスを利用するエンドユーザ企業がそれぞれ異なっていても問題ないか。

（ライセンス契約者がユーザ企業と個別に契約する事とし、Sun様からのサポートはライセンス契約者のみの前提）


MySQL Enterprise 5.1 MySQL Enterprise 5.1

ユーザ企業Bユーザ企業A



現在変更されている可能性もありますので、ご購入検討時に再確認いたします。

エンタープライズ環境で稼動する mysqlapサーバ （apache、tomcat、php、perl...

Documents

エンタープライズ環境で稼動する mysqlapサーバ（apache、tomcat、php、perl...