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リレーログの仕様を学ぶ – OpenGroove
MySQLレプリケーションの実装にあたってはバイナリログの存在が不可欠。 そしてスレーブ側マシンにおいてはリレーログが不可欠である。 レプリケーションの処理におけるバイナリログとリレーログの相関について、 今一度まとめてみた。簡単に書くと以下のようになる。 マスタ側の更新系のクエリが、マスタのバイナリログに記録される。 ↓ ↓ ↓ スレーブのI/OスレッドがマスタのBinlog Dumpスレッドに接続し、 マスタのBinlog Dumpスレッドはバイナリログの内容を送信する。 ↓ ↓ ↓ スレーブのI/Oスレッドは、受け取ったマスタのバイナリログをリレーログに保存。 ↓ ↓ ↓ スレーブのSQLスレッドがリレーログからクエリを読み取って実行。 リレーログの挙動について今ひとつ理解していなかったのだが、オフィシャルサイト に以下のように書いてある。 リレーログはバイナリログと同じ形式なので、
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.ス
MySQL AB :: MySQL 5.1 リファレンスマニュアル :: 5.3.6 フェイルオーバでのマスタ切り替え
障害が発生した場合にマスタとスレーブ間でのフェイルオーバに対応する正式なソリューションは現在の段階ではありません。現在利用可能な機能内では、マスタとスレーブ (または複数のスレーブ) をセットアップし、状況を把握するためにマスタを監視するスクリプトを作成することが挙げられます。そのときには、アプリケーションとスレーブに障害を認識した場合にマスタを変更するよう指示します。 CHANGE MASTER TO ステートメントを使用して、いつでもスレーブにマスタを変えるように指示することが重要です。スレーブはマスタのデータベースがスレーブとの互換性を保持しているかどうかを確認することができないため、新しいマスタが指定するログと場所からイベントを実行し始めます。フェイルオーバの状況で、グループ内すべてのサーバが同一のバイナリ ログからの同一のイベントを実行しています。そのため、イベント元の変更がデー
STOP SLAVE SQL_THREAD – variable.jp [データベース,パフォーマンス,運用]
REPLICATION環境にてSLAVE側でバックアップする為の手順。 STEP１ マスタの処理要求を停止する。または mysqladmin を使用して完全に スレーブを停止する。 shell> mysqladmin stop-slave or 別の方法としては、レプリケーション SQL スレッドを停止して リレー ログ ファイルの処理を停止します。この方法は、 バイナリ ログのデータの転送を許可します。 この方法を活発なレプリケーション環境で使用すると、 スレーブ処理を再開をしたときにキャッチ アップ プロセスを スピードアップする可能性があります。 shell> mysql -e ‘STOP SLAVE SQL_THREAD;’ STEP２ FLUSH TABLES STEP３ データベースのバックアップ shell> mysqldump --all-databases > fulld
MYSQLレプリケーション設定 - エーエイチレフ linuxサーバー技術情報
MySQLのインストールが終了した２台がある状態より設定を開始します。 マスターとスレーブの２台がある状態からスタートです。 事前準備 事前に２台のサーバーのデータが同じである必要があります。 mysqldump等でダンプを行い、データベースが完全に同じ状態とします。 マスターの設定 設定ファイルの編集 vi /etc/mysql/my.cnf 以下のように編集 server-id = 1 ↓ server-id = 18 (←ユニークな適当な数字へ変更) また以下を設定ファイル内のどこかに追記(ある場合はそのままでOK) log-bin = mysql-bin アカウントの作成 レプリケーション用のアカウントをマスターに作成する。 このアカウントはREPLICATION SLAVE権限を持っている必要がある 以下はすべての接続を許す’repl’ユーザーを作成する例。(グ
MySQL :: MySQL 8.0 リファレンスマニュアル :: 17.1.6 レプリケーションおよびバイナリロギングのオプションと変数
この変数は、サーバー 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
MySQL :: MySQL 8.0 リファレンスマニュアル :: 17 レプリケーション
スケールアウトソリューション - 複数のレプリカに負荷を分散して、パフォーマンスを向上させます。 この環境では、すべての書込みおよび更新がソースサーバーで実行される必要があります。 ただし、1 つまたは複数のレプリカで読み取りが行われる場合があります。 このモデルでは、(ソースが更新専用であるため) 書込みのパフォーマンスを向上させる一方で、レプリカの数の増加に伴って読取り速度を大幅に向上させることができます。 データセキュリティ - レプリカはレプリケーションプロセスを一時停止できるため、対応するソースデータを破損させることなくレプリカでバックアップサービスを実行できます。 アナリティクス - ライブデータはソースで作成できますが、情報の分析はソースのパフォーマンスに影響を与えることなくレプリカで実行できます。 長距離データ分散 - レプリケーションを使用すると、ソースに永続的にアクセス
2008-04-11
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
KLab技術者ブログ:その10 レプリケーションいろいろ
全てのスレーブに固有のサーバIDを割り当てないといけない。 一つのスレーブにはマスターを一つだけ割り当てることができる。 一つのマスターに多数のスレーブを割り当てることができる。 スレーブはほかのスレーブのマスターになることができる。 がある。 だが、最初の規則は必ずしも正しいわけではない。 ■ レプリケーションの構成について 先ほどの規則に基づいて簡単なレプリケーションを構成例を挙げる。 ■ １つのマスターと複数のスレーブ 最も基本的なレプリケーション。 この構成が有効なのは、書き込みが少なくて読み出しが多い場合。 問題点としてはマスターからスレーブへの帯域幅である。
MySQLレプリケーションを安全に利用するための10のテクニック
MySQLのレプリケーションは非常に簡単に使える割には応用の幅が広いので非常に人気のある機能の一つである。レプリケーションの応用分野は例えば、 バックアップ 参照系の負荷分散 HA（高可用性） ディザスタリカバリ（サイト間レプリケーション） BI（レポーティングetc） という風にとても多くのバリエーションがある。このブログを読んで頂いている皆さんの中にもレプリケーションを使っている方は多いのではないだろうか。ご覧の通りMySQLのレプリケーション機能はミッションクリティカル分野でも利用されているが、レプリケーションの使い方が適切でないとシステムの安定稼働に支障を来してしまってDBAやシステム管理者の肉体的、精神的負担が増大してしまう。逆にレプリケーションを堅牢に運用することが出来ればマクラを高くして眠れるというものだ。レプリケーションはMySQLの代表的な機能であるので、レプリケーション
ウェブリブログ：サービスは終了しました。
「ウェブリブログ」は 2023年1月31日 をもちましてサービス提供を終了いたしました。 2004年3月のサービス開始より19年近くもの間、沢山の皆さまにご愛用いただきましたことを心よりお礼申し上げます。今後とも、BIGLOBEをご愛顧賜りますよう、よろしくお願い申し上げます。 ※引っ越し先ブログへのリダイレクトサービスは2024年1月31日で終了いたしました。 BIGLOBEのサービス一覧
MySQLレプリケーション設定 (unshiu)
概要データベース冗長化のためにDBをマスタとスレーブにわけ、更新はマスタで行い、参照はスレーブで行うことで負荷分散や高可用性を実現する機能です。 MySQLのレプリケーションは標準で搭載されており、非同期で行われマスタで更新されたログがスレーブへ送られます。 導入方法Mysql-5.1.26 インストール $ ./configure --prefix=/usr/local/mysql --with-charset=utf8 \ --with-extra-charsets=all --with-mysqld-user=mysql --with-innodb --with-partition $ make $ make install $ groupadd mysql $ useradd mysql -g mysql $ ./scripts/mysql_install_db --user=
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
MySQL :: MySQL 5.1 リファレンスマニュアル (オンラインヘルプ) :: 4.5.6.5 スレーブレプリケーションの I/O スレッド状態
mysql:9805
http://www.aip.de/~weber/doc/mysql/manual_Replication.html
一本道 期間限定スペシャルー無料お試し開始！
Movable Type | Movable Type Pro
現場指向のレプリケーション詳説