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 5.5で消耗してるの？MySQL 5.6でクラッシュセーフなレプリケーションを活用して枕を高くして眠れる日々を満喫する方法
MySQL 5.6が登場してからかなりの月日が過ぎたが、他のことで多忙だったせいか、MySQL 5.6についてはあまりブログで情報を発信していないことに気がついた。これはイカン！！と思い、MySQL Casual Advent Calendar 2014に合わせて、MySQL 5.6を使用する上で最もオススメしたい機能であるクラッシュセーフなレプリケーションについて解説しようと思う。この記事は16日目の記事である。 レプリケーションがクラッシュセーフとはどういうことかクラッシュセーフとは、何らかの事情により、プロセスがダウンしたりマシンが電源ごと落ちたり（つまりクラッシュ）しても、再起動後に以前の状態に戻って処理を再開できるということだ。データのクラッシュリカバリであればみなさん既によくご存知であろう。（REDOやUNDOするアレのことだ。本稿では面倒臭い・・・ではなかった、本題ではないた
MySQLにおけるレプリケーション遅延の傾向と対策
レプリケーションはMySQLで最もよく使われる機能のひとつだ。レプリケーションは基本的に非同期でデータの複製を行う仕組みになっているのだが、非同期故にどうしても逃れられない問題がある。そのひとつが今回のテーマ、遅延である。というと、MySQLのレプリケーションはすぐに遅延が生じてしまうように感じてしまうかも知れないが、そのようなことはない。ほとんどの場合は即座にスレーブの更新が行われる。 なぜ遅延は発生するのか、どのように遅延が起きていることを調べるのか、どのように回避するのかということを本エントリでは解説したい。うまく遅延と付き合って、MySQLのレプリケーションをより快適に運用してもらえればと思う。 そもそも遅延とは何かMySQLのレプリケーションは非同期で行われる。これは準同期でも同じであり、スレーブにおいて更新が起きるのはマスターよりも一瞬遅れてしまう。これは非同期であるが故に逃れ
PostgreSQLユーザのためのMySQLバイナリログ・レプリケーション講座 - interdb’s blog
Original Streaming Replication搭載のPostgreSQL9.0リリースが近づき、MySQLとのレプリケーション比較が今後ますます盛んになると思われるので、PostgreSQLユーザ向けにMySQLの説明を行う。 参考->MySQLユーザのためのPostgreSQL:WALログとレプリケーション講座 なお、なぜ最初に延々とバイナリログを説明するかといえば、MySQLのレプリケーションでマスタからスレーブに送るのは、バイナリログのデータだからである。 [レベル:1] MySQLのバイナリログ MySQLにはWALログに直接対応するものはない。理由はMySQLがマルチストレージエンジンだからである。 マルチストレージエンジンについては後述するのでここでは簡単に説明すると、 MySQLはトランザクション機能ありのInnoDB型というテーブルや、トランザクション機能なし
MySQLユーザのためのPostgreSQL:WALログとレプリケーション講座 - interdb’s blog
Streaming Replication搭載のPostgreSQL9.0リリースが近づき、 MySQLとのレプリケーション比較が今後ますます盛んになると思われるので、 MySQLユーザ向けにPostgreSQLの説明をしてみようと思う。 参考->PostgreSQLユーザのためのMySQLバイナリログ・レプリケーション講座 (2012.10.30追記)PostgreSQLのレプリケーションについては書籍にまとめたので参照のこと。 原稿のサンプル：仕組みと設定を公開したので参照。 [レベル:1] PostgreSQLのWALログ PostgreSQLには「WALログ」と呼ばれるREDOログ(トランザクションログ)がある。MySQLでいうところのInnoDBのinnodbログのことである*1。 なぜレプリケーションの説明に"WALログ"がでてくるかといえば、PostgreSQL9.0のレプリ
MySQLで参照の負荷分散を行うslaveは3台から構成するのがよいのでは - 酒日記 はてな支店
前回の記事 MySQLをmaster:slave=1:1構成にして参照をslaveに向けるのがなぜ良くないか の続きです。 master : slave = 1 : 1 で参照を slave に分散してもまったく美味しくないわけですが、では参照の負荷分散を行いたい場合の slave は何台で構成するとよいのか考察してみます。具体的には slave 2台の場合と 3台の場合でどちらがお得か。 台数を増やすということは、どこかに障害が発生する確率が高まる、ということです。1台の slave に障害が発生してダウンした場合のことを考えてみます。 slave * 2 → 残り 1台で処理継続 生き残った1台あたりの処理が 2倍になる slave * 3 → 残り 2台で処理継続 生き残った1台あたりの処理が 1.5倍になる たとえば 1台あたり最大 1000qps の処理能力があるとします。sla
MySQLをmaster:slave=1:1構成にして参照をslaveに向けるのがなぜ良くないか - 酒日記 はてな支店
MySQLのmasterとslave 1:1にして参照をslave向けるのってやりたがる人多いみたいだけど、性能たいして上がらない割に可用性落ちるだけだからやめようキャンペーン 2011-06-19 00:16:30 via YoruFukurou MySQL はレプリケーションが簡単に構成できるのですが、時折 master 1台 に対して slave 1台、更新処理は master に、参照は slave に、という構成を目にします。 個人的にはこの構成はお勧めでないと思っているので、その理由を考察してみます。 1. 可用性が落ちる 当然ですが、master, slave のどちらが落ちても影響を受けるために可用性が低下します。 2. 全体の性能がほとんど上がらない master 1台ですべてのクエリを処理する場合と比べて、可用性が落ちる引き換えとして見合った性能向上が得られるか、という
Slony-Iによるレプリケーションとオンラインリカバリ
last update: 27 Apr 2009 この記事は技術評論社『WEB+DB PRESS』の 『WEB+DB PRESS Vol.48』2008年12月刊 に掲載された原稿の草稿を、許可を得て公開しているものです。 また、日本PostgreSQLユーザ会の仕組み分科会で発表したWALとPITRの資料とpgpool-IIのオンラインリカバリに関する資料がありますので、こちらも参照してください。 本章では、Slony-Iによるレプリケーションシステムの構成方法と、オンラインリカバリを含むいくつかの運用テクニックについて説明します。 Slony-IはPostgreSQL専用の非同期型シングルマスタ・マルチスレーブのレプリケーションソフトです。 2003年頃からJan Wieck氏によって開発が始められ、2004年6月にバージョン1.0がリリースされました。 以降、現在まで順調に開発が進
DECOLOGでのMySQL BlackHoleエンジンの使い方
こんにちわ、ミツバチワークス stoneです。 DECOLOGでは、データベースにMySQLを使用しています。 ストレージエンジンのメインはInnoDBなのですが、他にもMyISAM、BlackHole、Archiveエンジンを使っています。 今回は、その中でBlackHoleエンジンについて、DECOLOG内での利用方法をご紹介したいと思います。 BlackHoleエンジンについて BlackHoleエンジンは、何もしません。 insert、update、deleteを行っても、データは全く変更されませんし、selectをしても、データは何も返ってきません。 実際のデータファイルを見てみても、テーブル定義ファイルの.frm以外のファイルは作成されません。 /dev/nullと似ているイメージです。 が、BlackHoleのテーブルに対して発行されたinsert、update、delete
mysqlのテーブルの「のれん分け」
大まかな手順は以下です。 三段構成にする。 slaveを切り替える masterを切り替える 余分なテーブルを落とす の4ステップです。 1.三段構成にする。 これはつまりこんな状態にすることをいいます。 この作業は基本的には単純なslave増設と新規レプリケーション構成を組むのの組み合わせでできるので、前回のエントリ「replicationしてるMySQLのslave増設手順」を参考にしてください。 通常のレプリケーション構築との違う、ポイントとしては テーブル構成は最初は丸ままコピーすること 「New master」my.cnfの設定にlog-slave-updatesとreplicate-do-tableでノレン分けしたいテーブルを設定しておくこと です。 テーブル構成を丸ままコピーするのは、そうしないとレプリケーションが失敗するからです。replicate-ignore-dbやre
主要なPostgreSQLクラスタ
はじめに 今回は、数多くのPostgreSQLクラスタから、代表的な4つのソフトを紹介します。 Slony-I pgpool-II Streaming Replication Hot Standby 1. Slony-I Slony-Iは、最も初期に開発されたPostgreSQLクラスタです。第1回の分類では、シングル・マスター型にあたります。開発したのは、PostgreSQLのコア・メンバーでもあるJan Wieck氏で、現在のバージョンは2.0.4です。 図1に、Slony-Iの動作概要を示します。Slony-Iでは、「トリガー」と呼ばれる手法を使っています。これは、テーブルの行を作成・更新・削除する場面で利用できます。行が作成・更新・削除される際に、特定の関数（トリガー）が呼び出されるようになっています。 Slony-Iでは、テーブルのデータが変更される度に、変更内容をトリガーを使っ
Art of MySQL Replication.
1. Art Of MySQL Replicaton 〜 10 年の歴史を誇るレプリケーションの妙技〜 奥野 幹也 @nippondanji mikiya (dot) okuno (at) gmail (dot) com 2. 免責事項 ● 本プレゼンテーションにおいて示されている見解は、 私自身の見解であって、オラクル・コーポレーション の見解を必ずしも反映したものではありません。ご了 承ください。 3. 自己紹介 ● 今日は個人として来ています。 – http://nippondanji.blogspot.com/ – Twitter: @nippondanji ● 現職は MySQL サポートエンジニア。 – 2000 年にサン・マイクロシステムズ入社 – 2007 年に MySQL KK へ転職 – 気付くとまたサン・マイクロシステムズに・・・ – 現在は日本オラクルに在席。 ●
54行で分散KVSを実装する（レプリケーション機能付き） - Blog by Sadayuki Furuhashi
Ruby と MessagePack-RPC があれば、簡単なkey-valueストレージは簡単に作れます。54行で書けます（レプリケーションと負荷分散機能付き。サーバー38行、クライアント16行）。 簡単なKVSをベースにして、ログ集計や遠隔デプロイ、遠隔管理機能などの機能を追加していけば、ちょっと便利なサーバープログラムをサクサク自作できるハズ。 この分散KVSは、（keyのハッシュ値 % サーバーの台数）番目のサーバーにkeyを保存します。また、サーバーの名前順でソートしたときの「次のサーバー」と「次の次のサーバー」にデータをレプリケーションします。 すべてのサーバーで同じ設定ファイルを使います。サーバーごとの設定は引数を自分のホスト名に書き換えるだけなので、デプロイが容易です。 MessagePack-RPC for Ruby を使うと、分散しないkey-valueストレージ*1は
KLab
ご指定のページが見つかりませんでした URLの変更、もしくはページが削除された可能性があります。 お手数ですが、以下のリンクから目的のページをお探しください。
マスターInnoDB、スレーブMyISAMが勧められない理由
MySQLにおいて、マスターをInnoDBにして、スレーブをMyISAMにすると幸せになれるという主張をよく聞くことがあります。マスターは耐障害性の高いInnoDBにする一方で、スレーブは耐障害性が低くても大丈夫なので、InnoDBのかわりに高速とされるMyISAMを使えば、可用性と性能の両方をバランス良く実現できる、という考えです。 しかし、多くの場合これで幸せになることはできません。マスターとスレーブでストレージエンジンを合わせた方が無難です。その理由を以下に示します。 ●MyISAMはテーブルロックになる マスターへの更新結果はバイナリログに更新系SQL文として書かれ、スレーブのI/Oスレッドによってリレーログとして同じフォーマットで記録され、スレーブのSQLスレッドによってその更新系SQL文がそのまま実行されます。この更新系SQL文は、当然ながらスレーブに対して発行されるSELEC
レプリケーションの遅延を計るシンプルな方法 - くるくるサーカス
MySQLでレプリケーションをするときに、必ず気になるのが master-slave間の遅延だと思います。 そこで、先日のDeNAさんのテクノロジーセミナーで開示していただいたネタをもとに簡単な遅延監視方法を実装してみました。 MySQLバージョン 5.1.23 binlog_format=MIXED まずmasterに以下のようなテーブルを作ります。databaseは適当に作ってください。 CREATE TABLE `replitimes` ( `No` int(10) unsigned NOT NULL AUTO_INCREMENT, `date` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, `ldate` timestamp NOT NULL DEFAULT '0000-00-00
KLab技術者ブログ:その10 レプリケーションいろいろ
全てのスレーブに固有のサーバIDを割り当てないといけない。 一つのスレーブにはマスターを一つだけ割り当てることができる。 一つのマスターに多数のスレーブを割り当てることができる。 スレーブはほかのスレーブのマスターになることができる。 がある。 だが、最初の規則は必ずしも正しいわけではない。 ■ レプリケーションの構成について 先ほどの規則に基づいて簡単なレプリケーションを構成例を挙げる。 ■ １つのマスターと複数のスレーブ 最も基本的なレプリケーション。 この構成が有効なのは、書き込みが少なくて読み出しが多い場合。 問題点としてはマスターからスレーブへの帯域幅である。
レプリケーションを使う - Unlimited Island
レプリケーションとは、あるデータベースから他のデータベースに複製を作ることです。 これは通常、以下のような理由から使われます。 サーバがダウンしたときの対処 複数のデータベースが同じ内容を持つことで、一つのサーバがダウンしても 他のサーバを使うことが可能になります。 負荷分散 複数のデータベースを交互にアクセスすることで、一つのサーバに掛かる負担を減らすことが出来ます。 MySQLでは「一方向レプリケーション」を採用しています。 一つのサーバを「マスタ」として機能させ、残りのサーバが「スレーブ」になります。 データの複製は「マスタ→スレーブ」という方向でのみ行われます。 そのため、データの更新は必ずマスタサーバで実行する必要があります。 マスタサーバで更新を行うと、その更新内容が全てのスレーブサーバに通知され スレーブサーバはマスタサーバと同じ更新処理を行います。これにより、マスタとスレー
MySQLレプリケーション備忘録 master.infoとrelay-log.info | Livingdeadの日記 | スラド
レプリケーションに際してスレーブ側では二つのスレッドが起動する。 これは SHOW PROCESSLIST\G で確認することができる。 マスタからのバイナリログを読み込むためのスレッドと リレーログを書き出すためのスレッドである。 前者は /var/lib/mysql/master.info に情報を保存する。 これにはマスタに接続するために必要なアカウント情報も記録されている。 パスワードも平文のまま記録されているのでパーミッションには注意が必要である。 後者は /var/lib/mysql/relay-log.info に情報を保存する。 ここにはそのリレーログにはマスタのバイナリログのどこまでが記録されているか、 またリレーログのどこまでを実行してスレーブのデータベースに反映させたかが記録されている。 両スレッドともに起動時にはこれらのファイルに記録されている情報をもとに レプリケ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
現場指向のレプリケーション詳説