アーカイブ「2016年05月」

GCPとAWSで、拠点(リージョン)間の通信速度を簡単に図ってみた。

正確ではないし、3回程度しか実施していないので、その点は考慮ください。

 

■ComputerEngineのインスタンス(ASIA)から(AMERICA東部)への230MBのSCP

24秒

 

■EC2のインスタンス(TOKYO)から(AMERICA東部)への230MBのSCP

23秒

 

ほとんど同じ。

GCPはネットワークの強さをうたっているが、AWSと変わらないケースもある。

 

GCPの場合、ローカルネットワーク上で、異なるリージョンのインスタンスをまとめられるので、

データベースなどを複数リージョンで準同期レプリケーションできるとよいと思っていたが、

その目論見は成立しそうにないことがわかった。

 

ただし、GCPはグローバルロードバランサーとか、CloudStorageがめちゃくちゃ優秀だから、

実際にサービスとしてユーザの体感速度的なものは、広域範囲で考えればAWSより優秀なのではないか。

 

投稿日時:2016年05月27日 23:47   カテゴリー:aws, gcp   [コメントがあればどうぞ]

GCP(Google Cloud Platform)における、

Google Cloud Storage(以下、GCS)がすごい。

 

AWSでいうところのS3にあたるものですが、

バケット間同期が、

25,000ファイル、8GBを転送(同期)するのに、約5分。

驚異的。。

 

JAVAの並列処理(4CORE)で、

S3に同じ量をアップするのに、8分だったから、

ちょっと負けた気分。

 

なお、GCSはgsutilというツールを使うのがよい。

JAVAなどはSDKが出ているが、とてもめんどくさい。

 

gsutilは、gcloudの認証に影響を受けるようなので、

予めサービスアカウントを発行して、gcloudでの認証処理をしておくのがよい。

 

追記

ちなみに、上記の5分という数字は、

バケットのリージョンが異なっていても、同じでも変わらない。

つまり、AsiaからAmericaのバケット間転送でも超高速。

驚異的。。。

 

投稿日時:2016年05月27日 23:30   カテゴリー:gcp   [コメントがあればどうぞ]

以前の記事で、

master、slave構成において、

  • 非同期レプリケーション
  • 準同期レプリケーション

があることが抜けていた。

 

今回のように、maxscaleでsalve auto promotionを使う場合、

データロスト率が低い準同期方式がよいと思われる。

準同期レプリケーションについては、詳細説明をされているホームページがあるので、

それを参照されたい。

 

準同期レプリケーションの設定は以下。

[mysqld]
plugin-load=rpl_semi_sync_master=semisync_master.so;rpl_semi_sync_slave=semisync_slave.so
rpl_semi_sync_master_enabled=1
rpl_semi_sync_master_timeout=1000
rpl_semi_sync_slave_enabled=1

 

これで、プラグインのロードと、

準同期レプリケーションの設定が入る。

なお、ここでは、masterがslaveに、slaveがmasterになることがあるので、

master・slave問わず同じ設定を入れている。

 

ここで準同期レプリケーションの課題を考えてみると、以下のようなものがありそうだ。

  1. ネットワーク帯域が狭いとクラスターのパフォーマンスに影響を及ぼす
  2. slave台数が増えるとクラスターのパフォーマンスに影響を及ぼす
  3. バイナリログサイズがでかいとクラスターのパフォーマンスに影響を及ぼす

 

非同期と混在させることが出来なかったような気がするので、

遠隔地にバックアップをおくこともできないと思われる。

 

これらについて、検証したら詳細を記述したい。

 

投稿日時:2016年05月27日 23:21   カテゴリー:mariadb, mysql, rdb   [コメントがあればどうぞ]

前回

Slave auto promotionについて記載するといったが、

詳細はさておき、先に結論を書いておく。

 

【前提】

  • maxscaleによるWriterReaderSplit機能を使う
  • masterダウン時には、生きているslaveが自動昇格する

 

【結論】

  • ノード数は3以上が推奨と書かれているが、ノード数が1になると、maxscaleのWriterReaderSplitが機能しなくなる
  • slaveの同期が失敗していている状態では、masterに昇格しないし、maxscaleのクラスターからも外れる

 

ということが挙げられる。

つまり、3ノードあっても、2ノード死んだら、実質アウトなのである。

 

 

そのため、打っておく手段としては、

  • masterがダウン→手動復旧→自動で新masterのslaveとなるようにする
  • 1ノードになった場合、maxscale経由でアクセスしないようにする

ということをやっておけば完璧だと思われる。

 

ちなみに、良い点として、masterがダウン→復旧しても、新masterとバイナリログポジションがずれているため、

maxsacle上のクラスターからは外され、マルチマスター状態にはならない。(単独のマスターとして存在する)

 

幸い、maxscaleは結構イベントが拾えるので、

上記対策もなんとか実現できそうな気がしている。

そのあたりの検証記事を、今後書こうと思います。

 

以上

 

投稿日時:2016年05月17日 00:20   カテゴリー:mariadb, mysql, rdb   [コメントがあればどうぞ]

MariaDBでクラスターを組む際、

  • maxscale
  • mariadb-replication-manager
  • MariaDB

を使うとよい。

 

そもそも、MariaDBのクラスターには、

  • Spider(マルチマスター、データ分散型)
  • Galera(マルチマスター、データ同期型)
  • Slave auto promotion(マスタースレーブ、データ同期型)

のような3つの手段があるが(もっとあるかも。。調べてません。)、

GaleraとSlave auto promotionであれば、maxslace & repliacation-managerの監視および発砲でいける。

 

すいません、Spliderは記載しておきながら、大してわからないので、

GaleraとSlave auto promotionの特徴を書いてみる。

 

【Galera】

(メリット)

  • 全てmasterであるため、障害時のダウンタイムがほぼ0
  • 各ノードのデータ状況に差異が出にくい

(デメリット)

  • データの同期化のため、ノード数が増えると更新時間がかかる
  • テーブルor行ロックは同一ノードのみ有効

 

【Slave auto promotion】

(メリット)

  • データ更新時間はシングル構成と変わらない(うそ、シングルより遅いし、レプリケーションタイプにも影響をうける)

(デメリット)

  • Slaveの昇格が完了するまではダウンタイムとなる
  • Slave遅延が発生するとデータのロストが発生する

 

上記のような特徴があるので、

使いどころはサービスに依存するのかもしれない。

 

私の見解では、

・同一データを更新することがない場合 → Galera

・同一データを更新することが多い場合 → Slave auto promotion

がよいと思う。

決め手は、更新速度とロックの有無かと。

※Spiderは分散データなので、Slave auto promotionと組み合わせないとデータロストしちゃうかも。。

 

Galeraは結構やっている人がいるから、

Slave auto promotionについて、

maxscaleとreplication-managerを用いた構成の説明(やってみた)を近々で書こうと思う。

 

以上

 

投稿日時:2016年05月17日 00:02   カテゴリー:mariadb, mysql, rdb   [コメントがあればどうぞ]