携帯向けサイト「モバゲータウン」の勢いが止まらない。2010年3月の会員数は約1800万人、月間ページビュー(PV)600億という"モンスターSNS"に成長している。意外なことに、これだけのアクセスをさばくのに、memcachedをはじめとするKVS(Key-Value Store)系のインフラ・ソフトはあまり使っておらず、MySQLで十分だという。モバゲータウンのインフラ担当者に話を聞いた。 モバゲータウンを運営するDeNA(ディー・エヌ・エー)は、もともと1999年に開始したオークションサイト「ビッダーズ」で知られている。その後、オークションに加えてECサイトを開始し、auとの提携により「auショッピングモール」などで急速に成長した。 ビッダーズだけでも、数千万PV規模の大規模サービスだが、最近はモバゲータウンの成長が著しい。 「特に2009年9月から順次リリースした自社製のソーシャル
先日「Amazon RDS」に他ロケーション(Zone)で自動フェイルオーバーできるオプションが追加され、より実用性が高くなりました。また、"AWS Management Console"からの、Amazon RDSの利用がサポートされたことにより、利用の敷居もグッと下がりましたよね。 Amazon RDS – Multi-AZ Deployments For Enhanced Availability & Reliability | AWS News Blog MySQLに自動フェイルオーバー機能を追加したAmazonクラウド。オンラインのままパッチ当てやバックアップも - Publickey AWS Management Console Now Supports the Relational Database Service | AWS News Blog それに伴って、以前私が"@I
CONNECTION_ID( ) CONNECTION_ID関数を使用することで、現在接続中の自分の接続IDを調べることができます。 mysql> SELECT CONNECTION_ID( ); +------------------+ | CONNECTION_ID( ) | +------------------+ | 8 | +------------------+ 1 row in set (0.00 sec) KILLコマンドを使用することで、このプロセスIDを強制終了することができます。 mysql> SELECT CONNECTION_ID( ); +------------------+ | CONNECTION_ID( ) | +------------------+ | 10 | +------------------+ 1 row in set (0.00 sec)
MySQLレプリケーションの実装にあたってはバイナリログの存在が不可欠。 そしてスレーブ側マシンにおいてはリレーログが不可欠である。 レプリケーションの処理におけるバイナリログとリレーログの相関について、 今一度まとめてみた。簡単に書くと以下のようになる。 マスタ側の更新系のクエリが、マスタのバイナリログに記録される。 ↓ ↓ ↓ スレーブのI/OスレッドがマスタのBinlog Dumpスレッドに接続し、 マスタのBinlog Dumpスレッドはバイナリログの内容を送信する。 ↓ ↓ ↓ スレーブのI/Oスレッドは、受け取ったマスタのバイナリログをリレーログに保存。 ↓ ↓ ↓ スレーブのSQLスレッドがリレーログからクエリを読み取って実行。 リレーログの挙動について今ひとつ理解していなかったのだが、オフィシャルサイト に以下のように書いてある。 リレーログはバイナリログと同じ形式なので、
MySQLレプリケーションにおいて、スレーブをマスタとしてフェイルオーバーさせる時に やることをざっくりまとめてみた。 マスタでは障害等によりMySQLインスタンスが停止していることが前提。 マスタ1:スレーブ1構成の場合 1.マスタに昇格するスレーブにSTOP SLAVEを発行。 2.マスタに昇格するスレーブにRESET MASTERを発行。 3.スレーブに降格するマシンでCHANGE MASTER を実行し、 START SLAVEする。 もう少し詳しく書くと。 1.スレーブ側でIOスレッドでのバイナリログ受け渡しが完了する頃を見計らって、 STOP SLAVE IO_THREAD を発行。 mysql > STOP SLAVE IO_THREAD; “Has read all relay log”を確認できまるまで、SHOW PROCESSLIST の出力結果をチェックする。 2.ス
障害が発生した場合にマスタとスレーブ間でのフェイルオーバに対応する正式なソリューションは現在の段階ではありません。現在利用可能な機能内では、マスタとスレーブ (または複数のスレーブ) をセットアップし、状況を把握するためにマスタを監視するスクリプトを作成することが挙げられます。そのときには、アプリケーションとスレーブに障害を認識した場合にマスタを変更するよう指示します。 CHANGE MASTER TO ステートメントを使用して、いつでもスレーブにマスタを変えるように指示することが重要です。スレーブはマスタのデータベースがスレーブとの互換性を保持しているかどうかを確認することができないため、新しいマスタが指定するログと場所からイベントを実行し始めます。フェイルオーバの状況で、グループ内すべてのサーバが同一のバイナリ ログからの同一のイベントを実行しています。そのため、イベント元の変更がデー
REPLICATION環境にてSLAVE側でバックアップする為の手順。 STEP1 マスタの処理要求を停止する。または mysqladmin を使用して完全に スレーブを停止する。 shell> mysqladmin stop-slave or 別の方法としては、レプリケーション SQL スレッドを停止して リレー ログ ファイルの処理を停止します。この方法は、 バイナリ ログのデータの転送を許可します。 この方法を活発なレプリケーション環境で使用すると、 スレーブ処理を再開をしたときにキャッチ アップ プロセスを スピードアップする可能性があります。 shell> mysql -e ‘STOP SLAVE SQL_THREAD;’ STEP2 FLUSH TABLES STEP3 データベースのバックアップ shell> mysqldump --all-databases > fulld
MySQLのインストールが終了した2台がある状態より設定を開始します。 マスターとスレーブの2台がある状態からスタートです。 事前準備 事前に2台のサーバーのデータが同じである必要があります。 mysqldump等でダンプを行い、データベースが完全に同じ状態とします。 マスターの設定 設定ファイルの編集 vi /etc/mysql/my.cnf 以下のように編集 server-id = 1 ↓ server-id = 18 (←ユニークな適当な数字へ変更) また以下を設定ファイル内のどこかに追記(ある場合はそのままでOK) log-bin = mysql-bin アカウントの作成 レプリケーション用のアカウントをマスターに作成する。 このアカウントはREPLICATION SLAVE権限を持っている必要がある 以下はすべての接続を許す’repl’ユーザーを作成する例。(グ
この変数は、サーバー ID を指定します。server_id はデフォルトで 1 に設定されています。 このデフォルト ID を使用してサーバーを起動できますが、バイナリロギングが有効になっているときに、サーバー ID を指定するように server_id を明示的に設定しなかった場合は、情報メッセージが発行されます。 レプリケーショントポロジで使用されるサーバーの場合、レプリケーションサーバーごとに一意のサーバー ID を 1 から 2 の 32− 1 の範囲で指定する必要があります。 「Unique」 は、各 ID がレプリケーショントポロジ内の他のソースまたはレプリカで使用されている他のすべての ID と異なる必要があることを意味します。 詳細については、セクション17.1.6.2「レプリケーションソースのオプションと変数」,およびセクション17.1.6.3「Replica Serv
スケールアウトソリューション - 複数のレプリカに負荷を分散して、パフォーマンスを向上させます。 この環境では、すべての書込みおよび更新がソースサーバーで実行される必要があります。 ただし、1 つまたは複数のレプリカで読み取りが行われる場合があります。 このモデルでは、(ソースが更新専用であるため) 書込みのパフォーマンスを向上させる一方で、レプリカの数の増加に伴って読取り速度を大幅に向上させることができます。 データセキュリティ - レプリカはレプリケーションプロセスを一時停止できるため、対応するソースデータを破損させることなくレプリカでバックアップサービスを実行できます。 アナリティクス - ライブデータはソースで作成できますが、情報の分析はソースのパフォーマンスに影響を与えることなくレプリカで実行できます。 長距離データ分散 - レプリケーションを使用すると、ソースに永続的にアクセス
MySQLを含め、PostgreSQL、Oracleで使えるDB負荷テストツール、Super Smackをインストールしてみる。 配布サイト→http://vegan.net/tony/supersmack/さんのところの Solaris10 x86 バイナリがバージョンが古いので1.3をsourceからコンパイル。 MySQL 32bit版のパッケージなどを/usr/local/mysqlに展開 正確に測定するためSuperSmackとMySQLは違うホストに入れます。 ただ、Super-SmackにはMySQLクライアントライブラリが必要なので、手っ取り早くTAR PACKAGE版でも展開しましょう。 今回は、以下の構成を用意。 Super Smackホスト 192.168.1.101 ※MySQL 5.1.23 32bit版 MySQLサーバホスト 192.168.1.102 ※My
全てのスレーブに固有のサーバIDを割り当てないといけない。 一つのスレーブにはマスターを一つだけ割り当てることができる。 一つのマスターに多数のスレーブを割り当てることができる。 スレーブはほかのスレーブのマスターになることができる。 がある。 だが、最初の規則は必ずしも正しいわけではない。 ■ レプリケーションの構成について 先ほどの規則に基づいて簡単なレプリケーションを構成例を挙げる。 ■ 1つのマスターと複数のスレーブ 最も基本的なレプリケーション。 この構成が有効なのは、書き込みが少なくて読み出しが多い場合。 問題点としてはマスターからスレーブへの帯域幅である。
MySQLのレプリケーションは非常に簡単に使える割には応用の幅が広いので非常に人気のある機能の一つである。レプリケーションの応用分野は例えば、 バックアップ 参照系の負荷分散 HA(高可用性) ディザスタリカバリ(サイト間レプリケーション) BI(レポーティングetc) という風にとても多くのバリエーションがある。このブログを読んで頂いている皆さんの中にもレプリケーションを使っている方は多いのではないだろうか。ご覧の通りMySQLのレプリケーション機能はミッションクリティカル分野でも利用されているが、レプリケーションの使い方が適切でないとシステムの安定稼働に支障を来してしまってDBAやシステム管理者の肉体的、精神的負担が増大してしまう。逆にレプリケーションを堅牢に運用することが出来ればマクラを高くして眠れるというものだ。レプリケーションはMySQLの代表的な機能であるので、レプリケーション
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く