本番システムで Firebird データベースを使用することについて、主に 2 つの反対意見を耳にしました。レプリケーションがサポートされていないことと、バックアップを復元できないという重大な問題があることです。しかし、それは少し前のことであり、Firebird が継続的に改善され、開発されてきたことを知っています。
では、これらの問題は現在どの程度関連性があり、実稼働システムでの使用を不必要に困難にする他の契約違反はありますか?
Firebird の Web サイトで参考文献を確認してください: http://www.firebirdsql.org/en/case-studies/
データベースまたはバックアップ (firebird) がクラッシュした場合でも、必要に応じて復旧を行うチームがあります (壊れたバックアップまたは壊れたデータベースのいずれか): http://ib-aid.com/team/
私が個人的に経験した復元不可能なバックアップの状況 (テストする必要があります!) とレプリケーションに加えて、Firebird には次のような多くの高度な機能がありません。
さらに、テーブルあたりの行数とインデックスの幅にはいくつかの制限がありますが、これは決まった数ではなく、ページと行のサイズによって異なります。私が思い出したように、行の制限は一般に数十億です。
*(「慎重な書き込み」を使用すると、Firebird データベース ファイルは本質的にトランザクション ログとデータベース ファイルが 1 つになるため、クラッシュ時には、破損のない最後のトランザクションがコミットされている必要があります。これは、再起動時の回復時間が 0 であることも意味します。)
2000 年にリリースされた最初のバージョン (0.9 ベータ) から、Firebird を金融アプリケーション (2 層) のデータベース サーバーとして使用しています。
レプリケーション - そのために独自の内部ソリューションを使用しているため、利用可能なサードパーティ サービスについては何も言えません。
バックアップを復元できないという重大な問題について。. 私はしばらくこれらの問題に会っていません。バックアップはできるが復元できない場合、データベース構造を変更することは可能です。ただし、元のデータベースが削除されていない場合は、途中でデータまたはメタデータを修正することが常に可能です。これにより、そのデータベースのバックアップ/復元ルーチンが再び機能します。
従うべき唯一のルール: 復元中に元のデータベースを上書きしないでください。常に新しいファイルでバックアップを復元します。