開発環境のデータをできるだけ本番に近づける - クックパッド開発者ブログ
こんにちは。技術部の吉川です。 今回はクックパッドの開発環境構成、特に開発用データベースの構成についてご紹介します。 開発環境の構成 クックパッドのシステム環境は以下のようなフェイズに分かれています。 ※ これはcookpad.comの構成で、サブシステムや個別のサービスはその規模や特性に応じて構成が異なります。 development 開発者が実際に開発を行う環境です。クックパッドでは仮想環境は用いず、手元のマシンでRailsアプリケーションを動かして開発を行っています。 データベースはローカルではなく、開発者全体で共通の開発用データベースに接続しています。 test 手元でテストを実行する場合は、ローカルマシンのデータベースを利用します。CI（rrrspec）などの場合も同様で、テスト実行サーバーのデータベースが利用されます。 staging stagingといえば準本番環境として、本
MySQL 5.6 でのレプリケーション遅延は危険 : DSAS開発者の部屋
MySQL 5.6 の検証中に MySQL 5.5 とは違うタイプのレプリケーション遅延を見つけたので紹介します。 MySQL のレプリケーションのおさらい MySQL のレプリケーションは次のような仕組みで動作しています。 マスターの更新トランザクションが binlog を書く スレーブの I/O スレッドがマスターに接続し、 binlog を取得し、 relaylog を書く. マスター側はスレーブからの接続を受け付けると(dump スレッド)、指定された場所から最新までの binlog を転送する binlog が追記されるのを待ってさらにスレーブに送る スレーブのSQLスレッドが relaylog を再生する MySQL 5.5 でよくあったレプリケーション遅延 マスターは並列してトランザクションを処理して、最終的にコミットした順で反映されれば問題ないようになっています。 一方、ス
MySQLダンプからの無停止スレーブ作成 - Sudix's Blog
よく行うのでメモ。 マスタとスレーブのホスト名を以下と仮定する。 マスタ： masterdb スレーブ： slavedb また、スレーブ対象のDBは以下とする。 some_db_production マスタ上のMySQLでの作業 レプリケーション用ユーザーの作成 まだ無ければ作っておく。この例だとどのホストからでも接続できるので、 必要に応じてIPアドレスでの制限をかけること。 1 2 mysql> GRANT REPLICATION SLAVE ON *.* TO repl_user@"%" IDENTIFIED BY 'hogehoge'; mysql> FLUSH PRIVILEGES; スナップショットの作成(取得しつつスレーブへ送る） ダンプを取りながら圧縮しスレーブDBに送り込む。データが多いと数時間かかる。 ここでは転送速度を優先させるため、暗号化方式を軽量のものしている。
MySQL 5.6のクラッシュセーフなレプリケーションの仕組み
MySQL 5.6のnutshellを読むと、`クラッシュセーフなレプリケーションを実現するためにはmaster_info_repositoryとrelay_log_info_repositoryをTABLEに設定しな！ おっと、relay_log_recoveryも1にしておくんだぜ'みたいことが書いてある。 で、このバグレポートを見た時からずっと、sync_master_infoの暗黙のデフォルト10000のまんまじゃクラッシュセーフじゃなくね？ sync_master_info= 1必須？ それはパフォーマンス的に死ねる。という感じでモヤモヤしていたのだが、やっと合点がいったのでメモしときます。 master_info_repository FILEの場合、従来どおりmaster.infoファイルに書く。 ファイル名はmaster_info_fileにより可変。 更新があるたび(バイ
レプリケーション時の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のスレーブサーバを別サーバに移設する時に注意すること · さよならインターネット
August 12, 2013 移設元のスレーブサーバのMySQLが停止できる場合 移設先のスレーブサーバで CREATE DATABASEして master.infoからreplユーザ作成して dumpファイルをバックアップサーバから持ってきて〜 などの作業を行わなくてもSLAVE STOPし MySQLを落とし変更が走らない状態にして MySQLのディレクトリを移設先にrsyncで渡した方が手間も処理速度も遥かに速い。 ただし、移設先でMySQLを起動してSLAVE STARTをすると Could not find target log during relay log initialization rellay.log このようにrelay_logが見つからないよ。というエラーが発生する。 16.2.2.1. The Slave Relay Log / MySQL 5.1 Refer
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-5.6のレプリケーション状況出力（SHOW SLAVE STATUS構文）をMySQL-5.0と比較する - Y-Ken Studio
MySQL-5.6ではSHOW SLAVE STATUS;の出力が大幅に変わりました。 嬉しいポイントとしては、Last_SQL_Error_Timestampというカラムが増えたことです。 これはレプリケーションエラーが起きた際、それが何時何分に起きたのかが分かるのです。 従来であればサーバのmysqld.logを確認する必要がありましたが、その必要はありません。 ますます進化したMySQL-5.6のSHOW SLAVE STATUS構文の出力結果を追ってみましょう！ どう変わったか MySQL-5.0ではSHOW SLAVE STATUSの結果は33行でした。 MySQL-5.1/5.5を経て、5.6では54行にも増えました。 新しい21のカラム 私が注目する、4つの新機能から紹介します。 遅延スレーブの動作状況が見える SQL_Delay SQL_Remaining_Delay De
MySQL5.6のマスターにMySQL5.5(とそれ以前)のスレーブをぶら下げるとエラる
ぱっと見、誰も書いてなさそうなので。 MySQL 5.6ではバイナリログのチェックサム(binlog_checksum)が追加され、 しかもそれが5.6.5以降デフォルトで有効になっているので、 5.5をスレーブにして構成するとI/O ThreadがErr:1236で止まる。 mysql55> SHOW SLAVE STATUS\G *************************** 1. row *************************** Slave_IO_State: Master_Host: localhost Master_User: replicator Master_Port: 64056 Connect_Retry: 60 Master_Log_File: bin.000007 Read_Master_Log_Pos: 4 Relay_Log_File: re
rowベースのレプリケーション時にステートメントもバイナリログに保存する - hiroi10のブログ
MySQL5.6からrowベースのレプリケーションを使用している場合でもステートメント(クエリ)をコメントとしてバイナリログに記録するオプション(binlog_rows_query_log_events)が追加されています。 このオプションを利用することでrowベースでレプリケーションされたクエリが確認し易くなります。 マニュアル binlog_rows_query_log_events 動作確認環境 CentOS 6.3 x86_64(KVMゲスト) MySQL 5.6.10 binlog_rows_query_log_eventsが無効な場合 mysqlbinlogコマンドに-vオプションを使う事である程度は把握が可能でした。以下例はbinlog_rows_query_log_eventsが無効な場合の表示例です。 テーブル定義と設定 mysql> show create table
MySQL-5.5/5.6でのレプリケーション利用者に伝えたい「RESET SLAVE」にまつわる怖い話 - Y-Ken Studio
MySQL-5.5よりRESET SLAVE;の挙動が変わり、直後にCHANGE MASTER構文を 発行しないと場合によっては問題が発生するとMySQLのドキュメントに記載されていました。 さらに、RESET SLAVE ALL;というクエリもサポートされたようです。 どういう事なのでしょう？ 調べてみました。 ドキュメントにさらっと何か書いてある In MySQL 5.6 (unlike the case in MySQL 5.1 and earlier), RESET SLAVE does not change any replication connection parameters such as master host, master port, master user, or master password, which are retained in memory. Thi
MySQL5.6とMySQL5.0のレプリケーションでI/OスレッドがError: 2049
MySQL5.6をスレーブに、old_passwords = 1なMySQL5.0をマスターにしてレプリケーションを組もうとすると、 mysql56> show slave status\G *************************** 1. row *************************** Slave_IO_State: Connecting to master Master_Host: localhost Master_User: replicator Master_Port: 64050 Connect_Retry: 60 Master_Log_File: bin.000019 Read_Master_Log_Pos: 820 Relay_Log_File: relay.000001 Relay_Log_Pos: 4 Relay_Master_Log_File
MySQL5.6のちょっとした話 - まめ畑
最近、とあるサービスの本番環境にMySQL5.6を導入していっています。社内だけの環境も含めて5システムに導入しました。 5.5からのアップデートや最初から5.6というものもあります。 今回、導入で変わった点いろいろありますが、メモ程度にまとめておきます。 間違いなどありましたら指摘していただけるとありがたいです。 Replicationエラー時 今までは、replicationのエラーが起こった場合は SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1; とかでダメなクエリを確認しつつSKIP出来ればしていましたが、5.6でGTIDモードONの場合、これが使えなくなりました。 GTID便利なんですが、この点少し不便です。 以下のように直します。 まず、slaveでmaster server UUIDと最新のGTID、Retrieved_Gtid_Setを確認します
MySQLでstatement-based replicationを使っている場合のtrigger, function, procedureの扱い - 愛と勇気と缶ビール
row-basedなreplicationの場合はreplicationの対象が文字通りrow=dataであるため特にtrigger, function, procedureの動作について懸念点はないと思われます。でも、MySQLで既に多くの人が使っているであろうstatement-basedなreplicationの場合はどうなるの？masterだけで実行されるの？それとも両方で実行されるの？両方で実行されるとしたらデータの整合性とかはどうなるの？ これらの疑問への答えはだいたい以下のドキュメントに書いてあるようですが、日本語版は「お前は何を言っているんだ」という部分が多々あり、英語版を読んでもあまり実際の動作がイメージできなかったので確認を兼ねて自分で試すことにしました。 http://dev.mysql.com/doc/refman/5.1/en/replication-featur
稼働中のMySQLに無停止でスレーブを追加する - 雑記帳(2011-10-17)
■ [MySQL] 稼働中のMySQLに無停止でスレーブを追加する MySQLは簡単にレプリケーションすることができて便利。最初からレプリケーションを前提に構築するのは簡単にできる。しかし、実は運用が始まってしまって、なかなか停止できないMySQLにも、ほぼ無停止でスレーブサーバを追加できる。現在の設定状況にもよるが、再起動は必要になるかも。 マスターでバイナリログを出力するようにする my.cnfで、binlog_do_dbの設定をする。レプリケーション対象となるデータベースを指定する。 [mysqld] binlog_do_db=your_db マスタのserver_idを設定する my.cnf で server_idの設定をする。レプリケーションする際に、個々のサーバを識別するのに使われる。任意のユニークな整数を指定すれば良い。 [mysqld] server_id=10 ここまでの
SQL_SLAVE_SKIP_COUNTERについて教えてもらったよ - 愛と勇気と缶ビール
何らかの理由でmasterとslaveの間で不整合があって、「既にテーブルがある」とか「UNIQUE制約にひっかかる」とかそういう理由でreplicationが止まっている時は、 SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1; start slave; show slave status; (確認)って風に一つスキップするんだよ、ってnekokakさんに教えてもらったよ。 普通は慎重を期して1つずつスキップするものらしいんだよ。 こんなのDBの運用とかバリバリやってる人にとっては当たり前かもしれないけど、そんなので一々恥ずかしがってたら前に進めないのでblogに書くんだよ。 で、MySQL 5.0の該当リファレンス↓ http://dev.mysql.com/doc/refman/5.0/en/set-global-sql-slave-skip-counter
MySQL DBマスタのDC間移設 | Ore no homepage
システムをデータセンターAからデータセンターBに論理移設を行うときのメモ。 肝になるのはDB、特にマスタDBだと思うので、主題の通りおもにDBマスタの切り替えに焦点を当てて手順を書く。 移設先であるデータセンターBではサーバ構築やアプリケーション/コンフィグのデプロイは完了していて、新マスタおよび全スレーブは現マスタにレプリを張っている状態からスタートする。新マスタにはバイナリログ出力など、DBマスタとして振る舞うための設定が入っているものとする。 手順の要約 現DBマスタへの更新クエリをすべてブロックする 全てのスレーブと新マスタでshow slave statusしてログとポジションが一致していることを確認する 新マスタと全てのスレーブでstop slaveする 新マスタと全てのスレーブでreset slaveする 新マスタでreset masterする 全てのスレーブでchange
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
MySQL :: MySQL 8.0 Reference Manual :: 19.5.1.36 Replication and Triggers
MySQL :: MySQL 8.0 Reference Manual :: 19.4.11 Delayed Replication
Chef mysql master/slave recipes