タグ

mysqlに関するk1mのブックマーク (21)

  • DSAS開発者の部屋:5分でできる、MySQLのメモリ関係のチューニング!

    MySQLのチューニングにおいて非常に重要となるメモリ(バッファ)関連のパラメータについて、 チューニングのポイント DSASのとあるDBサーバ(実メモリ4GB)の実際の設定値 をまとめてみます。 また、必要メモリの総量の計算や限界値を越えてないかチェックしてくれるスクリプトも紹介します。 是非、参考にしてみてください! まず最初に注意点を。 バッファには2つのタイプがあります。 グローバルバッファ スレッドバッファ グローバルバッファはmysqld全体でそのバッファが1つだけ確保されるもので、 これに対し、 スレッドバッファはスレッド(コネクション)ごとに確保されるものです。 チューニングの際にはグローバル/スレッドの違いを意識するようにしましょう。 なぜなら、スレッドバッファに多くのメモリを割り当てると、コネクションが増えたとたんにアッという間にメモリ不足になってしまうからです。 in

    DSAS開発者の部屋:5分でできる、MySQLのメモリ関係のチューニング!
  • Technical Presentations

    All of Percona’s open source software products, in one place, to download as much or as little as you need.

  • mysql を高速化したいときに読むメモ (TechKnowledge)

    給料の振込口座として三井住友銀行に口座を持っています。自動支払いサービスを使用して光熱費等の公共料金の支払いをしていますが、先日それらの内の一つを失念してたことに気づきました。口座を確認した時にはすでに引き落としが完了していたため、手元の資金が心細くなった状態で数日を過ごさなければなりません。三井住友銀行で即日キャッシングが可能であれば、是非利用したいのですが。 運が良ければ、三井住友銀行の即日キャッシングは可能 三井住友銀行の特徴はまずクレジットカード会社との連携したサービスが魅力的なことがあげられます。キャッシングでは銀行カードローンですから、何より安い金利が大きい利点になります。概ね銀行系の審査に必要な時間は長くなるようですが、三井住友銀行ではカード発行が当日に行なってくれます。 三井住友銀行は即日キャッシングができるかと言うと微妙なことになります。申込から審査結果の連絡までは、土日

  • naoyaのはてなダイアリー - MySQL の負荷分散に LVS + keepalived を使う

    あとで書く、と言った手前なので書くとします。 DSASの中の人がすごい勢いで LVS の話を書いてくれてます。この辺。LVS を使うと Linux と箱でロードバランサが作れちゃいます。普通に買ったら数百万とかしちゃうやつ。 DSAS の中のひとに感謝しつつ、いい機会なのでやってみよう! と思っていろいろ試して昨日あたりからはてなの中でも LVS + keepalived で動かしはじめてます。いまのところ問題なし。 そのロードバランサをどこに使ってるかですが、普通ロードバランサというとインターネットからの入り口のところに置いてウェブサーバーの負荷分散に使うイメージがあります。が、今回ははてなでは MySQL のスレーブの手前に置くという役割でとりあえず使いはじめました。 +-----------+ +-----------+ | mod_perl | | mod_perl | +----

    naoyaのはてなダイアリー - MySQL の負荷分散に LVS + keepalived を使う
  • mysqldump2email公開 - Ogawa::Memoranda

    MySQLデータベースのダンプファイルをzipアーカイブして、メールサーバに送る、わりとアリガチなスクリプトを必要に迫られて書いたのでついでに公開。 mysqldump2email.ja JP - Ogawa Code mysqldump2email - Ogawa Code (English) 手前味噌だけど結構便利。ダンプデータを平文メールで送るのに抵抗を感じるので、zipのencryption機能も使えるようにしてある。1時間おきに意味なくダンプしたりすると、Gmailのスプールと言えどもみるみる埋まっていってユカイ。 例によって試してはいないけど、Gmailの30日でexpireするTrash機能と組み合わせると、バックアップとしての実用度がさらに高まるかもしれないと思った。例えば、 username+daily@gmail.com宛に毎日ダンプする。Gmailの設定でこのアドレ

  • naoyaのはてなダイアリー - MyISAM vs InnoDB

    あくまで憶測で仮説でしかないんですが。 MySQL のストレージエンジンのうち代表的な二つ、MyISAM と InnoDB はよく MyISAM: Read は速いけどテーブルロックのため並行性が低い。運用が簡単。 InnoDB: MyISAM より Read は遅いけど並行性が高い 。行レベルロックなので。あとトランザクションや外部キー制約。運用が MyISAM よりちょっとめんどくさい。 という区別がされます。ここから転じて、 MyISAM は参照系クエリが大部分を占める場合に適用すると良い。例えば blog アプリケーションとか。 InnoDB は更新系クエリが多い場合に適用すると良い。 と言わたりします。実践ハイパフォーマンスMySQL でも第2章 ストレージエンジン(テーブル型) P.30 に アプリケーションでトランザクションを使用する必要がなく、主に SELECT または I

    naoyaのはてなダイアリー - MyISAM vs InnoDB
    k1m
    k1m 2006/09/13
    参照割合高では MyISAM, という選択に一石
  • BKCon 2006 - にぽたん研究所

    昨日は BKCon 2006 に行ってきた。 BK というのは「一般的にはバッドノウハウの事」なんですが、昨日のは、BKCon と言っても、かつて開催された Bad Knowhow Conference 2004 の続編とかではなく、"B"atara "K"esuma "Con"ference 2006 です。 ※正しくは横浜 Linux ユーザグループ主催の「第 65 回カーネル読書会」のテーマ "mixi.jp: Scaling Out With Open Source" です。 ちなみに、Batara Kesuma さんというのは、株式会社ミクシィの取締役。 mixi の裏側を見せますというか、ちょっと hip な言いかたをすれば "Inside mixi's backend" ってカンジです。 とりあえず、プレゼン内容は YAPC::Asia の時と大凡同じでしたが、プレゼンの持ち

    BKCon 2006 - にぽたん研究所
    k1m
    k1m 2006/09/13
    "B"atara "K"esuma "Con"ference 2006 概要
  • tokuhirom blog

    Blog Search when-present<#else>when-missing. (These only cover the last step of the expression; to cover the whole expression, use parenthesis: (myOptionalVar.foo)!myDefault, (myOptionalVar.foo)?? ---- ---- FTL stack trace ("~" means nesting-related): - Failed at: ${entry.path} [in template "__entry.ftlh" at line 3, column 25] - Reached through: #include "__entry.ftlh" [in template "entry.ftlh" at

    k1m
    k1m 2006/09/13
    メールアドレスが
  • [Vol.2] RailsとMySQLによる大規模サイト構築実験

    vol2でも引き続き、負荷分散・高可用性を備えるDBとWEBアプリケーションフレームワーク(以下AF)のセットアップを目指します。 デュアルマスタ構成に複数台のスレーブがぶら下がっています。 もう少し、詳しく今考えているアーキテクトを見ていきたいと思います。 最小構成: マスタ2台, スレーブ1台 最低3台のDBを用意します。 なぜ3台か?スレーブを追加する際には、マスタのスナップショット取得のためにマスタへの更新を停止する必要があります。データ量が増えると、マスタを停止してスナップショットを取得するには、長時間を要するため、これは現実的な解ではない。 そこで、スレーブをマスタのスナップショットとして考え、スレーブへのレプリケーションを一時停止し、スレーブのスナップショットを新規に用意したスレーブにコピーしレプリケーションを設定する。 スレーブが1台しか存在しない場合でのスレーブ停止時は、

    [Vol.2] RailsとMySQLによる大規模サイト構築実験
  • MySQL :: MySQL 4.1 リファレンスマニュアル :: 2.3.6 MIT-pthreads に関する注意事項

  • 1人で稼ぐ日記 | MySQL:1台しかない環境でエセ負荷分散

    MySQLのネタ。 1台しかない環境でエセ負荷分散を行う。 MySQLで負荷分散を考えたとき、 1台目にマスターのDBサーバー、 2台目以降をスレーブのDBサーバーとして用いる。 マスターは更新系のみのSQL文を、 スレーブは参照系のみのSQL文を投げる。 こんな負荷分散を1台のサーバーで行う必要が出てきた。 現在1台でやっていて、ディスクIOが追いつかずに捜し求めた結果、下の形で落ち着いた。 1つのテーブルでインデックスを含めたサイズが 30MB〜100MBほどで安定している、という条件があるのですが かなり負荷下がります。 ※上記サイズは搭載メモリサイズによって変わります -------------------------- ■やりかた 負荷が高いテーブルをAとする 1:Aと同じテーブル構成で、エンジンをMEMORY(he

    k1m
    k1m 2006/09/13
    メモリ上にもうひとつ立てて,両方更新せよって主張。検索はオンメモリで。
  • MySQL関連の書籍の決定版と言えば!

    Blog Search when-present<#else>when-missing. (These only cover the last step of the expression; to cover the whole expression, use parenthesis: (myOptionalVar.foo)!myDefault, (myOptionalVar.foo)?? ---- ---- FTL stack trace ("~" means nesting-related): - Failed at: ${entry.path} [in template "__entry.ftlh" at line 3, column 25] - Reached through: #include "__entry.ftlh" [in template "entry.ftlh" at

    k1m
    k1m 2006/09/13
    「実践ハイパフォーマンスMySQL」と「MySQL全機能リファレンス」
  • mysql_auto_reconnect : blog.nomadscafe.jp

    mysql_auto_reconnect FemoはFastCGIで動かしているのですが、FastCGIで最後に悩んだのは、しばらくアクセスがないと(開発中など)MySQLのコネクションが切れて、 Caught exception in engine "DBD::mysql::st execute failed: MySQL server has gone away などとエラーがでてしまうところです。再接続してくれません。 いままで気にもしなかったのですが、普通のCGIやmod_perlで動かしている場合には、DBD::mysqlみるとmysql_auto_reconnectというフラグが自動的にOnになります。 FastCGI(Catalystの方?)では$ENV{GATEWAY_INTERFACE}も$ENV{MOD_PERL}もないので、どうもmysql_auto_reconnec

    k1m
    k1m 2006/09/13
    FastCGI 時は mysql_auto_reconnect
  • flashmyadmin.org - このウェブサイトは販売用です! - flashmyadmin リソースおよび情報

    This webpage was generated by the domain owner using Sedo Domain Parking. Disclaimer: Sedo maintains no relationship with third party advertisers. Reference to any specific service or trade mark is not controlled by Sedo nor does it constitute or imply its association, endorsement or recommendation.

    k1m
    k1m 2006/09/13
    へぇ.もう phpmyadmin はいらない(のか?)
  • mysql:12306

    From: "Shuichi Tamagawa" <"Shuichi Tamagawa" <tamagawa@xxxxxxxxxx>> Date: Thu, 27 Oct 2005 18:31:47 +0900 Subject: [mysql 12306] 玉川です。 http://www.mysql.gr.jp/mysqlml/mysql/msg/9530 で話題になっていたように、 ver. 4.1以降、クライアント/サーバー間でキャラクターセットが自動的に 変換されるようになったことに伴い、多くの方が文字化けといった問題に 悩まされていたかと思います。 この点については開発側に改善を要求してきましたが、4.1.15にて "--skip-character-set-client-handshake" というオプションが導入されました。 http://dev.mysql.com/doc/

    k1m
    k1m 2006/09/13
    ほう。
  • MySQL 新バージョン 5.0.15 (5.0.x系正式版)がリリース!

    最近、お仕事でデータベース絡みのことが多くて、必然的にデータベースの話題に引っ張られる今日この頃です。 さて、業でも MySQL は検索用途に用いているのですが、当然ながら今までは ver 5 系は正式リリースでないので ver 4.1 系を使っているのですが、この度めでたく ver 5.0 系列の正式版として 5.0.15 がリリースされました。今回の目玉は何と言っても、ビューとトリガーとストアドプロシージャのデータベース3種の神器?が MySQL にも搭載されたことでしょう。 MySQL Lists: mysql-ja: 5.0製品版リリースにリリースの日語訳があるので読んでみると、一通りの新機能について知ることができます。主な新機能を列挙すると、 SQL 2003 準拠のストアドプロシージャ、ストアドファンクションを実装 トリガーを実装 ビューを実装 サーバサイドカーソル機能を実

    k1m
    k1m 2006/09/13
    すごく‥‥速い‥‥のかな
  • 現場指向のレプリケーション詳説

    この文書は、技術評論社刊『WEB+DB PRESS Vol.22』に執筆した記事を技術評論社の 許可を得てWWWで公開しているものです。 このWWW版は校正前の原稿を元にしている点、WWW公開後に必要があれば修正する点で、雑誌版の文章とは異なる部分があります。また、図表も雑誌版とは異なります。 予めご了承ください。 また、この文章が対象しているのはMySQL 4.0系なので、最新のリリース版と比べると説明不足な点などが多々あると思います。 レプリケーションの基をおさえるには、この文書はまだ有益だと思いますが、設定レベルの説明は最新のドキュメントを参照するようにしてください。

    k1m
    k1m 2006/09/13
    WEB DB PRESS Vol.22
  • mysql:12071 階層化されたデータをMySQLで扱う

    From: zen kishimoto <zen kishimoto <zen@xxxxxxxxxx>> Date: Sat, 03 Sep 2005 09:24:15 -0700 Subject: [mysql 12071] 階層化されたデータをMySQLで扱う (Managing Hierarchical Data in MySQL) http://dev.mysql.com/tech-resources/articles/hierarchical-data.html (図はこのサイトを参照のこと) Mike Hillyer著 初めに 多くのユーザーは一回くらいはSQLデータベース内で、階層化したデータを 扱ったことがあると思います。そのときはリレーショナル データベースは階層化したデータ用に開発されなかったと考えたと思います。 リレーショナルデータベースのテーブルは階層化されておらず

    k1m
    k1m 2006/09/13
    再帰構造を MySQL で扱う
  • Cheat Sheets - Added Bytes

    The second version of the Regular Expressions Cheat Sheet, a quick reference guide for regular expressions, including symbols, ranges, grouping, assertions and some sample patterns to get you started.

    k1m
    k1m 2006/09/13
    JS や mysql などの、「これ一枚で!」なカンペチャート
  • MySQLの最適化

    限りなく眠気を誘うPHP Internalsのセッションから逃げる。こっちの 講師はMySQL.comの人。講演慣れしていて、ずっとまともでプロフェッショナルな 感じ。午前中を逃したのが惜しいが、詳しいプレゼン資料は後日公開される らしい。 DELETEのコストはかなり高い 読みだしがすごく多い場合は無効化を示すフィールドを作りUPDATEすべき、 index更新のコストが馬鹿にならないSHOW STATUSの表示結果の解析方法 起動ごとに初期化、全データベースに共通rnd と rnd_next の割合Key_reads : Key_read_requests 、ディスクから読まれた回数:総回数 この割合が1:100より悪くなったら要注意Key_write_requests:Key_writes 総書き込み要求回数:ディスクに書き込ま れた回数 キャッシュの効果などMax_used_con

    k1m
    k1m 2006/09/13