my.cnfで設定するMySQLオプションで重要そうなのまとめ
MySQL のチューニングで、my.cnf のオプション設定をいじっていたのですが、パラメータが大量にあって奥が深い。「現場で使える MySQL」のパフォーマンス・チューニングの章（13章, 14章）を読みなおしたのですが、そこからの抜粋中心で大事そうなパラメータの概要をまとめました。 現場で使える MySQL (DB Magazine SELECTION) スロークエリログ関連 log-queries-not-using-indexes これを指定すると、インデックスを使わないような処理（テーブルのフルスキャンなど）を行った全てのSQL文をスロークエリログに出力する。 slow_query_log スロークエリログを有効にするかどうかを指定。slow_query_log = 1 で有効になる。 logn_query_time 指定時間より長く実行時間がかかったSQL文をスロークエリログに
InnoDBの制限とファイルフォーマットAntelopeとBarracudaの違い - かみぽわーる
この投稿はMySQL Casual Advent Calendar 2014の5日目の記事です。 @kamipo 質問させてください。このエントリーで COMPRESSED ではなく DYNAMIC を選んでいる理由はなぜですか？あまりDB詳しくないので参考リンクなどポインタを教えていただけるだけでも構いません http://t.co/9sC4lzLjXr— kiyoshi nomo (@kysnm) November 27, 2014 先週ツイッターでInnoDBのことを質問されまして、せっかくなのでアドカレのネタにしようと思いますってことでInnoDBのファイルフォーマット毎の違いをカジュアルに説明しようと思います。 InnoDBのファイルフォーマットBarracudaと新機能 InnoDBにはファイルフォーマットとして昔からあるAntelopeと新しいフォーマット(5年も前からあるの
InnoDBのファイルサイズ管理
最近、InnoDBのデータ領域（テーブルスペース）が成長してしまって元に戻すことが出来ない場合の対処についてよく質問されるので、今日はテーブルスペースが成長することへの対策について説明しよう。（ここのところMySQLネタが続いているが、Planet MySQL日本語版を意識しているわけではないのであしからず！！＜＜ホントかよ？！＞俺） InnoDBのテーブルスペースが成長してしまうのは、ズバリ自動拡張しているからである。テーブルスペースに対して何もオプションを指定しないと、デフォルトでは次のような設定と同じテーブルスペースが作成される。 [mysqld] innodb_data_file_path=ibdata1:10M:autoextend サイズは10MBしかないが、自動拡張するのである。自動拡張してしまうと何が問題なのかというと、データが増えた場合にファイルシステムの空き領域を使い切
MySQL :: MySQL 5.1 リファレンスマニュアル (オンラインヘルプ) :: 9.6.2 InnoDB 復旧の強制
もしデータベースページが破損したら、SELECT INTO ... OUTFILE を利用してデータベースからテーブルをダンプしたいかもしれません。通常、この方法で取得されたデータは無傷です。ただし、破損によって SELECT * FROM tbl_name ステートメントや InnoDB バックグラウンド操作がクラッシュしたりアサートしたり、または InnoDB 前進復旧がクラッシュしたり、ということが起こる可能性があります。そのような場合には、innodb_force_recovery オプションを使用することで、バックグラウンド処理が実行されないようにしながら InnoDB ストレージエンジンを強制的に起動することができます。そうすればテーブルのダンプを行えます。たとえば、サーバーを再起動する前に、オプションファイルの [mysqld] 節に次の行を追加することができます: [mys
memolib.com - memolib リソースおよび情報
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.
MySQL(MariaDB) - テーブルの検査・分析・最適化・修復！
mk-mode.com Linux, Debian, IT, Server, PG, Ruby, Rails, Python, C++, Fortran, PC, MariaDB, math, GIS, etc... MySQL もしくは MariaDB でのテーブルの検査・分析・最適化・修復についての備忘録です。 それほど日常的な作業でもなく忘れやすいので、その時のための個人的記録です。 0. 前提条件 MySQL 5.6.16 サーバでの作業を想定。（MySQL 5.5 系や MariaDB でも同じ。旧バージョンは未確認） ストレージエンジンが InnoDB であるデータベースでの作業を想定。 （以下の「チェック」や「分析」は可能だが、「最適化」や「修復」は不可（別の方法で行う）） 1. テーブルの検査 1-1. 特定のテーブルのみを検査する場合は、以下のようにする。
InnoDBをリカバリして学んだこと
とても情けない理由でデータベースを壊してしまい、リカバリをすることに。破損個所はその直前の作業から言って何千万件のレコードを持つInnoDB。考えただけで己の「ポチ」を恨みたくなりますが、唯一ラッキーだったのはそのレコードの99%以上はノイズ（必要の無いログなど）で、最終的にはサイズを1000分の1以下にする予定だったということ。じゃなかったら多分復旧には日単位で時間が掛かっていたと思われる… 以下、解ったこと。 INSERT、UPDATE、DELETE中のkill プロセス、ダメ、絶対。 いや知ってました。もちろん知ってましたけど、クエリが暴走して仕方なかったんですよ… クエリの動作結果に対する見積もりの甘さ その停止方法についての認識の甘さ（もう少し待ったら終了できてたかも） INSERT、UPDATE、DELETE中のkill プロセス、ダメ、絶対。 まず、ログを見よう。ログを追おう
MySQLが何度も「Starting crash recovery」を実行する
ポイ探ではありませんが、他のサイトでMySQLの接続が不安定になる不具合がありました。MySQLのログを見ると下記のようになっています。 ****** 11:02:44 mysqld_safe Number of processes running now: 0 ****** 11:02:44 mysqld_safe mysqld restarted ****** 11:02:45 InnoDB: Initializing buffer pool, size = 8.0M ****** 11:02:45 InnoDB: Completed initialization of buffer pool InnoDB: The log sequence number in ibdata files does not match InnoDB: the log sequence number in
MySQLのクラッシュバグにご用心 - wadahiroの日記
ちょっと間があいてしまいましたが、今回はMySQLのお話です。 現象 2カ月ほど調子よく動いていたMySQLがある日突然ダウンしてしまいました。 MySQLのエラーログを見ると、下記のアサーションエラーが記録されており、どうやらMySQLがクラッシュしてしまったようです。 110831 13:12:39 InnoDB: Assertion failure in thread 1043281332 in file row/row0sel.c line 4473 InnoDB: Failing assertion: trx->isolation_level == TRX_ISO_READ_UNCOMMITTED InnoDB: We intentionally generate a memory trap. InnoDB: Submit a detailed bug report to htt
MySQLに対して、カジュアルにやってはいけない事をやってみよう[追記アリ] - oranie's blog
※ブクマコメントで指摘頂いた箇所を追記しました＞＜ MySQL Casual Advent Calendar 2011 21日目の記事です。 前日は@sohgohさんの 「MySQLのUDFでカジュアルにファイル操作【MySQL Casual Advent Calendar 2011 20日目】」 でした。図や動画もあって見やすいですね！ 改めて自己紹介です。21日目を担当する、今回のカレンダーでNo.1カジュアルの座を狙っているid:oranie（オラニエ）です。 今回はMySQLもそこそこで、僕の名前の正しい読み方だけを覚えてくれれば今日は大丈夫です。 意図的に間違えている人もたまにいますが、心が汚れすぎていると思うのでお寺で座禅とかした方がいいと思います。 今までの記事を拝見させて頂き、みんな真面目に色々Tipsを書いているのでニッチ狙い＆初心者の僕は 「MySQLに対して、カジュア
![MySQLに対して、カジュアルにやってはいけない事をやってみよう[追記アリ] - oranie's blog](https://cdn-ak-scissors.b.st-hatena.com/image/square/e7aa7259082e2b3a6d5f7863e2a9b834b82248ad/height=288;version=1;width=512/https%3A%2F%2Fogimage.blog.st-hatena.com%2F13208692334729889652%2F8454420450078344003%2F1419834482)
MySQL ibdata1が肥大化する理由(記事の意訳) | Ore no homepage
毎日暑い…。というか蒸し暑い。何年か前にベトナムとカンボジアをバックパッカー旅行したときを思い出す。日本の気候が亜熱帯ってか東南アジアっぽくなってきたような…昔はこんな頻繁にゲラリ豪雨とか降らなかったよねー？温暖化ってやつ？日本の植生とか変わるんじゃねーのかな…。 えーと、おれがよく見ている技術ブログの一つにPercona社のMySQL Performance Blogがある。そのブログに先日、「Why is the ibdata1 file continuously growing in MySQL?」という記事が投稿された。内容はInnoDBのibdata1の肥大化とその解消方法に関するもの。ibdata1の肥大化を解消する手段は、ダンプをとってDBを作り直してあげないと治らないということは多くのInnoDBユーザが知っていることだと思うけど、おれもInnoDBを触り始めたころは、「気
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
MySQL :: MySQL Forums
MySQL :: MySQL 8.4 Reference Manual :: 17.20.3 Forcing InnoDB Recovery