この記事で

 

症状

リーズン

ソリューション

回避策

恒久的な解決

リファレンス

適用範囲：
MySQLサーバのバージョン5.0以上
この資料の情報は、すべてのプラットフォームに適用されます。

症状

MyISAMテーブルにDMLを使ったら (inserts, deletes, selectsなど)，以下のトラブルになるかもしれない：

101001 14:57:57 [ERROR] ./bin/mysqld: Table ‘./test/t2’ is marked as crashed and last (automatic?) repair failed

 

原因

Bug 11764345 –SHOW TABLE STATUS + SMALL MYISAM_SORT_BUFFER_SIZE IN REPAIR, TABLE CRASHE

 

当小的myisam_sort_buffer_size与repair by sort发生，且有人运行 ‘show

table status’ 或引用表selects from information_schema tables，错误在日志中出现。当check table在运行时，表不显示损坏。

 

解決策

一時的な方法：

1.トラブルテーブルREPAIR TABLEでテーブルをリカバリする。

2. myisam_sort_buffer_size変数の数値を増やし、bugの発生を防ぐ

永久な解決策：

持続的にモニタリングBug 11764345。トラブルをモニタリングして， DocID 1298390.1 How to Monitor a Code or Enhancement Request (ER) Bug from My Oracle Support の指示に従う。

 

リファレンス

BUG:11764345 SHOW TABLE STATUS + SMALL MYISAM_SORT_BUFFER_SIZE IN REPAIR,

この記事で
ターゲット
ソリューション
リファレンス

適用範囲：
MySQLサーバのバージョン5.6以上
この資料の情報は、すべてのプラットフォームに適用されます。

ターゲット

Windowsシステムで，OPTIMIZE TABLEは4GBに超えたMyISAMテーブルを壊れた。

 

解決策

Windowsで作成したbugが損害を引き起こした：

 

http://bugs.mysql.com/bug.php?id=69683

BUG 17235179 OPTIMIZE AFTER A DELETE RETURNS ERROR 0 CAN’T GET STAT OF MYD FILE

 

解決策は5.6.19あるいはより新しいバーションにアップロードする。

 

リファレンス

BUG:17235179 –OPTIMIZE AFTER A DELETE RETURNS ERROR 0 CAN’T GET STAT OF MYD FILE

この記事で
ターゲット
ソリューション
リファレンス

適用範囲：

MySQL サーババーションは4.0から5.7 まで[リリース4.0から5.7まで]

どんなプラットフォームにも適用する

 

目標

トラブル：

InnoDBがこのようなエラをエラログに報告したら、mysqld.exe崩壊した：

 

130820 13:37:44 InnoDB: Operating system error number 1117 in a file operation.

InnoDB: Some operating system error numbers are described at

InnoDB: http://dev.mysql.com/doc/refman/5.5/en/operatingsystemerrorcodes.

html

InnoDB: File operation call: ‘flush’.

InnoDB: Cannot continue operation.

 

解決策

アドバイス：

これはInnoDBやMySQLのせいじゃない

该问题是由于硬盘，控制器，驱动或操作系统。

このトラブルはディスク、コントローラー、ドライブあるいはオペレーションシステムによるものである。

 

ERROR_IO_DEVICE

1117 (0x45D)

The request could not be performed because of an I/O device error.

 

完全なデータを持っているバックアップに対して、ハードウェアでトラブルを検出して、それをリカバリするかほかの何かで代わってあげるかを考えてください。

この記事で
ターゲット
ソリューション
InnoDBは破損の原因
リファレンス

適用範囲：
MySQLサーバのバージョン5.0以上
この記事では、すべてのプラットフォームに適用されます

目標：

InnoDB損害を起こすよくある原因を学んで、そしてそれを防ぐ

 

解決策

InnoDB損害な原因

InnoDB損害について主に四つの原因がある：

• ハードウェア損害(一般的にはディスクやメモリーにある)
• シャットダウン (例えば電源が切れたあるいはオペレーションシステムのbugによるもの)
• Bugs
• 整合性がないバックアップ

Error Correction Codeを使った場合を除いて、ディスクエラを防ぐ方法はあまりいない。

 

電源が切れたよるシャットダウンに対してUPSは最善な保護である。オペレーションシステムbugによるシャットダウンに対して（幸いこれは極まれに起こっている）、電池バックアップのディスクが一部の書き込むことを防げる。一般的にはinnodb_flush_log_at_trx_commit = 1でディスクに書き込むことを確保する。

だが、電池バックアップディスクは保護だから、オペレーションシステムあるいはディスクが実際に上書きされていないかもしれない。

 

変更ログでアップロード必要があるかを確認してください。さもなければ、bugを防げない。変更ログが以下のものにある：

• MySQL 5.0
• MySQL 5.1
• MySQL 5.5
• MySQL 5.6
• MySQL 5.7

 

一般的に、バックアップは予想したよりもっと壊されやすい。この場合の原因はFLUSH TABLES WITH READ LOCKで、InnoDBはまだ底でデータファイルを書き込む。これはこのバックアップ方法がMyISAMに効くが、InnoDBに適用していないと意味する

 

どんな場合にも、常にバックアップを用意することとバックアップをテストすることを勧めている。

 

この記事で
症状
その理由
ソリューション
リファレンス

適用範囲：
MySQLサーババージョン4.0以上

症状：

MyISAMテーブルをリカバリするときに、”Table ‘x’ is read only”エラはどういう意味か、どうやってリカバリできるか。

mysql> repair table t;

+‐‐‐‐‐‐‐‐+‐‐‐‐‐‐‐‐+‐‐‐ ‐‐‐‐‐‐‐+‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐+

| Table | Op | Msg_type | Msg_text |

+‐‐‐‐‐‐‐‐+‐‐‐‐‐‐‐‐+‐‐‐‐‐‐‐‐‐‐+‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐+

