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 でよくあったレプリケーション遅延 マスターは並列してトランザクションを処理して、最終的にコミットした順で反映されれば問題ないようになっています。 一方、ス
KLab Advent Calendar 2011 「DSAS for Social を支える技術」 : DSAS開発者の部屋
DSAS Blog もアドベント・カレンダーをはじめます。 最近日記をサボりがちでしたが、平日は毎日更新がんばります。 12/1: MySQL を PDO で使うときは ATTR_EMULATE_PREPARES を設定しよう 12/2: クエリキャッシュは切ったほうがいいんじゃなイカ？ 12/5: SHOW FULL PROCESSLIST を使った MySQL のプロファイリング 12/6: JavaScriptでつくる量子コンピューター 12/7: DSAS for Social での MySQL のボトルネックと今後の方針 12/8: ソーシャルアプリのボトルネック調査例（strace編） 12/9: php のプロセス数を絞ろう 12/12: 高負荷でも安定したサービスを提供するためのリバースプロキシ 12/13: 過負荷をかわす Apache の設定 12/14: Apache
MySQL を PDO で使うときは ATTR_EMULATE_PREPARES を設定しよう : DSAS開発者の部屋
「DSAS for Social を支える技術」 というネタでadvent calendar に挑戦します。 methane です。 PDOで MySQL を使うときは、みなさん $stmt = $con->prepare("..."); して $stmt->execute($values); とかしてプリペアドステートメントを利用されていると思います。 実は、このプリペアドステートメント、パフォーマンス的にはあまり良くありません。1つのクエリを実行するために、プレースホルダ付きのクエリを投げた後に、それに値をバインドして実行するコマンドを投げるので、1回のクエリを実行するのに2往復の通信が必要になるのです。 プリペアドステートメントにはパフォーマンスの利点（同じクエリを何度も発行するときにDBサーバーがクエリの解析を繰り返さないでもすむ）というものと、SQLインジェクション対策になる（正
過負荷をかわす Apache の設定 : DSAS開発者の部屋
KLab Advent Calendar 2011 「DSAS for Social を支える技術」の9日目です。 前回は php を動かしている Apache の手前にリバースプロキシを 置く必要性を解説しました。 今日は、 その前の php のプロセス数を絞る設定と合わせて、実際に Apache で 設定する方法を紹介します。 以降、 php を動かしている Apache の事をアプリサーバー、リバースプロキシ＋ 静的ファイル配信を行っている Apache の事をプロキシサーバーと呼びます。 基本設定 まずは基本的な設定のおさらいです。 アプリサーバー 並列数を絞るには MaxClients を設定します。アプリがどれくらいの時間を CPUの処理で使って、どのくらいの時間を外部リソース待ちに使っているかにも よりますが、だいたいCPU数の1.5倍〜2倍くらいが適当だと思います。 Hyp
DSAS開発者の部屋:keepalivedの運用ノウハウお見せします 〜 設定ファイルを同期する
keepalivedはLinuxで冗長構成を組む道具としてとても便利ですが、運用面に関する配慮に物足りなさを感じることがあります。例えばIncludeがないとかIncludeがないとかIncludeがないとか（笑） naoyaの日記でnaoyaさんも悩んでいるようですが、設定ファイルをうまく保守する仕組みをどう作るかが導入する際の大きな鍵になると思います。今回は、DSASではどのようにして2台のkeepalivedを運用しているかを少しだけご紹介させて頂きたいと思います。 1) マスターで設定ファイルを編集する 2) バックアップに設定ファイルを転送する 3) バックアップで設定を反映する 4) マスターとバックアップの差分を確認する 5) マスターで設定を反映する 具体的にはどのようにしているかというと、、、 lv1:# vi 設定ファイル lv1:# lvs-sync -ine lv1
DSAS開発者の部屋:5分でできる、MySQLのメモリ関係のチューニング！
MySQLのチューニングにおいて非常に重要となるメモリ(バッファ)関連のパラメータについて、 チューニングのポイント DSASのとあるDBサーバ(実メモリ4GB)の実際の設定値 をまとめてみます。 また、必要メモリの総量の計算や限界値を越えてないかチェックしてくれるスクリプトも紹介します。 是非、参考にしてみてください！ まず最初に注意点を。 バッファには2つのタイプがあります。 グローバルバッファ スレッドバッファ グローバルバッファはmysqld全体でそのバッファが1つだけ確保されるもので、 これに対し、 スレッドバッファはスレッド(コネクション)ごとに確保されるものです。 チューニングの際にはグローバル/スレッドの違いを意識するようにしましょう。 なぜなら、スレッドバッファに多くのメモリを割り当てると、コネクションが増えたとたんにアッという間にメモリ不足になってしまうからです。 in
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
