3

Hibernate が生き残るデータベース (この場合は MySQL) への変更 (データ、スキーマなど) は?

これは、Hibernate のダウンタイムがゼロであるためです。

データベースを変更し、アプリ サーバーを 2 つのクラスターに分割し、クラスターの 1 つにアプリケーションを再デプロイして、アプリケーションを切り替えます。

ありがとうステファン

4

1 に答える 1

1

これは、休止状態に関する特別な洞察からではなく、個人的な経験から回答します。したがって、これを一粒の塩で取ってください。また、少しあいまいな質問のようですが、適切な場所にコメントを追加してください。:)

まず第一に、hibernate でマップされていないスキーマを変更/追加/削除しても、問題が発生することはありません。Hibernate が実際に行っているのは、クエリを生成することだけです。これは、多くのものを SQL に変換するためです。これらのクエリが機能し続ける限り、アプリは単純に機能し続けます。これは、テーブルに列を追加したり、テーブルを追加したりすることは問題ではなく、マップしていない列を削除することも問題ではないことなどを意味します。

さらに問題なのは、マップされているものへの変更です。number(10,0) を number(11,0) に変更すると、通常はこれでうまくいきます。CHAR(1) フィールドを BIT フィールドなどに変更するなどの作業を開始すると、休止状態のマッピングに特定の変更が必要になり、既存の展開が失敗します。これは常識です。このような変更を行う必要がある場合、通常の db サーバーで ALTER TABLE を実行すると、おそらくテーブルがロックされるため、アプリを再起動することは最大の問題ではありません。

高可用性の下での主要なスキーマ変更への対処は、休止状態が直接対処することを意図したものではありません。Hibernate は、スキーマの変更に非常にコストがかかることが多い従来のリレーショナル データベースを想定しています。

あなたが言及した他の3つの問題：

  • データ ソースの変更: おそらくアプリの再起動が必要です
  • アプリサーバーの分割: 私が言っていることを意味しているのであれば、単に異なるアプリサーバーにデプロイすることができます。スイッチオーバーが必要な場合は、Web アプリと顧客の間に何かを使用してそれらを処理します。つまり、IP レベルのロード バランサーなどです。
  • データの変更: トランザクション データベースと複数の書き込みに関する通常の問題が適用されます。Hibernate は、データベースの一貫性のないビューになる可能性があります。他のユーザーによる変更を上書きする可能性があり、場合によっては例外が発生する可能性がありますが、これらの AFAICT のような状況を予測して対応できるはずです。
于 2009-03-12T10:45:33.613 に答える