質問をすることでしか得られない、回答やアドバイスがある。

15分調べてもわからないことは、質問しよう!

新規登録して質問してみよう
ただいま回答率
85.50%
MySQL

MySQL(マイエスキューエル)は、TCX DataKonsultAB社などが開発するRDBMS(リレーショナルデータベースの管理システム)です。世界で最も人気の高いシステムで、オープンソースで開発されています。MySQLデータベースサーバは、高速性と信頼性があり、Linux、UNIX、Windowsなどの複数のプラットフォームで動作することができます。

Q&A

解決済

2回答

1076閲覧

MySQL「InnoDB: ERROR: the age of the last checkpoint is」のエラーが解消しない

saken649

総合スコア60

MySQL

MySQL(マイエスキューエル)は、TCX DataKonsultAB社などが開発するRDBMS(リレーショナルデータベースの管理システム)です。世界で最も人気の高いシステムで、オープンソースで開発されています。MySQLデータベースサーバは、高速性と信頼性があり、Linux、UNIX、Windowsなどの複数のプラットフォームで動作することができます。

2グッド

3クリップ

投稿2018/03/12 06:31

編集2018/03/12 06:54

前提・実現したいこと

teratailユーザーの皆様にはお世話になっております。
現在私が運用保守を担当しているシステムにて、数週間前より、早朝のバッチが実行される度に、MySQLからInnoDB: ERROR: the age of the last checkpoint isのエラーが出続けている状態のため、これを解消したいです。
現在担当しているメンバー全員で対応するも解決策が全く出ない状態のため、こちらでも質問させて頂きました。

発生している問題・エラーメッセージ

InnoDB: ERROR: the age of the last checkpoint is 966364022, InnoDB: which exceeds the log group capacity 966363956. 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: largest such row.

当エラーが出る処理は、text型を含むテーブル相手に100万回以上のREPLACE文が走る処理です。
そもそもの作りが良くない気はしますが。。。

試したこと

http://interu.hatenablog.com/entry/20100907/1283786596
こちらによると、エラーの原因に、text型のカラムが関係していそうだったため、以下の対応を行いました。

  • 対象と思われるテーブルにALTER TABLE MODIFYを実行し、text型のカラムを、varchar型に変更

 => ログを元に、エラー発生時間に書き込みが行われているテーブルにtext型のカラムが存在していました。
そのカラムは、text型である理由が無いためvarchar型に変更しました。

なお、innodb_log_file_size の値の変更は 行っていません。
一年ほど前に一度変更(256M→512M)してしばらく出なくなったそうですが、一年経った今また出てきたため、今後データが加速度的に増え続けることを考えるとキリが無く、エラー内容的に「まずBLOB型関連を疑って」「いろいろやってダメなら最終手段として変更」しよう、というPMO判断によるものです。

それ以外に方法が無い、というのであれば、大人しくinnodb_log_file_size の値を上げることを提案しようと思います。。

補足情報(FW/ツールのバージョンなど)

my.cnfの設定のうち、関連しているだろう、と思われるものを記載致します。

paramvalue
innodb_buffer_pool_sixe4096M
innodb_additional_mem_pool_size20M
innodb_log_buffer_size16M
innodb_log_file_size512M
innodb_log_files_in_group2

その他の情報

paramvalue
MySQLバージョン5.1
MySQLサーバーメモリ6G
処理に使用している言語Perl
  • 対象のテーブルには、レコードが100万件以上入っています。そこに対して100万回以上のREPLACE文が走ります。
  • トランザクション制御は 一切行われていません。 (それもそれでどうなんだろう、とは思うのですが)
  • エラーハンドリングもあまりされていない処理なので、このエラーが出ていつつもガン無視して バッチ自体はちゃんと動いています。 (データが欠落した形跡も無さそうです)

その他気になっていること

直接関係しているのか、調べてもよく分からないでいるのですが、これはこれで気になっていることも参考として記載しておきます。

  • SHOW ENGINE INNODB STATUSの結果を見ると、TRANSACTION 0 117359796, not started,という内容がたくさん出ており、 トランザクションがロックを取得したままになっている? というのが確認出来ています。

 => ただし先述の通り、プログラム上でのトランザクション制御は行っていないはずなので、何だこれは。。?というのが正直なところです。

  • Log sequence numberLast checkpoint at より先行しているのでは?」というPMOの指摘があり確認してみましたが、特にそうで無いようなので、恐らくログファイルは全て書き込み出来ているものと思われます。
--- LOG --- Log sequence number 149 2813945280 Log flushed up to 149 2813945280 Last checkpoint at 149 2813945280 0 pending log writes, 0 pending chkp writes 4234543 log i/o's done, 0.00 log i/o's/second
  • Free buffersの値がえらく低いので、バッファはもしかしたら足りてないのでしょうか。
