タグ

関連タグで絞り込む (1)

タグの絞り込みを解除

mysqlとinnodbに関するjitsu102のブックマーク (17)

  • MySQL InnoDB Cluster入門

    データベースの設計や運用において、エンジニアが最も頭を悩ませる問題の一つに、データの不整合を防ぐことがあるかと思います。これは信頼性やパフォーマンスの向上に直結するものとなります。 MySQL InnoDB Clusterは、複数のMySQLサーバー間でデータを同期し、一貫性のあるデータベースを提供するための強力な仕組みとなるものです。 そこでInnoDB Clusterの基概念や、主要コンポーネントの役割についてまとめてみました。 MySQL InnoDB Clusterとは MySQLデータベースにおいて高可用性を実現するための技術で、自動フェイルオーバー機能を提供します。 これにより、データベースシステムのダウンタイムを最小限に抑えることが可能になります。 MySQL InnoDB Clusterを使用する目的と理由 InnoDB Clusterは、複数のデータベースサーバーを組み

    MySQL InnoDB Cluster入門
  • MySQLのInnoDB テーブルの断片化(フラグメンテーション)を解消する - Qiita

    概要 InnoDB では、追加・更新・削除操作を繰り返していると、断片化(フラグメンテーション)という現象が発生します。 これはいわば、ゴミみたいなもので、テーブルのデータを削除してもディスク容量が減りません。 このゴミが増えてくると、クエリ処理が遅くなる可能性があリます。 例えばレコードが100万件あるテーブルの内、99万9999件を削除し1件の状態にしても、テーブルが占有している領域は100万件分使っているということになります。 今回は実際にテストデータを作成し、フラグメンテーションの発生とその解消法について確認していきたいと思います。 フラグメンテーションの詳細については記事では述べないので、気になる方は下記記事が分かりやすかったのでご参照ください。 前提 MySQL 5.7.31 InnoDB テストデータの挿入 まずテスト用のDBとテーブルを作り、約100万件テストデータを挿入

    MySQLのInnoDB テーブルの断片化(フラグメンテーション)を解消する - Qiita
  • [MySQL] 断片化した InnoDB テーブルを最適化する

    MySQL の InnoDB では、断片化(フラグメンテーション)という現象が発生する。 フラグメンテーションが発生すると、クエリ処理が遅くなったり、サーバーの容量をたくさん使い問題が起こる。フラグメンテーションを解消するには最適化をおこなう。 断片化についてと最適化の方法に関するメモ。 断片化(フラグメンテーション)とは 断片化とは、ディスク上のインデックスページの物理的な順序がページ上のレコードのインデックス順序とかけ離れているか、またはインデックスに割り当てられた 64 ページのブロック内に未使用のページが多数存在することを示します。 MySQL 5.6 リファレンスマニュアル – 14.10.4 テーブルのデフラグ DB で DELETE クエリを実行すると、すぐに物理的な削除は行われない。削除フラグ的なのがつけられる論理削除となる。 なので、このレコードがあった場所には穴が空いた

    [MySQL] 断片化した InnoDB テーブルを最適化する
  • GitHub - jeremycole/innodb_ruby: A parser for InnoDB file formats, in Ruby

    You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert

    GitHub - jeremycole/innodb_ruby: A parser for InnoDB file formats, in Ruby
  • MySQL InnoDBの領域管理 - Qiita

    武蔵野Advent Calendar 2017の20日目の記事です。品川から参加しています。 今日はMySQL InnoDBの領域管理について勉強し、いくつか動作例を見ながらInnoDBに対する理解を深めていきたいと思います。アプリケーション開発者やデータベース管理者の方にとって明日からすぐに使えるノウハウとまではいきませんが、いつか何かの役に立てば幸いです。 まとめ InnoDBにはテーブルスペース、セグメント、エクステント、ページというデータの管理単位があるよ エクステント単位で空き領域が管理されているよ。だけどそれを知ったところであまり役には立たないよ 昇順INSERTが得意でランダムINSERTが苦手なのはよく知られているけれど、実は降順INSERTが得意だよ テーブルスペース、セグメント、エクステント、ページ InnoDBのデータが格納されるファイルのことをテーブルスペースと呼び

    MySQL InnoDBの領域管理 - Qiita
  • show innodb status

    Spring Bootのオートコンフィグレーションの恩恵によって、開発者はコンフィグレーションの煩わしさから解放され、Springを容易に動かすことができるようになりました。その反面、ブラックボックスになってハマってしまうことも少なくありません。セッションでは、Spring Bootのオートコンフィグレーションの仕組み・デバッグ方法・カスタマイズ方法を説明します。セッションを聞いてオートコンフィグレーションを便利に使っていきましょう。 (Spring Fest 2021での発表資料)

    show innodb status
  • なぜあなたは SHOW ENGINE INNODB STATUS を読まないのか - そーだいなるらくがき帳

    この記事は、MySQL Casual Advent Calendar 2017の20日目の記事です。 煽り気味のタイトルですがみなさん SHOW ENGINE INNODB STATUS 読んでますか? SHOW ENGINE INNODB STATUS \G 見づらいのなんとかならんのか。— そーだい@初代ALF (@soudai1025) 2016年12月20日 わかる。でもMySQLの振る舞いを知る中でSHOW ENGINE INNODB STATUSを読まざる得ない場面はそこそこあります。 どんな時に必要になるのでしょうか? そこでSHOW ENGINE INNODB STATUSにまつわる話を書きます。 SHOW ENGINE INNODB STATUS をまず読みやすくする まず末尾に \G を付けましょう。 これで3倍読みやすくなります。 次に pager less -S を

    なぜあなたは SHOW ENGINE INNODB STATUS を読まないのか - そーだいなるらくがき帳
  • なるべく負荷をかけずにInnoDBバッファプールに載っているページの情報を見る

    TL;DR information_schema.innodb_buffer_page は重い ib_buffer_pool にはテーブルスペースIDが記録されるので、それを使ってほげほげする こんな感じ? mysql> SET GLOBAL innodb_buffer_pool_dump_now = 1; mysql> SELECT space, name FROM information_schema.innodb_sys_tablespaces INTO OUTFILE '/tmp/space.txt'; $ awk -F, '{print $1}' /var/lib/mysql/ib_buffer_pool | sort | join - <(sort /tmp/space.txt) | uniq -c | sort -n -r -k 1 | head 54570 50 hogeh

  • InnoDBのウォームアップに別サーバでdumpしたib_buffer_poolを使ってみる - mikedaの日記

    MySQLでスレーブを複数台並べている。 負荷増加やサーバ障害で新規スレーブを追加したい。 で、構築したばかりのMySQLスレーブをいきなりサービスに突っ込むとどうなるか。 それなりの規模のサービスであれば、buffer_poolが空っぽのDBだとIOがつまって応答遅延が発生します。 というわけでサービス投入前にbuffer_poolのウォームアップが必要で、方法としてはいくつか考えられます。 クエリを実行して主要テーブルのIndexをロードする 低い振り分け比率でサービスに投入してしばらく待つ tcpdump + (mk|pt)-query-digest等で既存スレーブのクエリを流し込む 基的にサービス投入前の完璧なウォームアップは無理ゲーなので、 普段は主要テーブルのIndexを読み込んでから、低い振り分け比率でサービス投入、ディスクIO見ながら徐々に振り分け比率を上げていく、という

    InnoDBのウォームアップに別サーバでdumpしたib_buffer_poolを使ってみる - mikedaの日記
  • MySQL 5.7.9のinnodb_default_row_formatがまた何か企んでいるようです

    MySQL 5.7.9では innodb_default_row_format というサーバー変数が追加される(らしい。5.7.9はリリース前なので試せない) オンライン変更可能なグローバル変数なので、`SET GLOBAL innodb_default_row_format= ..'で変更も可能。暗黙のデフォルトは"Dynamic"。 名前と値から察せられる通り、kamipoさん の悲願をかなえる類のもの…なんだけれども、 MySQL(InnoDB) で "Index column size too large. The maximum column size is 767 bytes." いわれるときの対策 - かみぽわーる これ、 The innodb_file_format configuration option is ignored if a table is created

  • MySQL InnoDBの圧縮に関する雑感 | Ore no homepage

    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

    jitsu102
    jitsu102 2014/08/03
    レプリ遅延しやすくなるみたい
  • RHEL 6.3バンドル版MySQL 5.1.61がInnoDB Pluginをサポート - SH2の日記

    タイトルでエントリの内容はほぼ終了となりますが、6月20日にRed Hat Enterprise Linux 6.3がリリースされ、ディストリビューション付属版のMySQL 5.1.61においてようやくInnoDB Pluginが有効化されました。 redhat-release enhancement update for Red Hat Enterprise Linux 6.3 Low: mysql security and enhancement update The InnoDB storage engine is built-in for all architectures. This update adds InnoDB Plugin, the InnoDB storage engine as a plug-in for the 32-bit x86, AMD64, and I

    RHEL 6.3バンドル版MySQL 5.1.61がInnoDB Pluginをサポート - SH2の日記
  • mysqlのログファイルのサイズを変更する - よかろうもん!

    バイナリデータを格納するために、BLOB型やその拡張のMEDIUMBLOB型を利用するシーンが時折あるかと思います。 BLOB型を利用していて、サイズの大きなデータをDBに格納しようとすると、MySQLのログに以下のようなエラーログが出力されることがあります。 100906 00:00:00 InnoDB: ERROR: the age of the last checkpoint is 9440228, InnoDB: which exceeds the log group capacity 9433498. InnoDB: If you are using big BLOB or TEXT rows, you must set the InnoDB: combined size of log files at least 10 times bigger than the InnoDB:

    mysqlのログファイルのサイズを変更する - よかろうもん!
  • MySQL innodb_flush_method = O_DIRECTの検討 - SH2の日記

    MySQL InnoDBのパラメータでinnodb_flush_methodというものがあります。これはUNIX/Linuxにおいてデータファイル、ログファイルの読み書き方式を指定するためのもので、マニュアルの13.6.3. InnoDB Startup Options and System Variablesによると以下の3種類の設定が可能とされています。 無指定(fdatasync):デフォルトの設定です。特別なフラグなしでファイルをオープンし、書き込み時にfsync()を行います。 O_DSYNC:データファイルについてはfdatasyncと同じです。ログファイルについてO_SYNCフラグをつけてファイルをオープンします。 O_DIRECT:データファイルについてO_DIRECTフラグをつけてファイルをオープンします。ログファイルについてはfdatasyncと同じです。 今回はこのパ

  • AndroidのNFC機能でFeliCaの読み書きをする | −ゆめログ− | ゆめみスタッフブログ

  • InnoDBのログとテーブルスペースの関係

    InnoDBのデータ領域はログファイルとテーブルスペースという、切っても切れない2種類のファイルから構成されている。ログファイルは名前からするとただのログだから削除しても平気かな?と思って削除してしまうという問題が後を絶たない。そこで、今日はログファイルとテーブルスペースの関係について説明しようと思う。 InnoDBのログファイルは、別名WAL - Write Ahead Logと呼ばれるもので、名前を日語に直すと「前もって書き込んでおくためのログ」とでも呼べるだろうか。InnoDBのテーブルに対して行われた更新は、全ていったんログに書き込まれるのである。トランザクションがコミットされると、innodb_flush_log_at_trx_commit=1が設定されていればログファイルに書き込みが行われる。0または2の場合には、ログバッファと呼ばれる領域にデータが保持される。その後、時間を

    InnoDBのログとテーブルスペースの関係
  • KLab

    ご指定のページが見つかりませんでした URLの変更、もしくはページが削除された可能性があります。 お手数ですが、以下のリンクから目的のページをお探しください。

    KLab
  • 1