| test.t | repair | Error | Table ‘t’ is read only |

| test.t | repair | status | Operation failed |

+‐‐‐‐‐‐‐‐+‐‐‐‐‐‐‐‐+‐‐‐‐‐‐‐‐‐‐+‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐+

 

原因：

このトラブルについて可能な原因は二つがある。

1. MyISAMファイルにMYDかMYIに権限トラブルが起きて、それにmysqldプロセスが上書きできない。
2. MyISAMを凍結する

MyISAMテーブルが凍結/運用されたかをチェックする

show table status like ‘t’;

もし凍結されたら，Row_format は “Compressed”を映す:

mysql> show table status like ‘t’\G

 

 

 

*************************** 1. row ***************************

Name: t

Engine: MyISAM

Version: 10

Row_format: Compressed <‐‐‐‐‐‐‐‐

Rows: 0

Avg_row_ length: 0

Data_length: 41

Max_data_length: 281474976710655

Index_length: 1024

Data_free: 0

Auto_incremen t: NULL

Create_time: 2013‐0 6‐27 19:29:49

Update_time: 2013‐06‐27 19:29:49

Check_time: NULL

Collation: latin 1_swedish_ci

Checksum: 0

Create_optio ns:

Comment:

1 row in s et (0.02 sec)

 

解決策

可能な原因に対して、解決策は：

1. MyISAMファイルにMYDかMYIに権限トラブルが起きて、それにmysqldプロセスを上書きできない。リカバリしたいであれば、shellを運用してください：

chgrp ‐R mysql <dataDir>

chown ‐R mysql <dataDir>

chmod ‐R 660 <dataDir>

 

2. MyISAMテーブルがが凍結された。リカバリしたいであれば、shellを運用してください：myisamchk.exe ‐‐unpack <dataDir>\<db_name>\<table_name>

Then the table can be repaired:

mysql> flush tables;

Query OK, 0 rows aff ected (0.01 sec)

mysql> repair table t;

+‐‐‐‐‐‐‐‐+‐‐‐‐‐‐‐‐+‐‐‐ ‐‐‐‐‐‐‐+‐‐‐‐‐‐‐‐‐‐+

| Table | Op | Msg_type | Msg_text |

+‐‐‐‐‐‐‐‐+‐‐‐‐‐‐‐‐+‐‐‐‐‐‐‐‐‐‐+‐‐‐‐‐‐ ‐‐‐‐+

| test.t | repair | status | OK |

 

+‐‐‐‐‐‐‐‐+‐‐‐‐‐‐‐‐+‐‐‐‐‐‐‐‐‐‐+‐‐‐‐‐‐‐‐‐‐+

1 row in set (0.05 sec)

 

 

この記事で

ターゲット

リカバリ

リファレンス

適用範囲：

MySQLサーババーション

完全なshow create tableのテーブルインポートで定義ファイルを再構造できる。

目標

何のバックアップもない場合に、壊れたInnodbテーブル定義ファイルを再構造する。

リカバリ

以下のファイルはInnoDBに壊れたテーブル定義ファイルをリカバリする方法を示した。同じなテーブルを作成しないでその定義を壊れたテーブルからコピできる。

mysql [localhost] {msandbox} ((none)) > drop database test;

Query OK, 5 rows affected (0.44 sec)

mysql [localhost] {msandbox} ((none)) > create database test;

Query OK, 1 row affected (1.38 sec)

mysql [localhost] {msandbox} ((none)) > create table test.a (b int);

Query OK, 0 rows affected (0.09 sec)

mysql [localhost] {msandbox} (test) > insert into test.a values (1),(2);

Query OK, 2 rows affected (0.53 sec)

Records: 2 Duplicates: 0 Warnings: 0

mysql [localhost] {msandbox} (test) > select * from a;

+‐‐‐‐‐‐+

| b |

+‐‐‐‐‐‐+

| 1 |

| 2 |

+‐‐‐‐‐‐+

2 rows i n set (0.00 sec)

mysql [localhost] {msandbox} ((none)) > \q

Bye

$ l s ‐l data/test/

total 16

‐rw‐rw‐‐ ‐‐ 1 ronan ronan 8554 Oct 30 13:44 a.frm

‐rw‐rw‐‐‐‐ 1 ronan ronan 65 Oct 30 13:44 db.op t

$ file data/test/a.frm

data/test/a.frm: MySQL table definition file Version 9

 

frmファイルを編集して、損害状況を演じる：

$ hexedit data/test/a.frm

00000000 FE 01 09 0C 03 00 00 10 01 00 00 30 00 00 10 00 05 00 00 00 00 00 00 00 00

00 00 02 08 00 08 00 00 05 00 00 00 00 08 00 00 00 00 00 00 00 00 10 00 00 00 5D

………..0…………………………………]

 

データベースを再起動して、ファイルメモリーをクリンアップする。そしてファイルがこわれてアクセスできなくなった。

$ ./stop ; ./start

…. sandbox server started

$ ./use ‐Dtest

Reading table information for completion of table and column names

You can turn off this feature to get a quicker startup with ‐A

Welcome to the MySQL monitor. Commands end with ; or \g.

Your MySQL connection id is 1

Server version: 5.5.25‐enterprise‐commercial‐advanced‐log MySQL Enterprise Server ‐

Advanced Edition (Commercial)

Copyright (c) 2000, 2011, Oracle and/or its affiliates. All rights reserved.

Oracle is a registered trademark of Oracle Corporation and/or its

affiliates. Other names may be trademarks of their respective

owners.

Type ‘help;’ or ‘\h’ for help. Type ‘\c’ to clear the current input statement.

mysql [localhost] {msandbox} (test) > select * from a;

ERROR 1033 (HY000): Incorrect information in file: ‘./test/a.frm’