---------------------- BUFFER POOL AND MEMORY ---------------------- Total memory allocated 4764871170; in additional pool allocated 20963072 Dictionary memory allocated 2090384 Buffer pool size 262144 Free buffers 20 Database pages 255180 Modified db pages 0 Pending reads 0 Pending writes: LRU 0, flush list 0, single page 0 Pages read 22071024, created 2663468, written 15337711 0.00 reads/s, 0.00 creates/s, 0.00 writes/s Buffer pool hit rate 1000 / 1000
  • 同一サーバー上に別スキーマで別システムのDBも共存 しており、全体のデータ容量はかなり多いです。

 ただし、エラー発生時刻に、別システムのバッチは動いていないはずなので、影響は無いものと思われます。


以上、かなり記述内容が多くなってしまいましたが、何卒お力添え頂けますと幸いです。
MySQLの設定周りはまだ知識が浅いため、他に必要な情報がありましたらご指摘ください。
よろしくお願い致します。


補足

上述していますが、ログファイルのサイズ設定が小さい、で終了なのでしょうか。
BLOB型云々は関係無く、やはりそこに行きつくのでしょうか。

ログファイルのサイズを変更すると、今後データ量が増えるたびにその値も増やさなければいけないのか。。という話になっているので、それを把握しておきたいです。
それともそういうものなのでしょうか。。

m.ts10806, yukapome789👍を押しています

気になる質問をクリップする

クリップした質問は、後からいつでもMYページで確認できます。

またクリップした質問に回答があった際、通知やメールを受け取ることができます。

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

guest

回答2

0

・対象のテーブルには、レコードが100万件以上入っています。そこに対して100万回以上のREPLACE文が走ります。
・トランザクション制御は 一切行われていません。 (それもそれでどうなんだろう、とは思うのですが)

で、innodb_log_file_sizeを

一年ほど前に一度変更(256M→512M)してしばらく出なくなったそうですが、一年経った今また出てきたため、今後データが加速度的に増え続けることを考えるとキリが無く、エラー内容的に「まずBLOB型関連を疑って」「いろいろやってダメなら最終手段として変更」しよう、というPMO判断によるものです。

ということですから、
・innodb_log_file_sizeに収まるよう、トランザクションを分割する
事をしない限り、データが収まり切れなくなる度に起こるんだと思います。

ある程度の件数による分割とデータ的に並列処理可能なら、処理性能の向上も見込めると思いますけどね。

投稿2018/03/12 07:04

編集2018/03/12 07:23
sazi

総合スコア25138

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

saken649

2018/03/12 08:11

sazi様 ご回答有難うございます。 > ・innodb_log_file_sizeに収まるよう、トランザクションを分割する > 事をしない限り、データが収まり切れなくなる度に起こるんだと思います。 仰る通り、それが一番の懸念点で、この調子ではキリが無いどころか天井がありそうで。。 ただ不思議なのが、トランザクション制御を一切しておらず、またautocommitもオンになっているので、恐らくトランザクションが逼迫するようなことは無いのだろう、という認識なのですが。。。 もしかしてその認識が間違っているでしょうか。 並列処理も可能なのだろうとは思いますが、結局1つのマスタに集約されるので難しそうです。。
sazi

2018/03/12 14:22 編集

autocommit=ONでデータ処理を行ったなら、自動的にトランザクションが開始されて、自動でコミットされる訳です。 begin ~ commit; などの制御を行っていなくてもトランザクションは発生しますので、ログバッファは使用されます。 http://atsuizo.hatenadiary.jp/entry/2016/12/05/000000
guest

0

ベストアンサー

ログファイルのサイズが小さい って怒られています。このURLに対応方法も載っています。

投稿2018/03/12 06:37

Orlofsky

総合スコア16415

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

saken649

2018/03/12 06:44

Orlofsky様 早速の回答有難うございます。 BLOB型云々は関係無く、やはりそこに行きつくのでしょうか。 また、BLOB型を無くしてもなお、ログファイルのサイズが影響するのでしょうか。 ログファイルのサイズを変更すると、今後データ量が増えるたびにその値も増やさなければいけないのか。。という話になっているので、それを把握しておきたいです。 それともそういうものなのでしょうか。。
Orlofsky

2018/03/12 06:52

通常データ量が多いから BLOB や TEXT が挙げられているのでしょう。データ型を変えてもサイズが変わらないとか、去年よりデータ量が増えているとかでログファイルがパンクしているのでは? 本番データを開発環境に持って行ってログファイルのサイズを大きくして質問のエラーが出なくなるか確認されては?
saken649

2018/03/12 08:00

Orlofsky様 > 通常データ量が多いから BLOB や TEXT が挙げられているのでしょう。 そういうことなのですね。理解しました。 確かに圧倒的にデータが増えているのは確かなので、ログファイルがパンクしている、という可能性は十分あるかもしれません。 本番データそのものは持っていけないのですが、本番同等のレコード数まで水増しするスクリプトは以前作ったので、それで試してみたいと思います。
guest

あなたの回答

tips

太字

斜体

打ち消し線

見出し

引用テキストの挿入

コードの挿入

リンクの挿入

リストの挿入

番号リストの挿入

表の挿入

水平線の挿入

プレビュー

15分調べてもわからないことは
teratailで質問しよう!

ただいまの回答率
85.50%

質問をまとめることで
思考を整理して素早く解決

テンプレート機能で
簡単に質問をまとめる

質問する

関連した質問