みなさん mysqldump は好きですか? 自分はどっちでもありません。 MySQLでよくあるMaster-Slave構成を作る手順は以下のようになると思います MasterからSlaveとなるサーバに一貫性を保った状態のコピーをし、そのデータのバイナリログのファイル・ポジションをメモ。 SLAVEでデータをリストアし、Masterのホスト名、レプリケーションに使うユーザ名・パスワードとメモしたバイナリログのポジションをCHANGE MASTER文に渡し、START SLAVE 一貫性の取れたコピーを作成するためにmysqldumpやxtrabackup、LVMなどでのスナップショットが利用できますが、もっとも簡単な方法がmysqldumpだと思います。 mysqldumpで一貫性のあるデータをとり、その際のバイナリログポジションを記録するには $ mysqldump --single-
レプリケーションはMySQLで最もよく使われる機能のひとつだ。レプリケーションは基本的に非同期でデータの複製を行う仕組みになっているのだが、非同期故にどうしても逃れられない問題がある。そのひとつが今回のテーマ、遅延である。というと、MySQLのレプリケーションはすぐに遅延が生じてしまうように感じてしまうかも知れないが、そのようなことはない。ほとんどの場合は即座にスレーブの更新が行われる。 なぜ遅延は発生するのか、どのように遅延が起きていることを調べるのか、どのように回避するのかということを本エントリでは解説したい。うまく遅延と付き合って、MySQLのレプリケーションをより快適に運用してもらえればと思う。 そもそも遅延とは何かMySQLのレプリケーションは非同期で行われる。これは準同期でも同じであり、スレーブにおいて更新が起きるのはマスターよりも一瞬遅れてしまう。これは非同期であるが故に逃れ
このところ、Vine4.0が出たこともあって、レプリケーション・エラーが2回ほどあったので、そのときの対処メモです。 HDDとか、ネットワークなどのIOエラーではない場合で、対処してみました。 以下をスレーブ側で操作します。
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.ス
このウェブサイトは販売用です! hansode.org は、あなたがお探しの情報の全ての最新かつ最適なソースです。一般トピックからここから検索できる内容は、hansode.orgが全てとなります。あなたがお探しの内容が見つかることを願っています!
SQL Server (37) DB2 (2) PostgreSQL (4) MS-Access (0) その他 (23) OS (127) Windows (44) UNIX,Linux (74) Solaris (4) その他 (70) Mac (7) その他 (2) サーバ/ストレージ (25) サーバマシン (3) ストレージ/バックアップ (10) 仮想化 (7) その他 (5) ネットワーク (23) ルーティング/スイッチング (6) ロードバランス (2) 帯域コントロール (0) 無線LAN (0) VoIP関連 (0) リモートアクセス (0) その他 (15) セキュリティ (60) アンチウィルス (3) FireWall,IDS,IPS (1) メールフィルタリング (0) 脆弱性 (22) 暗号化 (4) 認証 (13) その他 (17) モバイル (30) S
1.2 レプリケーションの動作レプリケーションでは最初にDBの内容を同期させた後、Masterサーバーで実行された更新系のクエリ(UPDATEとか)をSlaveに渡してSlaveでも同じクエリを実行していくことで、DBを同期させている(図1)。 Master側で実行された更新系クエリはバイナリログに蓄えられており、Slave側が接続してきたら、前回の接続からの変更分をSlave側に送信する。Slave側は受け取ったクエリを一旦リレーログに蓄えて順次クエリを実行してDBを同期させていく。リプリケーション動作にはBinlogDump,I/O,SQLの3つのスレッドが連携して動作する。 2.設定手順 (Master-Slave構成) 2.1 Master側の設定の確認Master側ではバイナリログを採取しておく必要があるので、Master側のmy.cnfにlog-binの設定が入っていることを確
MySQLのレプリケーションは非常に簡単に使える割には応用の幅が広いので非常に人気のある機能の一つである。レプリケーションの応用分野は例えば、 バックアップ 参照系の負荷分散 HA(高可用性) ディザスタリカバリ(サイト間レプリケーション) BI(レポーティングetc) という風にとても多くのバリエーションがある。このブログを読んで頂いている皆さんの中にもレプリケーションを使っている方は多いのではないだろうか。ご覧の通りMySQLのレプリケーション機能はミッションクリティカル分野でも利用されているが、レプリケーションの使い方が適切でないとシステムの安定稼働に支障を来してしまってDBAやシステム管理者の肉体的、精神的負担が増大してしまう。逆にレプリケーションを堅牢に運用することが出来ればマクラを高くして眠れるというものだ。レプリケーションはMySQLの代表的な機能であるので、レプリケーション
レプリケーションとは、あるデータベースから他のデータベースに複製を作ることです。 これは通常、以下のような理由から使われます。 サーバがダウンしたときの対処 複数のデータベースが同じ内容を持つことで、一つのサーバがダウンしても 他のサーバを使うことが可能になります。 負荷分散 複数のデータベースを交互にアクセスすることで、一つのサーバに掛かる負担を減らすことが出来ます。 MySQLでは「一方向レプリケーション」を採用しています。 一つのサーバを「マスタ」として機能させ、残りのサーバが「スレーブ」になります。 データの複製は「マスタ→スレーブ」という方向でのみ行われます。 そのため、データの更新は必ずマスタサーバで実行する必要があります。 マスタサーバで更新を行うと、その更新内容が全てのスレーブサーバに通知され スレーブサーバはマスタサーバと同じ更新処理を行います。これにより、マスタとスレー
レプリケーションしてるMySQLで、マスタやスレーブが障害停止した場合のリカバリプラン でも掲げたゴールである、「マスタが落ちてもぐーすか寝ていられるようにしたい」がほぼできたので、ほとんどサービスが停止することなく、フェイルオーバする様をスクリーンキャストに収めました。 埋め込みプレイヤーだと、小さくてわからないと思うので、リンク直接でみてください。 http://www.irori.org/pub/mysql-mm.mov 登場するホスト 登場するホストは2台、db901とdb902です。 最初は、db901が更新系クエリを受けるプライマリでdb900の浮動IPアドレスを持っています。 画面分割 画面は5分割しています。 左上 = 「select sysdate(),@@server_id」をdb900に対して(sleep 1しながら)延々と実行しまくりんぐ 右上 = ping -n
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く