古くなったマスターDBを捨てる必要があったため下のページを参考にして手順まとめ。 MySQL :: MySQL 5.1 リファレンスマニュアル :: 5.3.6 フェイルオーバでのマスタ切り替え ほぼ、同じこと書いてますけど、仕事の作業だったので少しそこに手を加えました。 前提 マスターDBを停止してメンテナンスが行える 構成 マスターDB：host00 スレーブDB：host01,host02,host03 この内、host01を新マスターDBにする 以下まとめ。 スレーブDBがレプリケーションを終えているかチェック マスターDBから遅れがないか、全てが0になるまで確認したいので以下のコマンドを叩く for host in `echo host01 host02 host03`; do echo -n "$host: "; mysql -h $host -u replication --
ファーストサーバーといえば、ファーストサーバ岡田良介社長、新幹線で全裸になって逮捕とかファーストサーバ障害、深刻化する大規模「データ消失」の事案で有名な会社ですが、この会社の提供する共用サーバーもなかなかぶっ飛んでました。 VPSやクラウドサービスが浸透した現代では驚くほど時代遅れ且つ特殊です。 何も知らない私がいつものノリでLaravelアプリをファーストサーバーにデプロイしたら、全然まともに動かず、すごく苦労させられました。 私と同じような苦労をする方が出ないことを願って、その原因と対策方法を紹介します。 このお話に出てくるサーバーはファーストサーバーの共用サーバーで、PHPのバージョンは5.3.19です。 なんでそうした？PHPのconfigureオプション ./configure --enable-cgi --with-config-file-path=/usr/local/lib
wget https://dl.fedoraproject.org/pub/epel/6/x86_64/epel-release-6-8.noarch.rpm
サイバーエージェント公式ブログをご覧の皆さんこんばんは、インフラ＆コアテク本部の須藤(@strsk)です。普段はAmebaのソーシャルゲーム全般のインフラを見つつ、日本語ラップの啓蒙をしながら弊社社員を素材にコラ画像をつくったりしています。好きなAAは麻呂です。 はい、というわけで今回はMySQLインデックスチューニングの基本的な流れについてまとめてみました。 ソーシャルゲームは更新も参照もめちゃくちゃ多いです。数秒のレプリケーション遅延も致命的なので適切なテーブル、クエリとインデックス設計が重要です。（何でもそうですけど）インデックスが多くなると更新コストなどが懸念されますが、インデックスが正しく使われていないクエリを放置している方が悪です。そんなこんなで、割と例も偏ったりしてるかもしれませんがあしからず。 前提としてはInnoDBを想定しています。MyISAMはほとんど使っていません。
やってはいけない!!MySQLに悲鳴をあげさせる10の方法
いつも「MySQLを使うときはこうするべき」という観点から記事を書いているが、今日は逆に犯してはいけない過ちをリストアップしようと思う。 1. 全てのカラムにインデックスをつけるデータベース初心者がもっともやってしまいがちな間違いはコレではないだろうか。インデックスはいい。検索がとても速くなるから。しかし、それと引き替えにインデックスは更新するときにコストがかかるし、その分多くのディスクスペースを消費する。特に更新にかかるコストは時に甚大で、該当するインデックスのページがキャッシュ上にない場合はディスクからいったんそのページを読み込まなければいけない。ディスクアクセスは動作にとても時間がかかるので、インデックスが多数、例えば全てのカラムに付いていたりすると「あれ？固まったか？」というような状態になってしまうことがあるだろう。インデックスは必要なカラムにだけつけるようにテーブルを設計しよう。
第一回中国地方DB勉強会で発表したスライドをアップロードしました。
岡山でDB勉強会を開催するのだがMySQL 5.6の新機能について話して貰えないか。先月そのような提案をいただき、岡山までノコノコと顔を出してきた。JPUG（日本PostgreSQLユーザー会）主催かつ岡山という自分にとっては遠方の地で誰一人顔見知りが居ない中、若干緊張していたのだが、皆さん温かく迎えていただき楽しい時間を過ごすことができた。やはりデータベースを嗜む同士、通じ合うものである。皆さん勉強熱心で様々な質問、意見交換を通してとても勉強になった。大垣さんの発表もとても勉強になった。やはり「勉強会で発表すると自分が勉強になる」という法則が発動したように思う。 さて、MySQL 5.6の新機能について発表したのはこれが初めてではない。過去に発表したものに改良・修正を加えている。MySQL 5.6がリリースされてもう半年になろうとしているが、新機能は満載なので全てをキャッチアップしている
qpstudyで発表したスライドをアップロードしました。
本日、qpstudyで「データベースとは」という内容について、そして「リレーショナルモデルとは」という内容について話す機会を頂いた。リレーショナルモデルという硬い内容であったにも関わらず、出席者の皆さんには最後まで良い反応をして頂けたように思う。実はリレーショナルモデルについて誤解している、あるいは知らない人が本当に多い、そして良い解説書がないということを普段問題として感じており、そういった背景から今回qpstudyの話を引き受けさせて貰った。今回発表した内容が皆さんのお役に立てば幸いである。 発表の内容はほぼ現在WEB+DB PRESSで連載している「理論で学ぶSQL再入門」のいくつかの回のものを要約したものになっている。連載ではさらに詳しい内容について説明しているので、興味のある人はぜひWEB+DB PRESSのバックナンバー（連載はVol.68〜）を購入して頂きたい。 本日発表したス
CakePHPはよく触っていたものの、MySQLについてあまり知らなかったんですが、大規模なデータベースを扱ってみようと思い立ちいろいろ試行錯誤しています。 で、ついさっき感動したのが、40万件のレコードを扱ってるテーブルに簡単なSELECT分を投げて返ってくる時間がなんと5秒もかかっていて、なんじゃこりゃ？って首をかしげてたんですが、INDEXひとつで劇的に早くなったこと。 40万件が大規模かそうでないかはこの際おいておいて、INDEXのつけ方次第でこんなにも速度に変化があるのかと涙が出そうになった。 最初の激遅いテーブルは簡単に書くとこんな具合。 CREATE TABLE IF NOT EXISTS `shops` ( `id` int(10) unsigned NOT NULL AUTO_INCREMENT, `name` varchar(255) NOT NULL, `status
※写真と本文は関係ありません。 mysql 5.1 の my.cnf の書き方。『slow_query_log = ON』では設定が反映されない。 『slow_query_log = 1』と書く。 こんなふうに書いたら有効にならない。 [mysqld] slow_query_log = ON slow_query_log_file = /var/log/mysql-slow.log long_query_time = 0.1 mysql で show variables して確認。有効じゃない！！（他の設定は反映されてるのに…） mysql> show variables like 'slow%'; +---------------------+-------------------------+ | Variable_name | Value | +-------------------
MySQLでスロークエリログを記録する方法は、バージョンによって設定方法が異なったり、オプション名が変更されていたりと、意外と分かりづらいことが多いのでここでまとめておこうと思います。 いずれのバージョンでも、コンフィグファイル(Linuxでは my.cnf、Windowsでは my.ini)の mysqld セクションに設定を記述することになります。 MySQL5.0の場合 MySQL5.0の設定方法は簡単で、「log-slow-queries」にログを出力するファイル名を設定するだけです。 絶対パスによる指定も可能ですが、相対パスで指定した場合はデータディレクトリからの相対パスになります。 また、スロークエリとして記録されるクエリのしきい値、つまり何秒以上のクエリをスロークエリとしてログに記録するかはデフォルトで10秒以上となっています。 この値は「long_query_time」によ
今日は現状の力試しの為に渋谷区神宮の方へ面接へ行った。今日受験したのはファッション系のショッピングサイトだ。技術面で聞かれた内容は、 二重ループ時の計算量のオーダー MySQLのチューニング(バッファの容量) 英語の本は読めるか？ クラスタリングなど数学や統計に関する知識 CakePHPとMVCの概要、特定のメソッドのテストのやりかた の5つ。C言語(OpenCV)を使った事があるのなら経歴書に書きなさい(汗)。数学のできる人は需要があるよという貴重な意見を頂いた。質問の際に、 「データマイニングやりたいです」 「クラスタリングとかしってる」 K平均法*1とかですよね。 その概要は？ とその人がどれくらい技術の背景や概要を押さえているかを見積もる事が得意な面接官だった。又コンピューターサイエンスに詳しい方で、俺の実力が十分に追いついていれば大変有意義のある面接だった。適切なデータ構造の使い
MySQLを5.5にバージョンアップしました。 MySQLを起動すると、 Faildに！！！！ ログを調べてみたら「default-character-set」ってオプションて何？みたいなのが出てました。。 で、調べたら解決しましたのでメモ。 [mysql]MySQL 5.5.3-m3, 5.5.4-m3 同時リリース ここに書いてあるとおり、MySQLサーバのほうは 「default-character-set」というオプションが廃止されて、 「character-set-server」になった模様。 で、下記のようにmy.cnfを修正してMySQLを起動したら無事に再起動できました。 # vi /etc/my.cnf # default-character-set=utf8 ←ここはコメントアウト character-set-server=utf8 # ここを追加 ちなみ
MySQLアクセスを負荷分散する ユーザーからのアクセス数が非常に多いWebサイトにおいて、MySQLのSLAVEサーバーを複数台並べて負荷分散させるということがよく行われています。ただ、Webアクセスの負荷分散は一般的なテーマなのでいろいろなところで語られているのに対し、DBアクセスの負荷分散というテーマは一般的でないのかあまり語られていないように感じます。 DBアクセスを負荷分散するにあたって一番荒っぽい方法は、Webサーバー上のプログラムの中でどのSLAVEサーバーに接続するかをランダムで決める方法です。ランダムと言っても長時間アクセスしているとほぼ接続先が均等化されるので、一見この方法でも問題ないように見えます。しかしこの方法だと、接続しに行こうとしたSLAVEサーバーが高負荷もしくはサービス停止中であっても構わず接続しに行ってしまうという問題があります。 このような問題を解決する
これまでPublickeyではデータベースのスケーラビリティに関するさまざまなトピックを取り上げてきました。クラウド時代にはスケーラブルなデータベースのニーズがこれまでになく高まっているためです。 この記事では、これまで取り上げてきたデータベースのスケーラビリティに関する技術を少しまとめて紹介しようと思います。 従来のリレーショナルを拡張 従来のリレーショナルデータベースに対して、技術的工夫を凝らすことでスケーラブルなデータベースを実現しようというアプローチにも、さまざまなものがあります。 データベース研究者の大御所、マイケル・ストーンブレイカー氏は、リレーショナルデータベースは決して遅くないと主張。リレーショナルデータベースが遅い原因はロック、ラッチ、リソース管理にあるとして、それらを極力排除した「VoltDB」を開発しています。 NoSQLを上回る性能のVoltDB、そのアーキテクチャ
OSC 2011 Hokkaidoの発表で使用したスライド資料「大規模ソーシャルゲーム開発から学んだPHP＆MySQL実践テクニック」 2011年6月11日(土)に、「オープンソースカンファレンス 2011 Hokkaido」が開催されました。 弊社も協賛企業として参加しており、セミナー枠を1コマいただけましたので、 「大規模ソーシャルゲーム開発から学んだPHP＆MySQL実践テクニック」 という発表を行わせていただきました。 弊社が「ブラウザ三国志」や「英雄クエスト」といったゲームを、PHP＋MySQLで構築してきた上で、身につけたノウハウや、注意すべき箇所、指針などをまとめた発表となっています。 資料はslideshare上で公開しましたので、よろしければご覧ください。
MySQLのmasterとslave 1:1にして参照をslave向けるのってやりたがる人多いみたいだけど、性能たいして上がらない割に可用性落ちるだけだからやめようキャンペーン 2011-06-19 00:16:30 via YoruFukurou MySQL はレプリケーションが簡単に構成できるのですが、時折 master 1台 に対して slave 1台、更新処理は master に、参照は slave に、という構成を目にします。 個人的にはこの構成はお勧めでないと思っているので、その理由を考察してみます。 1. 可用性が落ちる 当然ですが、master, slave のどちらが落ちても影響を受けるために可用性が低下します。 2. 全体の性能がほとんど上がらない master 1台ですべてのクエリを処理する場合と比べて、可用性が落ちる引き換えとして見合った性能向上が得られるか、という
サーバを立てているとログに怪しいアクセスが出るのは日常的なことですが、とあるサーバにphpMyAdminクローラーの恐怖のログが残っていたのでシェアします。 Apacheのログを見ていたら下記のようなログを見つけました。 /path/to/www/ は apache のDocumentRoot です。 phpMyAdminを使っている方で、レンタルサーバ等を使っている場合、public_html 以下等に設置しているかと思いますが、クローラーは片っ端から存在しそうなパスを総当りしてきます。 URLが存在すれば200ステータスで検知してそこにphpMyAdminがあるみたいなことが分かってしまいます。(phpMyAdminだけ狙っているようでもなさそうですが) 仮に、MySQLのパスワードを設定していない人がいた場合はrootでDBを消されたり、データを盗まれたりする危険性があったのでシェア
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
