Enviar búsqueda
Cargar
MCCT20130926 tsakuradac
•
Descargar como PPTX, PDF
•
5 recomendaciones
•
11,975 vistas
Takeshi Sakurada
Seguir
2013.9.26 MySQL Cluster Casual Talks MySQL Clusterと丸4年の付き合いを振り返ってのよもやま話と、Version 7.3への期待
Leer menos
Leer más
Denunciar
Compartir
Denunciar
Compartir
1 de 36
Descargar ahora
Recomendados
Tritonn (MySQL5.0.87+Senna)からの mroonga (MySQL5.6) 移行体験記
Tritonn (MySQL5.0.87+Senna)からの mroonga (MySQL5.6) 移行体験記
Kentaro Yoshida
カジュアルにMySQL Clusterを使ってみよう@MySQL Cluster Casual Talks 2013.09
カジュアルにMySQL Clusterを使ってみよう@MySQL Cluster Casual Talks 2013.09
Mikiya Okuno
5分で作るMySQL Cluster環境
5分で作るMySQL Cluster環境
yoyamasaki
MySQL 5.6への完全移行を実現したTritonnからMroongaへの移行体験記
MySQL 5.6への完全移行を実現したTritonnからMroongaへの移行体験記
Kentaro Yoshida
MySQL Clusterのトラブル事例
MySQL Clusterのトラブル事例
hiroi10
No sql with mysql cluster (MyNA・JPUG合同DB勉強会)
No sql with mysql cluster (MyNA・JPUG合同DB勉強会)
Shinya Sugiyama
MySQl 5.6新機能解説@第一回 中国地方DB勉強会
MySQl 5.6新機能解説@第一回 中国地方DB勉強会
Mikiya Okuno
SQL+NoSQL!? それならMySQL Clusterでしょ。
SQL+NoSQL!? それならMySQL Clusterでしょ。
yoyamasaki
Recomendados
Tritonn (MySQL5.0.87+Senna)からの mroonga (MySQL5.6) 移行体験記
Tritonn (MySQL5.0.87+Senna)からの mroonga (MySQL5.6) 移行体験記
Kentaro Yoshida
カジュアルにMySQL Clusterを使ってみよう@MySQL Cluster Casual Talks 2013.09
カジュアルにMySQL Clusterを使ってみよう@MySQL Cluster Casual Talks 2013.09
Mikiya Okuno
5分で作るMySQL Cluster環境
5分で作るMySQL Cluster環境
yoyamasaki
MySQL 5.6への完全移行を実現したTritonnからMroongaへの移行体験記
MySQL 5.6への完全移行を実現したTritonnからMroongaへの移行体験記
Kentaro Yoshida
MySQL Clusterのトラブル事例
MySQL Clusterのトラブル事例
hiroi10
No sql with mysql cluster (MyNA・JPUG合同DB勉強会)
No sql with mysql cluster (MyNA・JPUG合同DB勉強会)
Shinya Sugiyama
MySQl 5.6新機能解説@第一回 中国地方DB勉強会
MySQl 5.6新機能解説@第一回 中国地方DB勉強会
Mikiya Okuno
SQL+NoSQL!? それならMySQL Clusterでしょ。
SQL+NoSQL!? それならMySQL Clusterでしょ。
yoyamasaki
MySQL5.6でGTIDを試してそっと閉じた
MySQL5.6でGTIDを試してそっと閉じた
Emma Haruka Iwao
MySQL Cluster 7.4で楽しむスケールアウト @DB Tech Showcase 2015/06
MySQL Cluster 7.4で楽しむスケールアウト @DB Tech Showcase 2015/06
Mikiya Okuno
逝くぞ最新版、罠の貯蔵は十分か
逝くぞ最新版、罠の貯蔵は十分か
yoku0825
What's New in MySQL 5.7 InnoDB
What's New in MySQL 5.7 InnoDB
Mikiya Okuno
正式リリースされた.Net coreに少し触れ合ってみる
正式リリースされた.Net coreに少し触れ合ってみる
Tsukasa Kato
AWSのRedHatにMySQL最速インストール
AWSのRedHatにMySQL最速インストール
sakaik
お金が無いときのMySQL Cluster頼み
お金が無いときのMySQL Cluster頼み
aoike
mikasafabric for MySQL
mikasafabric for MySQL
yoku0825
最近始めたあなたも今日から語れるようになるMySQLの{概要と最新情報}入門@
最近始めたあなたも今日から語れるようになるMySQLの{概要と最新情報}入門@
sakaik
Art of MySQL Replication.
Art of MySQL Replication.
Mikiya Okuno
What's New in MySQL 5.7 Security
What's New in MySQL 5.7 Security
Mikiya Okuno
MySQL 5.7の次のMySQLは
MySQL 5.7の次のMySQLは
yoku0825
MySQL Clusterを運用して10ヶ月間
MySQL Clusterを運用して10ヶ月間
hiroi10
Osc spring 20220311
Osc spring 20220311
Yasuaki Sera
MySQL 5.7の罠があなたを狙っている
MySQL 5.7の罠があなたを狙っている
yoku0825
Mysql toranomaki
Mysql toranomaki
Mikiya Okuno
OSC2017 Hokkaido. MySQL今こそインストールを極めよう~改めて考える環境構築~
OSC2017 Hokkaido. MySQL今こそインストールを極めよう~改めて考える環境構築~
sakaik
[C21] MySQL Cluster徹底活用術 by Mikiya Okuno
[C21] MySQL Cluster徹底活用術 by Mikiya Okuno
Insight Technology, Inc.
MySQLの冗長化 2013-01-24
MySQLの冗長化 2013-01-24
Yoshihiko Matsuzaki
MySQL Cluster 解説 & MySQL Cluster 7.3 最新情報
MySQL Cluster 解説 & MySQL Cluster 7.3 最新情報
yoyamasaki
Más contenido relacionado
La actualidad más candente
MySQL5.6でGTIDを試してそっと閉じた
MySQL5.6でGTIDを試してそっと閉じた
Emma Haruka Iwao
MySQL Cluster 7.4で楽しむスケールアウト @DB Tech Showcase 2015/06
MySQL Cluster 7.4で楽しむスケールアウト @DB Tech Showcase 2015/06
Mikiya Okuno
逝くぞ最新版、罠の貯蔵は十分か
逝くぞ最新版、罠の貯蔵は十分か
yoku0825
What's New in MySQL 5.7 InnoDB
What's New in MySQL 5.7 InnoDB
Mikiya Okuno
正式リリースされた.Net coreに少し触れ合ってみる
正式リリースされた.Net coreに少し触れ合ってみる
Tsukasa Kato
AWSのRedHatにMySQL最速インストール
AWSのRedHatにMySQL最速インストール
sakaik
お金が無いときのMySQL Cluster頼み
お金が無いときのMySQL Cluster頼み
aoike
mikasafabric for MySQL
mikasafabric for MySQL
yoku0825
最近始めたあなたも今日から語れるようになるMySQLの{概要と最新情報}入門@
最近始めたあなたも今日から語れるようになるMySQLの{概要と最新情報}入門@
sakaik
Art of MySQL Replication.
Art of MySQL Replication.
Mikiya Okuno
What's New in MySQL 5.7 Security
What's New in MySQL 5.7 Security
Mikiya Okuno
MySQL 5.7の次のMySQLは
MySQL 5.7の次のMySQLは
yoku0825
MySQL Clusterを運用して10ヶ月間
MySQL Clusterを運用して10ヶ月間
hiroi10
Osc spring 20220311
Osc spring 20220311
Yasuaki Sera
MySQL 5.7の罠があなたを狙っている
MySQL 5.7の罠があなたを狙っている
yoku0825
Mysql toranomaki
Mysql toranomaki
Mikiya Okuno
OSC2017 Hokkaido. MySQL今こそインストールを極めよう~改めて考える環境構築~
OSC2017 Hokkaido. MySQL今こそインストールを極めよう~改めて考える環境構築~
sakaik
[C21] MySQL Cluster徹底活用術 by Mikiya Okuno
[C21] MySQL Cluster徹底活用術 by Mikiya Okuno
Insight Technology, Inc.
MySQLの冗長化 2013-01-24
MySQLの冗長化 2013-01-24
Yoshihiko Matsuzaki
MySQL Cluster 解説 & MySQL Cluster 7.3 最新情報
MySQL Cluster 解説 & MySQL Cluster 7.3 最新情報
yoyamasaki
La actualidad más candente
(20)
MySQL5.6でGTIDを試してそっと閉じた
MySQL5.6でGTIDを試してそっと閉じた
MySQL Cluster 7.4で楽しむスケールアウト @DB Tech Showcase 2015/06
MySQL Cluster 7.4で楽しむスケールアウト @DB Tech Showcase 2015/06
逝くぞ最新版、罠の貯蔵は十分か
逝くぞ最新版、罠の貯蔵は十分か
What's New in MySQL 5.7 InnoDB
What's New in MySQL 5.7 InnoDB
正式リリースされた.Net coreに少し触れ合ってみる
正式リリースされた.Net coreに少し触れ合ってみる
AWSのRedHatにMySQL最速インストール
AWSのRedHatにMySQL最速インストール
お金が無いときのMySQL Cluster頼み
お金が無いときのMySQL Cluster頼み
mikasafabric for MySQL
mikasafabric for MySQL
最近始めたあなたも今日から語れるようになるMySQLの{概要と最新情報}入門@
最近始めたあなたも今日から語れるようになるMySQLの{概要と最新情報}入門@
Art of MySQL Replication.
Art of MySQL Replication.
What's New in MySQL 5.7 Security
What's New in MySQL 5.7 Security
MySQL 5.7の次のMySQLは
MySQL 5.7の次のMySQLは
MySQL Clusterを運用して10ヶ月間
MySQL Clusterを運用して10ヶ月間
Osc spring 20220311
Osc spring 20220311
MySQL 5.7の罠があなたを狙っている
MySQL 5.7の罠があなたを狙っている
Mysql toranomaki
Mysql toranomaki
OSC2017 Hokkaido. MySQL今こそインストールを極めよう~改めて考える環境構築~
OSC2017 Hokkaido. MySQL今こそインストールを極めよう~改めて考える環境構築~
[C21] MySQL Cluster徹底活用術 by Mikiya Okuno
[C21] MySQL Cluster徹底活用術 by Mikiya Okuno
MySQLの冗長化 2013-01-24
MySQLの冗長化 2013-01-24
MySQL Cluster 解説 & MySQL Cluster 7.3 最新情報
MySQL Cluster 解説 & MySQL Cluster 7.3 最新情報
MCCT20130926 tsakuradac
1.
MySQL Clusterと丸4年の付き合いを 振り返ってのよもやま話と、 Version 7.3への期待 (もっとユーザが増えるといいな ~) Takeshi
Sakurada @tsakurada Ultinet Inc. 2013.9.26 MySQL Cluster Casual Talks
2.
自己紹介 • 氏名:櫻田 剛史(さくらだ
たけし) • 所属:株式会社アルティネット • Twitter id: @tsakurada • MySQL Clusterと商用で丸4年関わった経験 を買われて(?)MCCTにお声がけ頂きま した。どうもありがとうございます。
3.
今日お話ししたいこと • MySQL Clusterとは(スキップ予定) •
選択(何故MySQL Cluster?) • 導入(どう使うか?) • 運用(何が起きるか?)
4.
ATTENTION • 以降のページの記載は基本的に筆者 (@tsakurada)の個人的な体験に基づくもの ですので誤りや思い込みがあるかもしれ ません。 • 実際に業務でお使いになる場合には必ず 公式の資料をご確認した方がよろしかろ うと思います。
5.
MySQL Clusterって? • ユーザ視点で見ると、 –
インメモリDBかつ高可用(MySQL CGE) – ストレージエンジンがMyISAMでもInnoDBでは なくてNDBであるものです(なので、関係者内 ではNDBとかNDBCLUSTERと呼ばれることが多 いです) – もともとはNDBは全く別に開発されていたも ので、MySQL AB(当時)に買収されて統合さ れた(と聞いてます)
6.
タイムライン 2008 2009 2010
2011 2012 2013 2014 構想・検証 ★V7.0.5(GA) ★V7.1.3(GA) ★V7.2.4(GA) ★V7.3.2(GA) ★V6.3.8(GA) 運用中
7.
~何故MYSQL CLUSTER? 選択
8.
選択当時(2009年)の特長認識 ① インメモリDBなので高速である ② 安価なIAサーバをクラスタ化して、必要性 能に応じてスケールアウト可能 ③
高可用性が求められるシーン(いわゆる ミッションクリティカル用途)に耐える という技術上の優位性から採用しました(単 に興味があったというもの…)。 今現在(2013年)の認識はどうかというと… (次ページ)
9.
①インメモリDBなので高速であ る • インメモリDBなので高速というのは本当 です • ただ、今となってはioDrive
+ InnoDBの組合 せでもかなり高い性能が出ちゃうので、 絶対的な優位性を主張するのは難しいか も…
10.
②安価なIAサーバをクラスタ化して、 必要性能に応じてスケールアウト可能 • 共有ストレージ型のDB(Oracle RAC)と比較 して安価、という意味であれば本当でし た •
ただし、スケールアウトという用語が万 能感を醸し出してしまうのですが、実際 にはスケールアウトが難しいケースもあ ります(ノード構成選びで説明)
11.
③高可用性が求められるシーン(いわ ゆるミッションクリティカル用途)に 耐える • これは今でも優位性が高いと思います • F/Oはとても高速で数秒で完了します •
ただ、いくつかポイントを押さえておか ないと意味が無くなるので注意が必要で す(後述)
12.
今、改めて聞かれたら 主張したい優位点 • ライセンスがGPLであり、無償で使えて ソースも入手できる(サポートが欲しい 人は商用ライセンスもあり) • MySQL(InnoDB)との互換性がV7.3以降でか なり向上したので使いやすくなった •
NDB単体でもトランザクションが使える、 データが永続化される、高可用KVSとして 堅牢である
13.
~どう使うか? 導入
14.
MySQL Cluster構成検討 • 基本的な構成 SQL
MGM SQL/MGM 1号機 SQL MGM SQL/MGM 2号機 データー 1号機 DATA L2 SW L2 SW Web server Web server Web server Web server Web server Web server Web server アプリケーションレイヤー データベースレイヤー データー 2号機 DATA データー 3号機 DATA データー 4号機 DATA 14
15.
ノード構成のパターン検討① 15 • 最小構成 DATA SQL MGM ミニマム構成だが、冗長性も 無いので商用環境には向かない。
16.
ノード構成のパターン検討② 16 • 冗長構成 DATA SQL MGM 単一障害点(SPoF)を排除した 冗長構成の基本形(NW部分の検討は必要) SQL
MGM DATA
17.
ノード構成のパターン検討③ 17 • データ量大 DATA SQL MGM 保存するデータ量(件数)が大きくなった場合にはデータノー 増やして対応できる。ただし、Secondary
Index使用時の制約あり SQL MGM DATA DATA DATA
18.
ノード構成のパターン検討④ 18 • アクセス多 DATA SQL MGM アクセスピークに応じて性能を向上(スケールアウト)さ せるため には、SQLノードを増やして対応する。 今となっては、この構成が最適なケースが多いかもしれな SQL MGM DATA SQL SQL
19.
ノード構成のパターン検討 構成 タイプ MGM ノード SQL ノード DATA ノード 合計ノー ド数 説明 I 1 1
1 3 最小構成(冗長化無し) 試験・開発環境ならば使えるがそれ 以上の意味が無い II 2 2 2 6 単一障害点(SPOF)無しの冗長構成 (基本形) III 2 2 4 8 保存するデータ量(件数)が大きく なった場合 IV 2 4 2 8 アクセスピークに応じて処理性能を 向上させたい場合 V 2 8 4 14 データ量と処理性能の両方に要求レ ベルが高い大規模システム VI 2 2 3 7 データノードの冗長化を2重ではな く、3重にした場合(レプリカ数3) VII 2 2 6 10 データ量が多く、データノードを増 やして対応した場合(レプリカ数 2) ※完全にPK(主キー)に帰着できるアプリにできないのであれば、データノードの数は最大でも4程度に止めた方が良い。 19
20.
高可用性を生かすために必要な システム設計上のポイント • H/W構成上SPoFが無いように2重化する – 多重障害をどこまで考慮するかは悩ましいです •
実行中のクエリ(トランザクション)がキャ ンセルされた時、エラーをキャッチして後続 処理を適切に作りこむ必要があります – 条件によって • 処理をリトライする • エラーとして処理を中断させる • 一時的な不整合を許容して後から自動的にリカバリす るバッチプログラムを定期的に起動する • など…
21.
その他、設計上悩ましいポイント ① • MySQL(InnoDB)と同じ感覚(経験則)で テーブル設計しても良いのか? – InnoDBで使っていたものをそのままNDBに 持ってくると期待する性能が全く出ない可能 性もまだあるかもしれません –
ただ、 V7.2, V7.3で互換性が大幅に向上してい ますのでチャレンジする価値は十分あると思 います
22.
その他、設計上悩ましいポイント ② • バッチ処理のことも考えてInnoDBと組み 合わせて使いたい場合 – 高可用性のレベルがInnoDB側に引っ張られる ことになるので、それをどう補償するかを考 える必要があります –
NDBとInnoDBは現状、トランザクションの分 離レベルが違うのでその点でも注意が必要で す
23.
~何が起きるか? 運用
24.
ハマリどころポイント • GCP Stop! •
ローリングリスタート • ボトルネックが見えづらい • データーのライフサイクルどうするか? • バックアップはいいけどリストアが…
25.
GCP Stop! • GCP:
Global Check Point • GCPは(デフォルトだと2秒毎に) HDDに メモリ上の更新ログを書き出しています が、これが何らかの理由で停止すると… • データノードがシャットダウンしてしま います
26.
GCP Stop! • 例えば… –
UPDATE テーブル名 SET カラム名=値 WHERE 条件 – 一度のコミットにかかる時間が一定閾値を超過し た場合(=更新対象となる行数が多数(数万件) になった場合など)に発生してしまいます – なので、UPDATEする時には実際に何件が更新対 象となるのかアプリ側で把握してクエリを発行す る必要があります – 最新バージョン(V7.3)では閾値を無制限に指定で きるのでその策で逃げる方法もありますが、本当 に異常が発生した場合のDBが固まってしまうリ スクが発生します。
27.
ローリングリスタート • NDBのパラメータ変更を反映するために データノードの再起動が必要なものがあ るのですが、サービスを止めずにデータ ノードを1台ずつ再起動する事ができま す
28.
ローリングリスタート • 例えば、データノードが4台あればDATA01 から1台ずつ再起動、起動後次のDATA02に 進めます • でも… DATA01
DATA02 DATA03 DATA04 再起動中 ノードグループ1 ノードグループ2
29.
ローリングリスタート • 図の事例でDATA01が再起動中にDATA02に 障害が発生したら当然ですが全断になり ますよね? DATA01 DATA02 DATA03
DATA04 再起動中 ノードグループ1 ノードグループ2
30.
ローリングリスタート • NDBの再起動(起動)が十分高速であれば問 題にならないのですが、データ量が多くなっ てくると(100GB over)数10分~2時間くらい はかかる事もありますので、その間の可用性 リスクが高まってしまいます。 –
リスタート中はDDL文が発行できないなど仕様上 の制約もあったりします – 最新のバージョンでは起動も高速化しているので すが再起動に掛かる時間を事前に想定、検証して おくのがよろしいかと思います。 • 多重障害をどこまで考慮するかNDBで一番悩 ましいのがこのポイントです
31.
ボトルネックが見えづらい • サーバの性能ボトルネックを探るツール としてvmstatやiostatを良く使いますが、 NDBの場合ボトルネックが見えづらいです (一見問題ないように見えるがサチレー ションが発生するなど) – Slowログを分析するのは有効な手段には変わ りないのですが、通常遅くならない主キーで のSELECTが出てきたりすることがなどありま す •
確認するべきポイントが多いと言った方 が適切かもしれません
32.
ボトルネックが見えづらい • 確認ポイントとしては例えば – データノードで異常が起きていないか? –
SQLノードで異常が起きていないか? – ノード間接続をしているN/Wに異常が無い か? – NDBINFOの値を見てみる (事例・ノウハウが貯まってくれば自然と解 決する課題だとは思います)
33.
データーのライフサイクルをどう するか? • メモリを節約するためには不要になった データはなるべくこまめに消したいとこ ろですが、DELETE文はやはり遅い(重 い)です • あと、DELETE文で削除した場合、その空 いたメモリ領域は同じテーブル内でしか 再利用されない仕様なので注意が必要で す –
データノードを再起動すれば解決しますが… – DROP TABLE文であれば即時に再利用されます
34.
バックアップはいいけどリストア が… • NDBには専用のオンラインバックアップ機能 があります(ロールフォワードリカバリをす るためにはbinlogを使います) • しかし…バックアップデータをリストアする には結構時間がかかりますので、やはり事前 に検証して運用設計をしておくことがよろし いかと思います –
100GBぐらいあるとおそらく半日以上かかります – ただ、通常はもう片方のデータノードが生存して おりそこからオンラインでデータを複製・フェイ ルバックするケース想定の方が多いと思われます
35.
まとめ • 高可用性システムを構築するには今でも MySQL Clusterは適した選択です •
ただ、いろいろ考慮した方がよいポイン トはあります • いろいろな課題はあるものの、最近の機 能拡張にはめざましいものがあるので、 ユーザーがもっと増えるといいな
36.
ご清聴ありがとうございまし た 今後とも、 MySQL Clusterをよろし く!
Descargar ahora