mysql [localhost] {msandbox} (test) > \q

Bye

[ronan@hydra msb_5_5_25]$ tail data/msandbox.err

121030 13:52:27 InnoDB: Waiting for the background threads to start

121030 13:52:28 InnoDB: 1.1.8 started; log sequence number 1574983512

121030 13:52:28 [Note] Server hostname (bind‐address): ‘0.0.0.0’; port: 5525

121030 13:52:28 [Note] ‐ ‘0.0.0.0’ resolves to ‘0.0.0.0’;

121030 13:52:28 [Note] Server socket created on IP: ‘0.0.0.0’.

121030 13:52:28 [Note] Event Scheduler: Loaded 0 events

121030 13:52:28 [Note] /1/mysql/tgz/5.5.25/bin/mysqld: ready for connections.

Version: ‘5.5.25‐enterprise‐commercial‐advanced‐log’ socket:

‘/tmp/mysql_sandbox5525.sock’ port: 5525 MySQL Enterprise Server ‐ Advanced Edition

(Commercial)

121030 13:52:31 [ERROR] /1/mysql/tgz/5.5.25/bin/mysqld: Incorrect information in file:

‘./test/a.frm’

121030 13:52:32 [ERROR] /1/mysql/tgz/5.5.25/bin/mysqld: Incorrect information in file:

‘./test/a.frm’

 

いま、同じようなcreate文を使って、別のデータベースで同じな名のテーブルを作成しえｔ。今は新しい定義でこわれた古いテーブル定義を上書きする（データベースがアウトラインするとき）。そして再起動する。これで、初期テーブル定義と関連するデータをアクセスできる。

mysql [localhost] {msandbox} (test) > create database dummy;

Query OK, 1 row affected (0.15 sec)

mysql [localhost] {msandbox} (test) > create table dummy.a (b int);

Query OK, 0 rows affected (0.09 sec)

mysql [localhost] {msandbox} (test) > \q

Bye

$ l s ‐l data/dummy/

total 16

‐rw‐rw‐‐ ‐‐ 1 ronan ronan 8554 Oct 30 13:53 a.frm

‐rw‐rw‐‐‐‐ 1 ronan ronan 65 Oct 30 13:52 db.op t

$ ls ‐l data/test/

total 16

‐rw‐rw‐‐ ‐‐ 1 ronan ronan 8554 Oct 30 13:51 a.frm

‐rw‐rw‐‐‐‐ 1 ronan ronan 65 Oct 30 13:44 db.op t

$ ./stop

$ cp dat a/dummy/a.frm data/test/

$ ./start

… sandb ox server started

$ ./use ‐Dtest

Reading table information for completion of table and column names

You can turn off this feature to get a quicker startup with ‐A

Welcome to the MySQL monitor. Commands end with ; or \g.

Your MySQL connection id is 1

Server version: 5.5.25‐enterp rise‐commercial‐advanced‐log MySQL Enterprise Server ‐

Advanced Edition (Commercial)

Copyright (c) 2000, 2011, Oracle and/or its affiliates. All rights reserved.

Oracle is a registered trademark of Oracle Corporation and/or its

2015/12/14 Document 1502290.1

https://support.oracle.com/epmos/faces/DocumentDisplay?_afrLoop=166632313173971&parent=DOCUMENT&sourceId=2049861.1&id=1502290… 4/4

Oracle is a registered trademark of Oracle Corporation and/or its

affiliates. Other names may be trademarks of their respective

owners.

Type ‘help;’ or ‘\h’ for help. Type ‘\c’ to clear the current input statement.

mysql [localhost] {msandbox} (test) > select * from a;

+‐‐‐‐‐‐+

| b |

+‐‐‐‐‐‐+

| 1 |

| 2 |

+‐‐‐‐‐‐+

2 rows i n set (0.00 sec)

mysql [localhost] {msandbox} (test) > \q

 

これで新しいテーブル定義で初期テーブルデータをアクセスできるようになった。

この記事で
症状
変更
原因

解決策

• 初期ログファイルをリカバリする
• データを再びロードする
• MyISAMに転換する
• 仕事テーブル

リファレンス

 

このファイルはOracle Support’s Rapid Visibility (RaV)で発信するから、独立した技術テストに制約されていない。

 

適用範囲:

MySQLサーバ4.0以降

この記事では、すべてのプラットフォームに適用する

 

症状

リカバリしてみた後にInnoDBを使うと、以下のエラになる。

ERROR

‐‐‐‐‐ ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐

120207 13:30:29 InnoDB: Error: page 573441 log sequence number 22 697197707

InnoDB: is in the future! Current system log sequence number 5 2916730276.

InnoDB: Your database may be corrupt or you may have copied the InnoDB

InnoDB: tablespace but not the InnoDB log files. See

InnoDB: http://dev.mysql.com/doc/refman/5.5/en/forci ng‐recovery.html

InnoDB: for more information.

 

変更

このトラブルは以下の変更をした後に起こる：

• もしInnoDBログファイルが削除されて、それにこれらのトランザクションが削除する前に起こる（どんなトランザクションでも外力がないままに自力で起これない。大体の場合は以下のトランザクションで引き起こした）:
  • ハードウェアサーバシャットダウン
  • Mysqldプロセスがkill ‐9あるいはほかの原因で中止する。
  • データがホットバックアップからリカバリする。
  • innodb_fast_shutdown = 2を使うときに，MySQLが閉められる。
• MySQLがInnoDBが存在していないあるいはほかのバックアップからリカバリする。
• MySQLが整合性のないバックアップからリカバリする。
• innodb_force_recovery = 6の場合に，MySQLが起動される。

 

原因

根本的な原因はInnoDBログファイル（redoログ）とデータファイルが同期していない。

