こんにちは。技術部の吉川です。 今回はクックパッドの開発環境構成、特に開発用データベースの構成についてご紹介します。 開発環境の構成 クックパッドのシステム環境は以下のようなフェイズに分かれています。 ※ これはcookpad.comの構成で、サブシステムや個別のサービスはその規模や特性に応じて構成が異なります。 development 開発者が実際に開発を行う環境です。クックパッドでは仮想環境は用いず、手元のマシンでRailsアプリケーションを動かして開発を行っています。 データベースはローカルではなく、開発者全体で共通の開発用データベースに接続しています。 test 手元でテストを実行する場合は、ローカルマシンのデータベースを利用します。CI（rrrspec）などの場合も同様で、テスト実行サーバーのデータベースが利用されます。 staging stagingといえば準本番環境として、本
MySQL 5.6 の検証中に MySQL 5.5 とは違うタイプのレプリケーション遅延を見つけたので紹介します。 MySQL のレプリケーションのおさらい MySQL のレプリケーションは次のような仕組みで動作しています。 マスターの更新トランザクションが binlog を書く スレーブの I/O スレッドがマスターに接続し、 binlog を取得し、 relaylog を書く. マスター側はスレーブからの接続を受け付けると(dump スレッド)、指定された場所から最新までの binlog を転送する binlog が追記されるのを待ってさらにスレーブに送る スレーブのSQLスレッドが relaylog を再生する MySQL 5.5 でよくあったレプリケーション遅延 マスターは並列してトランザクションを処理して、最終的にコミットした順で反映されれば問題ないようになっています。 一方、ス
よく行うのでメモ。 マスタとスレーブのホスト名を以下と仮定する。 マスタ： 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により可変。 更新があるたび(バイ
結論 Redisは2.6を使おう master-slave構成を取る場合はclient-output-buffer-limitをちゃんと意識するべき 概要 redisはエッジトリガ型のnon-blocking I/Oを用いてシングルスレッドでソケットの読み書きをぶん回す構造で書かれています。 よってclientやslaveへ対してのreplyを行う際も、ソケット自体の送信バッファが溢れた際(EAGAINが帰った際)には一度イベントループに処理を戻し、またソケットが書き込み可能になってイベントループが自分を呼んでくれた時に続きをwriteします。 まあnon-blocking I/Oなんだから当たり前なんですが、送信処理を再入可能にするためにredisはアプリケーションレベルで出力バッファを持っています。 これは送信が終わり次第適宜解放されるものの、write自体が間に合わなくなると詰まって
Klikbet77 Best – Platform Resmi Fitur Lengkap & Update Game Berhadiah Terbaru Klikbet77 Best menyediakan platform resmi dengan fitur lengkap, update game berhadiah terbaru, serta performa yang stabil. Cocok bagi pemain yang mencari kenyamanan, informasi akurat, dan pengalaman bermain yang optimal. Klikbet77 Be kind to each other. Hours: Wednesday-Thursday: 3-10pm Friday-Saturday: 12-10pm Sunday: 1
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
KlikBet77 Dalam Tren Hiburan Digital Modern Perkembangan hiburan online saat ini bergerak cepat, dari game kasual hingga platform interaktif yang menawarkan pengalaman bermain lebih seru. Salah satu fenomena yang banyak dibicarakan adalah KlikBet77, sebuah portal hiburan digital yang dikenal memiliki teknologi permainan terkini dan akses yang mudah bagi komunitas gamer dewasa. Halaman ini hadir un
@ymmt2005 こと山本泰宇です。 今回は memcached 互換で冗長構成を簡単に組める自社製 KVS である yrmcds のリリースをご案内します。 ... この Redis 全盛なご時世になんで？とか、repcached や Kyoto Tycoon があるじゃない、といったツッコミの嵐が聞えてきそうです。わかってます、わかってますから物を投げないで！ 順を追って説明しますので、批判はそれからにしてください！ 何が欲しいのか 私は日頃 cybozu.com のインフラで動作するソフトウェアを開発しています。リリース後もうすぐ２年になりますが、お蔭様で 4,000 社以上にご利用いただくまでになりました。商売繁盛で嬉しいのですが、運用側は日々増えるデータとアクセスを捌くべく奮闘しています。 ここのところ問題になっていたのが、MySQL に保存しているセッション情報でした。アプリ
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
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より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
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] 稼働中のMySQLに無停止でスレーブを追加する MySQLは簡単にレプリケーションすることができて便利。最初からレプリケーションを前提に構築するのは簡単にできる。しかし、実は運用が始まってしまって、なかなか停止できないMySQLにも、ほぼ無停止でスレーブサーバを追加できる。現在の設定状況にもよるが、再起動は必要になるかも。 マスターでバイナリログを出力するようにする my.cnfで、binlog_do_dbの設定をする。レプリケーション対象となるデータベースを指定する。 [mysqld] binlog_do_db=your_db マスタのserver_idを設定する my.cnf で server_idの設定をする。レプリケーションする際に、個々のサーバを識別するのに使われる。任意のユニークな整数を指定すれば良い。 [mysqld] server_id=10 ここまでの
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
