실패 후 Postgres 데이터베이스를 복구한 첫 번째 경험(relatton base/4123007의 블록 16490에 있는 잘못된 페이지)

Postgres 데이터베이스를 전체 기능으로 복원한 첫 번째 성공적인 경험을 여러분과 공유하고 싶습니다. 저는 반년 전에 Postgres DBMS를 알게 되었지만 그 전에는 데이터베이스 관리에 대한 경험이 전혀 없었습니다.

저는 대규모 IT 회사에서 준 DevOps 엔지니어로 일하고 있습니다. 우리 회사는 고부하 서비스용 소프트웨어를 개발하고 있으며, 성능, 유지 관리, 배포를 담당하고 있습니다. 나는 하나의 서버에서 애플리케이션을 업데이트하는 표준 작업을 받았습니다. 애플리케이션은 Django로 작성되었으며, 업데이트 마이그레이션이 수행되는 동안(데이터베이스 구조 변경), 이 프로세스 전에 만일을 대비해 표준 pg_dump 프로그램을 통해 전체 데이터베이스 덤프를 수행합니다.

덤프를 수행하는 동안 예기치 않은 오류가 발생했습니다(Postgres 버전 9.5).

pg_dump: Oumping the contents of table “ws_log_smevlog” failed: PQgetResult() failed.
pg_dump: Error message from server: ERROR: invalid page in block 4123007 of relatton base/16490/21396989
pg_dump: The command was: COPY public.ws_log_smevlog [...]
pg_dunp: [parallel archtver] a worker process dled unexpectedly

곤충 "블록의 잘못된 페이지" 파일 시스템 수준의 문제를 말하는데 이는 매우 나쁩니다. 다양한 포럼에서 다음을 제안했습니다. 완전 진공 옵션 포함 zero_damaged_pages 이 문제를 해결하기 위해. 자, 한번 해보자...

회복 준비

주의 데이터베이스 복원을 시도하기 전에 Postgres 백업을 수행하십시오. 가상 머신이 있는 경우 데이터베이스를 중지하고 스냅샷을 찍습니다. 스냅샷을 찍을 수 없는 경우 데이터베이스를 중지하고 Postgres 디렉터리의 내용(wal 파일 포함)을 안전한 장소에 복사하세요. 우리 사업에서 가장 중요한 것은 상황을 악화시키지 않는 것입니다. 읽다 그것.

데이터베이스는 일반적으로 나에게 적합했기 때문에 정기적인 데이터베이스 덤프로 제한하고 데이터가 손상된 테이블은 제외했습니다(옵션 -T, --exclude-테이블=테이블 pg_dump에서).

서버가 물리적이어서 스냅샷을 찍는 것이 불가능했습니다. 백업이 제거되었습니다. 계속 진행하겠습니다.

파일 시스템 확인

데이터베이스를 복원하기 전에 파일 시스템 자체에 모든 것이 올바른지 확인해야 합니다. 그리고 실수가 있으면 바로잡으세요. 그렇지 않으면 상황을 더 악화시킬 수 있기 때문입니다.

내 경우에는 데이터베이스가 있는 파일 시스템이 마운트되었습니다. "/srv" 유형은 ext4였습니다.

데이터베이스 중지: systemctl 중지 [이메일 보호] 파일 시스템을 다른 사람이 사용하고 있지 않고 다음 명령을 사용하여 마운트 해제할 수 있는지 확인하세요. 이소프:
lsof +D /srv

또한 Redis 데이터베이스도 사용하고 있었기 때문에 Redis 데이터베이스를 중지해야 했습니다. "/srv". 다음으로 마운트를 해제했습니다. / srv (마운트).

유틸리티를 사용하여 파일 시스템을 확인했습니다. e2fsck 스위치 -f (파일 시스템이 깨끗한 것으로 표시된 경우에도 강제 검사):

