タグ

MySQLに関するdrivejpnのブックマーク (63)

  • MySQLのインデックスを学ぶ (1) - 刺身☆ブーメランのはてなダイアリー

    実践ハイパフォーマンスMySQL 第2版とLinux-DBシステム構築運用入門を読んで、 MySQL のインデックスについて勉強しなおしている。理解が曖昧だった部分の知識を深められたり、自分の間違いに気づけたりして、とても収穫が多い。 フルテーブルスキャンとフルインデックススキャン Linux-DBシステム構築運用入門 P185 に書いてあるケース。インデックスを利用してても対象レコード数が多いとランダムI/Oが大量に発生して遅くなる。読むべきレコード数が多いのならばフルテーブルスキャンのほうがI/O一回で多くのブロックを読み込めるので速い。 IGNORE INDEX ヒントを与えてパフォーマンスを改善するという例があった。 マルチカラムインデックスと範囲検索 SELECT * FROM users WHERE a = ? AND b >= ? and (c IS NULL OR c >=

    MySQLのインデックスを学ぶ (1) - 刺身☆ブーメランのはてなダイアリー
  • Twitterが、Cassandraの本採用を断念。「いまは切り替えの時期ではない」

    「いまは新しい技術への大規模な移行をする時期ではないと確信している」。Twitterは、サービスの核となるツイートを保存するデータベースを、MySQLによる大規模分散データベースから、NoSQLデータベースであるCassandraへ移行しようとしていました。しかしCassandraへの移行作業を中止し、引き続きMySQLでの運用を継続すると、Twitter Engineering Blogへのエントリ「Cassandra at Twitter Today」で明らかにしました。 これは戦略の変更だ Twitterは利用者からのツイートを、Scalaによって独自開発したミドルウェア「Gizzard」とMySQL、そしてmemcachedを用いた大規模分散データベースに保存しています。 しかしこうした複雑なシステムによる運用は非常に手間がかかり、人的コストを中心としたコストの増加が非常に大きくな

    Twitterが、Cassandraの本採用を断念。「いまは切り替えの時期ではない」
  • 特定のデータベースだけをmysqldumpで作成したダンプファイルから抜き出すawkスクリプト

    タイトルのまんまのプチトリビアを紹介しようと思う。mysqlの--one-databaseオプションを使えば「mysqldumpで--all-databasesとか--databasesオプションを使って作成したダンプファイルに含まれる複数のデータベースから、一つのデータベースだけを選択してリストアする」という操作ができるけど、毎回ダンプファイル全体を読み込むのは無駄じゃないか?と思われることもあるだろう。だったら事前にダンプファイルを分けちゃいたい!と考えるのが人情というもの。そんなときはawkコマンドを使うといい。 #!/usr/bin/awk -f BEGIN { dump_current_db = 0; num_db = split(databases, db_arr, ",") for (i = 1; i <= num_db; i++) { db_arr[i] = "`" db_

    特定のデータベースだけをmysqldumpで作成したダンプファイルから抜き出すawkスクリプト
  • MySQLバックアップ頂上決戦!! LVMスナップショット vs InnoDB Hot Backup

    スナップショットを使えばとある瞬間のディスクやファイルシステムのデータをいつでも後から参照することができる。しかもスナップショットの作成は一瞬だ。スナップショット機能を活用すれば最強のオンラインバックアップソリューションが出来るだろう。 しかし、スナップショットでバックアップを取るなんて危険な操作じゃないのか?!と不安に思われる方もいらっしゃるかも知れない。MySQL Serverが稼働中にいきなりデータだけをとってくるのだから、そのような疑問を持たれるのは頷ける。しかし仕組みさえ分かればスナップショットによるバックアップは怖くないということが分かるはずだ。そこで、まずはスナップショットによるバックアップの仕組みについて説明する。スナップショットを取る際の要件は次の通りである。 全てのデータを単一のボリュームに置くこと。つまり、一回のスナップショット操作でバックアップが取れることだ。 ディ

    MySQLバックアップ頂上決戦!! LVMスナップショット vs InnoDB Hot Backup
  • MySQL 5.5.0-m2リリース - SH2の日記

    出ました。突然のメジャーバージョンアップですが、これは新しい開発サイクルに基づくものです。曰く、 trunkは常にβ版以上の品質を保つ (純粋な新機能の開発は別のstaging treeで行う) 3〜6ヶ月ごとにRC版の品質でマイルストーンリリースを行う 12〜18ヶ月ごとにいずれかのマイルストーンからbranchを切ってGA版のリリースを行う マイルストーンリリースの直後にstaging treeから新機能のマージを行う という仕組みです。これによって大規模な新機能の追加によるリリースの遅延を抑えるとともに、より安定した品質でのリリースを行うということを狙っているそうです。またMySQL 5.5.0-m2のリリースに伴い、MySQL 5.4.x-betaの更新は終了となります。 MySQL 5.5の新機能からいくつかピックアップしてご紹介します。 準同期レプリケーション。MySQL 5.

    MySQL 5.5.0-m2リリース - SH2の日記
  • MySQL 5.5登場

    MySQL 5.5がリリースされた。「えっ?!この前5.4をリリースしたばっかりでしょ?!まだ5.4すら使ってないよ!!」と驚かれた方はご安心を。これは開発リリースモデルが変更されたためで、MySQL 5.4はこれでいったん開発終了して今後の開発はバージョン5.5をベースにして継続されることになる。バージョン5.4も5.5も「マイルストーンリリース」(以下MR)という位置づけであり、GA(正式リリース)版ではない点に注意して頂きたい。MR版の位置づけは次のようなもの。 品質的にはRC(リリース候補)版と同レベル(従ってほぼ安定している) 3〜6ヶ月ごとに新しいバージョンが出る 新しいMR版では機能が追加されることになるが、RC版と同レベルまで安定した機能だけが追加の対象になる MR版へ追加する予定の機能については別のブランチで開発が進められる 12〜18ヶ月ごとにMRのうち一つをGA版へと

    MySQL 5.5登場
  • MySQL InnoDBだけで全文検索 - SH2の日記

    実験エントリです。 予習してみる 「転置インデックス」というキーワードで検索して、しばらく勉強してみます。 転置インデックス - Wikipedia mixi Engineers’ Blog » 転置インデックスを実装しよう ASCII.jp:悟空、秘剣「転置インデックス」を手に入れる |Googleはなぜ的確に探せるのか? [を] 転置インデックスによる検索システムを作ってみよう! 転置インデックスで学ぶ検索エンジンの中身アプリ - 睡眠不足?! うーんなるほど。分かったような分からないような。 作ってみる とりあえず、Twitter4Jを使ってこんなデータを用意しました。ちなみに人選は漢(オトコ)のコンピュータ道: MySQLerのTwitterアカウントまとめ。を参考にさせていただきました。 5707049458,2009-11-14 20:28:34,sakaik,@hbstudy

    MySQL InnoDBだけで全文検索 - SH2の日記
  • MySQL 5.1のmysqldumpslowで快速チューニング - SH2の日記

    MySQL 5.1のmysqldumpslowを使うとチューニングが楽になる!という話題です。 mysqldumpslowはもともとMySQLに付属しているツールで、スロークエリログを集計してくれるものです。これ自体はMySQL 5.1で特に変わったところはありませんが、スロークエリログ体の方が機能強化されているため、組み合わせるとなかなか便利になっています。MySQL 5.1におけるスロークエリログの主な機能強化は以下の三点です。 long_query_timeに1秒未満の値を設定できるようになった。 出力先を設定できるようになった。 これらの設定をオンラインで変更できるようになった。 これでどうなるかというと、MySQLの性能分析をしたいと思ったときに、サーバを止めずにその場で mysql> set global slow_query_log = 1; mysql> set glob

    MySQL 5.1のmysqldumpslowで快速チューニング - SH2の日記
  • MySQL 5.1.41リリース - SH2の日記

    出ました。今回は機能の追加・変更が4件、バグ修正が62件あります。 MySQL 5.1.38から同梱されるようになったInnoDB Pluginですが、MySQL 5.1.41ではバージョンが1.0.5に上がり、ついにRC(リリース候補版)となりました。再掲になりますがInnoDB PluginはビルトインのInnoDBに比べて以下のような機能強化が施されており、非常に有用性の高いものです。そろそろ利用を検討しても良い時期に入ってきたのではないかと思います。 高速なインデックス作成。従来InnoDBCREATE INDEXはテーブルの再作成を伴っていました テーブルとインデックスの圧縮 (検証結果その1、その2) INFORMATION_SCHEMAによるロック競合の検出 (検証結果) CPUスケーラビリティの向上 (1.0.3から) バックグラウンドI/Oスレッドの増加 (1.0.4か

    MySQL 5.1.41リリース - SH2の日記
  • 実録、ほぼ無停止なMySQLのフェイルオーバ (動画もあるよ) - (ひ)メモ

    レプリケーションしてるMySQLで、マスタやスレーブが障害停止した場合のリカバリプラン でも掲げたゴールである、「マスタが落ちてもぐーすか寝ていられるようにしたい」がほぼできたので、ほとんどサービスが停止することなく、フェイルオーバする様をスクリーンキャストに収めました。 埋め込みプレイヤーだと、小さくてわからないと思うので、リンク直接でみてください。 http://www.irori.org/pub/mysql-mm.mov 登場するホスト 登場するホストは2台、db901db902です。 最初は、db901が更新系クエリを受けるプライマリでdb900の浮動IPアドレスを持っています。 画面分割 画面は5分割しています。 左上 = 「select sysdate(),@@server_id」をdb900に対して(sleep 1しながら)延々と実行しまくりんぐ 右上 = ping -n

    実録、ほぼ無停止なMySQLのフェイルオーバ (動画もあるよ) - (ひ)メモ
  • Sphinx | Open Source Search Engine

    Sphinx 3.5.1 released We are starting 2023 off by making Sphinx 3.5.1 available, with about 30 new features compared to 3.4.1 released mid-2021 (it has been a little while), and almost a hundred changes and fixes. We voted internally for the top-3 features but ended up choosing top-6 to highlight on the front page. They are as follows. Read more... Sphinx 3.3.1 released We have just made Sphinx 3.

  • Registration: Machine learning & data conference | O'Reilly Strata

    We’ve made the very difficult decision to cancel all future O’Reilly in-person conferences. Instead, we’ll continue to invest in and grow O’Reilly online learning, supporting the 5,000 companies and 2.5 million people who count on our experts to help them stay ahead in all facets of business and technology. Come join them and learn what they already know. Become an O’Reilly online learning member

    Registration: Machine learning & data conference | O'Reilly Strata
  • MySQL Clusterが苦手とするJOINを如何にして克服するべきか。

    シェアードナッシング型の負荷分散機能を持ち、なおかつ同期レプリケーションによるHA機能まで備えたMySQL Cluster最大の弱点といえば、JOINの遅さであろう。MySQL ClusterのJOINは偽りなく遅い。JOINを多用するアプリケーションでMySQL Clusterを利用するのはある意味マゾヒスティックな行為であると言えよう。何故MySQL ClusterはJOINが遅いのか?それはMySQL Clusterが分散データベースだからである。 ご存じの通り、MySQLにおけるJOINのアルゴリズムにはNested Loopしかない。他のストレージエンジンを利用していればそれでも十分実用に耐えうるぐらい高速なのだが、MySQL Clusterの場合はそうはいかない。JOINでは自ずとストレージエンジンからデータをフェッチする回数が増えるが、MySQL Clusterの場合レコード

    MySQL Clusterが苦手とするJOINを如何にして克服するべきか。
  • MyISAMとInnoDBのどちらを使うべきか

    Twitterで話題になってたので簡単にまとめました。 ●MyISAMにしか無い機能を使いたい場合はMyISAMを使うしかない ・全文検索 (TritonnやSphinx) ・GIS ●InnoDBの利点(MyISAMの欠点) ▲障害対応系 ・クラッシュしても再起動するだけでリカバリができる ・クラッシュリカバリにかかる時間はテーブルサイズに比例するようなことはなく、コミット済みのデータは修復できる (巨大なMyISAMテーブルのREPAIRには数日単位で時間がかかることがある) ・オンラインバックアップができる ・INSERTやLOAD DATAなどを実行している途中でCtrl+Cでその更新系SQL文を止めても、テーブルは壊れないし、中途半端な状態で更新されることも無いし、スレーブが止まることも無い ▲性能系 ・行レベルロックなので並列性が高い(MyISAMはテーブルロック)。またSEL

  • (特にMyISAMを使っていた)ウェブ屋さんがInnoDBを使う場合の設定項目 - kazuhoのメモ置き場

    InnoDBはMyISAMと比較して安全(OSクラッシュや電源断が発生してもテーブルが壊れない)分、書き込みが遅い。データベース屋さんからすると、それは当然のことでMyISAMがおかしいんだ、ということになり、だからバッテリバックアップ機能のついたRAIDカードを使うんだ、という話になる。でも、MyISAMを使っているウェブ屋さんの現場では、場合によって多少データが消えてもかまわないから、安いハードウェアで大量のアクセスを捌きたい... って乖離があるんじゃないかなーと思ってる。 そのような場合には、my.cnf の innodb_flush_log_at_trx_commit パラメータを調整することで、MyISAMに比肩する書き込み速度を得ることができる(そのかわり、クラッシュや電源断の場合は、設定によって直近1秒以内の変更が失われる)。 他のパラメータも含めて書いておくと、データベー

    (特にMyISAMを使っていた)ウェブ屋さんがInnoDBを使う場合の設定項目 - kazuhoのメモ置き場
  • レプリケーションしてるMySQLで、マスタやスレーブが障害停止した場合のリカバリプラン - (ひ)メモ

    MySQLで、レプリケーションベースのHAな構成について考えたメモです。 3台(というか2台+1台)がいいかなぁと思っていて、前半はその理由を、後半では{マスタ,スレーブ}が{再起不能になった,ちょっとダウンしてすぐ復帰した}場合のリカバリプランについて書きます。 今のところはこれがベストかなと思っているのですが、「こうしたほうがいいと思う!」「ここがおかしい!」などなどのご意見はコメント、TBなどでいただけるとうれしいです。 ゴール マスタが落ちてもぐーすか寝ていられるようにしたい リカバリの作業はできるだけ単純に、かつ、短時間で完了するようにしたい めんどくさいのはいや 基構成、方針 2台+1台 サービスで使うのは2台 (db1, db2) もう1台は管理用 (db3) スレーブを多数並べる構成にはしない 台数増えると管理コストが上がる マスタダウン時のフェイルオーバとそのフェイルバ

    レプリケーションしてるMySQLで、マスタやスレーブが障害停止した場合のリカバリプラン - (ひ)メモ
  • スワップサイズをゼロにしてはいけない

    先月発売された書籍「Linux-DBシステム構築/運用入門」は、なかなか上々の売れ行きとなっているようです。Amazonではしばらく「1-2ヶ月待ち」の状態が続いてしまっていたのですが、最近になってようやく解消され、容易に入手できるようになっているようです。Amazonの在庫切れ問題がひと段落したところで、これからは書籍のサポート的な情報を書いていくことにします。 まず、書を購入された皆さまありがとうございました。結構な数の方がBlogやTwitter等で、このをほめてくださっていることに大変感謝しています。まだ自体の認知度が低い(存在自体を知らない顧客も多い)ので、普及活動をしつつ、これからも読者の期待に応えられる記事を書いていきたいと思っています。 最初は、よく見かけることの多い「メモリ管理」の話題を取り上げようと思います。第12章では、メモリ管理とスワップ領域に関する解説をして

  • InnoDBの超高負荷更新処理安定性

    最近は沢山CPUコアのある高速なサーバーとか高回転数のHDDが沢山付いたRAIDストレージとか、もの凄く更新系の負荷がかかるベンチマーク(「db_STRESS」 by Dimitriさん)とかがあるので、InnoDBの構成の更新系での様々な限界が見えてきています。 まぁ、現実的にそのような限界を突破する必要のあるシステムがあるかどうかは判りませんが、将来のためにも色々アイデアを加えてXtraDBを作成してきました。今、大幅な変更無しに実装できる範囲のオプションが揃ってきたので高負荷更新系処理のチューニングをXtraDBベースで一旦書き出してみます。 今回もサクサクとポイントだけ。 (IOスレッドを増やす とか、他でも語られている既知のものは省略します。) 今回のチューニングの方針は、 「mutexやrw_lockなどの競合をできるだけ避ける」 ということと 「あまり沢山溜めてはイケナイもの

  • TOP [Tipsというかメモ]

    このサイトはweb系エンジニアが普段接している技術のちょっとしたテクニック(Tips)の紹介と自分自身の備忘録(メモ)を目的に開設しています。 最近の変更

  • データベース負荷テストツールまとめ(1) - SH2の日記

    Webシステム開発において性能試験を行う場合、hp LoadRunnerやApache JMeterといったウェブブラウザをエミュレーションしてくれる負荷テストツールを用いるのが定番だと思います。そんななか、たまにデータベース単体での性能を測ってほしいと頼まれることがあるので、そうした便利なツールはあるのかなと思って調べてみました。 データベースに対する負荷テストツールは探すとたくさん出てくるのですが、案件で使用しているRDBMSに対応していなかったり、トランザクション仕様が希望と異なっていたり、微妙に作りが悪かったりと、ニーズに合致したツールはすぐには見つかりません。そんなときにこのエントリがツール探しの参考になればと思います。 pgbench 対応RDBMS:PostgreSQL 対応OS:Linuxなど 言語:C 作者:石井達夫氏 ライセンス:独自(BSDライセンスに近い) トランザ

    データベース負荷テストツールまとめ(1) - SH2の日記