(特にMyISAMを使っていた)ウェブ屋さんがInnoDBを使う場合の設定項目 - kazuhoのメモ置き場
InnoDBはMyISAMと比較して安全(OSクラッシュや電源断が発生してもテーブルが壊れない)分、書き込みが遅い。データベース屋さんからすると、それは当然のことでMyISAMがおかしいんだ、ということになり、だからバッテリバックアップ機能のついたRAIDカードを使うんだ、という話になる。でも、MyISAMを使っているウェブ屋さんの現場では、場合によって多少データが消えてもかまわないから、安いハードウェアで大量のアクセスを捌きたい... って乖離があるんじゃないかなーと思ってる。 そのような場合には、my.cnf の innodb_flush_log_at_trx_commit パラメータを調整することで、MyISAMに比肩する書き込み速度を得ることができる(そのかわり、クラッシュや電源断の場合は、設定によって直近１秒以内の変更が失われる)。 他のパラメータも含めて書いておくと、データベー
［速報］AmazonクラウドがMySQLサービス開始、パッチもバックアップもおまかせ
Amazon Web Servicesがクラウド上でMySQLをホスティングする「Amazon Relational Database Service (Amazon RDS)」のβ公開を開始しました。 インストール不要でMySQLの利用を開始でき、パッチ当てやバックアップなどもAmazonクラウド側で実行してくれるため、MySQLの導入や運用の手間を大幅に削減可能です。 MySQLのインスタンスは規模に応じて5種類が用意されています。 Small DB Instance : （1時間あたり0.11ドル） 1.7 GB memory, 1 ECU (1 virtual core with 1 ECU), 64-bit platform Large DB Instance : （1時間あたり0.44ドル） 7.5 GB memory, 4 ECUs (2 virtual cores with
Amazon Relational Database Service (Amazon RDS)
Amazon Relational Database Service Easy to manage relational databases optimized for total cost of ownership Amazon Relational Database Service (Amazon RDS) is an easy-to-manage relational database service optimized for total cost of ownership. It is simple to set up, operate, and scale with demand. Amazon RDS automates undifferentiated database management tasks, such as provisioning, configuring,
MyISAMとInnoDBのどちらを使うべきか
Twitterで話題になってたので簡単にまとめました。 ●MyISAMにしか無い機能を使いたい場合はMyISAMを使うしかない ・全文検索 (TritonnやSphinx) ・GIS ●InnoDBの利点(MyISAMの欠点) ▲障害対応系 ・クラッシュしても再起動するだけでリカバリができる ・クラッシュリカバリにかかる時間はテーブルサイズに比例するようなことはなく、コミット済みのデータは修復できる (巨大なMyISAMテーブルのREPAIRには数日単位で時間がかかることがある) ・オンラインバックアップができる ・INSERTやLOAD DATAなどを実行している途中でCtrl+Cでその更新系SQL文を止めても、テーブルは壊れないし、中途半端な状態で更新されることも無いし、スレーブが止まることも無い ▲性能系 ・行レベルロックなので並列性が高い(MyISAMはテーブルロック)。またSEL
「MySQLによるタフなサイトの作り方」を読んだ (Ameba の MySQL 本) - @kyanny's blog
Ameba の中のひとが書いた MySQL 本。出るって噂は聞いてて、気になるなーと思っていたらかぜぶろさんのところでレビューされてたので買ってみた。 某 4G 本よりお薦め（俺にとって某 4G 本の内容はさほど目新しくないので、目新しい内容の本のほうを薦めたくなるのは当然ではある）。仕事で MySQL をいじることがあるウェブアプリケーションプログラマやデータベースエンジニアの人は一読して損はないと思う。知れてよかった！と思えるノウハウがたくさん書いてある。 某 4G 本と同じソフトバンククリエイティブだし、なんとなく会社紹介的というか、技術カタログ・品評会的な構成になるのかなぁ・・・と、あまり期待せずに読み始めたんだけど、予想に反してかなり泥臭いというか、現場の人のキーボードのキートップが手垢でテカテカしてるのまで見えてきそうな詰め詰めな内容だったので、なんと届いたその日に一日かけて読
ricollab Web Tech Blog » Blog Archive » MySQLパーティショニングについて（その1：基本知識編）
初めまして、リコーの濱田です。このたび私も本ブログを担当することになりました。今後ともよろしくお願いいたします。 本エントリではデータベースに関する技術トピックとして、MySQL 5.1 から導入された機能であるパーティショニングについて書こうと思います。少し長くなりそうなので、「基本知識編」「性能検証編」の2回に分けて書くことにします。 今回は「基本知識編」として、パーティショニングの概要と基本的な使い方について紹介します。 パーティショニングの概要 パーティショニングとは、事前に設定されたルールに従ってデータをパーティションと呼ばれる部分的なテーブルに分割する仕組みです。 データ挿入時には、設定ルールに従ってデータが該当するパーティションに自動的に振り分けられます。データ参照時には、オプティマイザがクエリから必要なパーティションを判断し、該当するパーティションのみにアクセスします。これ
レプリケーションしてるMySQLで、マスタやスレーブが障害停止した場合のリカバリプラン - （ひ）メモ
MySQLで、レプリケーションベースのHAな構成について考えたメモです。 3台(というか2台＋1台)がいいかなぁと思っていて、前半はその理由を、後半では{マスタ,スレーブ}が{再起不能になった,ちょっとダウンしてすぐ復帰した}場合のリカバリプランについて書きます。 今のところはこれがベストかなと思っているのですが、「こうしたほうがいいと思う！」「ここがおかしい！」などなどのご意見はコメント、TBなどでいただけるとうれしいです。 ゴール マスタが落ちてもぐーすか寝ていられるようにしたい リカバリの作業はできるだけ単純に、かつ、短時間で完了するようにしたい めんどくさいのはいや 基本構成、方針 2台＋1台 サービスで使うのは2台 (db1, db2) もう1台は管理用 (db3) スレーブを多数並べる構成にはしない 台数増えると管理コストが上がる マスタダウン時のフェイルオーバとそのフェイルバ
InnoDBの超高負荷更新処理安定性
最近は沢山CPUコアのある高速なサーバーとか高回転数のHDDが沢山付いたRAIDストレージとか、もの凄く更新系の負荷がかかるベンチマーク(「db_STRESS」 by Dimitriさん)とかがあるので、InnoDBの構成の更新系での様々な限界が見えてきています。 まぁ、現実的にそのような限界を突破する必要のあるシステムがあるかどうかは判りませんが、将来のためにも色々アイデアを加えてXtraDBを作成してきました。今、大幅な変更無しに実装できる範囲のオプションが揃ってきたので高負荷更新系処理のチューニングをXtraDBベースで一旦書き出してみます。 今回もサクサクとポイントだけ。 （IOスレッドを増やす とか、他でも語られている既知のものは省略します。） 今回のチューニングの方針は、 「mutexやrw_lockなどの競合をできるだけ避ける」 ということと 「あまり沢山溜めてはイケナイもの
【注意】PowerPCのマルチプロセッサとInnoDB
多分、関係ある人にはクリティカルな内容なので、急いで報告します。 ここ２週間くらい、とある案件で頭を悩ませていました。 POWER5 の 8コア構成の IBM のサーバ(Linux)でMySQL(InnoDB)を利用すると、どのバージョンでも（ビルトインInnoDBでも、InnoDB Pluginでも、GCC atomic builtin を使わなくても）しばらくするとハングアップ／クラッシュするそうなのです。 紆余曲折ありましたが、どうも自分の仮説が正しそう（作ったパッチが効果ある模様）なので、先ほどバグレポートを報告しました。 All InnoDB (builtin and plugin) is unstable at PowerPC SMP server 簡単に言うと、InnoDBのコードはIntel CPUのSMPの仕様に依存した作りになっています。Intel系CPUのSMPでは、
データベース負荷テストツールまとめ(2) - SH2の日記
データベース負荷テストツールまとめの第2回です。 前回はTPC-Bベース、TPC-Wベースのものから6つのツールをご紹介しました。今回はTPC-Cベースのものについて見ていきたいと思います。 tpcc-mysql 対応RDBMS：MySQL 対応OS：Linuxなど 言語：C 作者：Percona Inc. ライセンス：不明(ライセンスに関する記述がない) トランザクション仕様：TPC-Cベース URL：https://code.launchpad.net/~percona-dev/perconatools/tpcc-mysql tpcc-mysqlはMySQLのコンサル会社であるPercona Inc.によって開発されたベンチマークツールで、TPC-Cをベースとしています。TPC-Cの仕様やtpcc-mysqlについては以前のエントリで詳しく扱っているので、そちらをご覧ください。 tpc
正しいベンチマークをするための10のポイント
世の中ではたくさんの人が独自にベンチマークを行ない、独自に情報発信がされています。そのベンチマークの中には、非常に参考になるものもあれば、現実性に大きく欠けるものもあります。競合他社が、ライバル社の製品にとって不利な条件でベンチマークを行い、それを発信することも日常的に行われています。ベンチマークの結果を鵜呑みにすることは危険で、結果の意味を判断するスキルを持つことが重要です。これはプロジェクトにおいて負荷テストを行う場合にも重要です。負荷テストの条件設定が正しいかどうかを判断できるようになるためです。 ここでは、私がDBサーバのベンチマーク/負荷テストを行ったり結果を読んだりする上で、心がけているポイントを10個ほど紹介したいと思います。 ■ハードウェアに関する4つのポイント 1. ハードウェアのスペックと設定を注視する ハードウェア構成によってベンチマーク結果は劇的に変わるので、言わず
InnoDBのAUTO_INCREMENTが遅い問題は5.1でどう改善されたのか
MySQL5.1のGA版が出てから8ヶ月余りが経過しましたが、まだ5.0(あるいはそれ以前)をメインで使っている方も多いのではないでしょうか。5.1の何が良いのかいまいち分からないという方も多いかもしれません。そんな方にとって分かりやすい例の1つが、「5.1でInnoDBのAUTO_INCREMENT性能が大幅に改善された」という点です。私は仕事柄Web系の技術者の方と話をする機会もよくありますが、意外と知られていない改善なので(まさにトラフィックと同時接続数の多いWeb系システムのための改善なのに…)この機会に取り上げることにします。 簡単に言えば、AUTO_INCREMENTを持つテーブルに対してINSERTをするクライアント数が数十、数百と増えていった時に、従来はスループットが指数関数的に落ちてしまっていたのが、5.1では高速かつ安定するようになりました。以下にmysqlslapのI
マスターInnoDB、スレーブMyISAMが勧められない理由
MySQLにおいて、マスターをInnoDBにして、スレーブをMyISAMにすると幸せになれるという主張をよく聞くことがあります。マスターは耐障害性の高いInnoDBにする一方で、スレーブは耐障害性が低くても大丈夫なので、InnoDBのかわりに高速とされるMyISAMを使えば、可用性と性能の両方をバランス良く実現できる、という考えです。 しかし、多くの場合これで幸せになることはできません。マスターとスレーブでストレージエンジンを合わせた方が無難です。その理由を以下に示します。 ●MyISAMはテーブルロックになる マスターへの更新結果はバイナリログに更新系SQL文として書かれ、スレーブのI/Oスレッドによってリレーログとして同じフォーマットで記録され、スレーブのSQLスレッドによってその更新系SQL文がそのまま実行されます。この更新系SQL文は、当然ながらスレーブに対して発行されるSELEC
Kazuho@Cybozu Labs: MySQL のボトルネックを統計的に監視・解析する方法
MySQL のチューニング、と言った場合には、サーバーパラメータの調整や EXPLAIN コマンドを利用したクエリ実行計画の最適化が話題に上ることが多いです。しかし、発行する全ての SQL について、いちいち EXPLAIN コマンドを使って確認していては、いくら時間があってもたりません。チューニングを効率的に進めるには、まず、ボトルネックとなっている SQL クエリを特定し、次にその最適化を行うべきです。 ではどのようにして、ボトルネックを特定するのか。MySQL Conference & Expo 2009 のキーノートにおいて Mark Callaghan 氏は、Google では SHOW PROCESSLIST コマンドを使った統計的アプローチを使っていると述べていらっしゃいます (参照: MySQLConf 09: Mark Callaghan, "This is Not a
mysql と drizzle の負荷テストツール「skyload」が凄い！ - kazuhoのメモ置き場
tmaesakaさんがやってくれました。 ずいぶん前からSQLのベンチマークを測定するのに使いやすいプログラムないかなーと思ってました。個人的にはmysqlslapというのを使ってたのですが、幾らか気に入らない所があったりコマンドラインオプションが複雑で毎回 --help を読んだりしていました。余計な機能なんかなくて、指定したSQLを高速にくりかえしてくれる物が欲しいなぁって思ってたんです。 とあるIRCでこの前、tmaesakaさんから「いま作ってる」という話を聞いて、いろいろ要望を言ってたんですが、ついさっきチュートリアルが公開されました。速いw 名前はskyload。とても小さく、実装コードだと800行程度です。しかもオプションが少ないので使い方が単純です。試しに適当な INSERT の速度を測ってみました。 $ skyload --server=localhost --mysql
Kazuho@Cybozu Labs: MySQL のトリガーの実用性を確認するために InnoDB の SELECT COUNT(*) を高速化してみる
最近 RDBMS のトリガーを色々書いているのですが、知らない人にトリガーが何かいちいち説明するのに簡単な例はないかな、というのと、MySQL の処理速度はトリガーによってどの程度変化するか、ということを確認するために、以下のような実験を行ってみました。 InnoDB はしばしば、「SELECT COUNT(*) が遅い！」と批判されます。では、トリガーを使って行数を別のテーブルにキャッシュすればいいのではないでしょうか？ 以下のように、極めて小さなテーブル t1 を作り、その行数を t1_cnt にキャッシュしてみることにします。 mysql> create table t1 ( -> id int unsigned not null primary key auto_increment, -> v int unsigned not null -> ) engine=innodb
MySQL :: MySQL 8.0 リファレンスマニュアル :: 12.10.6 MySQL の全文検索の微調整
MySQL の全文検索機能には、ユーザーが調整できるパラメータがほとんどありません。 一部の変更でソースコードを変更する必要があるために、MySQL ソース配布を持っている場合は、全文検索の動作をさらに制御できます。 セクション2.9「ソースから MySQL をインストールする」を参照してください。 全文検索の有効性は、慎重に調整されます。 ほとんど場合、デフォルトの動作を変更すると、実際には有効性が低くなる可能性があります。 使用方法を理解していない場合は、MySQL ソースは変更しないでください。 このセクションで説明するほとんどの全文変数は、サーバーの起動時に設定する必要があります。 変更するには、サーバーの再起動が必要です。サーバーが動作しているときは、変更できません。 一部の変数を変更するには、テーブル内の FULLTEXT インデックスを再構築する必要があります。 これを行う手
参照と更新が頻繁に発生するテーブルでMyISAMとInnoDBを比較 - cloned.log
[追記 2012/09/29] 最近でもこの記事を参照してくださる方がいるので追記します。下記エントリを書いた時点では非常に局所的なケースで重い現象に悩まされていたことを前提に調査しており、その延長線上で「一律InnoDBというのは言い過ぎな印象を受けるパフォーマンス差に感じる」ということを書いてしまっていますが、その後色々と勉強した結果、特定箇所のニッチなベンチマークではなく一般的な運用上の負荷を焦点にした場合はInnoDBは適切に設定しておれば十分にパフォーマンスがある（もしくはInnoDBの方が有利）というのが現在の意見です。 「MyISAM InnoDB」で検索するとあちらこちらであるように、今時は理由がなければInnoDB、ということでMyISAMのテーブルをいくつかInnoDBに変更したところ、かなりパフォーマンスが落ちるケースがあった。 InnoDBにしたら軒並み遅くなったと
MySQLがフォークか、オープンアライアンスが誕生 － ＠IT
2009/05/14 オラクルによるサン・マイクロシステムズ買収で注目が集まるOSSプロダクトの1つ「MySQL」に異変が起きている。MySQLのオリジナル開発者で創業者でもあるマイケル・ウィデニウス（Michael Widenius）氏は5月13日、オープンソースコミュニティベースでMySQL関連の開発やサポートを行うためのハブとなる「The Open Database Alliance」（ODA）の設立を発表した。 PostgreSQLと並んでオープンソース界でデータベース製品のデファクトスタンダードとなっているMySQLは、サン・マイクロシステムズに2008年1月に買収されたことで同社の一部門に。その後、2009年4月にオラクルがサン・マイクロシステムズを買収すると発表したことから、開発体制やライセンスモデルなどを巡って憂慮の声や憶測が流れていた。オラクルのデータベース製品との整合性
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
MySQL FULLTEXT Ngram : LIKE検索より数十倍高速な、お手軽 日本語全文検索 について｜blog｜たたみラボ