この記事で

症状

変更

原因

解决策

リファレンス

 

この記事はOracle Support’s Rapid Visibility (RaV) プロセスで発信するので、独立した技術テストに制約されていない。

 

適用範囲

MySQLサーバのバージョン5.5〜5.5[5.5をリリース]

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

 

症状

MySQL5.5.20あるいは5.5.21を再起動するときに、うまくMySQL起動せず、エラログには以下のエラが報告された：

121215 11:25:25 InnoDB: Error: data file /mysql_data/mysql_databases/ibdata2 uses page size

1024,

12121 5 11:25:25 InnoDB: but the only supported page size in this release is=16384

121215 11:25:25 InnoDB: Could not open or create data files.

 

報告のibdata2ページの大きさは1024以外すべてのサイズも含んでいる。

 

変更

一般的に、このトラブルはALTER TABLE文でInnoDBテーブルのKEY_BLOCK_SIZE属性を変えたときに起こる。

 

原因

これはMySQL5.6がレベルダウンしないように、変更した操作によるものである・16k以外に、すべてのページの大きさも支持している。

 

Bug 13698765 64160: PAGE SIZE 1024 BUT THE ONLY SUPPORTED PAGE SIZE IN THIS RELEASE IS=16384.に参考してください

 

解决策

解決策は、MySQL5.5.22以降にアップグレードしてください。

すべての最新のパッチを入手するためのパッチの最新版にアップグレードすることをお勧めします。

 

適用範囲：

5.6 MySQLサーババージョン5.0[5.6に5.0をリリース]

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

 

目標

もしテーブルをアクセスときに以下のエラ情報があったら、テーブル構造ファイル.frmがこわれたと意味する。

ERROR 1033 (HY000): Incorrect information in file: ‘./world/Country.frm'”

 

解決策

もし.frmファイルがこわれたとしたら。簡単の方法でリカバリできるか。バックアップからテーブルをリカバリできる。あるいは以下の方法を実行してください：

 

1) もしテーブル構造が持っていれば、同じサーバの別のデータベースで似たようなテーブルを作成してください。

2)別のデータベースから.frmファイルをworldデータベースにコピしてください。

cp Country.frm <datadir>/world/

3) ファイルの権限をチェックして、新しいコピしたファイルは今のファイルと同じな所有者と組みにあることを確保してください。

4)そして、既存するデータでテーブルをアクセスできるはずである。

 

注：再起動なしにオンラインで操作できるが。テーブルが活躍中に何のスレッドもアクセスしていないと確保してください。またシャットダウンするから。

 

適用範囲：

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

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

 

症状

MySQLサーバは以下の情報でシャットダウンする：

InnoDB: Database page corruption on disk or a failed

InnoDB: file read of page

 

原因

データを守るために、InnoDB使用テストはページと一緒にある。InnoDBがディスクから読み取るときに、各ページの合計を計算して、ディスクでロードした合計と比べる。数値に相違があったら、エラがあるかも知れない。InnoDBはMySQLサーバを閉じて、損害を防ぐ。

 

解决策

エラが起こった原因を見つけ出す

万能な解決策なんてはない。よくあるのはハードウェアトラブル。例えば：物理ディスクあるいはメモリートラブル、こわれたドライブ/コントローラー、オペレーションシステムのbug。次はアドバイス：

 

• Linuxプラットフォームで，ときにはページメモリーをリセットしてトラブルを解決できる：

echo 2 > /proc/sys/vm/drop_caches

 

• もしInnoDBが特定なページでシャットダウンすればいい、一番な原因は物理ディスクにトラブルがあった。OS ハードウェアにたいする詳しいディスク診断を実行してください。
• シャットダウンがランダムで、同じクエリに繰り返さなければ、RAMトラブルかもしれないから：詳しいRAM診断を実行してください。
• MySQLが閉められるときに、innochecksumツールでInnoDBファイルをチェックしてください。

 

どうやってリカバリするか

大事なのは、詳しいハードウェア診断を実行することで、トラブルが拡大することを避ける。もしオペレーションシステムI / Oメモリーはディスク損害の原因であれば、メモリーをリセットするあるいはオペレーションシステムを再起動するのはトラブルを解決できる。

適用範囲：

MySQL Clusterのバージョン6.3以上

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

症状

ある場合に、システムテーブルndb_binlog_indexがこわれたかもしれない

 

