MySQL Casual Talks Vol.4 でのライトニングトークに利用した資料です。 MySQL-5.6.4より「InnoDB FTS」としてInnoDBで全文検索機能が加わりました。 この全文検索機能を利用し、日本語の全文検索エンジンとしての可能性を探ります。 ブログ記事はこちらです。 http://y-ken.hatenablog.com/entry/mysql-casual-talks-vol4-innodb-ftsRead less
phpmyadminでinformation_schemaをクリックするのが危険過ぎる – K52.NIKKI ver3.0というのが添えられていました。 よくわからなかったので現象を呟いたところ、親切なMySQLのACE(えーす)のyoku0825さんがinnodb_stats_on_metadata=1があやしいんじゃないかと教えてくれました。 ググってみたところ、innodb_stats_on_metadata に要注意 – TAKUMI SAKAMOTO’S BLOGというページを見かけて何が起きたかわかった気になったのでした。 起きたことの予測: ・テーブルの更新状況が統計情報更新の発生条件に達している状態だった ・information_schemaのリンクをクリックすることでshow table status相当の統計情報更新のきっかけになるクエリが走った ・統計情報更新のた
MySQL 5.6のnutshellを読むと、`クラッシュセーフなレプリケーションを実現するためにはmaster_info_repositoryとrelay_log_info_repositoryをTABLEに設定しな! おっと、relay_log_recoveryも1にしておくんだぜ'みたいことが書いてある。 で、このバグレポートを見た時からずっと、sync_master_infoの暗黙のデフォルト10000のまんまじゃクラッシュセーフじゃなくね? sync_master_info= 1必須? それはパフォーマンス的に死ねる。という感じでモヤモヤしていたのだが、やっと合点がいったのでメモしときます。 master_info_repository FILEの場合、従来どおりmaster.infoファイルに書く。 ファイル名はmaster_info_fileにより可変。 更新があるたび(バイ
外部キー便利!!! MackerelではPostgreSQLで外部キーあり そのレコードがあることが保証される 各テーブルのidにアプリケーションレベル(Mackerelの場合Scala)で型付けをするとなお便利 MemberID型、MonitorID型 → idで誤ったテーブルを引くとかがない 本日のスキーマ CREATE TABLE `member` ( `id` INTEGER unsigned NOT NULL auto_increment, `earned_item_count` INTEGER unsigned NOT NULL DEFAULT 0, `name` VARCHAR(191) NOT NULL, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARACTER SET utf8mb4; CREATE TABLE `item`
本連載では、現在MySQLを利用していて、チューニングやより大規模な環境に向けた構成の拡張を体系的に説明することを目的としています。MySQLのこれまでの開発と最新の動向から、チューニングやスケールアップ/スケールアウトの注意点を解説します。 第1回である今回は、MySQLのアーキテクチャをこれまでの開発の歴史と併せて解説します。 黎明期 MySQLの最初期のバージョンは1994年に開発され、1995年に公開されています。公開当初は独自のライセンスを採用していましたが、2000年にGPL v2を採用し、商用ライセンスとのデュアルライセンスモデルを採用しました。また、MySQLの代表的な機能の1つでもあるレプリケーションも2000年に実装されており、Webシステムとの相性の良さや構成の柔軟さから数多くのWebシステムで以前からMySQLが採用される理由にもなっています。 2001年にGA(G
今回から数回にわたり、TransactdのオペレーションとInnoDBにおけるロックについて解説します。 ロックについてはあまり良くわからなくてもとりあえずそれなりに動くアプリケーションは作れてしまいます。ですが、マルチユーザー環境でミッションクリティカルなアプリケーションを書くには、ロックの理解が不可欠です。ロックをうまく使って、矛盾や間違いのない読み書きをしつつ同時実行性も高いアプリケーションにしましょう。 その1では、Transactdを実装する上でMySQLのソースやドキュメントから得た知見を基に、InnoDBのロックの種類と分離レベルに応じてそれをどのように使うかをまとめてみます。 Index MySQLのトランザクション関連用語 MySQLのREPEATABLE-READ InnoDBのロック 行ロック (row-level locking) GAPロック GAPロック単体 ネ
この記事はMySQL Casual Advent Calendar 2014の8日目の記事です。 MySQL系のブログや投稿は初めてなので、軽く自己紹介。 Oracleで育ってMySQLやPostgreSQLもいじっている節操の無いDBAです。 現在はMySQLばっかりです。 10月にMySQLサーバーをリプレイス&5.5から5.6へのバージョンアップしたのでつらつらと書いてみます。 MySQL5.6が出てだいぶ立ち、参考になるようなブログや資料はたくさんあったので苦労はしませんでした。 ありがたやーありがたやー。 ・Casualにmy.cnf Casualだし、有名な方々の資料がググればいっぱいあるのでパラメータの意味までは書きません。 注意してたのはこのへんくらい。 sql_mode='' explicit_defaults_for_timestamp=true innodb_onli
InnoDBのデータ領域はログファイルとテーブルスペースという、切っても切れない2種類のファイルから構成されている。ログファイルは名前からするとただのログだから削除しても平気かな?と思って削除してしまうという問題が後を絶たない。そこで、今日はログファイルとテーブルスペースの関係について説明しようと思う。 InnoDBのログファイルは、別名WAL - Write Ahead Logと呼ばれるもので、名前を日本語に直すと「前もって書き込んでおくためのログ」とでも呼べるだろうか。InnoDBのテーブルに対して行われた更新は、全ていったんログに書き込まれるのである。トランザクションがコミットされると、innodb_flush_log_at_trx_commit=1が設定されていればログファイルに書き込みが行われる。0または2の場合には、ログバッファと呼ばれる領域にデータが保持される。その後、時間を
MySQL 5.7.5の新機能。 ログ貼ってたら長くなったので、バッファプールサイズを小さくするのは別エントリーへ。 理屈的には、 - バッファプールを大きくするとき * innodb_buffer_pool_chunk_size ごとに新しいページを確保しながらゴニョゴニョやる * この処理中は *バッファプールへの全てのアクセスがブロックされるよ* - バッファプールを小さくするとき * innodb_buffer_pool_chunk_size ごとにページを追い出しながらゴニョゴニョやる らしい。 http://dev.mysql.com/doc/refman/5.7/en/innodb-buffer-pool-online-resize.html しかしバッファプール大きくする時の動作はInnoDBのトラフィック全滅ですか使えNEEEE とか、「オンラインでバッファプールサイズを
MySQL 5.7.5の新機能、オンラインバッファプールサイズ変更について。 今のサイズより大きくする(サイズ拡大編)は別エントリーで。 ↑のエントリーにも書いたけど、理屈的には * バッファプールサイズを今より大きく変更する時には全ブロック * バッファプールサイズを今より小さく変更する時にはブロックなし らしい。れつご。 # mysqladmin -r -i 2 ex | grep Innodb_rows_inserted .. | Innodb_rows_inserted | 19837 | -- 前のエントリーの続きで、バッファプール80GBでtpcc_startでトラフィックかけてる | Innodb_rows_inserted | 18892 | | Innodb_rows_inserted | 18198 | | Innodb_rows_inserted | 17974 |
発表資料 Gotanda.pm #2 でMySQL::Warmerというモジュールの紹介をしたのですが、それをCPANizeしたのでエントリを書いています。 % cpanm MySQL::Warmer とすると、mysql-warmupというコマンドがインストールされ以下のようなコマンドを打つとウォームアップクエリがダラっと発行されます。--dry-runもあり、その場合、発行されるクエリが標準出力されます。 % mysql-warmup mydatabase -h db.example.com -u dbuser -p サービス投入前のDBのデータをメモリに乗っけてやるのに有用でしょう。 ウォームアップ戦略はkazuhoさんのMySQL のウォームアップ (InnoDB編)に基づいていますが一部適当です。突っ込みどころがあれば指摘いただければと思います。 ISUCONでも再起動かかった直
よい機会なのでまとめておく。対象はMySQL5.6以下とMariaDB10.0以下。 (2014.12.3追記:以下の書籍にも記述した。) 要旨 MySQL/MariaDBのバックアップについて、相変わらず「InnoDBさえ使っていれば、FLUSH TABLES WITH READ LOCKは不要。よってバックアップ中に更新不可になることはない!」との主張が繰り返されているが、少なくとも5.6/10.0まではそんなことはない。 オンラインバックアップに関するロックの正確な記述 より正確に言えば「全データベース領域をバックアップする場合には、FLUSH TABLES WITH READ LOCKは必須。特定のInnoDBだけのデータベースやテーブルをバックアップする際は、この限りではない」。 なのだが、全領域のバックアップをしたい人に対してロック不要説を吹き込む人が未だにいる。 ロックの必要
Percona MySQL Webinarsの発表(MYSQL開発でやってしまいがちな致命的なミスについて)のQAをご紹介します。 本発表はSQLアンチパターン著者のBill Karwinさんの発表です。 オリジナル: http://www.percona.com/resources/mysql-webinars/how-avoid-even-more-common-deadly-mysql-development-mistakes July 17, 2014 by Bill Karwin 水曜日に「MySQLを開発する上でよく起こる(そして致命的な)ミスをどのように回避するか」をPercona MySQL webinarsで発表した。お見逃の際は、ビデオとスライドを見る為に登録すればまだご覧にいただける。 参加いただいた皆様、そしてとりわけすばらしい質問をしていただきありがたく思っている
7月は一回も記事書かなかった。3年くらい前からInnoDBの圧縮をしてみたり止めてみたりって行為を度々しているので、所感についてまとめとく。 2011年頃(MySQL5.1) 容量削減目的で圧縮を試す。 環境 CPU: Intel(R) Xeon(R) CPU E5620 @ 2.40GHz(仮想8コア)×1 memory: 24GB storage: ioDrive Duo(2面合わせて600GBくらい。SW RAID0で組む。) OS: CentOS 5.4(kernel: 2.6.18-164.el5) filesystem: xfs(noatime, nobarrier) MySQL: 5.1 innodb plugin Query: ピーク時に更新系が5kqpsくらいだったかなあ…忘れた。 圧縮した結果 容量は半分に削減できた。 パフォーマンスはあまり変わらなかった。 CPU
今月から社内勉強会は、社員が持ち回りで講師を担当することになりました。 初回のテーマは「MySQLのトランザクション」です。 MySQLにほぼ限定した形でトランザクションについて発表をしました。 資料は以下の5章立てになっています。 1.トランザクションとは 2.ストレージエンジン 3.トランザクションの開始と終了 4.ACID特性 5.オートコミット 日頃の業務では、実行したSQLの動作確認をした際に、意図した結果が得られない場合に処理を戻せるように、「begin」で書き始めてトランザクションを開始するようにしています。 しかし、そもそもトランザクションは「失敗した時に戻すための機能」ではありません。 普段から使ってはいるけれど深くは知らなかったトランザクションについてちょっとだけ知識を深めるよい機会になったと思います。 なお、「2.ストレージエンジン」の中で、MySQLで利用できるスト
MySQLの更新系処理のパフォーマンスを、innodb_flush_log_at_trx_commitのチューニングで上げる 経緯 Master(更新系のMySQL Database)が非常に高負荷となっている。 slowquerylogsに、下記のような「commitがボトルネックになっている」旨の出力が大量にでる # User@Host: apps[apps] @ ip-10-163-30-24.ap-northeast-1.compute.internal [10.163.30.24] # Query_time: 9.523171 Lock_time: 0.000000 Rows_sent: 0 Rows_examined: 0 SET timestamp=1349786490; COMMIT; # User@Host: apps[apps] @ ip-10-132-8-20.ap-
こんにちは、DBAです。 MySQL5.6のオンラインALTER TABLEでハマった時のおはなしです。 5.6にはオンラインALTER TABLE関連のパラメーターに innodb_sort_buffer_size というものが追加されており(5.5以前はfast index creationが効く時に使われるパラメーターとして内部的に1Mでハードコードされていたものが、設定可能になった)、前にざっくり試したところ 大きくすれば一応それなりの恩恵は受けられそうなので大きくしたんですよ。 毎日の定期バッチで盛大にInnoDBのテーブルにバルクインサートをかけた後にALTER TABLEでインデックスをくっつけてRENAME TABLEでテーブルを切り替える…なんてことをやっているサービスには打ってつけだと思ったわけです(そもそもそのやり方の善悪について やがて DBAは 考えることを止めた
久しぶりにMySQLガチュアルカジュアルに参加してきたので、そんなログと資料をまとめておこうと思います。 zusaar.com - zusaar リソースおよび情報 尚、このイベントの過去の参加記録は以下。 「MySQL Casual Talks vol.1」に参加してきたよ、のメモ 「MySQL Casual Talks vol.2」に参加してきたよ、のメモ 「MySQL Casual Talks vol.3」に参加してきたよ、のメモ 「MySQL Casual Talks Vol.4」のエア参加レポート vol.4がエア参加で、vol.5・・・っていつやったの。。。な感じで久しぶりに参加させていただきました。 TokuDB試してみる (@yoku0825) TokuDB試してみる from yoku0825 TokuDB、InnoDBの3倍くらい圧縮が効くとのことで、レイテンシ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く