Maclean’s Oracle Database Tech Blog Archives

この記事で 症状 変更 原因 解决策 リファレンス   この記事は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.…

適用範囲： 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…

  この記事で 症状 原因 解决策 リカバリ 今後同じようなことが起こることを防ぐ リファレンス   適用範囲： 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…

検討 このエラは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に対して、読み書き権限が持っていることを確保してください。そして、すべてのディレクトリの権限をチェックしてください。  …

  この記事で ターゲット ソリューション リファレンス   適用範囲： 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……