InnoDBに変更があったら、データファイルに書き込む前に、まずはログファイルに書き込む。innodb_fast_shutdown = 0か1 (ディフォルト)が正常に閉められる間に、InnoDBはすべてのページが上書きされるから、すべてのページより遅いチェックポイントを設定する。そしてサーバがシャットダウンする前にチェックポイントをつくる。innodb_fast_shutdown = 2の場合に今のがチェックポイントとされるが、どんなページも今の位置にフラシュしないから、シャットダウンリカバリが必要としている。シャットダウンリカバリがこのエラを引き起こさないが、もしログファイル削除されたら、シャットダウンしたあとこれらを削除するようにエラになる。

 

InnoDBがディスクからページを読み取り、エラについての情報を発信する時に、ページとログファイル位置と比べるようになる。

 

ログ位置は今の位置に超えたページに対してシャットダウンリカバリを実行しない。これはトラブルが解決されるまでまともに運用できないと意味する。

 

もし原因はinnodb_force_recovery = 6でMySQLを起動したことと関係あるなら、これははっきりとMySQLエラログに映される。詳しい情報はStarting InnoDB on a Corrupted Databaseに参考してください。

 

解決策

1. もしそれらをまだ持っていれば、バックアップあるいはデータファイルをコピする位置から初期ログファイルをリカバリする。このトラブルが起きたが何の変更をしていない場合に、全てのデータをリカバリする。
2. mysqldumpでデータをバックアップする。すべてのInnoDBテーブルのib_logfile*, ibdata*, *.ibd, 及び*.frmを削除する；ダンプからInnoDBテーブルを再構造する。この場合にはデータをなくしたことがよくある。
3. すべてのInnoDBテーブルをMyISAMに変更する。すべてのib_logfile*, ibdata*を削除して、MySQLを再起動して、テーブルをInnoDBに格納する。効果は解決策２と同じようになるから、データもよくなくす。
4. InnoDBストレージエンジンで”work table”を作成する。大きさはログファイルの大きさと同じようになる。 データをインサートして、仕事テーブルを削除する。これもデータをなくすことを引き起こす。

 

策2と３は大体同じで、大事なのは残したInnoDBテーブルがないということ。例えば、InnoDBテーブルをMyISAMに転換する。その中には具体的なInnoDB情報がなくして、mysqldumpを使っているテーブルが残されたテーブルはバックアップされて、再起動したらリカバリできる。

 

策2., 3., 及び4で選んで、人々がよく選択でいるのは一番短い時間に完成できる策である。けど、策４には未検知なトラブルがあるかも知れないので、ほかの二つ方法を選んでください。

 

• 初期ログファイルをリカバリする

これはログファイルを使っているすべてのトランザクションから時間を計算するから、後のデータをなくなる方法より増しだと思う。エラが起こり、データが変更された場合を除き、この選択肢を優先的に使ってください。こうすれば損害を最低に控える。

 

2. データを再びロードする

すべてのInnoDBファイルを初期化して、すべてが元のように戻ることを確保してください。

 

ステップは：

1. すべてのInnoDBデータをダンプする。mysqldump あるいは SELECT … INTOOUTFILEで完成してください。Schema情報を含んでください。例えばテーブル定義とトリガー。別のストレージエンジンを使うとき必要は内容。
2. MySQLを中止する。
3. すべてのInnoDBファイルを削除する。ファイルの位置と名前がMySQL セットで決める；ディフォルトはすべてのファイルがdatadirでMySQLデータパスに配置される。以下のファイルを削除してください：

• 共有テーブルスペースファイル（各ファイルはディフォルトでibdata*と呼んでいる）。
• InnoDBログファイル(redoログ) ib_logfile*。
• InnoDBテーブルのテーブル定義ファイル、*.frm。
• InnoDBテーブルのトリガーファイル (*.TRN と *.TRG)。
• InnoDBデータファイル*.ibd。

4. MySQLを起動して、InnoDBが再び初期化されることを待つ。

InnoDBが共有テーブルスペースとログファイルを作成したら、MySQLエラログで見られる。

5. InnoDBファイルのデータとschemaを再びロードする。

 

3. MyISAMに転換する

InnoDBテーブルをMyISAMに転換し、InnoDB共有テーブルスペースとログファイルを削除した同時に、mysqldumpがそれをリカバリすることを阻止してください。

特にMySQL 5.1、InnoDBプラグインとMySQL 5.5を使った場合に、高速インディクスでこのプロセスをより加速する。

 

ステップは：

1. 各InnoDBテーブルに対して、テーブルをMyISAMオプションに転換する：

もし5.1あるいはMySQL 5.5にInnoDBプラグインを使ったら、テーブルからすべてのsecondaryインディクスを削除してください。

 

Secondaryインディクスを削除することはオプティマイザだから、この選択肢は必要じゃない。大きいなテーブルに対して、著しい性能向上をもたらす。

 

例えば：

ALTER TABLE t1

DROP INDEX va l1,

DROP INDEX val2,

ENGINE=MyISAM;

2. MySQLを中止する.
3. すべてのInnoDBファイルを削除する。ファイルの位置と名前はMySQLセットで決める；ディフォルトはすべてのファイルはdatadirでMySQLデータパスに配置される。以下のファイルを削除してください：

• 共有テーブルスペースファイル（各ファイルはディフォルトでibdata*と呼んでいる）。
• InnoDBログファイル(redoログ) ib_logfile*。

4. MySQLを起動して、InnoDBが再び初期化されることを待つ。

InnoDBが共有テーブルスペースとログファイルを作成したら、MySQLエラログで見られる。

5. 各テーブルに対して：
6. テーブルをInnoDBに転換して、そしてステップ１削除された唯一インディクスを追加する。この段階で操作したいくないがであれば、唯一インディクスが高速インディクスで作成できないから、後で追加するのはテーブルが再構造することに導く：

ALTER TABLE t1

ADD UNIQUE ( val1),

