AutoMysqlBackupスクリプトを使用してアプリケーションの毎日のバックアップを実行しようとしています。残念ながら、最初の試みでは私が思ったようにうまくいきませんでした。
スクリプトがその--lock-tables=trueパラメータを使用しているため、私のアプリケーションは機能しないようです。
この場合、スクリプトがテーブルをロックしないようにするにはどうすればよいですか？ （私のアプリケーションを引き続き実行できるように）？
ありがとうございます。
ベストアンサー1
いいですね。ソフトウェアにはあまり慣れていませんが、次のようになります。
- シェルスクリプトなので（理論的に）編集が簡単です。もちろん約2200行のシェルスクリプトだ。
- 私の考えでは、--lock-tablesが--optから来たようです。非常にクイックビュー）機能の上部にあります
parse_configuration。--skip-lock-tablesそこに追加してください。 - これはmysqlユーティリティを使用するため、
.my.cnf一般的な方法で追加することもできます。
一般的に言うと：
- InnoDBではなくMyISAMを使用しているため、トランザクションはありません。したがって、使用できません
--single-transaction。 - したがって、一貫性を確保するにはロックが必要です。ロックがあっても保証されません（ただの可能性が高いだけです）。ただし、これは通常の動作で保証される制限にすぎません。 InnoDBを真剣に検討してください（ただし、まず文書を読んで調査し、アプリケーションが中断されないことをテストしてください）。
- ロックを無効にすると、次のことができます。
- バックアップの開始
- テーブルAをバックアップします。
- A のレコードを削除し、B の子レコードを削除します。
- バックアップテーブルＢ。
- バックアップには、存在しない B のレコードを指す A のレコードが含まれます。つまり、一貫性がありません。
- より広く使用されているMySQLバックアップソリューションもあります。たぶん、これらのいずれかに切り替える必要があります。より多くの人が使用しているソフトウェアのヘルプを見つけるのは簡単です（そしてテストもうまくいく傾向があります）。
- あなたはできます考えるバックアップはありますが、実際に正常に復元するまでバックアップは実行されません。可能であれば、ベアメタル（新しくフォーマットされたハードドライブ）から復元することをお勧めします。理想的には、これを定期的に実行することができ、自動化することをお勧めします。これはMySQLに限定されず、次のように動作します。みんなサポート。
解決策があります（InnoDBへの切り替えに加えて）：スレーブサーバーでバックアップを実行できます。SLAVE STOP SQL_THREADプライマリテーブルは重要ではないため、バックアップ中にすべてのテーブルをロックしたり、すべてのテーブルをロックしたりしても問題ありません。これはダウンタイムのないソリューションです。あなたしなければならないとにかく、メインサーバーに障害が発生した場合に備えて、このサーバーをホット/ホットスタンバイとして使用してください。
ダウンタイムを最小限に抑える別のソリューションがあります。データベースをLVMボリュームに配置して操作を実行し、FLUSH TABLES WITH READ LOCKLVMスナップショットを撮ってから読み取りロックを解除します（接続を切断するとこれが起こります）。その後、スナップショットからバックアップできます。これが「他の機械を購入する余裕がない」ソリューションです。