MySQLのDRBD構成におけるネットワーク遅延の影響について - SH2の日記
今さらですが、Amazon RDSのマルチAZデプロイメントについて調べていました。マルチAZデプロイメントとは、独立した電源、空調、ネットワーク、セキュリティを備えた物理的に異なるロケーションに対して同期レプリケーションを行うことで、データベースの耐障害性を高める機能です。AZはAvailability Zoneの略です。 異なるロケーションに対する同期レプリケーションと聞くと、性能が出ないのではないかという懸念がどうしても出てきます。そこで、どの程度性能が落ちるものなのか検証を行いました。なお、すでに実際のAmazon RDSを利用して検証を行った方がいらっしゃいましたので、今回は手元の環境を利用して、ネットワーク遅延やMySQLパラメータと性能との関連性を確認していきたいと思います。 Amazon RDS MYSQL Performance Benchmarking - Cloud
MySQLのreplication時に起こる、double free or corruption について - 基本へ帰ろう
環境 OS CentOS 6.0 (動作はMac OS X 10.6.8 上の VMWare Fuction) MySQL MySQL-client-5.5.17-1.linux2.6.i386, MySQL-devel-5.5.17-1.linux2.6.i386, MySQL-server-5.5.17-1.linux2.6.i386, MySQL-shared-5.5.17-1.linux2.6.i386 （2011/10/26時点で最新） CPU Intel(R) Core(TM) i7 CPU 870 @ 2.93GHz メモリ 2GB （割り当てメモリ） ※Master, Slave共に同じです。 MySQL設定 Master my.cnf [mysqld] skip-character-set-client-handshake character-set-serve = ut
MySQLにおけるレプリケーション遅延の傾向と対策
レプリケーションはMySQLで最もよく使われる機能のひとつだ。レプリケーションは基本的に非同期でデータの複製を行う仕組みになっているのだが、非同期故にどうしても逃れられない問題がある。そのひとつが今回のテーマ、遅延である。というと、MySQLのレプリケーションはすぐに遅延が生じてしまうように感じてしまうかも知れないが、そのようなことはない。ほとんどの場合は即座にスレーブの更新が行われる。 なぜ遅延は発生するのか、どのように遅延が起きていることを調べるのか、どのように回避するのかということを本エントリでは解説したい。うまく遅延と付き合って、MySQLのレプリケーションをより快適に運用してもらえればと思う。 そもそも遅延とは何か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.ス
レプリケーション時のRESET MASTERとRESET SLAVE – OpenGroove
さっそく一部追記（2010/04/14)。 MySQLレプリケーションにおいて発行するコマンド、RESET MASTERとRESET SLAVE、 それぞれの動作・挙動についてうっすらとまとめておく。なお、どちらもスレーブ側で 実行するという前提で話を進める。 RESET MASTER RESET MASTER文はスレーブがマスタに昇格するフェイルオーバー時に発行する。 これにより、スレーブはマスタのバイナリログを読みに行くのをストップする。 具体的には以下の状態になる。 バイナリログインデックスファイルを空白にリセット。 インデックスファイルにリストされたすべてのバイナリログを削除。 バイナリログがすべて消えてなくなるのではなく、例えばbin-log.000019まであった バイナリログはリセットされ、bin-log.000001のみが存在する状態になる。 RESET SLAVE RES
MySQL構築（スレーブ構築-mysqldump方式） - のんびりSE備忘録 @ ウィキ
RPMインストール # rpm -ivh --nopost MySQL-server-advanced-gpl-5.1.30-0.rhel4.x86_64.rpm # rpm -ivh MySQL-client-advanced-gpl-5.1.30-0.rhel4.x86_64.rpm 1. マスターのデータをダンプする。 # mysqldump -uユーザ名 -pパスワード \ --all-databases --master-data=2 \ --single-transaction --flush-logs > dumpfile.sql 2. マスター上にレプリケーション用のユーザを作成する。 mysql> GRANT REPLICATION SLAVE ON *.* TO 'レプリケーションユーザ名'@'スレーブのホスト名' IDENTIFIED BY 'パスワード'; 2. レ
勝手に図解するmemcached
先日、Brian Akerとミクシィの前坂氏によるmemcachedのセミナーがあった。 実践で使用する上での話や開発最前線の話が聴けたため、セミナーは非常に盛況であった。筆者にとっても非常に勉強になる内容だった。セミナーの資料はBrian Aker氏のサイトから入手できるのでセミナーに参加出来なかったひとはこの資料を読んで自習して頂きたい。 が、いかんせん氏のスライドはパッと見ただけではなんとなく分かりづらいように俺は思う。なぜだろうか？それはきっと図がないからだ・・・と勝手に想像する。オトコたるもの、時には勝手な憶測で突き進むのもアリだ。ちなみにBrianのスライドはほとんど要点の箇条書きになっている。これでは解説がないと、特に新規にmemcachedやMySQLを学習している人たちには分かりづらいだろう。 というわけで氏に代わり、memcachedがどのように既存の仕組みを置き換える
マスターInnoDB、スレーブMyISAMが勧められない理由
MySQLにおいて、マスターをInnoDBにして、スレーブをMyISAMにすると幸せになれるという主張をよく聞くことがあります。マスターは耐障害性の高いInnoDBにする一方で、スレーブは耐障害性が低くても大丈夫なので、InnoDBのかわりに高速とされるMyISAMを使えば、可用性と性能の両方をバランス良く実現できる、という考えです。 しかし、多くの場合これで幸せになることはできません。マスターとスレーブでストレージエンジンを合わせた方が無難です。その理由を以下に示します。 ●MyISAMはテーブルロックになる マスターへの更新結果はバイナリログに更新系SQL文として書かれ、スレーブのI/Oスレッドによってリレーログとして同じフォーマットで記録され、スレーブのSQLスレッドによってその更新系SQL文がそのまま実行されます。この更新系SQL文は、当然ながらスレーブに対して発行されるSELEC
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
株式会社TAP