以下のクエリを実行するときに、この損害がよくある症状はERROR 1194：

query:

mysql> SELECT * from ndb_binlog_index;

ERROR 1194 (HY000): Table ‘ndb_binlog_ index’ is marked as crashed and should be repaired

 

テーブル損害もMySQLエラログから証明される：

[…]

Faile d to flush master info file

Slave I/O thread exiting, read u p to log ‘log‐bin.NNNNNN’, position MMMMMMMMM

Error reading relay log event: slave SQL thread was killed

Error writing file ‘path‐to‐binlog/log‐bin’ (errno: 30)

mysqld: Incorrect key file for table ‘./mysql/ndb_binlo g_index.MYI’; try to repair it

NDB Binlog: Writing row (A,B,C) to ndb_binlog_index: N

[…]

 

原因

ディスクトラブル。

 

実際には損害がディスクにトラブルが起きたら起こる、例えば：

kernel: sd 0:0:0:0: SCSI error: return code = 0x06000000

kernel: end_request: I/O error, dev sda, sector 112313

kernel: Buffer I/O error on device sda1, logical block 14039

kernel: lost page write due to I/O error on sda1

kernel: Aborting journal on device sda1.

kernel: journal commit I/O error

kernel: journal commit I/O error

kernel: journal commit I/O error

kernel: journal commit I/O error

kernel: ext3_abort called.

kernel: EXT3‐fs error (dev ice sda1): ext3_journal_start_sb: Detected aborted journal

kernel: Remounting filesystem read‐only

logrotd: Rotating log /var/log/ldapfe

mysqld: Failed to flush master info f ile

mysqld: Slave I/O thread exiting, read u p to log ‘log‐bin.000007’, position 59561189

mysqld: Error reading relay log event: slave SQL thread was killed

 

解決策

以下のコマンドを使ってください：

REPAIR TABLE ndb_binlog_index table;

 

この記事で

症状

原因

解决策

リカバリ

今後同じようなことが起こることを防ぐ

リファレンス

 

適用範囲：

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

このドキュメントの情報は、すべてのプラットフォームに適用可能である。

Checked for relevance on 07Feb2013

 

症状

MySQLが実行中のInnoDBストレージエンジンで再起動できない。MySQLエラログにこのようなエラが現れる：

InnoDB: Serious error! InnoDB is trying to free page 11200

InnoDB: though it is already marked as free in the tablespa ce!

InnoDB: Assertion failure in thread 16363778 in file fsp0fsp.c line 2981

mysqld got signal 11 ;

 

ページ番号とスレッド番号の整合性がなくなる。fsp0fsp.cソースコードファイルの行が違っているが、ファイルが同じになる。

 

原因

可能な原因は三つがある。可能性高いから低いまでの順で配列する；

• 電源が切れた、書き込みバッファーが起動した、あるいは書き込みコントローラーが実行しているバック電池のディスクドライブがないからである。
• 二つのMySQLバックアップが同じInnoDBデータファイルと仕事をすると試している。
  • 同時に運用される二つMySQＬバックアップのエラログの起動情報をコピして、時間スタンプを確認して、ロックするという方法はこのエラを避けられる。
• InnoDBプラグインバーションのblobストレージのレアエラはMySQL 5.1.51と5.7でリカバリされた。この一連のbugsにはこういう場合も含んでいる：Bug:11762662, Bug:11762893, Bug:11763287

 

症状はInnoDBログでそれをシャットダウンリカバリの間に暇の状態を保つと指示して、一つページが暇だと標識された。

 

解决策

もしサビース要請を起動したら、損害が低い方法を見つけ出せる。自身の判断でリカバリするか助けを求めるかを判断してください。

 

リカバリ

まずはデータディレクトリ、すべてのサブディレクトリ及びほかのMySQLバックアップデータ位置の2進数バックアップを作成して、Gzipあるいはほかの解凍は’必要な時間を短縮できる。希に、一つのリカバリする方法は’ほかのリカバリを阻止する。リカバリがうまくいかないとデータを削除するかもしれないので、可用性が高いバックアップが必要である。

 

可能性が一番低いinnodb_force_recoveryレベルで再びデータを獲得してください、レベル２(5.5, 5.1, 5.0, 4.0とその以下)からである。もし高いレベルを使っていなければ、起動したあと数秒のシャットダウンが起こるサーバに対しては正常なことだから、サーバをアクセスしたあと６０秒ほど待っていればいい。シャットダウンについては心配いらない。バックグラウンドクリンアップ、ロールバック、インサートバッファー、ログを合併や取り消すなどの操作を実行するから。次のレベルに移せば、以下のステップを実行してください：

