3.3beta1에서 3.5beta7로 복원 시 "discourse_automation_automations" 관계 오류

지원 자체 호스팅
1

다음과 같은 상태의 데이터베이스를 현재 버전으로 복원하려고 시도하고 있습니다.

    <meta name="generator" content="Discourse 3.3.0.beta1-dev - https://github.com/discourse/discourse version a4022f69f31af611bc0e21258b0ccb77dec38ba3">

같은 app.yml을 복사하여 복원 작업(새 VM에서 수행 중, pg 업그레이드를 우회하려는 시도이나, 복원 대신 업그레이드를 시도해야 할 수도 있음)를 진행 중입니다.

다음과 같은 오류가 발생합니다:

PG::DuplicateTable: ERROR:  relation "discourse_automation_automations" already exists

어떤 마이그레이션이 다시 체크인되어 해당 사이트가 그 몇 가지 커밋 사이에 빌드된 또 다른 사례인 것 같습니다.

하지만 무엇을 해야 할지 모르겠습니다. 이 테이블을 생성하려는 마이그레이션을 삭제해야 할까요?

구버전 데이터베이스는 20240122015630이고, 신버전은 20250617085536입니다.

새 소스에서 다음 내용을 확인했습니다:

db/migrate/20190601000001_create_automations_table.rb:    create_table :discourse_automation_automations do |t|

하지만 어째서인지 이 마이그레이션은 해당 작업을 수행하지 말아야 한다는 것을 인식하지 못하는 것 같습니다. 해당 테이블은 양쪽에서 동일한 필드를 가지고 있습니다. 2019년의 그 마이그레이션을 그냥 삭제하면 될까요?

2

I think 3.3beta1 was before the plugin was included in core in April. Could this lead to any issues - for example, due to the plugin now being included in core while still also being installed separately via app.yml?

3

That’s a good idea, but that’s not it. I’m not including it again. I wonder if maybe I should have tried adding it (but I don’t see it in a quick look). My current idea is to drop all of the automations tables (they are empty) on the old site, make a new backup and trying restoring that.

4

Well, and then it failed because discourse_automations_automations was missing. :person_shrugging:

5

So I removed these:

20210108134117_add_pending_pms_table.rb
20210512090204_add_timestamps_to_automations.rb
20210530122323_move_triggers_to_fields.rb
20211119103353_adds_discourse_automation_user_global_notice.rb
20230412120414_add_prefers_encrypt_field_to_pending_pms.rb

and probably should have removed 20190601000001_create_automations_table.rb, but instead I added unless table exists code (I think when I deleted it I had another problem?).

And I finally got it to restore.

And when I rebuild, I get the same errors when the database tries to migrate.

So somehow I guess I need to convince rails that these migrations have, uh, run already. So then I tried this:

INSERT INTO schema_migrations(version) VALUES
('20190601000001'),
('20210108134117'),
('20210512090204'),
('20210530122323'),
('20211119103353'),
('20230412120414');

And that didn’t work either.

I think maybe it’s just those ones frrom 2021 I need to skip? Or maybe 202105?

But the version that’s running is from January 2024.

I was able to restore the first database (before I’d mucked with the schema_migrations) on the old server, so at least I’m back where I started. I guess I need to know how to look at the commits and migrations in some ways that I don’t.

6

Can we close this topic? Or move it to Development or #installation:hosting if you want to keep it open ended?

7

Yeah. You can close it. I’m unclear if it’ll ever happen to anyone else so that this may or may not be useful.