ENGINE=InnoDB;

2. secondaryインディクスを再びテーブルに追加する：

ALTER TABLE t1

ADD INDEX (v al2);

4. 仕事テーブル

この方法は今のログ順列を未来が報告するシリアル番号に追加するので、二つのシリアル番号の違いによって、インサートする必要があるデータ量を見積もることができる：

120207 13:30:29 InnoDB: Error: page 573441 log sequence number 22 697197707

InnoDB: is in the future! Current system log sequence number 5 2916730276.

 

番号はSHOW ENGINE INNODBSTATUS (参见Document 1326051.1如何在计算中使用日志序列号的示例)でのLOG部分のフォーマットと一緒だが、両者の違いは：

data required = ((22 ‐ 5) * 4 * 1024 * 1024 * 1024) + (697197707 ‐ 2916730276)

= 70794911463 bytes

 

つまり66GBくらい。

 

注意：InnoDBプラグインがあるMySQL 5.1あるいはMySQL 5.5を使えば，ログシリアル番号は2つの32ビット数じゃなく、64桁の番号を含む。

 

この方法を実行したいであれば、テーブルを作成して、システムログシリアル番号がログシリアル番号と同じようになるまで、データを停ずにインサートする。完成したら、テーブルを削除する。

 

これはlinuxのスクリプト，ログシリアル番号より20Mほど上回る：

#!/bin/sh

mysql ‐uroot test <<EOF

DROP TABLE IF EXISTS te mp_advance_lsn;

CREATE TABLE temp_advance_lsn (col1 TE XT) ENGINE=InnoDB;

INSERT INTO temp_advance_lsn VALUES (REPEAT(‘0123456789’ , 1000));

INSERT INTO temp_advance_lsn SELECT * FROM temp_advance_lsn;

INSERT INTO temp_advance_lsn SELECT * FROM temp_advance_lsn;

INSERT INTO temp_advance_lsn SELECT * FROM temp_advance_lsn;

INSERT INTO temp_advance_lsn SELECT * FROM temp_advance_lsn;

INSERT INTO temp_advance_lsn SELECT * FROM temp_advance_lsn;

INSERT INTO temp_advance_lsn SELECT * FROM temp_advance_lsn;

INSERT INTO temp_advance_lsn SELECT * FROM temp_advance_lsn;

INSERT INTO temp_advance_lsn SELECT * FROM temp_advance_lsn;

INSERT INTO temp_advance_lsn SELECT * FROM temp_advance_lsn;

INSERT INTO temp_advance_lsn SELECT * FROM temp_advance_lsn;

DROP TABLE temp_advance_lsn;

EOF

mysql ‐uroot ‐e ‘SHOW ENGINE INNODB STATUS;’ \

| sed ‘s/\\n/\n/g’ \

| grep ‘^Log sequenc e’

 

ログシリアル番号より20M以上に超えるようにしたいであれば、テーブルを削除することじゃなく、テーブルをTRUNCATEしてください。LSN目標に達成するまで、データと前にTRUNCATEされたプロセスを追加することを繰り返す。これはより少ないデータでより多くデータを高速で作成した例である。

作成したら、場合によって一番効率が高いデータブロックにきめる。

この記事で
ターゲット
修理
リファレンス

適用範囲：
MySQLサーバ – バージョン4.0以上
この資料の情報は、すべてのプラットフォームに適用されます。

目標

MySQLのmyisamrecoveroptionsオプションを学んで、サーバを起動するときのシャットダウンの場合にどうやって自動的なリカバリを起動することを把握できる。

myisam‐recover‐options MySQL 5.1とより早いバーションでmysqlrecoverと呼んでいる。

 

リカバリ

myisam‐recover‐optionsオプションは起動MySQLを作成するときのMyISAM自動リカバリである。myisam‐recover‐optionsオプションが以下の数値を使える：

• DEFAULT: バックアップなしに強制的に手早くテストしてリカバリできる。
• BACKUP: データファイルがリカバリするときに変更されたら、MYD ファイルのバックアップをtbl_name‐datetime.BAKと格納してください
• FORCE: .MYD ファイルが一行以上のデータをなくしたとしてもリカバリを実行する。
• QUICK: どんなdeleteブロックもなければ行をテストしない。

 

myisam‐recover‐options には値の組合も適用できる。例えば、データファイルがリカバリするときに変更されたら、たとえ例如果数据文件在恢复时被更改，即使创建备份时丢失了多于一行，FORCE,BACKUP 结合恢复的使用。

myisam‐recover‐optionsのQUICKとDEFAULT値はどんなデータを削除しないから、二つの安全なオプションである。自動リカバリにも適応している。DEFAULTとFORCEの違いはたとえFORCEが前に完成した文からすべての行を見つけ出せないとしても、リカバリを続けられるから、 FORCEとBACKUPを組み合って、MyISAMデータファイルを変更する前にバックアップを作成してください。

 

myisam‐recover‐options オプションでDEFAULT を使うとはいい策と思っているが、失敗した場合に、そのエラがこのあとよく現れてデータをなくすリストを納得できるなら、人工的にリカバリして、myisamrecover=FORCE,BACKUPを使ってください。

 

人工的なリカバリを実行する前にテーブルバックアップを作成してください。

 

Myisamchkを使えば， myisamchk时没有其他程序在使用表。を運用しているときにほかのプログラムがテーブルを使っていないことを確保してください。

この文で

症状

4.xでは、5.0.84以下、下記の5.1.37と、InnoDBのプラグイン5.1.40とし、以下の

使用のInnoDBテーブルスペースは、すべてのバージョンを使用していませんもしinnodb_file_per_table

問題を再現：

自動拡張機能を備えたInnoDBのテーブルスペースは、すべてのバージョンの使用を含むもしinnodb_file_per_table

原因

