既存のデプロイのバックアップを復元してサイトを移行しようとしています。スキーマの不一致（ソースがターゲットより新しい）により、復元が失敗しています。
現在、両方のデプロイの admin/plugins エンドポイントを確認していますが、リストされているプラグイン、そのステータス、バージョンは一致しており、少し首をかしげています。念のため、すべてのテーマとコンポーネントを元に戻してみましたが、変化はありませんでした。両方のサイトはアプリ 3.1.3 であり、このケースでは根本原因ではないようです。
サイトにプラグインがインストールされ、その後インスタンスが再デプロイされ、このプラグインなしでデータベースが保持された可能性がありますが、これは推測にすぎません。インスタンスまたはデータベースが与えられた場合、スキーマのずれの原因を特定できる決定論的な方法はありますか？また、「ダウングレード」する方法はありますか、それともターゲットサイトを一致させるかスーパーセットにするしかないのでしょうか？
古い方がベータ版またはテスト合格済みで安定版ではなかったため、最新の安定版が実際には古いということでしょうか？
コミット番号が一致するかどうか確認します（可能であれば）。
バックアップはデータベースのものなので、プラグインのポピュレーションは関係ないと思います。プラグインデータが追加されるだけで、実際には使用されません…
いいえ、そうは思いませんが、開発環境なので何でもあり得ると思います。
schema_migrations テーブル（またはクローンされたコンテナコード）で、スキーマバージョンと何らかの変更を照合できる手動で確認できるものはありますか？
ファイル名を変更するとUI経由でアップロードできるようになりますが、私はmergerを使用しており、これはmax(schema_migrations)に基づいてブロックされます。そのため、あまりハッキングせずに済ませたいと考えています。
これらの一部は、マイグレーションバージョンの不一致が発生する可能性のある運用タスクよりも先行しています。マイグレーションバージョンをどのように変更にまで遡って追跡できるかを理解しておけば、次回同様の問題が発生した際に、調整するためのrunbookを作成できることを願っています。
rails db:version
を discourse ディレクトリからコマンドラインで実行します…ただし、リストアしていない場合は役に立たないかもしれません…
または psql から:
SELECT * FROM schema_migrations ORDER BY version DESC LIMIT 1;
その後、GitHub でそれを検索して、コミットを相互参照できます…
例: https://github.com/search?q=repo%3Adiscourse%2Fdiscourse+20231222030024&type=code
マイグレーションファイルを参照し、追加されたときのコミットを記録して、日付などを確認します。
注意: これは必ずしもコードコミットと同じではありません！古い可能性があります 
(git log -1 で取得できます)
はい、最大スキーマ移行（バックアップファイル名を見るだけでも）は確認できますが、テーブルを確認したところ、日付の値しかありませんでした。どこから来たのかを示すものは何もありません。
例えば、「良い」は 20230823100627 で、サイトは 20231022224833 です。post_migrate フォルダー（またはリポジトリの他の場所）で「20231022」のファイルを見つけることすらできません。
きっと私の目の前にあるのだと思います。そして、8月以降に不正なバージョンが紛れ込んだ可能性のあるアクションを特定するために、過去の変更履歴やメールを掘り起こしています。
待ってください、開発インスタンスを本番データベースに復元しようとしているのですか、それともその逆ですか？
私はそれを試したことがありません。本番から本番への復元のみを行ったことがあります（その場合、データベース名やその他の構成は一貫しています）。
この場合、Devインスタンスから新しくプロビジョニングされた「Merge」インスタンスに移行します。その後、mergerを使用して別のDevインスタンスをインポートし、現在実施中のインスタンス統合のテストを行います。スキーマ移行リビジョンが同期していることは前提条件です（驚きはありません）。この場合、ターゲット環境は1022で、ソースは0823です。私が持っているすべての3.1.3では0823なので、1022がどこから来たのかが謎であり、それを突き止めようとしていますが、手がかりが見つかりません。
OK、あなたのワークフローは非常に…エキゾチックですね！
理想的には、開発環境にデータを保持する必要はなく、データベースを削除してマイグレーションを再実行できるはずです。
分岐した2つの開発インスタンスをマージするには、通常、ブランチ（マイグレーションを含む）をマージしてから、すべてを新規に作成して新しいインスタンスを作成しますか？
これは、作業できるものを用意するために、フィクスチャを事前に入力する便利なrakeタスクがある理由の一部です: rake dev:populate
400以上のプラグインのすべての移行IDを含むデータベースがあるため、簡単にプラグインにマッピングできます。これはdiscourse-automationからのものです。
ええ、農場の家畜がしばらく前に納屋から逃げ出したので、みんなを囲いに戻そうとしています。あるいは少なくともそれが可能かどうかを把握しようとしています。
そして、インスタンスのファイルシステムを見ながら、なくしたピースを見つけました。
人々は自動化について調べていましたが、他の環境ではそれを有効にしたことがなかったため、プラグインリストで利用可能であり、スキーマの変更は行われていませんでした。理想とはほど遠いですが、この作業での私のヒントは、無効になっていても、過去に有効になっていた可能性があるため、インストールされているすべてのプラグインのリポジトリを確認することです。
これらのR&Dプラグインの一部を削除する再デプロイを行っており、プラグイン/DBエントリをより注意深く監視し、そこでより良い記録保持を行っています。
おかげさまで、インスタンスの実行時自体を確認して、ようやく解決策を見つけましたが、理想とは程遠いです。運用ランブックが必要になった場合の教訓になりました。自動化リポジトリは無効になっているように見え、誰も使用した記録がなかったため、組織内のリポジトリを確認しませんでした。私の早合点でした。
@RGJ、そのデータベースはどこかで公開アクセス可能でしょうか？インスタンスのファイルシステムを使用することは「機能」しますが、私が好むよりも面倒なことになります。
コミットをプッシュしなかったということですか？
何を保存しようとしているのですか？
はい、私はディスコースリポジトリ自体で検索していました。世界中をスイープアップするのではなく、それが表示されるかどうかさえ確信が持てなかったからです。スコープなしでの検索は高すぎますが、ディスコースの公式な取り組みのヒットがあるかどうかを確認するために組織にまで手を伸ばしませんでした。
独立したチームが共通のビジネス上の問題を解決するために立ち上げた 3 つまたは 4 つの Discourse インスタンスがあり、以前の作業を失うことなく、全員を 1 つのインスタンスに統合できるかどうかを確認しています。
開発環境でデータを保持することが良いプラクティスであるとは信じがたいです。
データが重要であれば、より管理された状況下で本番環境に配置されるべきです。
あなたが何をしようとしているのか、その全容はわかりませんが、意見を述べさせてもらうと、ソリューションはどこにでもデプロイできるプラグインであるべきで、特定のバージョンのDiscourseに完全に依存する必要もなく、独自のフィクスチャのシード以外で特定のデータが事前に投入されていることを気にする必要もないはずです。
はい 
この場合、Devインスタンスをいくつか使用して、本番インスタンスのマージ操作の実現可能性を調査しています。ランブックを確実に作成できれば、すべてのデータとインスタンスは本番レベルになりますが、これまでは独立したチームによって管理されてきました。したがって、正常なマージのブロッカーを把握することが、現在私が取り組んでいることです。スキーマバージョンは明らかに重要なものであり、アプリとプラグインの両方が「マージ可能性」に影響を与える可能性があります。幸いなことに、本番インスタンスでは0823が示されているため、この特定の問題は本番実行では発生しませんが、スキーマドリフトを分析する方法を知ることは必要であり、opdocsに非常に役立ちます。
なるほど、本番DBのマージをプロトタイピングしているのですね。興味深いです。
しかし、何をマージしようとしているのですか？
トピック（およびそのユーザー！）をインスタンス間で移動することは公式にサポートされていることをご存知ですか？:
既存のトピックと関連コンテンツが数千件あるため、個別のものは少し厄介です。
Merge two Discourse sites into one これは異なるスクリプトを使用していますが、基本的な考え方は同じです。
スキーマの別のニュアンスを発見しました。デプロイから自動化プラグインを削除して再デプロイしました。その後、schema_migration が最新として 0823 にロールバックされたように見えました。そのため、マージするインスタンスに自動化プラグインをインストールしなくても大丈夫だと思っていました。しかし、インポートをもう一度実行したところ、PG::UndefinedTable: ERROR: relation "discourse_automation_automations" does not exist というエラーが発生しました。マイグレーションのバージョンはロールバックされましたが、それに関連するスキーマ変更は実際の DB に残っていたようです。
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.
