MySQLの準同期レプリケーション

MySQL 5.5での準同期レプリケーション

準同期レプリケーション自体はMySQL 5.5から導入されました。マスターー側およびスレーブ側にそれぞれ準同期レプリケーション用のプラグインをインストールし、マスターー側で rpl_semi_sync_master_enabled とスレーブ側で rpl_semi_sync_slave_enabled を有効にしておくと準同期レプリケーションが利用できるようになります。 rpl_semi_sync_master_enabled を有効にしたマスターに対して、非同期レプリケーションと準同期レプリケーションのスレーブを混在させることは可能です。

準同期レプリケーションの流れ

1. アプリケーションからトランザクションをコミット
2. バイナリログとストレージエンジンにトランザクション内容を記録
3. マスターからスレーブにトランザクション内容を転送
4. スレーブのリレーログにトランザクション内容を記録
5. スレーブからマスターに応答
6. マスターからアプリケーションに応答

上記の3の時点でスレーブに障害が発生しているかネットワークに問題があるなどで通信できない場合は、マスターの rpl_semi_sync_master_timeout で設定されたタイムアウトまで待ち、非同期レプリケーションと同様にスレーブの応答が無いままアプリケーションに応答を返します。この値のデフォルト値は10,000ミリ秒です。
rpl_semi_sync_master_wait_no_slave がデフォルトの ON の場合には、スレーブが一時的に切断されている場合などもタイムアウトまで待ちます。OFFに変更するとスレーブが接続されていない場合はすぐにアプリケーションに応答します。

MySQL 5.7で複数台の準同期スレーブを待つ設定

MySQLの準同期レプリケーションで何台のスレーブが応答した時点で以降の処理を継続するかはマスターの rpl_semi_sync_master_wait_for_slave_count で制御します(5.7.3以降)。 デフォルトでは1台のスレーブから応答があった段階でアプリケーションに応答します。

MySQL 5.7の"Lossless"準同期レプリケーション

従来の準同期レプリケーションでは、特定のタイミングでマスターに障害が発生した場合にデータの不整合が起こりえる課題が残っていました。上記の流れの2の時点で、別のクライアントからはコミットの内容を参照することができます。
上記の2の後でマスターに障害が発生すると、他のクライアントから見えていたコミット済みのトランザクションがスレーブには存在せず、データの整合性が取れていないように見えてしまいます。この問題を解決するのがMySQL 5.7の"Lossless"準同期レプリケーションです。
"Lossless"準同期レプリケーションはMySQL 5.7から新たに加わったパラメタ rpl_semi_sync_master_wait_point のデフォルト値 AFTER_SYNC を利用することで実現できます。この値を AFTER_COMMIT に変更した場合はMySQL 5.6までの挙動になります。

"Lossless"準同期レプリケーションの流れ

1. アプリケーションからトランザクションをコミット
2. バイナリログのみにトランザクション内容を記録
3. マスターからスレーブにトランザクション内容を転送
4. スレーブのリレーログにトランザクション内容を記録
5. スレーブからマスターに応答
6. ストレージエンジンにトランザクション内容を記録
7. マスターからアプリケーションに応答

MySQLのレプリケーション構成の模式図
※非同期レプリケーションやMySQL 5.6の準同期レプリケーションではバイナリログへの記録とストレージエンジンへの変更点の記録は逐次ではなく同時

準同期レプリケーション関連のパラメタ一覧

パラメタ名	設定箇所	デフォルト値
rpl_semi_sync_master_enabled	マスター	OFF
rpl_semi_sync_slave_enabled	スレーブ	OFF
rpl_semi_sync_master_timeout	マスター	10000
rpl_semi_sync_master_wait_no_slave	マスター	ON
rpl_semi_sync_master_wait_for_slave_count	マスター	1
rpl_semi_sync_master_wait_point	マスター	AFTER_SYNC

スカイマークがデルタ航空傘下になったとしての妄想

妄想なので機材繰り、発着枠、政治的な観点での調整やらの細かいことは調べても無いし考えてない。あくまでも素人の妄想。

現状

• デルタ航空就航路線(2015年7月現在)
  • 東京/成田 - アトランタ、ニューヨーク、デトロイト、ミネアポリス、シアトル、ロサンゼルス、ポートランド、ホノルル
  • 東京/成田 - 台北/桃園、シンガポール、バンコク、マニラ、上海/浦東、香港、グアム、サイパン、パラオ
  • 東京/羽田 - ロサンゼルス、シアトル※
  • 名古屋/中部 - デトロイト、ホノルル、グアム
  • 大阪/関西 - ホノルル、グアム
  • 福岡 - ホノルル