4.xでは、5.0.84以下、以下のInnoDBプラグとでは、次の5.1.37と5.1.40

固定サイズのInnoDBテーブルスペースを使用し、もしinnodb_file_per_tableのすべてのバージョンを使用していません

自動拡張機能を備えたInnoDBのテーブルスペースは、すべてのバージョンの使用を含むもしinnodb_file_per_table

ソリューション

5.1.40とバージョン4.x以下、5.0.84以下、5.1.37以下、InnoDBのプラグインで

InnoDBのテーブルスペースの固定サイズを使用し、もしinnodb_file_per_tableのすべてのバージョンを使用していません

自動拡張機能を備えたInnoDBのテーブルスペースは、すべてのバージョンの使用を含むもしinnodb_file_per_table参考

このドキュメントでは、Oracle Support’s Rapid Visibility (RaV) で送信されるため、独立した技術検査の対象ではありませんされています。

 

適用範囲：

MySQLサーバのバージョン4.0以上

この資料の情報は、すべてのプラットフォームに適用できる。

***Checked for relevance on 22jun2014***

 

症状

このトラブルに及ぼす可能性は二つがある：

4.xでは、5.0.84以下、5.1.37以下、同様、、InnoDBのプラグインとバージョン5.1.40、次のサーバーのバージョンのMySQLのいずれかを実行しているとき：

• 0と4.1すべてのバーション
• 0.84とその以下
• InnoDBプラグインなしの1：5.1.37とその以下
• MySQLの1ウィジェットがあるInnoDB：5.1.40以下

1023を超えた動的なトランザクションがあって、エラ情報”Table is Full”がクライアントへ返されたときに、インサートエラが起こる。エラログには、より記述的なエラを含む：

110912 14:52:14 InnoDB: Warning: cannot find a free slot for an undo log. Do you have too

InnoDB: many active transactions running concurrently?

 

すべてのバーションは固定した大きさのInnoDBテーブルを使っている、それにinnodb_file_per_tableを使っていない。

それでデータをInnoDB テーブルにインサートする場合に以下のエラになる：

The table ‘<tablename>’ is full

その中に<tablename> はテーブルの名である。該当するMySQL エラコードSQL 状態は：

MySQL Error Code: 1114

SQLState: HY000

 

MySQLエラログに反映するエラは使っているInnoDBストレージエンジンバーションに左右される。

• InnoDBプラグインがあるMySQL 5.1 とMySQL 5.5 ，エラログには以下のようなエラを含んでいる：

InnoDB: Error: Data file(s) ran out of space.

Please add another data file or use ‘autoextend’ for the last data file.

110908 12:18:13 [ERROR] /usr/sbin/mysqld: The table ‘<tablename>’ is full

• MySQL/InnoDB に対して更早的版本(InnoDBがあるbuildinバーションのMySQL 5.1 を含む)，エラ情報は：

110908 13:25:37 [ERROR] /usr/sbin/mysqld: The table ‘t1’ is full

 

たとえ SHOW TABLE STATUS 或 SELECT * FROM information_schema.TABLES はInnoDB テーブルに0を超えたData_freeがあることと示した 。

トラブルを再現する：

このステップは以下のステップで再現できる：

1. 再びインストールしたMySQLを起動する
2. MySQLを起動する前に、my.cnfにこのようにセットされたことを確保してください：

innodb_data_file_path = ibdata1:100M

それにinnodb_file_per_tableを起動しないでください

3. MySQLを起動して、InnoDB がデータファイルを作成させる。
4. MySQLに登録して実行する：

CREATE DATABASE innodbtest;

use innodbtest

CREATE TABLE t1 (id mediumint unsigned NOT NULL auto_increment PRIMARY KEY) ENGINE=InnoDB;

5. The table ‘t1’ is fullが返されたまで持続的に行をテーブルにインサートする。
6. スペースがもうすぐ使い切るにエラ情報は：

SQLSTATE[HY000]: General error: 1114 The table ‘t1’ is full

7. SHOW TABLE STATUSを実行する：

mysql> SHOW TABLE STATUS LIKE ‘t1’\G

*************************** 1. row ***************************

Name: t1

Engine: InnoDB

Version: 10

Row_format: Compact

Rows: 3918789

Avg_row_length: 23

Data_length: 90800128

Max_data_length: 0

Index_length: 0

Data_free: 4194304

Auto_increment: 3920001

Create_time: 2011-09-08 12:14:35

Update_time: NULL

Check_time: NULL

Collation: latin1_swedish_ci

Checksum: NULL

Create_options:

Comment:

1 row in set (0.00 sec)

使用可能なデータがなくともData_free はまだ4194304 。

 

自動的に 拡張するInnoDB テーブルスペースには innodb_file_per_table を使ったすべてのバーションを含んでいる。

 

Table is full errorが現れて、 MySQLエラログによくある症状は：

2014-09-15 08:33:38 7f28aeb8a700 InnoDB: Error: Write to file /mysql/data/ibdata1 failed at offset 20971520.

InnoDB: 1048576 bytes should have been written, only -1 were written.

InnoDB: Operating system error number 28.

InnoDB: Check that your OS and file system support files of this size.

InnoDB: Check also that the disk is not full or a disk quota exceeded.

InnoDB: Error number 28 means ‘No space left on device’.

InnoDB: Some operating system error numbers are described at

InnoDB: http://dev.mysql.com/doc/refman/5.6/en/operating-system-error-codes.html

2014-09-15 08:33:38 7101 [ERROR] /usr/sbin/mysqld: The table ‘t1’ is full

2014-09-15 08:33:39 7101 [ERROR] /usr/sbin/mysqld: The table ‘t1’ is full

Windowsに，エラがこのようになるかもしれない：

2014-09-15 10:04:06 12AB InnoDB: Encountered a problem with file C:\ProgramData\MySQL\ibdata1

