コマンド一つでMysqlを速くする - Qiita
稼働中のシステムであっても下記のコマンドを実行するだけで再起動等必要はないので、非常にお手軽に出来る。 デフォルトではinnodb_flush_log_at_trx_commit = 1 になっているはず。 1に設定するとトランザクション単位でログを出力するが 2 を指定すると1秒間に1回ログファイルに出力するようになる。 そのため、マスターDBが落ちて別スレーブに切り替わる仕組みを導入していても1秒の間に発生したトランザクションは完全にもとに戻す事が出来ない。 マスターDBの死 = サービス停止 みたいに冗長構成を持たせていないのならばこの設定にしても問題はなさそう。 mysqlslapでベンチマークを測ってみた。 テストの内容としては20クライアントから計10万回のINSERT文を実行するという内容で 結果として約3倍近く速くなっている。 innodb_flush_log_at_trx
innodb_support_xa と binlog の危ない関係 : DSAS開発者の部屋
昨日の記事 で innodb_support_xa = 0にすると RDS が速くなることを紹介したのですが、その後 Twitter で innodb_support_xa = 0 にするとクラッシュ時だけでなく通常時も binlog とトランザクションログの一貫性が無くなる（コミットする順序が前後する）可能性があることを指摘していただきました。 innodb_support_xa=0すると、トランザクションがコミットされた順番でバイナリログに載ることが保証できなくなるんだけどいいのかな？ DSAS開発者の部屋:AWS RDS の書き込み性能チューニング dsas.blog.klab.org/archives/52108… — ts. yokuさん (@yoku0825) 2013年4月24日 実際に、 MySQL 5.5 と 5.6 両方で、 innodb_support_xa の説明に
Amazon RDSのリードレプリカでClient requested master to start replication from impossible positionに出会う
Amazon RDSのリードレプリカでClient requested master to start replication from impossible positionに出会う マスターがMulti-AZ構成で、フェイルオーバーした時に、リードレプリカのI/Oスレッドが止まっちゃいました。 mysql56> SHOW SLAVE STATUS\G .. Last_IO_Errno: 1236 Last_IO_Error: Got fatal error 1236 from master when reading data from binary log: 'Client requested master to start replication from impossible position; the first event 'bin.000001' at 64056, the
ISUCON5 予選問題 参照実装ならびにベンチマーク等の公開 : ISUCON公式Blog
ISUCON5 の出題担当の一人、tagomorisです。みなさん予選はいかがでしたか？ 楽しめましたか？ 今回の準備をするにあたり、参考実装の準備などについて多くの協力を @najeira さん、 @hydrakecat さん、 @making さん、 @taroleo さんにいただきました。多くのみなさんが参加できたのはひとえにこの方々の協力があってこそだと思います。特に @najeira さんには予選直前の土壇場での動作確認・修正など非常にお世話になりました。本当にありがとうございました。決勝の準備でも、できればこれに懲りず、よろしくお願いします。次こそは余裕をもって準備します :P また共犯者というかメイン出題担当のもう一人 @kamipo さんにも大きな苦労をかけました。いつもすまないねえ……。 今回の予選はいろいろと不手際が多く、特にNode.js実装が土壇場で用意できないとい
モバイル広告を使うDDoS攻撃発生、毎秒27万超のHTTPリクエスト
スマートフォンなどのモバイル端末に配信される広告を悪用したと思われる新手の分散型サービス妨害（DDoS）攻撃が確認された。標的に対してピーク時で毎秒27万5000以上のHTTPリクエストが送り付けられていたという。セキュリティ企業の米CloudFlareが9月25日のブログで明らかにした。 それによると、これまでのDDoS攻撃にはPythonやRubyなどのスクリプトが使われるのが典型だったが、CloudFlareが調べたところ、今回の攻撃ではWebブラウザ経由で65万のユニークIPから大量のリクエストが特定の標的に送り付けられていたことが判明。ピーク時のリクエストは毎秒27万5000件超、1日で45億件に上った。 このうち99.8％は中国から来ていて、80％はモバイル端末が発信源だった。原因は中国で人気のモバイルアプリやモバイルブラウザに表示された広告だったと思われる。 この攻撃には広告
ISUCON5予選 2位で通過しました - 考える人、コードを書く人
ISUCON5予選に@kazeburo、@shmorimo、@cubicdaiya(敬称略)の3人でチーム「GoBold」として参加してきました。 isucon.net 15時過ぎるくらいまではスコアが伸び悩んでいましたが、結果的に2位でフェニッシュすることができました。 以下はスコアの遷移をグラフ化したものです。 GoBoldスコア遷移のグラフ #isucon pic.twitter.com/JKkfjiVJnS— Shigeki Morimoto (@shmorimo) September 28, 2015 準備と方針 今回は予選に臨むにあたって事前に以下の準備を行いました。 Wikiで各種ミドルウェアの定石設定テンプレートを共有 Slackでプライベートグループを作成 各人個別にGCE上でISUCON4予選問題(Ubuntu)の復習 次に事前に軽く打ち合わせして使用言語などの方針を固
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