다음으로 유틸리티를 사용하여 덤프 2fs (sudo dumpe2fs /dev/mapper/gu2—sys-srv | grep 확인됨) 검사가 실제로 수행되었는지 확인할 수 있습니다.

e2fsck ext4 파일 시스템 수준에서 문제가 발견되지 않았음을 의미합니다. 이는 데이터베이스 복원을 계속 시도하거나 오히려 extXNUMX 파일 시스템 수준으로 돌아갈 수 있음을 의미합니다. 진공청소기 가득 (물론 파일 시스템을 다시 마운트하고 데이터베이스를 시작해야 합니다).

물리적 서버가 있는 경우 반드시 디스크 상태를 확인하십시오(다음을 통해). smartctl -a /dev/XXX) 또는 RAID 컨트롤러를 사용하여 문제가 하드웨어 수준에 있지 않은지 확인하십시오. 제 경우에는 RAID가 '하드웨어'인 것으로 판명되어 로컬 관리자에게 RAID 상태를 확인해달라고 요청했습니다(서버는 저에게서 수백 킬로미터 떨어져 있었습니다). 그는 오류가 없다고 말했습니다. 이는 확실히 복원을 시작할 수 있음을 의미합니다.

시도 1: zero_damaged_pages

슈퍼유저 권한이 있는 계정으로 psql을 통해 데이터베이스에 연결합니다. 슈퍼유저가 필요한 이유는... 옵션 zero_damaged_pages 오직 그 사람만이 변할 수 있다. 제 경우에는 포스트그레스입니다.

psql -h 127.0.0.1 -U postgres -s [데이터베이스_이름]

옵션 zero_damaged_pages 읽기 오류를 무시하려면 필요합니다(postgrespro 웹사이트에서):

PostgreSQL은 손상된 페이지 헤더를 감지하면 일반적으로 오류를 보고하고 현재 트랜잭션을 중단합니다. zero_damaged_pages가 활성화되면 시스템은 대신 경고를 발행하고 메모리의 손상된 페이지를 XNUMX으로 만든 다음 처리를 계속합니다. 이 동작은 데이터, 즉 손상된 페이지의 모든 행을 파괴합니다.

옵션을 활성화하고 테이블을 완전히 비우려고 합니다.

VACUUM FULL VERBOSE

불행히도 불운입니다.

비슷한 오류가 발생했습니다.

INFO: vacuuming "“public.ws_log_smevlog”
WARNING: invalid page in block 4123007 of relation base/16400/21396989; zeroing out page
ERROR: unexpected chunk number 573 (expected 565) for toast value 21648541 in pg_toast_106070

pg_toast – 한 페이지(기본적으로 8kb)에 맞지 않는 경우 Poetgres에 "긴 데이터"를 저장하는 메커니즘입니다.

시도 2: 재색인

Google의 첫 번째 조언은 도움이 되지 않았습니다. 몇 분 동안 검색한 끝에 두 번째 팁을 찾았습니다. 재색 인 손상된 테이블. 나는 이 조언을 여러 곳에서 보았지만 자신감을 얻지 못했습니다. 다시 색인을 생성해 보겠습니다.

reindex table ws_log_smevlog

재색 인 문제없이 완료되었습니다.

그러나 이는 도움이 되지 않았으며, 진공이 가득 참 비슷한 오류로 인해 충돌이 발생했습니다. 나는 실패에 익숙했기 때문에 인터넷에서 조언을 더 찾기 시작했고 다소 흥미로운 것을 발견했습니다. статью.

시도 3: SELECT, LIMIT, OFFSET

위의 기사에서는 테이블을 행별로 살펴보고 문제가 있는 데이터를 제거할 것을 제안했습니다. 먼저 우리는 모든 라인을 살펴봐야 했습니다:

for ((i=0; i<"Number_of_rows_in_nodes"; i++ )); do psql -U "Username" "Database Name" -c "SELECT * FROM nodes LIMIT 1 offset $i" >/dev/null || echo $i; done

