サクサク読めて、
アプリ限定の機能も多数！
アプリで開く
redo ログは、不完全なトランザクションによって書き込まれたデータを修正するためにクラッシュリカバリ中に使用されるディスクベースのデータ構造です。 通常の操作中、redo ログは、SQL ステートメントまたは低レベルのAPI コールによって発生したテーブルデータを変更するリクエストをエンコードします。 予期しないシャットダウンの前にデータファイルの更新を終了しなかった変更は、初期化中、および接続が受け入れられる前に自動的にリプレイされます。 クラッシュリカバリにおける redo ログの役割の詳細は、セクション15.18.2「InnoDB のリカバリ」 を参照してください。 デフォルトでは、redo ログはディスク上で ib_logfile0 および ib_logfile1 という名前の 2 つのファイルによって物理的に表されます。MySQL は、redo ログファイルに循環して書き込
自分の浅はかな理解だと、Deadlock が起こる理由が説明できないケースに遭遇したので、InnoDB の行レベルロックについて調べてまとめてみました。 「行レベルロックだと、同じ行を更新する場合にしか Deadlock が起こらないんでしょ」と思っているような人が対象です。 また、主に InnoDBのロックの範囲とネクストキーロックの話 - かみぽわーる を参考にさせていただいたので、そちらの内容がすんなり理解できる方には冗長な内容だと思います。MySQL のバージョンは 5.6.33 です。 サンプルデータ 次のSQL で作成したデータを扱うことにします。CREATE TABLE `orders` ( `id` int(10) unsigned NOT NULL AUTO_INCREMENT, `product_id` int(10) unsigned NOT NULL, `us
doublewrite とは？ InnoDB が備わっている「データ二重書き込み」によるデータ保護機能。最初から有効になっている。1 この機能はトランザクションログとは別なので混同しないように。MySQL Server での説明 https://dev.mysql.com/doc/refman/5.7/en/innodb-doublewrite-buffer.html MariaDB Server での説明 https://mariadb.com/kb/en/library/xtradbinnodb-doublewrite-buffer/ Percona Server での説明 https://www.percona.com/doc/percona-server/5.5/performance/innodb_doublewrite_path.htmlSSD/HDD 混在環境のために d
InnoDBのREPEATABLE READにおけるLocking Readについての注意点本日は、MySQL Casual Advent Calendar 2013の20日目である。というわけでカジュアルに小ネタを紹介しよう。 MVCC - Multi Version Concurrency Controlご存知の通り、InnoDBはMVCCを実装している。そのため、分離レベルがREPEATABLE READの場合には、行にロックをかけることなく、一貫した読み取りが可能になっている。 もし、あるトランザクションT1開始後に、別のトランザクションT2によって同じ行が書き換えられてしまった場合には、T1はロールバックセグメントにある古いバージョンの値を読み取ることができるので、T1内で実行したSELECTは常にT1開始時点のデータを参照することができるのである。大事なのでもう一度言うが、REPEATABLE READにおける単純なSELECTでは行ロックは必要ない。 Lost Up
■ はじめに 現実を前にして正規化などといった理想を捨て去ったとある人は、 とある日とあるスキーマに全知全能の神を降臨させようと画策した。 すなわちTEXT型の列を大量に備えたテーブルを用意して、 あらゆる情報と状況を何とかしてもらおうと企図したのだった……！！ ■ やってみるMySQL5.6を実行できる環境を用意して、 とりあえず以下のようなCREATE TABLE文を叩いてみる。mysql>CREATE TABLE zeus ( -> col1TEXT -> , col2TEXT -> , col3TEXT -- 中略 -> , col195TEXT -> , col196TEXT -> ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;ERROR 1118 (42000): Row size too large (> 8126). Ch
MySQLのFLUSH構文は、内部キャッシュのクリア、リロード、ロックの取得、テーブルのフラッシュなど、構文によってさまざまなことを実行します。今回はFLUSH構文について説明していきます。なお、今回の例で使用しているMySQLのバージョンは8.0.11、各テーブルはInnoDBを想定しています。 FLUSHLOGS構文 FLUSHLOGS構文を利用して各ログファイルをスイッチさせるには、FLUSH <log_type>LOGSを実行します。log_typeに入るのは、BINARY, ENGINE,ERROR, GENERAL, RELAY,SLOWです。BINARY、RELAYの場合は、FLUSH <log_type>LOGSを実行すると番号を繰り上げたバイナリログまたはリレーログファイルを生成し、ログスイッチをします。 また、FLUSH RELAYLOGS FOR CHAN
[MySQL]原文 Tuning InnoDB Primary Keys - PerconaDatabase PerformanceBlog (English) 原文著者 Yves Trudeau 原文公開日 2018-07-26 翻訳依頼者 翻訳者 kakuka4430 翻訳レビュアー doublemarket 原著者への翻訳報告 2374日前 原文へのコメントで報告済み 編集 良いInnoDBプライマリキーを選ぶことは、パフォーマンスチューニングの方向性にとても重要です。この記事では、あなたのワークロードに応じた最適なプライマリキーを選ぶための方法を紹介したいと思います。 Percona社のプリンシパルアーキテクトとしての私の責務の一つは、顧客のデータベースをチューニングすることです。パフォーマンスチューニングに関連する側面は多く存在し、それがこの仕事を複雑、かつ大変興味深いものに
All of Percona’s open source software products, in one place, to download as much or as little as you need.
MySQLがメモリー不足で停止してしまった(OOM Killerに停止させられた)時に確認すべき項目を紹介する。特に、MySQLのバグでメモリリークが起きている可能性がある場合に手がかりを得る方法について。 [MySQL]原文 What To Do WhenMySQL Runs Out of Memory: TroubleshootingGuide - PerconaDatabase PerformanceBlog (English) 原文著者Alexander Rubin 原文公開日 2018-06-28 翻訳依頼者 翻訳者 doublemarket 翻訳レビュアー kakuka4430 原著者への翻訳報告 2299日前 原文へのコメントで報告済み 編集 クラッシュした時のトラブルシューティングが楽しいタスクであったためしはありませんが、クラッシュの原因をMySQLが教えてくれ
武蔵野Advent Calendar 2017の20日目の記事です。品川から参加しています。 今日はMySQL InnoDBの領域管理について勉強し、いくつか動作例を見ながらInnoDBに対する理解を深めていきたいと思います。アプリケーション開発者やデータベース管理者の方にとって明日からすぐに使えるノウハウとまではいきませんが、いつか何かの役に立てば幸いです。 まとめ InnoDBにはテーブルスペース、セグメント、エクステント、ページというデータの管理単位があるよ エクステント単位で空き領域が管理されているよ。だけどそれを知ったところであまり役には立たないよ 昇順INSERTが得意でランダムINSERTが苦手なのはよく知られているけれど、実は降順INSERTが得意だよ テーブルスペース、セグメント、エクステント、ページ InnoDBのデータが格納されるファイルのことをテーブルスペースと呼び
Percona XtraBackup（以降、PXB）とは、Percona社が公開しているオンラインでMySQLのバックアップを取得できるOSSツールです。 一般的にMySQLのバックアップはmysqldumpクライアントを使用するかと思います。mysqldumpは論理バックアップであり、データベース内のデータをテキスト（INSERT文）として保存します。そのため、リストアにはINSERT文を使用しなければならず、遅いのが難点です。 今回紹介するPXBは、物理バックアップであり、実際のデータベースのファイルを物理的にコピーすることでバックアップを取得します。リストアはそのファイルに対して、バックアップの開始時間からの差分データをリカバリしてファイルを配置するだけなので、論理バックアップのリストアよりも高速です。 Percona XtraBackupの動作について PXBは、トランザクションに
日々更新されるテーブルは、想定していたよりも予想外に更新が増え、サイズが肥大化してストレージの問題が発生することがあると思います。今回はそれを未然に防ぐため、InnoDBのテーブルサイズを確認する方法をいくつか紹介します。今回の例ではMySQLのバージョン5.7.19を使用します。 TABLESテーブル はじめに、InnoDBのテーブルとインデックスサイズを確認する方法として、information_schema内のtablesテーブルを見るのが一般的だと思います。ただし、このテーブルは統計情報から取得されるため正確な値ではありません。概算値となります。mysql> SELECT TABLE_NAME,ENGINE,DATA_LENGTH,INDEX_LENGTH,DATA_FREE FROM information_schema.tables WHERE TABLE_NAME = 't
MySQLのInnoDBストレージエンジンは行ロックをサポートしています。しかしOracleと同じ感覚でアプリケーションを作っていると、思わぬところでデッドロックに出くわすことがあります。これはInnoDBのロック範囲がOracleよりも微妙に広いためです。 実際の例で確認してみましょう。mysql> select * from t; +----+------+ | c1 | c2 | +----+------+ | 10 | a | | 15 | a | | 20 | a | | 25 | a | | 30 | a | | 35 | a | | 40 | a | | 45 | a | | 50 | a | +----+------+c1列は主キーになっています。1つめのセッションで以下のSQLを実行します。mysql> set tx_isolation = 'repeatable-r
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Known issues and limitations for Amazon RDS for MySQL - Amazon Relational Database Service