1. 以下の方法でデータバックアップを作成してください：
2. ALTER TABLEですべてのInnoDBテーブルをMyISAMに変更する。もしinnodb_file_per_tableを使っていれば、この方法のディスク使用スペースが最低になって、運用中にスペースも解放される。必要であれば、インディクスでディスクスペースを使うことを避けられる。どれを削除したかを覚えてください、後で再構造する必要があるから。
3. mysqldumpプログラムですべてのInnoDBテーブルのバックアップを作成する(5.5, 5.1, 5.0. 4.1とその以下)。作成したら、DROP TABLEで削除する。

3.この部分のリカバリに対して、InnoDBホットバックアップあるいは2進数コピのMySQL企業バーションバックアップを使わないでください。これはデータとエラを一緒にコピする。これは前に作成した2進数ファイルバックアップの付き添いである。二つのバックアップを格納するスペースがなければ。初期2進数コピで第一歩を完成してください。

2. もしINFORMATION_SCHEMAがMySQLバーションにあるなら、SELECT from INFORMATION_SCHEMAですべてのテーブルが変更されたことを確保してくださいさもなければSHOW TABLESとオペレーションシステム検索サブディレクトリの*.ibdを使ってください。InnoDBのどんなデータも次のステップでなくなる、徹底的なテストが大事である。
3. 残したすべてのInnoDBファイル、ib_logfile *和ibdata *を削除する。これはサーバにあるすべての有InnoDBデータを削除し、まだバックアップしていないデータをなくす。実行する前にバックアップしてください。それに、テーブルがMyISAMに変更したことを確保してください。
4. MySQLを再起動して新しい空っぽなInnoDBファイルが作成する。

5.あるいはALTER TABLEでMyISAMからInnoDBに変更して、mysqldumpバックアップファイルを再びロールバックする。このオペレーションが完成したら、サーバがもとに戻たはずである。前にインディクスをしたことがあるなら、今また追加してください。

 

今後同じようなことを防ぐ

データを格納するに使われるため、すべてのディスクドライブのバッファが閉められる。

メモリーディスクコントローラーがバック電池が備えていることを確保してください。

If you are affected by the blob bug, upgrade to MySQL 5.1.51 or 5.5.7 or later. blob bugから影響を受けたら、MySQL 5.1.51あるいは5.5.7バーションにアップグレードしてください。

検討

このエラはMySQLがテーブルファイル，VIEW，.frmファイル，logsファイル，全文インディクスのノイズワードがあるファイルあるいは時間情報があるファイルを読み取るときに引き起こす。

 

意外なEOFエラはMySQLが予想したより小さいファイルを獲得したからである。一般的にこのエラになれない。もし発生すると、こわれたファイルシステムあるいはこわれたテーブルファイル、ログなどがあると意味する。

検討

そのエラはMySQLがあるファイルロックするときに、ファイルシステムからのエラ情報が返ってきたから。

一般的に、このエラは外部アプリがMySQLデータファイルをアクセスしたよるものである。

この状況は以下の内容を含む：

Mysqlを運用するときにファイルをバックアップする

アンチウイルスソフトウェアがファイルをロックする(Windowsで)

Mysqlが実行されるときに、myisamchkが誤りに使われた。

複数のmysqldサーバが同じデータファイルにアクセスする。

Mysqldが –external-lockingオプションを指定した。それにシステムロックが頼れない

 

–external-lockingオプションを考えると、複数のmysqld daemonを実行して同じデータファイルアクセスする場合を除き（勧めない）、それをmy.cnfから移してください。詳しい状況はシステムファイルの外部リソースリンクを参考してください。

検討

以上情報は指定したテーブルが意外でハードウェアあるいは一个MySQLサーバシャットダウンで整合性がなくなった。整合性をチェックするには、以下の文を使ってください：

CHECK TABLE table_name EXTENDED;

 

以上の文はテーブルのあらゆる行とキーを挙げて、見つけたエラも報告する。

CHECK TABLEオプションとインポートの完全なディスクライブはMySQLブックを参考してください。

 