내 경우에는 테이블에 포함되어 있습니다. + 1 628 991 윤곽! 잘 챙겨야 했어요 데이터 파티셔닝, 그러나 이것은 별도의 토론 주제입니다. 토요일이었습니다. 저는 tmux에서 다음 명령을 실행하고 잠자리에 들었습니다.

for ((i=0; i<1628991; i++ )); do psql -U my_user -d my_database -c "SELECT * FROM ws_log_smevlog LIMIT 1 offset $i" >/dev/null || echo $i; done

아침까지 나는 상황이 어떻게 진행되고 있는지 확인하기로 결정했습니다. 놀랍게도 20시간 후에는 데이터의 2%만 스캔되었다는 사실을 발견했습니다! 50일을 기다리고 싶지 않았어요. 또 다른 완전한 실패.

하지만 나는 포기하지 않았습니다. 스캔하는 데 왜 그렇게 오래 걸리는지 궁금했습니다. 문서(다시 postgrespro에 있음)에서 다음을 발견했습니다.

OFFSET은 행 출력을 시작하기 전에 지정된 수의 행을 건너뛰도록 지정합니다.
OFFSET과 LIMIT가 모두 지정된 경우 시스템은 먼저 OFFSET 행을 건너뛴 다음 LIMIT 제약 조건에 대한 행 수 계산을 시작합니다.

LIMIT를 사용할 때는 결과 행이 특정 순서로 반환되도록 ORDER BY 절도 사용하는 것이 중요합니다. 그렇지 않으면 예측할 수 없는 행 하위 집합이 반환됩니다.

분명히 위의 명령은 잘못되었습니다. 첫째, 주문, 결과가 잘못될 수 있습니다. 둘째, Postgres는 먼저 OFFSET 행을 스캔하고 건너뛰어야 했습니다. OFFSET 생산성은 더욱 떨어지게 됩니다.

시도 4: 텍스트 형식으로 덤프를 가져옵니다.

그러다가 겉보기에는 훌륭해 보이는 아이디어가 떠올랐습니다. 텍스트 형식으로 덤프를 가져와서 마지막으로 녹음된 줄을 분석하는 것입니다.

하지만 먼저 테이블의 구조를 살펴보겠습니다. ws_log_smevlog:

우리의 경우에는 열이 있습니다. "신분증", 행의 고유 식별자(카운터)가 포함되어 있습니다. 계획은 이랬습니다.

1. 텍스트 형식(SQL 명령 형식)으로 덤프를 시작합니다.
2. 특정 시점에서 오류로 인해 덤프가 중단되지만 텍스트 파일은 여전히 ​​디스크에 저장됩니다.
3. 텍스트 파일의 끝을 보면 성공적으로 제거된 마지막 줄의 식별자(id)를 찾습니다.

나는 텍스트 형식으로 덤프를 시작했습니다.

pg_dump -U my_user -d my_database -F p -t ws_log_smevlog -f ./my_dump.dump

예상대로 덤프가 동일한 오류로 중단되었습니다.

pg_dump: Error message from server: ERROR: invalid page in block 4123007 of relatton base/16490/21396989

더 나아가 꼬리 덤프의 끝부분을 보니 (꼬리 -5 ./my_dump.dump) id가 있는 라인에서 덤프가 중단되었음을 발견했습니다. 186 525. “그래서 문제는 ID 186 526에 있는 줄에 있고, 깨져서 삭제해야 합니다!” – 나는 생각했다. 그러나 데이터베이스에 쿼리를 수행하면 다음과 같습니다.
«ID=186529인 ws_log_smevlog에서 *를 선택하세요."이 줄에서는 모든 것이 괜찮다는 것이 밝혀졌습니다... 인덱스가 186 - 530인 행도 문제 없이 작동했습니다. 또 다른 "훌륭한 아이디어"는 실패했습니다. 나중에 나는 왜 이런 일이 발생했는지 이해했습니다. 테이블에서 데이터를 삭제하고 변경할 때 물리적으로 삭제되지 않고 "데드 튜플"로 표시됩니다. 자동 진공화 이 줄을 삭제된 것으로 표시하고 이 줄을 재사용할 수 있도록 허용합니다. 이해하자면, 테이블의 데이터가 변경되고 autovacuum이 활성화되면 순차적으로 저장되지 않습니다.

