andy@ubuntu-s-1vcpu-1gb-ams3-01:/var/discourse/shared/standalone/backups/default$ file public-happiness-2023-07-25-033857-v20220628031850.tar.gz
public-happiness-2023-07-25-033857-v20220628031850.tar.gz: gzip compressed data, was "public-happiness-2023-07-25-033857-v20220628031850.tar", last modified: Tue Aug 8 14:53:40 2023, max speed, from FAT filesystem (MS-DOS, OS/2, NT)
전체 파일 내용은 정상적으로 보입니다. 다만, 정보가 너무 많아 단정하기는 어렵습니다: Hastebin
파일 경로와 관련이 있을 것 같습니다. 아래를 확인해 보세요.
음. 그게 문제가 아닐 수도 있겠네요. 저는 7zip이 호환되는 tar 파일을 생성하는 것을 별로 신뢰하지 않지만, 그게 비합리적인 생각일 수도 있습니다.
-h, --dereference
심볼릭 링크를 따릅니다. 링크가 가리키는 파일을 아카이브하고 덤프합니다.
답은 위의 파일 안에 있을 수 있습니다. 사실, 같은 디렉토리의 다른 파일 안에 있을 가능성이 더 높습니다.
감사합니다 - 내용은 맞는데, 이름이 잘못된 것 같습니다. 그래서 문제가 생긴 거죠.
현재는 다음과 같습니다:
-rwxrwxrwx 0/0 26927534 2023-08-08 14:37 public-happiness-2023-07-25-033857-v20220628031850/dump.sql.gz
하지만 원본이나 수정되지 않은 백업 파일은 다음과 같았을 것입니다:
-rwxrwxrwx 0/0 26927534 2023-08-08 14:37 dump.sql.gz
수정: 따라서 해당 tar.gz 파일을 생성할 때 7zip을 조금 다르게 사용해야 합니다.
도와주셔서 감사합니다. 파일을 압축 해제하고, 중복된 태그를 다시 수정한 뒤, 파일 이름에 특히 주의를 기울여 다시 압축을 풀었습니다. 그리고 마침내 진전이 있었습니다!
이제 복원할 때 다음과 같은 오류 메시지가 표시됩니다. 이 오류는 훨씬 더 흔한 것 같습니다:
[2023-08-25 15:25:21] CREATE INDEX
[2023-08-25 15:25:21] ERROR: could not create unique index "index_tags_on_lower_name"
[2023-08-25 15:25:21] DETAIL: Key (lower(name::text))=(socialmedia) is duplicated.
[2023-08-25 15:25:21] EXCEPTION: psql failed: DETAIL: Key (lower(name::text))=(socialmedia) is duplicated.
제가 태그를 성공적으로 변경했지만, 데이터베이스의 게시물들 중 여전히 해당 태그가 남아있다는 의미일 것 같습니다. tag_id 번호를 보면 'socialmedia’라는 이름의 태그가 있어야 하는데, 대신 'socialmedia2’라는 태그를 찾아 충돌을 일으키고 있습니다.
이 게시물과 이 게시물에서 수정 방법을 다루고 있지만, 저는 로컬 머신에서 코드를 직접 편집하는 방식으로만 백업에 접근할 수 있으므로 mysql 도구를 사용해 정리할 수 있는 상황이 아닙니다.
다행히 제 데이터베이스에는 'socialmedia' 인스턴스가 단 38개뿐입니다(50,000개 이상의 socialmedia 발생 건수와 비교할 때). 위에서 스크린샷으로 보여드린 대로 395,421번째 줄의 하나를 올바르게 변경했다면, 나머지 인스턴스 중 어느 것이 ‘socialmedia’ 태그와 연결되어 있고, 어느 것이 제가 'socialmedia2’로 수정한 태그와 연결되어 있는지 구별하는 방법을 알 수 없습니다.
아래는 socialmedia 태그를 사용한 비교적 짧은 게시물의 예시입니다.
9488 '/groups/communitybuilders':86 '/groups/socialmedia':84 '/groups/webdev':89 '1st':117 '2022':131 '6':125 'activ':61 'banner':113 'btw':143 'close':169 'comment':21 'communiti':47 'communitybuild':87 'concept':4A 'especi':28 'event':119 'excit':164 'feedback':8B 'final':166 'get':38,133 'github':94 'grow':6A,142 'hack':127 'hard':156 'help':96 'homepag':151 'host':124 'improv':11B 'join':71,106 'launch':41,118,126 'like':128 'link':110 'live':140,175 'lot':27 'love':1A,67 'marvelxi':152 'mean':25 'media':51 'member':62 'mention':93 'move':45 'much':15 'new':150 'one':72,107 'onto':53 'plan':121 'platform':7B,43,139 'pleas':5A 'project':137 'promot':97 're':33,36,56,161 'readi':39,172 'rhorho358':23 'right':63 'see':100,167 'site':176 'slight':76,177,179 'small':58 'smile':77,178,180 'social':50 'socialmedia':85 'stage':31 'suggest':10B 'sure':79 'take':17 'team':59,75,103 'thank':12 'think':147 'time':19 'use':108 'webdev':90 'websit':3A 'whether':80 'work':155 'would':66,82 Thank you so much for taking the time to comment here @R , it means a lot, especially in the st... has been working hard on it and we’re all very excited to finally see it close to being ready on the live site :slight_smile: :slight_smile: en_GB 4 f
하지만 제가 잘못된 방향으로 가고 있을 수도 있습니다. 사용자가 게시물에서 사용할 법한 것보다 시작 부분에 태그가 더 많이 보이는 것처럼 보이기 때문입니다. 또한 위의 게시물에서 'socialmedia’가 사용된 태그가 아닐 수도 있지만, 원래 사용되었어야 할 것 같습니다.
데이터베이스를 수동으로 복구한 다음, Wyeth의 데이터베이스에 인덱스를 추가하고 문제를 수정하는 방법을 시도해 보았습니다. 하지만 텍스트 파일이 아니라 데이터베이스를 다루는 것이므로 이 또한 쉽지 않습니다.
바로 그 결론을 내리거나 내릴 수 있다고 생각하지 않습니다. 문제는 단순해야 합니다:
인덱스가 빌드되지 않는 이유는 tags 테이블에 이름의 소문자 변환 시 동일한 값으로 해석되는 항목이 최소 두 개 이상 있기 때문입니다. 오류 메시지가 말해주는 바로 그 내용입니다.
따라서 해당 변환을 거쳤을 때 충돌하는 단일 테이블 내의 관련 항목을 여전히 찾아내야 한다고 생각합니다.
중복 항목을 삭제하기 전에 ID를 기록해 두세요. topic_tags 테이블의 관련 행도 삭제해야 하기 때문입니다 (참고로, 인스턴스를 파괴하는 대신 컨테이너를 단순히 재시작하여 이러한 유지보수를 온라인으로 수행했다면 이 문제를 빠르게 처리할 수 있었을 것입니다!).
우리 사이트가 다시 돌아왔습니다! 도움을 주신 모든 분께 감사드립니다.
사실 며칠 전에 문제를 해결해 두었는데, 오류 메시지를 읽을 때 부주의했습니다. 중복된 태그가 두 개, 'socialmedia’와 'social-media’가 있었습니다. 첫 번째를 수정한 후, 두 중복 태그가 매우 비슷했기 때문에 오류 메시지가 바뀌었다는 사실을 알아차리지 못했습니다.
이 두 오류를 수정하는 과정은 다음과 같습니다:
1. 태그 테이블과 중복 태그 찾기
백업을 운영체제로 다운로드하세요. 이 가이드는 Windows를 기준으로 작성되었지만, Linux에서도 과정은 거의 동일합니다.
압축된 폴더를 모두 추출하면 dump.sql 파일과 uploads 폴더가 남게 됩니다.
텍스트 에디터로 dump.sql 파일을 엽니다. 저는 Visual Studio Code를 사용했습니다.
"COPY public.tags"를 검색하여 태그 테이블의 위치를 찾습니다. 파일 하단 근처에 있으며, 다음과 같은 모습일 것입니다:
직접 탐색하거나, 태그 테이블을 별도의 문서에 복사하여 검색 기능을 사용해 중복 태그를 찾을 수 있습니다.
수정된 dump.sql 파일을 dump.sql로 저장하세요.
2. 재압축 시 파일과 폴더의 순서와 이름이 정확해야 합니다.
추출 후 dump.sql 파일과 uploads 폴더가 있어야 합니다.
dump.sql을 마우스 오른쪽 버튼으로 클릭하여 7zip의 '압축에 추가’를 선택하세요.
압축 형식으로 gzip를 선택하되, 파일 이름은 그대로 유지하세요.
새로 생성된 dump.sql.gz 파일과 uploads 파일을 선택한 뒤, 마우스 오른쪽 버튼 > 7zip > 압축에 추가 > 압축 형식: tar를 선택하세요. 파일 이름이 원래 백업과 정확히 일치해야 하며, 다음과 같은 형태여야 합니다: ‘public-happiness-2023-07-25-033857-v20220628031850’
새로 생성된 .tar 파일을 선택한 뒤, 7zip > 압축에 추가 > 압축 형식: gzip를 선택하세요. 파일 이름이 원래 백업과 정확히 일치해야 하며, 다음과 같은 형태여야 합니다: ‘public-happiness-2023-07-25-033857-v20220628031850’
최종 결과물은 원래 백업과 동일한 이름을 가진 .tar.gz 파일이어야 합니다.
관리자 영역에 업로드하고 백업을 복구하세요
태그가 반복될 수 있는 또 다른 장소가 하나 더 있습니다. 바로 검색 데이터 테이블입니다:
COPY public.tag_search_data (tag_id, search_data, raw_data, locale, version) FROM stdin;
여기도 수정이 필요한지 확실하지 않습니다.
드디어 고쳤으니 정말 기뻐요!
