私自身の喜びのために、ウィキペディアのロボットが私のコンピューター(
account1 、
account2 、
ソースコード )で回転してい
ます 。 ボットは、Wikipediaページのバージョンのローカルキャッシュを保持します。これにより、背後にあるたびにリモートサーバーにアクセスしないようになります。また、過去数年間収集されたボットにとって非常に重要な特定のデータセットも保持します。 データは、Apache Derbyの制御下にあるデータベースに収集され、キャッシュと合わせて、データベースは約50 GBを占有します。
そして、ある晴れた日、ボットが4つのCPUで8スレッドでデータを処理したとき、Abbyy FinereaderはA. A. Polovtsevが編集したロシアの伝記辞書の第14巻を認識し、敵はCivilization Age of Kingsで動きました...彼が登場-死のブルースクリーン。 久しぶり、コンピューターを再起動すると思った。 理由は申し分ありません-ほとんどの場合、ハードウェアのビデオアダプタに問題があります。 しかし、コンピューターが起動し、ボットを再び起動しようとしたときにのみ、これが発生しました。
エラーXSDG2:ページPageのチェックサムが無効です
そして、以前のバックアップは、いつものように、3月の日付です...
問題の調査に30分または1時間を費やしました(Google検索を読んでください)。
- データ回復ユーティリティはありません。 なし。 バックアップを使用する-これは公式の唯一の方法です。
- 特定のページのチェックサムチェックをバイパスできる推奨パッチがあります。 たとえば、 DERBY-1648
- 最後に、データリカバリを単に無視する方法があります。 はい、あなたの目はあなたを欺かない-それは回復です。 事実、Apache Derbyは誤った完了後、トランザクションログを読み取り、自尊心のあるACID互換DBMSと同様に、不完全なトランザクションをロールバックしようとします。 彼女が外出しないというだけです-彼女は誓います。
最後の作り方は? ログを削除するだけです! ただし、
IBMが警告しているように (Cloudscape開発者は後にDerbyになりました):
Derbyデータベースのディレクトリ構造内の* ANY *ファイルを削除または操作しないでください。 そうすると、データベースが破損します。
それで、土曜日から日曜日の夜に私は何をしましたか?
- ハードディスクには、現在のデータベースのサイズの3倍以上のスペースがあると確信しました。
- 稼働していないデータベースのバックアップを作成しました。 絶対に遅れることはありません。
- フライングパスタモンスターに祈りを捧げた後、彼はログフォルダーからすべてのファイルを削除しました(フォルダー自体は残しておく必要があります-それなしではロードされません)。
- SQuirreL SQL Clientを使用してデータベースにアクセスし、動作することを確認しました。
しかし、これはもちろん、すべてではありません。 トランザクションログを削除すると、特にデータベースの回復エラーが発生した場合、何も問題にならないことを理解する必要があります。 このようなベースは機能しますが、長くは続かない-構造の最初の枠まで。 どういうわけかデータベースにすべてのテーブルのすべてのデータを強制的にシャベルする必要があります(Derbyの用語では-新しいコングロマリット)。
Apache Derbyの
バックアップと復元に組み込まれた
メカニズムは役に立ちません。構造を確認せずにデータファイルを愚かにコピーします。 ただし、パッケージには
ijという興味深いユーティリティが含まれています。 データベースへのコンソールアクセスを提供することに加えて、他のアプリケーションからデータベースにアクセスするときに使用できない機能を呼び出すこともできます。
Export&Importスイートには、このような関数が2つ必要です。
- SYSCS_UTIL.SYSCS_EXPORT_QUERY_LOBS_TO_EXTFILE
- SYSCS_UTIL.SYSCS_IMPORT_TABLE_LOBS_FROM_EXTFILE
これらの関数は、標準のテキスト形式でデータのエクスポート(およびインポート)を行います。 オプションのLOBS_FROM_EXTFILEプレフィックスは、バイナリテキストフィールドと単純に大きなテキストフィールドが別のファイルに保存されることを示します。 これは、少なくとも目の角からデータの正確性を確認する場合に便利です。
したがって、次のステップはijの起動でした...
java -cp "derby.jar;derbytools.jar" -Dij.maximumDisplayWidth=120 org.apache.derby.tools.ij
データベースへの接続(ijのコマンドの最後にあるセミコロンを忘れないでください)
ij>connect secretarydb;
すべてのアプリケーションデータをエクスポートします(各テーブルの個別のコマンド)
ij>CALL SYSCS_UTIL.SYSCS_EXPORT_TABLE_LOBS_TO_EXTFILE(null,'TABLENAME','c:\data\TABLENAME.del',null,null,'UTF-8', 'c:\data\TABLENAME.dat');
ところで、ijのコマンド「SHOW TABLES」
はです。
エクスポートが完了したら、適切なデータサイズをサポートするお気に入りのテキストエディターを使用して、少なくともファイルの先頭と末尾の読みやすさを確認できます。 何かが間違っていることが判明した場合、.delファイルから余分な行を削除することができます。一般に、何も拒否しないでください。これはまさに、数人のサブスクライバーの口座残高を編集できる瞬間です。
完了したら、データベースを削除します。 どちらかといえば、バックアップがあります。 その後、ボットを再び起動するだけで十分であり、休止状態にして、起動時にテーブル構造を復元しました。 その後、すぐにアプリケーションを停止し、ijを実行してデータをインポートします。
java -cp "derby.jar;derbytools.jar" -Dij.maximumDisplayWidth=120 org.apache.derby.tools.ij
ij>connect secretarydb;
ij>CALL SYSCS_UTIL.SYSCS_IMPORT_TABLE_LOBS_TO_EXTFILE(null,'TABLENAME','c:\data\TABLENAME.del',null,null,'UTF-8', 1);
最後にあるものは、テーブル内のデータが既に存在する場合は上書きする必要があることを示しています。 LOBデータを含むファイルの名前を指定する必要はありません。メインファイルにはそのファイルへのリンクがあります。
それだけです データが回復しました。 しかし、もちろん、ボットに追加される次の機能は、各開始時に最も重要なデータを自動的にアーカイブすることです。