もし、’OK’や’Table is already up to date’以外の情報が返ってきたら、テーブルをリカバリしてください。ステップは以下の通り：

REPAIR TABLE table_name EXTENDED;

 

以上の文はMySQにリカバリする命令を下し、進展情報も返ってくる。

REPAIR TABLEオプションとインポートの完全なディスクライブはMySQLブックに参考してください。

検討

もしこんなエラが現れた：ERROR 1017 (HY000): Can’t find file: ‘./test/test.frm’ (errno: 13), or ERROR 1017 (HY000): Can’t find file: ‘./test/test.frm’ (errno: 2)，まずはOSエラdaunt (errno) と perrorツールを考えてください。そのツールはMySQLから提供し、binパスに位置する。前に提供したエラ番号で、コマンド行から以下の情報が現れる：

$ perror 13

OS error code 13: Permission denied

$ perror 2

OS error code 2: No such file or directory

 

MySQLがテーブルファイルをアクセスできないあるいはこれらのファイルを見つけ出したらエラになる。

 

解決策

まずはエラ情報に言ったファイルをチェックする。(例えば, ‘./test/test.frm’) データファイルパスにあるか否か。もしあるなら、テーブルファイルとMySQL datadirが運用されて、mysqldのユーザーが持っていることを確保してください (ディフォルトはmysql:mysql)。MySQLサーバがこれらのファイルとMySQL datadirに対して、読み書き権限が持っていることを確保してください。そして、すべてのディレクトリの権限をチェックしてください。

 

オペレーションシステムで、大文字に敏感なシステムから（例えばMS Windows)大文字に敏感ではないファイルシステムのオペレーションシステム（大体はUnixに基づくシステムである）に転移して、正確な文字でテーブルを使うことを確保してください。例えば、Windowsで運用するMySQLサーバはディフォルトはlower_case_tables_names=1、これはテーブルは小文字でディスクに格納されていることと意味する。そして、MySQLは格納や検索するときにテーブル名前を小文字に転換するから、例えばWindowsサーバでTESTという名前のMyISAMテーブルを作成して、MySQLはテーブルのために、test.frm, test.MYI, and test.MYDという名前のファイルを作成する。’TEST’でこのテーブルを利用すれば、MySQLはそれを’test’に変更する。もし、データベースごとにLinuxサーバへ転換すれば、MySQＬがそれを’test’に変更したから、TESTじゃなく、testでこのテーブルを利用する必要がある。MySQLサーバはＬinuxシステムでlower_case_tables_names=0のときに運用されるから。

 

この記事で

ターゲット

ソリューション

リファレンス

 

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

 

目標

Undropforinnodbでこわれたテーブルからデータを抽出する。

 

解決策

オープンソースUsing the opensource UnDROP tool for InnoDB from twindb.comで、時々innodb_force_recoveryで読み取ったテーブルからリカバリできる。

 

Undropツールは使われていないDBサーバが使っているibdataファイル。

 

一般的に、そのツールはibdataファイルあるいは独立したInnoDB tablespaceファイル(innodb_file_per_table使っている.ibdファイル)でインディクスページを抽出する。Blobページが利用できるサブディレクトリへ抽出する。

 

もしデータがインディクスページに抽出されたら、次のステップはデータディレクトリから主キー、一般的なクラスタリング索引IDをリカバリする。そして、データをLOAD DATA INFILEが使えるファイルに抽出する。

 

もしよければ、リカバリしたいデータベースのschema dumpで起動して、必要なときに、innodb_force_recoveryを使ってください。たとえ古いバックアップであっても、何もないよりまだましである。時にUnDROPでibdataファイルから有効なテーブル定義を抽出できる。何のバックアップもなければ、.frmファイルでテーブル定義を再作成できる。.frmもなければ、最後の手はUnDROPでidbataからテーブル定義を抽出して、せめて一部だけのデータをリカバリできる。

 

UnDROPツールは以下の通り。データを抽出する順で配列する： stream_parser

 

stream_parserはbdataからページを抽出するツールである。使い方もすごく便利である：

./stream_parser f

<path_to_ibdata>

 

ページはディフォルトで”pages-<ibdata_file_name>”に抽出する。インディクスページはサブディスプレイに格納される。

FIL_PAGE_INDEX，且blob页被储存在子目录FIL_PAGE_TYPE_BLOB。

 

