MySQL :: MySQL ForumsForum to discuss quality assurance techniques, such as bug reports, test cases, code patches
実録、ほぼ無停止な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
［MySQLウォッチ］第18回 レプリケーションのトラブル脱出
server-id=7 master-host = 192.168.11.2 master-user= satou master-password = pass replicate-do-db = databank レプリケーションの対象となるデータベースは，「databank」，1つのテーブル「accesslog」が格納されている。マスタ側で，随時データを追加し，レプリケーションの機能を使用してスレーブに複製を作成する。現時点で，リスト1のようにマスターおよびスレーブにデータが格納されている。 リスト1●テーブル「accesslog」の内容(マスター側) mysql> select * from accesslog; +-----+-----+----------+------------+--------------+ | No | ID | Name | Time | Nemo |
MySQL レプリケーション基礎 - shibainu55日記
今日は、MySQLのレプリケーションのお話。バージョンは5.0を前提として説明。 MySQLにおけるレプリケーションは更新情報を記録したバイナリログ(binlog)をベースとしたアーキテクチャ。マスターでの更新情報をバイナリログとしてスレーブに転送、これをSQLに変換しスレーブで実行しデータ同期を行う。Oracle Data GuardのLogicalスタンバイによく似ている。 基本概念図を以下に示す。 特徴 複数のスレーブを用意することで、参照系クエリの負荷分散が可能 マルチマスター構成の場合には更新系クエリの負荷分散も可能 ただし、この場合にはアプリの扱うデータに依存し実現可否が分かれる。 マルチマスター扱いとするオブジェクトを限定するなど、論理設計でも考慮が必要 マスタのバックアップとしてスレーブを切り離し、サービス無停止のままバックアップが可能 この場合、スレーブを停止しコールドバ
MySQL :: MySQL 8.0 リファレンスマニュアル :: 17.1.2.8 レプリケーション環境へのレプリカの追加
新しいレプリカを作成するためにコピーするレプリケーションソースサーバーまたは既存のレプリカにスケジュールされたイベントがある場合は、それらが新しいレプリカで無効になっていることを確認してから開始してください。 ソースですでに実行されている新しいレプリカでイベントが実行されると、複製された操作によってエラーが発生します。 イベントスケジューラは、event_scheduler システム変数によって制御されます。このシステム変数のデフォルトは MySQL 8.0 の ON であるため、元のサーバーでアクティブなイベントは、新しいレプリカの起動時にデフォルトで実行されます。 新しいレプリカでのすべてのイベントの実行を停止するには、新しいレプリカで event_scheduler システム変数を OFF または DISABLED に設定します。 または、ALTER EVENT ステートメントを使用
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
mysql_replicated
HolyWar.net is for sale | HugeDomains
現場指向のレプリケーション詳説