2014-09-15 10:04:06 12AB InnoDB: Disk is full. Try to clean the disk to free space.

2014-09-15 10:04:06 13D7 [ERROR] C:\Program Files\MySQL\bin\mysqld.exe: The table ‘t1’ is full

以上は共有テーブルスペースのエラで、似たようなエラは各テーブルスペースにも起こる。

 

原因

4.x, 5.0.84 とその以下, 5.1.37 とその以下, InnoDBプラグイン付きの5.1.40 及以下版本とその以下

これはIf InnoDB Runs Out of Undo Slots, It Returns Misleading ‘Table is Full’ bugによるものである。在MySQL 5.1 とその以下にはInnoDB せいぜい1023動的なトランザクションを支持する。より多くの起動はエラになるかもしれない。またはbugの影響を受けたバーションにassertionが作成する。

 

大きさが固定したInnoDB テーブルスペースを使うが、どんな innodb_file_per_tableバーションも利用しない。

このトラブルはInnoDBが共有テーブルスペースの使用可能なスペースを使い切ったからである。すべてのガイドブックにはTable is fullがディスクを使い切ったあるいはテーブルが最大に達ったと意味する。InnoDBが共有テーブルスペースと設定されたら、InnoDBテーブルスペースの大きさは（データファイル）テーブルの最大なスペースと同じようになる。

 

InnoDBテーブルスペースにはディフォルト16KBのデータページを含んでいる。一部のページが全然利用されていないが、実際には新たなデータに対して提示しないから、SHOW TABLE STATUS報告にはまだスペースがあるが、どんなデータもインサートできなくなる。

 

MySQLガイドブックのページを参考してください：

• The table is full
• Limits on Table Size
• Configuring InnoDB
• InnoDB File Space Management

 

自動的に 拡張するInnoDB テーブルスペースには innodb_file_per_table を使ったすべてのバーションを含んでいる

この場合の原因は：

ストレージテーブルスペースディスクが満たされた。

設定した限度が満たされた

テーブルスペースファイルがファイルシステムが支持できる最大なサイズに達した。

 

解決策

4.x, 5.0.84 とその以下, 5.1.37 とその以下, InnoDBプラグイン付きの5.1.40 及以下版本とその以下。

解決策はプラグイン付きのMySQLのバーションにアップロードする：

• MySQL 5.0: 5.0.85
• InnoDBプラグインなしのMySQL 5.1：1.38
• MySQLの1ウィジェットがあるInnoDB：5.1.40

 

使用可能で最新なGAバーションにアップロードする。

 

アップロードする前にデータベース部分を作成してください。（schema、データ及びデータベースが実行する必要があるプログラム（変数、トリガーなど））。安全こそ最善策である。もしや、アップグレード途中に何かトラブルが起きたら、前のバーションに容易くリカバリできる。

 

アップグレードは以下の通りに参考してください：

• Downloading MySQL Server
• MySQLをアップロードするあるいはダウンロードする場合に、テーブルとインディクスをテストして再構造する必要があるかを確認することは一番大事である。ダウンロードしたバーションにページ: 5, 5.1, 5.0を使ってください。How to Upgrade your Existing MySQL Server to MySQL 5.6 Version を参考して、より多くのアドバイスを獲得できる。

 

生産サーバがアップロードする前に、開發段階でテストしてください。

 

大きさが固定したInnoDBテーブルとinnodb_file_per_tableすべてのバーションを使わない場合。

解決策は’InnoDBテーブルスペースをより大きくなってあげる。以下のステップで完成できる：

 

生産に投入する前に、開發段階で試してください。

 

1. MySQLを中止する

2.好みのエディタでMySQL配置ファイルをオープンする。

3. innodb_data_file_path オプションを設定する行を見つけ出す。
4. 新たなテーブルテーブルを追加するあるいは最近のテーブルスペースを自動的に拡張する：
5. innodb_data_file_path を

innodb_data_file_path = ibdata1:100M;ibdata2:100Mと設定する

あるいは

2. innodb_data_file_path を

innodb_data_file_path = ibdata1:100M:autoextendと設定する

5. MySQL配置ファイルを格納する
6. MySQLを再起動する

7.データを再びInnoDBテーブルにインサートできるかを確認する。

8.解決策を別の環境に移す。

 

MySQLガイドブックにある以下のページを参考してください：

Configuring InnoDB

Adding, Removing, or Resizing InnoDB Data and Log Files

 

 

自動的拡張するInnoDBテーブルスペースを使ってinnodb_file_per_tableすべてのバーションを含む

その原因はテーブルの大きさをより大きく拡張できないから、解決策は：

• テーブルスペースファイルストレージパスには余ったディスクスペースがあることを確保してください。

スペースを空けるために共有なテーブルスペースとInnoDBファイルを削除するのはいかない。削除すれば、InnoDBが起動できなくなる。

スペースを取り戻すには、以下の内容を参考してください。

• ディフォルトの定量がテーブルスペースが伸びることを阻止しないことを確保してください。
• ファイルシステムが支持する最大ファイルサイズが達していないことを確保してください。もしこれはTable is fullエラの原因であれば、以下の解決策を使ってください：
  1. すべてのテーブルを共有テーブルスペースに格納してください。(innodb_file_per_table = 0):
     1. 別の共有テーブルスペースファイルを作成してください。
     2. あるいは、別の共有テーブルスペースを作成して、innodb_file_per_tableでそれをテーブルスペースから移す。これで、共有なテーブルスペースの大きさに影響を及ばない。MySQL Server Variable: innodb_file_per_tableに参考して、innodb_file_per_tableについて、より詳しい情報が獲得できる。
  2. 各テーブルのテーブルスペースのファイルに対して、パーティションしてください。パーティション完成したテーブルに対して、各パーティションが自身のテーブルスペースにあるから、それにinnodb_file_per_table = 1、所以这是你能将总大小分割到多个文件。

 

