저는 그 오류들이 PostgreSQL 버전 불일치와 관련이 있다고 생각했지만, 며칠 전 디스크 공간이 부족했던 시스템에서 같은 \N 오류를 확인한 적이 있습니다(백업을 만든 것과 동일한 시스템에 복원 중이었음). 문제를 완전히 진단하지는 못했습니다(당시 또 다른 기이한 문제가 있었고, 다른 서버로 백업을 복원하니 문제가 해결되었습니다. 동일한 서버로 복원했으면 해결되었을지 궁금했었습니다).
공간이 부족하다고 언급하셨는데, 이것이 문제일 것 같습니다. 복원 과정은 백업을 압축 해제하면서 많은 공간을 사용하므로, 압축 해제된 백업 전체 두 부본과 복원에 필요한 공간, 그리고 실패 시 되돌리기 위해 필요한 공간까지 모두 필요합니다.
상황은 더 나빠졌지만, 아마도 근본적인 문제에 더 가까워진 것 같습니다… 더 많은 디스크 공간이 필요하다는 가정 하에, 이전의 50 GB와 달리 이번에는 100 GB 용량으로 이미지를 기반으로 새로운 인스턴스를 생성했습니다. (백업은 각각 5 GB이며 S3에 저장되어 있습니다.) 이번에는 명시적인 오류가 발생했습니다. “No space left on device”(디바이스에 남은 공간 없음)였습니다. 그런데 df 명령을 실행하면 충분한 공간이 남아 있는 것으로 표시됩니다.
> [2019-11-29 22:42:58] Making sure /var/www/discourse/tmp/restores/default/2019-11-29-224258 exists...
> [2019-11-29 22:42:58] Downloading archive to tmp directory...
> [2019-11-29 22:45:46] Unzipping archive, this may take a while...
> [2019-11-29 22:51:46] No metadata file to extract.
> [2019-11-29 22:51:46] Validating metadata...
> [2019-11-29 22:51:46] Current version: 20191129144706
> [2019-11-29 22:51:46] Restored version: 20191108000414
> [2019-11-29 22:51:46] Extracting dump file...
> [2019-11-29 22:53:47] EXCEPTION: No space left on device @ io_write - /shared/tmp/restores/default/2019-11-29-224258/dump.sql
> [ec2-user@ip-172-31-47-237 discourse]$ df / -h
> Filesystem Size Used Avail Use% Mounted on
> /dev/xvda1 99G 28G 71G 28% /
스왑 파일 문제일까요? EC2 인스턴스는 2 GB 메모리를 가진 t2.small이며, 이미 오래전에 정상 작동하는 포럼에 스왑 파일을 생성해 두었습니다. 새로운 인스턴스에도 스왑 파일이 복제되었을 것으로 추측합니다. 저는 전문가가 아니지만, 스왑 파일이 존재한다고 생각합니다. 왜냐하면 새로운 스왑 파일을 생성하지 못했고, 또한 다음과 같은 이유 때문입니다:
> /var/www/discourse# swapon -s
> Filename Type Size Used Priority
> /swapfile file 2097148 1024 -2
Creating missing functions in the discourse_functions schema
Cannot restore into different schema, restoring in-place
플러그인과 관련이 있을까요? “소스” 사이트에는 지원되는 플러그인과 사용자 정의 플러그인 등 여러 플러그인이 설치되어 있습니다. 일부는 사용자 정의 사용자 필드를 사용합니다. 플러그인이 있는 경우와 없는 경우 모두를 포함하여, 플러그인이 없는 “대상” 사이트로 복원을 시도해 보았습니다.
스키마 비교를 시작하는 방법에 대한 조언을 구합니다.
> [2019-12-07 04:51:36] 'admin' has started the restore!
> [2019-12-07 04:51:36] Marking restore as running...
> [2019-12-07 04:51:36] Making sure /var/www/discourse/tmp/restores/default/2019-12-07-045136 exists...
> [2019-12-07 04:51:36] Downloading archive to tmp directory...
> [2019-12-07 04:53:49] Unzipping archive, this may take a while...
> [2019-12-07 04:57:12] No metadata file to extract.
> [2019-12-07 04:57:12] Validating metadata...
> [2019-12-07 04:57:12] Current version: 20191129144706
> [2019-12-07 04:57:12] Restored version: 20191120015344
> [2019-12-07 04:57:12] Extracting dump file...
> [2019-12-07 04:59:10] Creating missing functions in the discourse_functions schema
> [2019-12-07 04:59:11] Cannot restore into different schema, restoring in-place
> [2019-12-07 05:05:02] ERROR: current transaction is aborted, commands ignored until end of transaction block
> [2019-12-07 05:05:03] ERROR: current transaction is aborted, commands ignored until end of transaction block
> < repeats about 100 times >
> [2019-12-07 05:05:03] ERROR: current transaction is aborted, commands ignored until end of transaction block
> [2019-12-07 05:05:03] EXCEPTION: psql failed
> [2019-12-07 05:05:03] /var/www/discourse/lib/backup_restore/restorer.rb:331:in `restore_dump'
> /var/www/discourse/lib/backup_restore/restorer.rb:75:in `run'
> /var/www/discourse/lib/backup_restore.rb:166:in `block in start!'
> /var/www/discourse/lib/backup_restore.rb:163:in `fork'
> /var/www/discourse/lib/backup_restore.rb:163:in `start!'
> /var/www/discourse/lib/backup_restore.rb:22:in `restore!'
> /var/www/discourse/app/controllers/admin/backups_controller.rb:119:in `restore'
> < rest of traceback >
메모리 4GB인 $20짜리 새 Lightsail 인스턴스를 만들었습니다. 복원 중에 'free -m’을 관찰했는데, 항상 충분한 여유 및 사용 가능 메모리가 있었습니다.
구체적인 오류는 플러그인이 설치되어 있느냐에 따라 다르지만, 아마도 동일한 근본 원인으로 인해 발생하는 것 같습니다. 이 경우 백업 전에 플러그인을 설치하지 않았습니다. 오류는 두 가지 유형으로 나뉩니다:
postgres 로그에서 이러한 오류가 많이 발생하며, 때로는 34번째 문자 위치에서, 때로는 41번째 문자 위치에서 발생합니다.
discourse@discourse ERROR: relation “user_auth_tokens” does not exist at character 34
이러한 오류는 관리자 > 백업 > 로그 페이지에 해당하는 출력이 없으며, 이러한 오류에도 불구하고 복원이 몇 분 동안 계속 진행됩니다.
두 번째 오류는 플러그인이 설치되어 있느냐에 따라 다릅니다. 이 경우 플러그인을 설치하지 않았으므로 Data Explorer에 대한 오류가 발생하며, 이때 모든 것이 엉망이 됩니다.
관리자 > 백업 > 로그에서:
[2019-12-07 07:38:34] CREATE INDEX
[2019-12-07 07:38:34] CREATE INDEX
[2019-12-07 07:38:34] ERROR: could not create unique index “index_plugin_store_rows_on_plugin_name_and_key”
[2019-12-07 07:38:34] DETAIL: Key (plugin_name, key)=(discourse-data-explorer, q:-6) is duplicated.
[2019-12-07 07:38:34] ERROR: current transaction is aborted, commands ignored until end of transaction block
[2019-12-07 07:38:34] ERROR: current transaction is aborted, commands ignored until end of transaction block
< 1000회 반복 후 종료 >
그리고 postgres 로그의 해당하는 출력:
2019-12-07 07:38:34.718 UTC [8991] discourse@discourse LOG: duration: 165.427 ms statement: CREATE INDEX index_notifications_on_user_
id_and_topic_id_and_post_number ON public.notifications USING btree (user_id, topic_id, post_number);
2019-12-07 07:38:34.767 UTC [8991] discourse@discourse ERROR: could not create unique index “index_plugin_store_rows_on_plugin_name_an
d_key”
2019-12-07 07:38:34.767 UTC [8991] discourse@discourse DETAIL: Key (plugin_name, key)=(discourse-data-explorer, q:-6) is duplicated.
2019-12-07 07:38:34.767 UTC [8991] discourse@discourse STATEMENT: CREATE UNIQUE INDEX index_plugin_store_rows_on_plugin_name_and_key O
N public.plugin_store_rows USING btree (plugin_name, key);
2019-12-07 07:38:34.984 UTC [8991] discourse@discourse ERROR: current transaction is aborted, commands ignored until end of transactio
n block
2019-12-07 07:38:34.984 UTC [8991] discourse@discourse STATEMENT: CREATE INDEX index_policy_users_on_post_policy_id_and_user_id ON pub
lic.policy_users USING btree (post_policy_id, user_id);
