MySQLレプリケーションの運用が劇的変化！！GTIDについて仕組みから理解する
メリークリスマス！！やあ、良い子のみんな！！サンタクロース・・・ではなく、ヒゲモジャギークからのクリスマスプレゼントだよ！！ というわけで、MySQL Casual Advent Calendarの25日目である。今朝Advent Calendarを覗いてみると、本日分のエントリーが無かったので、急遽書くことにした。Advent Calendar最後の日、クリスマスを飾る記事のテーマはGTIDだ。 前回の投稿では、MySQL 5.6の目玉機能として、レプリケーションがクラッシュセーフになったことを挙げた。レプリケーションまわりで言えば、もうひとつ外せない目玉機能がある。それがGTID（Global Transaction ID）である。 GTIDは良くも悪くもレプリケーションの運用を変化させる。GTIDを使うことによって得られる最大のメリットは、CHANGE MASTER TOでバイナリロ
MySQLでのレプリケーション - 日常メモ
目次 ◎レプリケーションとは ◎レプリケーションの用途およびメリット・デメリット ◎レプリケーションの設定方法 ◎レプリケーションの運用 ◎レプリケーションとは レプリケーションとは、あるMySQLサーバで更新されたデータを別のMySQLサーバに複製する機能。 MySQLではマスタからスレーブヘの複製は非同期に行われるのが標準である*1。 ここで、レプリケーションの種類と仕組みについて整理する。 片方向レプリケーション 双方向レプリケーション 非同期レプリケーション ・マスタ→スレーブという片方向でのレプリケーション。 ・I/Oスレッドによる「スレーブでのバイナリログの受信」とSQLスレッドによる「スレーブでのバイナリログの実行」という2段階のステップが非同期に行われるレプリケーション。 ・マスタを2個以上持たせて、それぞれのマスタを更新できるようにした構成。MySQL Clusterが双
MySQL :: MySQL 8.0 リファレンスマニュアル :: 17.5.1 レプリケーションの機能と問題
以降のセクションでは、MySQL レプリケーションでサポートされていることとされていないことに関する情報、および特定のステートメントの複製時に発生する可能性がある固有の問題と状況に関する情報を提供します。 ステートメントベースレプリケーションは、ソースとレプリカの間の SQL レベルでの互換性に依存します。 つまり、ステートメントベースのレプリケーションが成功するには、使用される SQL 機能がソースサーバーとレプリカサーバーの両方でサポートされている必要があります。 現在のバージョンの MySQL でのみ使用可能なソースサーバーで機能を使用する場合、以前のバージョンの MySQL を使用するレプリカにレプリケートすることはできません。 このような非互換性は、リリースシリーズ内およびバージョン間でも発生する可能性があります。 MySQL 8.0 と以前の MySQL リリースシリーズの間で
MySQLレプリケーションにおけるフェイルオーバー – OpenGroove
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.ス
LifeKeeper -HAクラスタ-
安心を､簡単に｡ LifeKeeper（ライフキーパー）は、システムの障害を監視し、稼動系に障害が生じた場合に待機系に自動的に切り替えを行うことで、システムダウンタイムの時間を短縮し、ビジネス損失を最小限にするHAクラスターソフトウェアです。 カタログダウンロード LifeKeeperはシステムの障害を監視し、稼動系に障害が生じた場合に待機系に自動的に切り替えを行うことでシステムダウンタイムを短縮し、ビジネス損失を最小限にするHAクラスターソフトウェアです。 当社のアンケート調査によると、止められないシステムが停止した経験がある方は、51%に上りました。システム障害が身近に起きている今、あなたの大切なシステムを守るのがLifeKeeperの役目です。
MySQL レプリケーションの設定 - とみぞーノート
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の設定が入っていることを確
suz-lab.com - suz lab リソースおよび情報
This webpage was generated by the domain owner using Sedo Domain Parking. Disclaimer: Sedo maintains no relationship with third party advertisers. Reference to any specific service or trade mark is not controlled by Sedo nor does it constitute or imply its association, endorsement or recommendation.
mysqlで双方向(マルチマスタ)レプリケーション - end0tknr's kipple - web写経開発
前回までに1台の複数のmysqlを起動する方法を紹介しましたが、今回は、それらで双方向(マルチマスタ)レプリケーションを行う方法を紹介します。 my.cnf と my2.cnf 私のcolinux環境ではオプションファイルを切り替えることで、複数のmysqlを起動していますが、以降では次のように表記します。 オプションファイル ここでの表記 /etc/my.cnf my.cnf /etc/my2.cnf my2.cnf レプリケーション用ユーザの追加 mysqlではslaveからmasterを参照する際、レプリケーション用のユーザを使用するようです。そこで、my.cnf, my2.cnf のそれぞれに「GRANT REPLICATION SLAVE」を実行して下さい。 my.cnf> GRANT REPLICATION SLAVE ON *.* TO repl@localhost IDEN
実録、ほぼ無停止な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で、マスタやスレーブが障害停止した場合のリカバリプラン - （ひ）メモ
MySQLで、レプリケーションベースのHAな構成について考えたメモです。 3台(というか2台＋1台)がいいかなぁと思っていて、前半はその理由を、後半では{マスタ,スレーブ}が{再起不能になった,ちょっとダウンしてすぐ復帰した}場合のリカバリプランについて書きます。 今のところはこれがベストかなと思っているのですが、「こうしたほうがいいと思う！」「ここがおかしい！」などなどのご意見はコメント、TBなどでいただけるとうれしいです。 ゴール マスタが落ちてもぐーすか寝ていられるようにしたい リカバリの作業はできるだけ単純に、かつ、短時間で完了するようにしたい めんどくさいのはいや 基本構成、方針 2台＋1台 サービスで使うのは2台 (db1, db2) もう1台は管理用 (db3) スレーブを多数並べる構成にはしない 台数増えると管理コストが上がる マスタダウン時のフェイルオーバとそのフェイルバ
MySQLでレプリケーションのメモ - 記憶Log
まずマスター側でバイナリログの出力と識別IDの設定 MySQLのmy.cnfを設定 識別ＩＤはほかとかぶらないようにする [mysqld] log-bin ←バイナリログの設定 server-id=1 ←識別ＩＤMySQLを再起動 スレイブ側の識別IDを設定 [mysqld] server-id=2 ←識別ＩＤマスター側と同じようにmy.cnfを変更したらMySQLを再起動 マスター側にレプリケーションの権限ユーザ作成 スレイブ側からマスター側に接続する時のユーザ mysql> GRANT REPLICATION SLAVE ON *.* TO repl_user@99.999.99.999 IDENTIFIED BY 'repl_passwd'; ↑スレイブ側のIPを入れる Query OK, 0 rows affected (0.01 sec) マスター側のDBのバックアップ＆スレイブ
かっぱの金町Blog: テーブルタイプの変更はレプリケーションされるか実験
MySQL でデータベースをレプリケーションしている環境で、マスターのテーブルのテーブルタイプを、MyISAM から InnoDB に変更した場合にどうなるか実験君。 マスターの状態。 mysql> show table status\G *************************** 1. row *************************** Name: kappa_aho Engine: MyISAM Version: 9 Row_format: Fixed Rows: 4192 Avg_row_length: 5 Data_length: 20960 Max_data_length: 21474836479 Index_length: 1024 Data_free: 0 Auto_increment: NULL Create_time: 2
MySQL :: MySQL 8.0 リファレンスマニュアル :: 17.1.2.2 レプリカ構成の設定
各レプリカには、server_id システム変数で指定された一意のサーバー ID が必要です。 複数のレプリカを設定する場合、各レプリカの server_id 値は、ソースと他のレプリカの値とは異なる一意である必要があります。 レプリカサーバー ID がまだ設定されていない場合、または現在の値がソースまたは別のレプリカに選択した値と競合する場合は、それを変更する必要があります。 デフォルトの server_id 値は 1 です。 次のようなステートメントを発行して、server_id 値を動的に変更できます: SET GLOBAL server_id = 21; サーバー ID の値が 0 の場合、レプリカはソースに接続できません。 そのサーバー ID 値 (以前のリリースではデフォルト) が以前に設定されていた場合は、サーバーを再起動して、新しいゼロ以外のサーバー ID でレプリカを初期
レプリケーションを使う - Unlimited Island
レプリケーションとは、あるデータベースから他のデータベースに複製を作ることです。 これは通常、以下のような理由から使われます。 サーバがダウンしたときの対処 複数のデータベースが同じ内容を持つことで、一つのサーバがダウンしても 他のサーバを使うことが可能になります。 負荷分散 複数のデータベースを交互にアクセスすることで、一つのサーバに掛かる負担を減らすことが出来ます。 MySQLでは「一方向レプリケーション」を採用しています。 一つのサーバを「マスタ」として機能させ、残りのサーバが「スレーブ」になります。 データの複製は「マスタ→スレーブ」という方向でのみ行われます。 そのため、データの更新は必ずマスタサーバで実行する必要があります。 マスタサーバで更新を行うと、その更新内容が全てのスレーブサーバに通知され スレーブサーバはマスタサーバと同じ更新処理を行います。これにより、マスタとスレー
MySQLでのレプリケーションの設定 - KAWANO's PukiWiki
レプリケーションとは 通常、データベースを別のサーバに複製することを、「レプリケーション」という。 レプリケーションのメリットは、次のとおり。 データベースのバックアップ データベースの冗長化 サーバの負荷分散 MySQLは標準でレプリケーション機能を備えているが、 その方式は「マスタ-スレーブ方式」で、 データベースの更新を受け付ける「マスタ」と、 マスタから伝搬されたデータを受け付ける「スレーブ」からなる、 一方通行の複製になる。 細かいことは、参照先のページを見ること。 ▲ ▼ 今回の目的 まったく同一構成の2台のマシンがあるので、 1台をマスタ、もう1台をスレーブにして、 データベースのバックアップと冗長化をはかる。 ▲ ▼ レプリケーション用のユーザの作成 スレーブがマスタに接続するための専用ユーザを、マスタで作成する。 与える権限は「REPLICATION」「SLAVE」
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://blog.cloud.nifty.com/174/
現場指向のレプリケーション詳説