日本オラクル梶山隆輔氏
非同期型のレプリケーション
ディザスタリカバリー構成
FBは、ディザスタリカバリ
基本は一方向だが、双方向でのレプリケーションも可能
(マスタからスレーブにそのままコピーするのはNG)
レプリケーションの構成
マスタ→マルチスレーブ
マスタ→スレーブ→マルチスレーブ(マルチスレーブから見たらスレーブがマスターに見える)
特定のテーブルだけメモリーのストレージにする
ストレージエンジン
ブラックホールストレージエンジン nullデバイスみたいなもの
トランザクションのlogをもとに処理を行っていく。
データのレプリケーションに必要なのは、logだけでいいので、
データの中身は不要です。
準同期の場合、スレーブのログが書き換えられたら
アプリケーション(クライアント)にレスポンスを返す
シェアードナッシング型Active-Activeデータベースクラスタ
データノードと呼ばれる別のサーバにデータを分散させる
(均等ではなく同じデータを2つのサーバにばらまいているので、
ストライピングとミラーリングを同時に行う)
単一障害点が存在せず、1台死んでもOK
トランザクション対応のキーバリューデータストア
SQL文を使わずにデータを呼び出すAPIがいくつか存在する
(もとはNoSQLで、まずはC++から、だいぶ後になってSQL文が書けるようにAPI
が作られた)
もとは、NoSQLで、MySQLでもある。
MySQL Cluster7.2は劇的に性能が向上した(性能が70倍向上したが、VMを使わ
ない環境だと230倍になったらしい)
注目のポイント
1分間に10億クエリーを達成!
GA(正式版)リリース
複雑なクエリー処理パフォーマンス70倍
ノード4倍
NoSQL Memcached APIが使えるようになった。スキーマレス、キーバリュー型
データストアを開発
高い処理能力
汎用インテルサーバー8台
6コアプロセッサ 2.93GHz * 2
x5670プロセッサ(24スレッド)
48GM RAM
Linux
弱いJOINを克服
webベースコンテンツ管理システムを採用して、90秒かかる処理が1秒に
Memcached(分散キャッシュの仕組み) + 新しいモジュールを開発
1. アプリからキャッシュに話しかける
2. もしキャッシュにデータがなかったら。キャッシュの更新。いろいろと
面倒である。そのため、MemcachedのAPIだけで更新を行う
MySQLCluster + Memcached
完全にNoSQLとしても扱える
データは常に自動化されているので、
負荷分散も容易
トランザクション処理が可能
Appにサーバを置いて、APIを選ぶことが出来る(SQLを使ってもいいし、使わな
くてもいい)
Memcachedのデータを通して、サーバのレプリケーションが可能になる。
遠隔地レプリケーションの向上
データセンター間でクラスタを完全に複製
非同期レプリケーションだと事故に対応しきれない場合がある
マルチサイトクラスタリング
同期的なレプリケーションが可能になる
当然のことながら、極限までレイテンシを削ることや、
高品質なネットワークを作ることも重要となった。
(これまでは無料版となる)
有償だと運用監視ツールの提供や、容易なアップデートが可能となる。
webエンジニアのためのデータベース技術入門
プロになるためのデータベース技術入門
MySQL Cluster構築運用バイブル
エキスパートのためのMySQL[運用+管理]トラブルシューティングガイド
漢のコンピュータ道