テーブルにすべてのデータを抽出したいであれば、テーブルの主キーのデータディレクトリインディクスIDを識別する必要がある。これはUnDROPツールの”recover_dictionary.sh”スクリプトで、抽出されたインディクスページに抽出されたディクショナリーデータはサーバの’test’ schemaに移す。このように：

$ ./recover_dictionary.sh

Generating dictionary tables dumps… OK

Creating test database … OK

Creating dictionary tables in database test:

SYS_TABLES … OK

SYS_COLUMNS … OK

SYS_INDEXES … OK

SYS_FIELDS … OK

All OK

Loading dictionary tables data:

SYS_TABLES … 1845 recs OK

SYS_COLUMNS … 22029 recs OK

SYS_INDEXES … 4994 recs OK

SYS_FIELDS … 6070 recs OK

All OK

 

どんなインディクスIDもディクショナリーを検索して探し出せる。

例はmoodle2 schemaのテーブルmdl2_user：

mysql> SELECT SYS_TABLES.NAME TABLE_NAME, SYS_TABLES.ID TABLE_ID,

SYS_INDEXES.NAME INDEX_NAME, SYS_INDEXES.ID INDEX_ID FROM SYS_TABLES LEFT JOIN

SYS_INDEXES ON SYS_TABLES.ID = SYS_INDEXES.TABLE_ID WHERE SYS_INDEXES.NAME LIKE

‘%PRIMARY%’ AND SYS_TABLES.NAME LIKE ‘moodle2/mdl2_user’ AND SYS_INDEXES.NAME IN

(‘PRIMARY’, ‘GENERAL_CLUSTERED_INDEX’);

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

| TABLE_NAME | TABLE_ID | INDEX_NAME | INDEX_ID |

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

| moodle2/mdl2_user | 646 | PRIMARY | 1867 |

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

1 row in set (0.00 sec)

 

INDEX_IDは名１に該当する抽出ページファイルを返す：