시도 5: SELECT, FROM, WHERE id=

실패는 우리를 더욱 강하게 만듭니다. 결코 포기해서는 안 되며, 끝까지 나아가 자신과 자신의 능력을 믿어야 합니다. 그래서 나는 다른 옵션을 시도하기로 결정했습니다. 데이터베이스의 모든 레코드를 하나씩 살펴보는 것입니다. 내 테이블의 구조(위 참조)를 알면 고유한(기본 키) id 필드가 있습니다. 테이블에는 1개의 행이 있고 id 순서대로 되어 있으므로 하나씩 살펴볼 수 있습니다.

for ((i=1; i<1628991; i=$((i+1)) )); do psql -U my_user -d my_database  -c "SELECT * FROM ws_log_smevlog where id=$i" >/dev/null || echo $i; done

누군가 이해하지 못하는 경우 명령은 다음과 같이 작동합니다. 테이블을 행별로 스캔하고 stdout을 다음으로 보냅니다. / dev / null, 그러나 SELECT 명령이 실패하면 오류 텍스트가 인쇄되고(stderr이 콘솔로 전송됨) 오류가 포함된 줄이 인쇄됩니다(|| 덕분에 선택에 문제가 있음을 의미합니다(명령의 반환 코드). 0))이 아닙니다.

운이 좋았습니다. 필드에 인덱스가 생성되었습니다. id:

이는 원하는 ID가 있는 라인을 찾는 데 많은 시간이 걸리지 않음을 의미합니다. 이론적으로는 작동해야 합니다. 자, 다음에서 명령을 실행해 보겠습니다. tmux 그리고 자러 가자.

아침까지 나는 약 90개의 항목을 조회한 것을 발견했는데, 이는 000%가 조금 넘는 수치입니다. 기존 방법(5%)과 비교했을 때 탁월한 결과! 하지만 2일을 기다리기 싫었어요...

시도 6: SELECT, FROM, WHERE id >= 및 id

고객은 우수한 데이터베이스 전용 서버를 보유하고 있었습니다. 듀얼 프로세서 인텔 제온 E5-2697 v2, 우리 위치에는 무려 48개의 스레드가 있었습니다! 서버의 로드는 평균 수준이었고 약 20개의 스레드를 문제 없이 다운로드할 수 있었습니다. RAM도 충분했습니다. 최대 384GB!

따라서 명령을 병렬화해야 합니다.

for ((i=1; i<1628991; i=$((i+1)) )); do psql -U my_user -d my_database  -c "SELECT * FROM ws_log_smevlog where id=$i" >/dev/null || echo $i; done

여기서는 아름답고 우아한 스크립트를 작성할 수 있었지만 가장 빠른 병렬화 방법을 선택했습니다. 0-1628991 범위를 수동으로 100개의 레코드 간격으로 분할하고 다음 형식의 000개 명령을 별도로 실행했습니다.

for ((i=N; i<M; i=$((i+1)) )); do psql -U my_user -d my_database  -c "SELECT * FROM ws_log_smevlog where id=$i" >/dev/null || echo $i; done

하지만 그게 전부는 아닙니다. 이론적으로 데이터베이스에 연결하는 데에도 시간과 시스템 리소스가 필요합니다. 1명을 연결하는 것은 그리 현명한 일이 아니었습니다. 여러분도 동의하실 것입니다. 따라서 하나의 연결에서 하나의 행을 검색하는 대신 628개의 행을 검색해 보겠습니다. 그 결과 팀은 다음과 같이 변했습니다.

for ((i=N; i<M; i=$((i+1000)) )); do psql -U my_user -d my_database  -c "SELECT * FROM ws_log_smevlog where id>=$i and id<$((i+1000))" >/dev/null || echo $i; done

