問題タブ [flyway]

継続的デリバリーでの本番環境でのリレーショナルデータベース（およびスキーマ）の移行パターンとは何ですか？

多くの従来の開発では、DBAは、現在のリリースサイクルで作成された多くの小さなスクリプトから大きな移行スクリプトを配置します。しかし、CDの場合、開発者は、他のスクリプトでコンパイルするのを待つのではなく、今すぐ変更を本番環境にプッシュしたいと思うかもしれません。

私はrails-migrationで知っていますが、生のsqlスクリプトを使用する方が合理的に見えます。

移行を管理するためのflywayのようなツールも見たことがありますが、本番環境でそれらを使用している多くの人々のことは読んでいません。これが、ここでの一般的な慣行は何であるか疑問に思う理由です。

Flywayをpostgresqlで使用することを検討しています。

移行が失敗した場合、手動でロールバックする必要がありますか、それとも postgres で ootb で動作しますか? 次の移行は、失敗した移行の後も引き続き実行されますか?

liquibaseやflywayなどのツールを使用すると、データベースを簡単にアップグレードできます。私が頭に浮かんだのは、リリースブランチとトランクの両方で発生する変更を最適に処理する方法です。

例：

製品に含まれている私のコードはバージョン2.5であり、リリースブランチにあります。その間、開発者はトランク上に存在するバージョン3.0の作業を開始しました。

本番環境でバグが見つかりました。データベース変更スクリプトが作成され（2.5.1）、リリースブランチにコミットされます。同じ変更スクリプトをトランク（3.0.1？）にマージして戻す必要があります。

バージョン3.xは、実際の本番環境にリリースされています。データベースには、2.5.1からの変更がすでに含まれています。アップグレードが失敗する可能性があります。

逆に、転送のみの戦略を使用してデータベースを最初から作成している場合、同じ変更が2回発生します（2.5.1と3.0.1）。

他の人はこのシナリオをどのように処理していますか？

私たちのシステム

移行を .sql ファイルとしてバージョン管理下に置こうとしています。開発者は VN__*.sql ファイルを作成し、バージョン管理にコミットし、5 分ごとに実行されるジョブは自動的に Dev and Test データベースに移行されます。変更によって問題が発生しないことが判明したら、他の誰かが手動ジョブを実行して、本番環境で移行を実行します。

私の問題：

いくつかのテーブルを作成するデモ移行がありました。V4__DemoTables.sql を PC のバージョン管理にチェックインしました。

私たちの Linux ボックスでは、5 分ごとに実行されるジョブがバージョン管理から新しいファイルを抽出し、次に flyway.sh ファイルを実行しました。ファイルを検出して実行しました。

しかし、.sql ファイルにはタイプミスがありました。また、フライウェイが BEGIN TRAN ... END TRAN で移行を自動的にラップすることに問題がある Neteeza を使用しています。そのため、移行によって 2 つのテーブルが作成され、3 つ目のテーブルの前に中止されました。

問題ないと思いました。.sql ファイルが作成した 2 つのテーブルを削除しました。バージョン管理から V4__ をチェックアウトし、タイプミスを修正して再送信しました。

5 分後にアップデートが抽出されましたが、flyway はチェックサムが一致しないと訴えています。したがって、更新された V4__DemoTables.sql ファイルは実行されません。

更新されたファイルを受け入れ、入力ミスの場合に SCHEMA_VERSION ファイルのチェックサムを更新するにはどうすればよいですか?

ドキュメントを読むと、開発者が修正を含む新しい V4_1_DemoTables.sql ファイルを作成する必要があると提案しているようです。しかし、これは V4__ ファイル内のコマンドと衝突するため、これは間違っているように見えました。

したがって、ドキュメントが私がしなければならないことを暗示しているのは次のとおりです。

• SCHEMA_VERSION テーブルに従って、V4__ を「成功した」移行として残します。

  V4_1_ を作成して、V4__ のタイプミス行の前に作成されたテーブルを削除します。

  すべての実際の作業を行うために、元のファイルのタイプミスを修正した V4_2_ を作成します。

これは正しいです？

Flywayはoraclepl/ sqlパーサーを提供しているので、移行にpl / sqlダンプ（.pde）を使用することは可能ですか？

現在、flyway1.7とjBoss7を使用しています。完全に移行する時間が5分以上かかる場合、Flywayの移行が実行されていると、jBossはトランザクションをタイムアウトすることを示しますが、その後もFlywayは移行を続け、最終的には完全に移行されます。 DBですが、トランザクションのタイムアウトが原因でデプロイに失敗しました。また、最近、移行の実行中にjBossをシャットダウンしようとしても、移行は影響を受けず、実行を継続することに気付きました。これは望ましい動作ですか？フライウェイは、私がそれについて何もできない彼女自身のブロックされたトランザクションのある種の下で移行を実行していますか？

よろしく、D

特にデータベースを作成する必要がある場合は、createEntitymanagerFactoryに時間がかかることがあります。

データベースにFlywayを使用していて、移行中に問題を見つけ始めました。ログを見ると、テーブルが作成される前に移行しようとしているようです。例えば

JPAは、テーブルを作成するように設定されています。JPAでログを有効にすると、JPAがデータベースの作成を完了する前に上記のエラーが発生することが示されます。

JPAデータベースをリッスンして、いつ準備ができたかを知る方法はありますか？エンティティ自体のリスナーのみが見つかりましたが、PersistenceManagerのライフサイクルには何も見つかりませんでした。

flyway-maven-plugin でいくつかの実験を行います。私は空のデータベースを持っていないので、最初の ddl スクリプトが必要です。Flyway wiki の指示に従います。

V1__Base_Migration.sqlという名前の SQL スクリプトをsrc/main/resources/db/migrationに配置しました。

flyway-maven-plugin の構成は次のようになります。

cmdを呼び出しmvn install flyway:initてデータベースで実行を確認すると、flyway のバージョン テーブルは見つかりますが、sql スクリプトに ddl があるテーブルは見つかりません。

Maven のデバッグ ログを見ると、SQL スクリプトが実行されたというヒントが見つかりません。

私は何か間違ったことをしていますか？誰かが私にヒントを与えてくれるなら、私が間違っていることを教えてくれるとうれしいです。

Maven テスト プロジェクト全体は [github] (https://github.com/skosmalla/flyway-maven-test) にあります。

よろしくお願いします、

サンドラ

私は最近Flywayについて知り、それを読んで検索しているときに、次のブログ投稿に遭遇しました：データベーススキーマの進化とスキーマのバージョン管理。

だから私は疑問に思っていました：

• それがまだ真実である（またはその時点でさえ真実である）と言っていることですか
• フライウェイを使用している間、そのようなケースはどのように扱われるべきですか。

編集：

FAQはこれについて簡単に説明しています（前述の問題の解決策は提供していません）。

schema_version テーブルを更新し、変更された PL/SQL パッケージ/手順をフライウェイでコードの重複なしに実行するには、どのような方法が望ましいでしょうか?

私の例では、PL/SQLコードの変更ごとにクラス・ファイルを作成する必要があります

AbstractMigration クラスは、db/updateフォルダー内のファイルを実行します。

PL/SQLコードを実行するより良い方法はありますか?