ディスクスペースを解放する方法は以下の通り：

 

• OPTIMIZE TABLE <table_name>で各テーブルスペースに余ったスペースを取り戻す必要がある。

这需要重建在表空间文件位置的表。テーブルスペースファイル位置のテーブルを再構造する必要があるから、スペースを解放したあるいはテーブルを別の位置に移した場合に限って効ける。

• 共有テーブルスペースのファイルを取り戻すには：How to Reclaim Unused Space and Decrease InnoDB ibdata1 Data File Size.
• もしエラーログ、スロークエリログ、一般クエリログ、監査ログなどテーブルスペースと同じディスクに格納されたら、これらのログを別のディスクに移してください：
  1. サーバログ維持
  2. audit_log_rotate_on_size
• もし2進数ログがデータと同じなディスクにあれば、古い2進数ログを削除することを考えてください。

削除された2進数ログは確実にいらないということを確保してください。例えば、2進数がコピするときに使われていないが、リカバリするときにまだ使う必要があれば、ログを削除する前ににバックアップを作成してください。

PURGE BINARY LOGS コマンドで古い2進数ログを削除できるか。

• MySQL 5.6で， InnoDB native linksでtablespaceにあるテーブルスペースを別のディスクに移すことができる。
• ログを別のディスクに移す：
  1. What is the General Query Log and How to Control Where the Log is Stored?
  2. What is the Slow Query Log and How to Control Where the Log is Stored and What is Logged?
  3. –log_ error
  4. –audit_ log_file

何が原因でMySQLサーバのMyISAMテーブル壊れた

 

利用できるプラットフォーム：

MySQLサーバー – バージョン：4.0〜5.5 – リリース：5.5

MySQLサーバ – バージョン：4.0 – リリース：4.0

MySQLサーバー – バージョン：4.0〜5.5 – リリース：4.0〜5.5

 

目標：

MyISAMテーブルが壊れた具体的な原因を説明する

 

解決策

MyISAMストレージエンジンはとっても頼りになれる。もしMyISAM テーブルが壊れたことがよくあれば、それについての原因をよく考えるほうがいい。データを検索するときに、以下のエラ情報が出たら、テーブルが壊れたことと意味している：

Error 1034 Incorrect key file for table: ‘…’. Try to repair it

あるいは：

Error 126 = Index file is crashed

Error 127 = Record-file is crashed

Error 134 = Record was already deleted (or record file crashed)

Error 144 / Error 1195 = Table is crashed and last repair failed

Error 145 / Error 1194 = Table was marked as crashed and should be repaired

 

問合せで見つけ出したテーブルなのに見つけない時に、あるいは不完全なデータが返した時に、壊れたと仮定してもいいと思う。CHECK TABLE文でMyISAMテーブルが壊れているかを検証できる。

いろんな原因でMyISAMを壊れる。可能性が大きいから小さいまでの順にすれば：

1. サーバシャットダウン、あるいはハードウェアトラブルでこわれた

• 書き込む中に，mysqldプロセスが殺されるかシャットダウンするか損害を及ぼす。
• 電源トラブルのせいでMySQLを実行するサーバが閉じて壊れるかもしれない。
• ハードウェアのトラブルが出るかも知れない。例えば、サーバのディスクトラブル。
• RAMの損害：ハードウェアを再起動すればこのトラブルが解決できる。システムメモリーでこわれたデータがあれば、電源を切らずに再起動すればいいと思う。このトラブルが極まれに現れる。けど、ハードウェアに損害があれば、よく発生する。

サーバを再起動して、自動的なリカバリがこの問題を解決するが、時々REPAIR TABLE SQL文でより深刻なテストが必要としている。テーブルが大きいな場合に、サーバがアウトラインさせて、より早くリカバリしたい時にmyisamchkを使ってください。CPUのコールが多く、いろんなインディクスオプションが失敗したら、myisamchkオプションでスレッドを選択してください、より速くなるから。このオプションは時々失敗するので、見つけ出したら必要とするスレッドが一つの場合があまりない。

 

2.ほかのプログラムによる損害

• もしほかの外部的なプログラムを使っているとしたら、例えばmyisamchk。これはサーバが運用している時に上書きされて、壊れるかもしれない。
• 一部のアンチウイルスソフトウェアもよく損害を及ぶので、時々古いテーブルをリカバリする。あるいは必要とするファイルをテストする。

この場合の第一歩はどんなファイルを変更されたことである。テーブルをリカバリするのは一時的な方法である。

3. bugによる損害

• 2007夏の前のバーションのサーバ建設を使う。2006年から2007年まで、MySQLはいろんなシステムテストを実行して、レアでコピしにくいMyISAM損害bugを見つけ出す。おおよそ2007の夏で、ほぼすべてのbugに関連する損害トラブルが古いバーションによるもので、リカバリ機能が強い新バーションがあまり影響されていないから、バーションを2007夏のバーションにより近くにアップロードしてください。
• もしbugでまたこわれたとしたら、最近のサーバ機能と状況を確認してください。今日では、新しいバグの損傷は通常、顧客固有の結合および並行性の高い文、または新しい機能と高い並行性に伴う。

エラ報告でよく再起動されるmysqldでテーブルがシャットダウンしたことによる損害を受けたかを確認できる。エラ報告がサーバトラブルによるものと示されて、損害が正常操作の間で起こったとすれば、それはバグによるものかもしれない。それで、トラブルを示されるためにコピできるテストを作成して、My Oracle SupportでSupport Requestを起動し、トラブルを報告してください。もう一度言うけど、REPAIR TABLE SQL文でこわれたMyISAM表テーブルをリカバリできる。Mysqldを運用していない場合に、myisamchkコマンドでテーブルをリカバリできる。