tmux 세션에서 16개의 창을 열고 다음 명령을 실행합니다.

1) for ((i=0; i<100000; i=$((i+1000)) )); do psql -U my_user -d my_database  -c "SELECT * FROM ws_log_smevlog where id>=$i and id<$((i+1000))" >/dev/null || echo $i; done
2) for ((i=100000; i<200000; i=$((i+1000)) )); do psql -U my_user -d my_database  -c "SELECT * FROM ws_log_smevlog where id>=$i and id<$((i+1000))" >/dev/null || echo $i; done
…
15) for ((i=1400000; i<1500000; i=$((i+1000)) )); do psql -U my_user -d my_database -c "SELECT * FROM ws_log_smevlog where id>=$i and id<$((i+1000))" >/dev/null || echo $i; done
16) for ((i=1500000; i<1628991; i=$((i+1000)) )); do psql -U my_user -d my_database  -c "SELECT * FROM ws_log_smevlog where id>=$i and id<$((i+1000))" >/dev/null || echo $i; done

하루 후 첫 번째 결과를 받았습니다! 즉, XXX 및 ZZZ 값은 더 이상 유지되지 않습니다.

ERROR:  missing chunk number 0 for toast value 37837571 in pg_toast_106070
829000
ERROR:  missing chunk number 0 for toast value XXX in pg_toast_106070
829000
ERROR:  missing chunk number 0 for toast value ZZZ in pg_toast_106070
146000

이는 세 줄에 오류가 있음을 의미합니다. 첫 번째와 두 번째 문제 레코드의 id는 829~000, 세 번째 문제 레코드의 id는 830~000 사이였으며, 다음으로 문제 레코드의 정확한 id 값을 찾아야 했습니다. 이를 위해 문제가 있는 기록이 있는 범위를 146단계로 조사하고 ID를 식별합니다.

for ((i=829000; i<830000; i=$((i+1)) )); do psql -U my_user -d my_database -c "SELECT * FROM ws_log_smevlog where id=$i" >/dev/null || echo $i; done
829417
ERROR:  unexpected chunk number 2 (expected 0) for toast value 37837843 in pg_toast_106070
829449
for ((i=146000; i<147000; i=$((i+1)) )); do psql -U my_user -d my_database -c "SELECT * FROM ws_log_smevlog where id=$i" >/dev/null || echo $i; done
829417
ERROR:  unexpected chunk number ZZZ (expected 0) for toast value XXX in pg_toast_106070
146911

해피엔딩

문제가 있는 라인을 발견했습니다. psql을 통해 데이터베이스로 이동하여 삭제를 시도합니다.

my_database=# delete from ws_log_smevlog where id=829417;
DELETE 1
my_database=# delete from ws_log_smevlog where id=829449;
DELETE 1
my_database=# delete from ws_log_smevlog where id=146911;
DELETE 1

놀랍게도 옵션이 없어도 문제 없이 항목이 삭제되었습니다. zero_damaged_pages.

그런 다음 데이터베이스에 연결하여 진공이 가득 참 (이렇게 할 필요는 없다고 생각합니다) 마지막으로 다음을 사용하여 백업을 성공적으로 제거했습니다. pg_dump. 덤프는 오류 없이 촬영되었습니다! 문제는 이렇게 멍청한 방법으로 해결되었습니다. 기쁨은 끝이 없었습니다. 수많은 실패 끝에 우리는 해결책을 찾았습니다!

감사의 말씀과 결론

이것이 실제 Postgres 데이터베이스를 복원한 첫 경험의 결과였습니다. 나는 이 경험을 오랫동안 기억할 것이다.

마지막으로 문서를 러시아어로 번역해 준 PostgresPro에게 감사 인사를 전하고 싶습니다. 완전 무료 온라인 강좌, 문제를 분석하는 동안 많은 도움이 되었습니다.

출처 : habr.com