• スカイマーク就航路線(2015年7月現在、wikipedia:スカイマーク#.E5.B0.B1.E8.88.AA.E8.B7.AF.E7.B7.9A)
  • 東京/羽田 - 札幌/新千歳、神戸、福岡、鹿児島、那覇
  • 神戸 - 札幌/新千歳、仙台※※、茨城、長崎、鹿児島、那覇、米子※
  • 名古屋/中部 - 札幌/新千歳、那覇
  • 札幌/新千歳 - 茨城、福岡、
  • 福岡 - 茨城、那覇
  • 那覇 - 米子※

　　　※2015年9月で終了 ※※2015年10月で終了

デルタ航空傘下になったスカイマークのポイント

1. 座席利用率LFが高い路線はA330でしっかり稼ぐ
2. 成田発着はデルタ・コネクションとしてフィーダー路線のみ運行
3. スカイチーム加入
4. 地方間路線は一部例外を除いて廃止

1. 座席利用率LFが高い路線はA330でしっかり稼ぐ

羽田からの札幌線や福岡線はこれまでの搭乗実績としてもコンスタントに高めの数字が出ているので、A330を再度利用してより稼ぐ方向に持って行く。A330を利用再開することになればエアバスなど利害関係者からの理解＆支援も得やすいのではないか。
デルタはA330-200 11機、A330-300 23機運用中で後者はあと8機受領予定なので、A330の整備や訓練などデルタから支援を受けられそう。ただし現状のスケジュール上はデルタの東京線にはA330は使われていないが、名古屋 - デトロイトがA330-200で運航されている。太平洋路線だとソウル - シアトル、ロサンゼルスや上海 - シアトル、ミネアポリスあたりにA330-300、北京全路線と香港 - シアトルにA330-200が入っている。

2. 成田発着はデルタ・コネクションとしてフィーダー路線のみ運行

スカイマーク単独だと成田線の搭乗実績は惨憺たる数字で結局撤退。日本におけるデルタ・コネクションとして、コードシェアまたはデルタ便名での運行を前提とし、海外からの乗り継ぎ客を取り込むことでLCCとは違った位置づけとなってそれなりの搭乗率が期待できるのではないか。デルタが就航予定の成田 - 関西線は成田 - 神戸にしてスカイマークで吸収することができなくはなさそう。
羽田線と共通の就航先に限定することで機材繰りや拠点でのコストの最適化ができそう。運航はデルタに乗り継ぐ客のための15時着18時発前後の便に限定。ただ内際乗り継ぎなので早め到着遅め出発が必要となるとすると成田に4,5時間留め置くことになり、もったいなければ間合い運用で近距離に飛ばすかが微妙。

参考：2013年10月の成田発着の搭乗実績
旭川：28.8％、札幌/千歳：51.2％、福岡：40.2％、沖縄/那覇：54.1％、石垣：29.6％

中部は主にデトロイト線へのフィーダーとして何路線か若干の搭乗率向上が狙えそう。

3. スカイチーム加入

ラウンジ設置が多少課題になりそうなものの、クレジットカード会員のラウンジなどを利用できればどうにかなりそうだし、エリート会員特典とかはデルタからまるごとコピーすればなんとかなりそう。
スカイチーム　 加盟に必要な条件
各地から東南アジア方面や逆に成田 - 札幌への乗り継ぎのレジャー需要ありそうだし、エールフランスがJAL国内線とコードシェアしているのでそれを奪い取れればそれなりに成り立ちそう。KLMがその昔JASとコードシェアしていた国内線なんかも。中台韓のスカイチーム各社は割と全国各地に就航しているので国内線への乗り継ぎ需要はあまり高く無さそう。

参考:エールフランスによるJAL国内線でのコードシェア
東京/成田 - 大阪/伊丹、名古屋/中部、札幌/新千歳、福岡、東京/羽田 - 長崎、大阪/関西 - 札幌/新千歳

4. 地方間路線は一部例外を除いて廃止

米子と仙台はすでに撤退決定。茨城も搭乗率が低くデルタやスカイチームとのシナジーもないのでおそらく撤退になりそう。間合い運用で飛ぶなり地方間で残す路線も、能登空港の搭乗率保証制度のような就航先自治体からの補助金があるところに限定することになるのが現実的か。
「関西の拠点」として格納庫まで整備しちゃった神戸空港からは、現状で60%以上の搭乗率が見込める路線を残すかどうかがポイントになりそう。

想定される就航先と路線の案

以上を踏まえて確定といえる空港は羽田と成田に加えて、搭乗実績とフィーダー路線としての需要から新千歳、福岡、那覇、それに中部ぐらいか。

• 案A: 就航先を絞ったパターン(7空港13路線)
  • 東京/成田 - 札幌/新千歳、神戸、福岡、那覇
  • 東京/羽田 - 札幌/新千歳、神戸、福岡、那覇
  • 名古屋/中部 - 札幌/新千歳、福岡、那覇
  • 神戸 - 札幌/新千歳、那覇

• 案B: 路線をある程度維持したパターン(8空港16路線)
  • 東京/成田 - 札幌/新千歳、神戸、福岡、那覇
  • 東京/羽田 - 札幌/新千歳、神戸、福岡、鹿児島、那覇
  • 名古屋/中部 - 札幌/新千歳、福岡、那覇
  • 神戸 - 札幌/新千歳、鹿児島、那覇
  • 福岡 - 札幌/新千歳、那覇

• 案C: 羽田以外は実質フィーダー路線のみ(7空港11路線)
  • 東京/成田 - 札幌/新千歳、神戸、福岡、那覇
  • 東京/羽田 - 札幌/新千歳、神戸、福岡、那覇
  • 名古屋/中部 - 札幌/新千歳、福岡、那覇

デルタ中心でスカイチーム加入前提で再建計画を立てたら、インバウンド旅客の利便性も上がるし3アライアンスの航空各社が競争することで全体的なサービス改善が進んだら良いのではないかと個人的には結論。航空会社の再建になるとどうしても地方路線からの撤退が課題になるけど、リンクが就航前に破綻したみたいに簡単な話でないことは確か。

MySQLはドキュメントデータベースの夢を見るか

MySQL 5.7.7 Release Candidateと同時にLabs(実験室)版としてMySQL JSONがリリースされました。MySQL JSONでは新しいデータ型としてJSON型をサポートしています。JSON型は格納されるデータ形式が正しいかを自動的にチェックするDocument Validationを持ち、またJSONドキュメントをバイナリ化して格納することで参照性能の向上を図っています。またMySQL 5.7.6で実装されたGenerated Column(生成列)を活用することで、functional indexes(関数インデックス)の形でインデックスを利用できます。
関連情報(MySQL Server Teamブログ)：
機能概要 JSON Labs Release: Native JSON Data Type and Binary Format | MySQL Server Blog
データ変更 JSON Labs Release: JSON Functions, Part 1 — Manipulation JSON Data | MySQL Server Blog
データ参照 JSON Labs Release: JSON Functions, Part 2 — Querying JSON Data | MySQL Server Blog
インデックス JSON Labs Release: Effective Functional Indexes in InnoDB | MySQL Server Blog

MySQL JSONはソースコードとLinux用バイナリが下記からダウンロード可能です。ただし、Labs(実験室)版はテスト用途として公開されており本番環境での利用には適しません。
MySQL :: MySQL Labs

まずはMySQL 5.7なのでmysql_install_dbではなくてmysqldの --initialize-insecure オプションで初期化。
MySQLサーバは --character-set-server=utf8mb4 を付けて起動。
クライアントは --default-character-set=utf8mb4 を付けてMySQLサーバに接続し、
データベースを作成そしてテーブルを作ります。

mysql> CREATE TABLE t1 (id SERIAL, info JSON) DEFAULT CHARSET=utf8mb4;
Query OK, 0 rows affected (0.08 sec)

mysql> SHOW CREATE TABLE t1 \G
*************************** 1. row ***************************
       Table: t1
Create Table: CREATE TABLE `t1` (
  `id` bigint(20) unsigned NOT NULL AUTO_INCREMENT,
  `info` json DEFAULT NULL,
  UNIQUE KEY `id` (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4
1 row in set (0.00 sec)

3行ほどデータを流し込んでみます。

mysql> INSERT INTO t1(info) VALUES ('{"id":1,"Name":"Farmer grandmas","price":50000,"Conditions":["farms",15]}');

mysql> INSERT INTO t1(info) VALUES ('{"id":2,"Name":"Worker grandmas","price":300000,"Conditions":["factories",15]}');

mysql> INSERT INTO t1(info) VALUES ('{"id":3,"Name":"グランマ","price":300000,"Conditions":["factories",15]}');

jsn_extract()関数は指定したキーの値を取得するSQL関数です。

mysql> SELECT jsn_extract(info, '$.Name') FROM t1;
+-----------------------------+
| jsn_extract(info, '$.Name') |
+-----------------------------+
| "Farmer grandmas"           |
| "Worker grandmas"           |
| "グランマ"                  |
+-----------------------------+
3 rows in set (0.00 sec)

日本語の照合も何となくできているようです。

mysql> SELECT jsn_extract(info, '$.Name')='グランマ' FROM t1;
+--------------------------------------------+
| jsn_extract(info, '$.Name')='グランマ'     |
+--------------------------------------------+
|                                          0 |
|                                          0 |
|                                          1 |
+--------------------------------------------+
3 rows in set (0.00 sec)

'🍣'='🍺'がどうなるかは、試してみて下さい。

MySQL公式英語ブログ＆開発エンジニアブログ

MySQL Server開発チーム

http://mysqlserverteam.com

高可用性関連チーム (レプリケーション＆Utilities)

http://mysqlhighavailability.com/

InnoDBチーム

https://blogs.oracle.com/mysqlinnodb/

MySQL Clusterチーム by Andrew Morgan, Product Managemer

http://www.clusterdb.com

MySQL Enterprise チーム

https://blogs.oracle.com/mysqlenterprise/

MySQL Workbench チーム

http://mysqlworkbench.org
https://blogs.oracle.com/mysqlworkbench/

バックアップチーム

https://blogs.oracle.com/mysqlenterprisebackup/

MySQL on Windowsチーム

https://blogs.oracle.com/MySqlOnWindows/

MySQLテストチーム

https://blogs.oracle.com/mysqltesting/

リリース エンジニアリング チーム (ダウンロードパッケージ＆レポジトリ＆サポートプラットフォーム)

http://mysqlrelease.com

製品リリース情報＆MySQL研修

https://blogs.oracle.com/mysql/

コミュニティチーム by Morgan Tocker, MySQL Community Manager

http://www.tocker.ca

コミュニティチーム by Dave Stokes, MySQL Community Manager

https://opensourcedba.wordpress.com

Tomas Ulin, Vice President MySQL Development at Oracle

http://insidemysql.com

Todd Farmer Director of Technical Product Management

http://mysqlblog.fivefarmers.com

Dimitri Kravtchuk, MySQL Performance Architect

http://dimitrik.free.fr/blog/index.html

駄文：MySQLエコシステムと車の関係

MySQLサーバを市販されている乗用車だとすると、MySQL Clusterは整備されたサーキットでの高速走行に最適化されたフォーミュラカーな感じで、WebScaleSQLは市販車をベースにして、特殊な走行環境に最適化されたラリーカーなイメージか？

photo by djkennyc; CC-SA 3.0, from deviantart.com
フォーミュラカーの限界性能を引き出すためには特殊な運転テクニックのみならず、専門スタッフによるメンテナンスが必須。エンジンや仕様は市販車とは大幅に異なり、一人しか乗れなかったり荷物を搭載できない上、一般道での走行が実質的に不可など制限事項が多いが、圧倒的に高速。フォーミュラカーでの蓄積された技術が市販車に反映されたり、逆に市販車でのニーズをもとにフォーミュラカーの仕様が決められることも。

photo by kallerna; CC-SA 3.0, from Wikimedia Commons
ラリーカーの外観は市販車と似ていたり、エンジンも市販車のものをチューニングしたものを使用する。ただ後部座席が取り払われていてロールケージが取り付けられていたりエアコンが無かったりと安全性や快適性などの仕様は異なる。以前は大幅な仕様変更が多かったが、最近は市販車に対して限定的な改良にとどまることが増えている。
レギュレーションとして全般的な仕様は公開されているが、完成車は販売されていないため、各チームが個別に機能の追加や最適化を行って作成するのが基本。レプリカが一般向けに販売されることもあるが、実際のレース仕様車にするには自力での改造が必要となる。

photo by Taisyo; CC-SA 3.0, from Wikimedia Commons
libmysqldはエンジンだけを販売している感じ。内燃機関を必要とする装置に組み込むことを目的として作られてる。インターフェースとなるハンドルやアクセルブレーキ類、動力伝達装置などは一切ついてこないので、自分で実装することになる。

photo by Lexus owner; CC-SA 3.0, from Wikimedia Commons
MySQLサーバのEnterprise Editionは、市販車の中でもカーナビや全席エアバッグなど様々な追加オプションに加えて保険や点検サービスなどを含んだグレードみたいな感じ。欲しいと思った装備がそのグレードにしか無いのに、いらない気がするオプションがついて来ちゃうあたりも似ている。でも最初いらないと思った装備も使ってみると実はものすごく便利だと気づくこともある。点検付きパッケージを買うと一部のオプションもついてくるのがStandard Editionっぽい。
一部装備を除けば純正パーツではなく代替品を自分で装着したり整備を自前でやることもできるので、車そのものにあたるベースグレード(コミュニティー版のイメージ)を使うケースも十分ありえる。以前はオプションだった装備がベースグレードに標準装備されることもあったり。

他にも一部の方々に喜ばれるような痛車や、せっかく便利なエンジンを搭載したのにわざわざ人力で引っ張るリアカーを再発明したようなものがあるあたりも、なにかエコシステムとして似ているのかもしれない。

MySQL Connect 2014 Call for Proposals 3月18日募集開始

米国でプレスリリースが出て、今年のMySQL ConnectのCall for Proposals募集開始となりました。

http://www.oracle.com/us/corporate/press/2168491

2014年のMySQL Connectは9月29日から10月2日にサンフランシスコにて、Oracle OpenWorldと同時開催されることになっています。このMySQL ConnectのCall for Proposals(セッション講演者募集)は、4月15日までです。
参考: MySQL Connect @ OpenWorld Call for Proposals Open | The Oracle MySQL Blog

応募時に必要となる主な情報は下記の通りです。

• セッションタイトル
• セッションのタイプ
  • カンファレンスセッション 1時間 (通常の講演)
  • Birds-of-a-Featherセッション 1時間 (特定の技術を中心としたディスカッション)
  • チュートリアル 2.5時間 (ハンズオン形式のミニトレーニング)
• セッション概要 (750文字以内)
• ターゲットとなる聴講者(選択)
• 講演者情報 (氏名、メールアドレス、略歴)
• 講演トラック
  • Architecture & Application Development
  • Cloud & Big Data
  • Database Administration and DevOps
  • High Availability and Replication
  • Performance & Scalability
• セッション詳細 (3,000文字以内)

複数のセッションを応募することも可能ですし、1つのセッションを複数の講演者で担当することもできます。MySQLサーバやMySQL Clusterの特定の技術セッションは開発者と重複することも考えられるので、導入事例や実際の現場での運用を踏まえた上での技術解説、また独自ツールの紹介もテーマとして面白いと思います。

今年も日本からの講演者が出ればと思います。募集期間はまだ少し先ですが、応募資料の確認やプレゼンの準備など、なにかお手伝いできればと考えておりますので、Call for Papers応募を検討されている方はぜひ下記コメントかツイッターの [twitter:@RKajiyama] までDM下さい。特に英語が不安という場合でも、全力で支援させていただきますのでご連絡下さい。

MySQL Connect 2014 Call for Papers 3月4日募集開始予定

「みんな!サンフランシスコへ行きたいかーっ!!」「どんなことをしても、サンフランシスコへ行きたいか!!」「罰ゲームは怖くないかーっ!!」※罰ゲームはたぶんありませんw

2014年のMySQL Connectは9月29日から10月2日にサンフランシスコにて、Oracle OpenWorldと同時開催されることになっています。このMySQL ConnectのCall for Papers(セッション講演者募集)は、3月4日から4月8日の間となる予定※です。　※募集日程は変更になる可能性が若干あります。
参考: Prepare Now for the MySQL Connect 2014 Call for Papers

応募時に必要となる情報は下記の通りです。

• セッションタイトル
• セッションのタイプ
  • カンファレンスセッション 1時間 (通常の講演)
  • Birds-of-a-Featherセッション 1時間 (特定の技術を中心としたディスカッション)
  • チュートリアル 2.5時間 (ハンズオン形式のミニトレーニング)
• セッション概要 (750文字以内)
• 講演者情報 (氏名、メールアドレス、略歴)
• 講演トラック
  • Performance & Scalability
  • High Availability and Replication
  • Cloud & Big Data
  • Database Administration and DevOps
  • Architecture & Application Development

複数のセッションを応募することも可能ですし、1つのセッションを複数の講演者で担当することもできます。MySQLサーバやMySQL Clusterの特定の技術セッションは開発者と重複することも考えられるので、導入事例や実際の現場での運用を踏まえた上での技術解説、また独自ツールの紹介もテーマとして面白いと思います。

今年も日本からの講演者が出ればと思います。募集期間はまだ少し先ですが、応募資料の確認やプレゼンの準備など、なにかお手伝いできればと考えておりますので、Call for Papers応募を検討されている方はぜひ下記コメントかツイッターの [twitter:@RKajiyama] までDM下さい。特に英語が不安という場合でも、全力で支援させていただきますのでご連絡下さい。