$ ls pages‐ibdata1/FIL_PAGE_INDEX/*1867.page

2015/12/14 Document 2056049.1

https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrlstate=

scibdopz6_382&id=2056049.1 3/6

pages‐ibdata1/FIL_PAGE_INDEX/0000000000001867.page

 

c_parser

もし、テーブル定義があれば、データがc_parserでリカバリできる。このように、mdl2_user.sqlにはテーブル定義を含んでいる：

$ ./c_parser ‐b “./pages‐ibdata1/FIL_PAGE_TYPE_BLOB” ‐p “dumps/moodle2″ ‐l

dumps/moodle/mdl2_user.load ‐5f pagesibdata1/

FIL_PAGE_INDEX/0000000000001867.page ‐t mdl2_user.sql

 

各schemaに対して、以下のスクリプトとダンプディレクトリのテーブル定義で、データディレクトリで見つけ出したテーブルを抽出して、LOAD DATA INFILEにふさわしいファイルにロードする。もし、もとのテーブル定義がないあるいは.frmファイルで抽出出来ない場合に、最後の手として、sys_parser行をアンチノートしてください。元のテーブル定義があれば

分けられたｓｑｌファイルとしてdumps/<schema>/<table>.sqlに格納してください：

#!/bin/bash

RECOVERY_DB=”test”

USER=”root”

PASS=”somepass”

DUMPS=”dumps”

# Create schema

echo > ${DUMPS}/schema.sql

for DB in `mysql ‐‐user=${USER} ‐‐password=${PASS} ‐NBe “select name from

${RECOVERY_DB}.sys_tables” | sed ‐r “s/^(.*)\/.*$/\1/” | grep ‐v SYS_ | sort ‐u `

do

mkdir ‐p ${DUMPS}/${DB}

echo “Creating schema for $DB…”

echo >> ${DUMPS}/schema.sql

echo “CREATE DATABASE IF NOT EXISTS $DB;” >> ${DUMPS}/schema.sql

for TABLE in `mysql ${RECOVERY_DB} ‐‐user=${USER} ‐‐password=${PASS} ‐NBe

“SELECT NAME FROM SYS_TABLES WHERE NAME LIKE ‘${DB}/%'”`

do

echo $TABLE

# ./sys_parser ‐u${USER} ‐p${PASS} ‐d ${RECOVERY_DB} ${TABLE} | tee

${DUMPS}/${TABLE}.sql >> ${DUMPS}/schema.sql

PKEY=`mysql ${RECOVERY_DB} ‐BNe “SELECT SYS_INDEXES.ID FROM SYS_TABLES

LEFT JOIN SYS_INDEXES ON (SYS_TABLES.ID = SYS_INDEXES.TABLE_ID) WHERE

SYS_TABLES.NAME = \”${TABLE}\” AND SYS_INDEXES.NAME=\”PRIMARY\””`

echo “pkey = $PKEY”

PAGE=”pages‐ibdata1/FIL_PAGE_INDEX/`printf ‘%016u’ ${PKEY}`.page”

echo “PAGE = $PAGE”

./c_parser ‐b “./pages‐ibdata1/FIL_PAGE_TYPE_BLOB” ‐p “./${DUMPS}/${DB}” ‐

l ${DUMPS}/${TABLE}.load ‐5f ${PAGE} ‐t ${DUMPS}/${TABLE}.sql > ${DUMPS}/${TABLE}

2015/12/14 Document 2056049.1

https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrlstate=

scibdopz6_382&id=2056049.1 4/6

done

done

 

sys_parser

前に言ってたとおりに、sys_parserはibdataファイルからテーブル定義を抽出するときに使える。けどこれはせいぜい最後の手段で、テーブル定義がなければ、ibdataから使用可能データを抽出することはありえない。

.frmファイルから有効なテーブル定義を抽出する

MySQL Utilitiesパッケージのmysqlfrmで壊れていない.frmファイルから有効な定義を抽出できる。診断モードで、mysqlfrmを使うと、sys_parserでibdataからデータを抽出するときに、同じようなトラブルになるから、mysqlfrmを使うこととサーバ標識は大切である。インポートは調整されて、c_parserと運用する。

所以使用mysqlfrm与服务器标识是很重要的。输出必须被调整来与c_parser运作，コマンドライン、警告、またはデフォルトの文字セット情報は、テーブル定義で発見された場合ので、c_parserが死ぬ。これはテーブル定義を抽出し、一つのschema.sqlがディレクトリから見つけ出した.frmファイルでschema(s)を作成する方法である：

#!/bin/bash

for FRM in `find ../datadir/ ‐type f ‐wholename “*frm” | sort`

do

mysqlfrm ‐‐server=root:somepass@localhost:../datadir/mysql.sock ‐‐port=33307

$FRM | extract_schema.pl

if [ ${PIPESTATUS[0]} ‐ne 0 ]; then

echo “$FRM is corrupt”

fi

done

 

extract_schema.plこのように：

!/usr/bin/perl

open (SCHEMAFILE, ‘>>’, “schema.sql”) or die “Can not write to schema.sql $!”;

$schema = “”;

$table = “”;

2015/12/14 Document 2056049.1

https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrlstate=

scibdopz6_382&id=2056049.1 5/6

while (<STDIN>) {

$origline = $ _;

chomp;

if (/^ CREATE TABLE.*$/) {

m/.*CREATE TABLE \`(. *)\`\.\`(.*)\`[[:space:]]\(/;

$schema = $1;

$table = $2;

print “Creat ing $schema.$table\n”;

unless (‐e $schema or mkdir $schem a) {

die “Unable to create dir for sche ma $schema”;

}

p rint SCHEMAFILE “CREATE DATABASE IF NOT EXISTS $schema;\n”;

print SCHEMAFILE “USE $schema;\n”;

print SCHEMAFILE “$origline”;

open (TABLEFILE, ‘>’, “$schem a/$table.sql”) or die “Can not write to

$schema/$table.sql”;

print TABLEF ILE “CREATE TABLE $table (\n”;

} else {

s/ENGINE=(.*?)[[:space:]].*/ENGINE=\1;/;

s/`PRIMARY`//;

s/^#.*$//;

s/^WARNING.*$//;

$origline =~ s/(.*ENGINE.*$)/\1;/;

$origline =~ s/^#.*$//;

$origline =~ s/^WARNING.*$//;

print SCHEMAFILE “$origline” if (!/^\s*$/);

print TABLEFILE “$_\n” if (!/^\s*$/);

}

}

 

幸い、UnDROPはまだ使用可能だが、これを使うこととは状況はとってもひどくなった。データベースがこわれたときに、どんなデータをリカバリする保障もない。このような状況を避けるために、MySQL Enterprise Backupで定期的に、バックアップを作成してください。そして、せめて一つのslaveをコピしてください。