WAL-G의 백업. 2019년에는 무엇이 있나요? 안드레이 보로딘

Andrey Borodin의 2019년 초 보고서 "WAL-G를 사용한 백업. 2019년에는 무엇이 있을까요?"를 읽어 보시기 바랍니다.

안녕하세요 여러분! 내 이름은 안드레이 보로딘입니다. 저는 Yandex의 개발자입니다. 저는 2016년부터 PostgreSQL에 관심을 갖고 있었습니다. 개발자들과 이야기를 나눈 후 그들은 모든 것이 간단하다고 말했습니다. 소스 코드를 가져와 빌드하면 모든 것이 잘 될 것입니다. 그 이후로 저는 멈출 수 없었습니다. 저는 온갖 종류의 글을 썼습니다.

제가 하고 있는 일 중 하나는 백업 시스템입니다. 월지. 일반적으로 Yandex에서는 오랫동안 PostgreSQL의 백업 시스템 작업을 진행해 왔습니다. 그리고 우리가 백업 시스템을 만드는 방법에 대한 일련의 XNUMX개 보고서를 인터넷에서 찾을 수 있습니다. 그리고 매년 그들은 조금씩 발전하고, 조금씩 발전하고, 더욱 신뢰할 수 있게 됩니다.

하지만 오늘 보고서는 우리가 한 일뿐만 아니라 그것이 얼마나 단순하고 무엇인지에 관한 것입니다. WAL-G에 대한 내 보고서를 이미 본 사람이 몇 명이나 됩니까? 꽤 많은 사람들이 보지 않은 것이 다행입니다. 가장 간단한 것부터 시작하겠습니다.

갑자기 PostgreSQL 클러스터가 있고 모든 사람이 클러스터를 몇 개 갖고 있는데 갑자기 아직 백업 시스템이 없다면 S3 스토리지나 Google Cloud 호환 스토리지를 구입해야 합니다.

예를 들어, 당사 부스에 오셔서 S3와 호환되는 Yandex Object Storage에 대한 프로모션 코드를 받으시면 됩니다.

그런 다음 버킷을 생성합니다. 그것은 단지 정보를 담는 그릇일 뿐입니다.

서비스 사용자를 생성합니다.

서비스 사용자에 대한 액세스 키(aws-s3-key)를 생성합니다.

WAL-G의 최신 안정 릴리스를 다운로드하세요.

사전 릴리스는 릴리스와 어떻게 다릅니까? 조기 석방하라는 요청을 자주 받습니다. 그리고 충분한 시간(예: 한 달) 동안 버전에 버그가 없으면 릴리스합니다. XNUMX월에 발표된 내용은 다음과 같습니다. 이는 매달 우리가 일반적으로 중요하지 않은 기능에서 일종의 버그를 발견했지만 아직 릴리스를 출시하지 않았음을 의미합니다. 이전 버전은 XNUMX월뿐입니다. 우리에게 알려진 버그는 없습니다. 즉, 프로젝트가 진행되면서 버그가 추가되었습니다.

WAL-G를 다운로드한 후에는 환경 변수를 전달하여 간단한 "백업 목록" 명령을 실행할 수 있습니다. 그리고 Object Storage에 연결하여 어떤 백업이 있는지 알려줍니다. 물론 처음에는 백업이 없어야 합니다. 이 슬라이드의 요점은 모든 것이 매우 간단하다는 것을 보여주는 것입니다. 환경 변수를 받아들이고 하위 명령을 실행하는 콘솔 명령입니다.

그런 다음 첫 번째 백업을 만들 수 있습니다. WAL-G에서 "backup-push"라고 말하고 WAL-G에서 클러스터의 pgdata 위치를 지정합니다. 그리고 아마도 PostgreSQL은 백업 시스템이 아직 없는 경우 "아카이브 모드"를 활성화해야 한다고 알려줄 것입니다.

이는 설정으로 이동하여 "archive_mode = on"을 켜고 WAL-G의 하위 명령이기도 한 "archive_command"를 추가해야 함을 의미합니다. 그러나 어떤 이유로 사람들은 종종 이 주제에 대해 막대 스크립트를 사용하고 WAL-G를 둘러쌉니다. 제발 이러지 마세요. WAL-G에 있는 기능을 사용하세요. 누락된 내용이 있으면 다음 주소로 편지를 보내주세요. GitHub의. WAL-G는 archive_command에서 실행되는 유일한 프로그램이라고 가정합니다.

우리는 Yandex 데이터베이스 관리에서 고가용성 클러스터를 생성하기 위해 주로 WAL-G를 사용합니다.

그리고 일반적으로 하나의 Master와 여러 개의 Replica로 구성된 토폴로지에서 사용됩니다. 동시에 Yandex Object Storage에 백업 복사본을 만듭니다.

가장 일반적인 시나리오는 특정 시점 복구를 사용하여 클러스터 복사본을 만드는 것입니다. 하지만 이 경우 백업 시스템의 성능은 그다지 중요하지 않습니다. 백업에서 새 클러스터를 업로드하기만 하면 됩니다.

일반적으로 새 노드를 추가할 때는 시스템 성능을 백업해야 합니다. 왜 중요 함? 일반적으로 사람들은 기존 클러스터가 읽기 로드를 처리할 수 없기 때문에 클러스터에 새 노드를 추가합니다. 새 복제본을 추가해야 합니다. pg_basebackup의 로드를 마스터에 추가하면 마스터가 무너질 수 있습니다. 따라서 마스터에 대한 부하를 최소화하면서 아카이브에서 새 노드를 신속하게 업로드할 수 있는 것이 매우 중요했습니다.

그리고 또 다른 비슷한 상황. 연결이 끊어진 데이터 센터에서 클러스터 마스터를 전환한 후 이전 마스터를 다시 시작해야 합니다.

• 결과적으로 복사 시스템에 대한 요구 사항을 공식화할 때 pg_basebackup이 클라우드에서 작동할 때 적합하지 않다는 것을 깨달았습니다.
• 우리는 데이터를 압축할 수 있기를 원했습니다. 그러나 기본으로 제공되는 것 이외의 거의 모든 백업 시스템은 데이터 압축을 제공합니다.
• 클라우드 사용자가 대량의 프로세서 코어를 구입하기 때문에 우리는 모든 것을 병렬화하고 싶었습니다. 그러나 일부 작업에 병렬성이 없으면 많은 수의 코어가 쓸모 없게 됩니다.
• 데이터가 우리 것이 아니고 일반 텍스트로 저장할 수 없는 경우가 많기 때문에 암호화가 필요합니다. 그런데 WAL-G에 대한 우리의 기여는 암호화에서 시작되었습니다. 우리는 WAL-G에서 암호화를 완료한 후 "우리 중 한 명이 프로젝트를 개발할까요?"라는 질문을 받았습니다. 그 이후로 저는 XNUMX년 넘게 WAL-G와 함께 일해 왔습니다.
• 또한 클라우드를 사용하면서 시간이 지남에 따라 때때로 사람들이 밤에 중요한 식료품을 로드해야 하는데 이 로드를 방해할 수 없다는 사실을 알게 되었기 때문에 리소스 조절도 필요했습니다. 이것이 바로 우리가 리소스 제한을 추가한 이유입니다.
• 상장 및 관리도 가능합니다.
• 그리고 검증.

우리는 다양한 도구를 살펴보았습니다. 다행히 PostgreSQL에는 다양한 선택 항목이 있습니다. 그리고 어디에서나 우리는 뭔가를 놓치고 있었습니다. 하나의 작은 기능, 하나의 작은 기능이었습니다.

그리고 기존 시스템을 검토한 결과 WAL-G를 개발하겠다는 결론에 도달했습니다. 그때는 새로운 프로젝트였어요. 백업 시스템의 클라우드 인프라 개발에 영향을 미치는 것은 매우 쉬웠습니다.

우리가 고수하는 주요 이념은 WAL-G가 발랄라이카처럼 단순해야 한다는 것입니다.

WAL-G에는 4개의 명령이 있습니다. 이것:

WAL-PUSH - 샤프트를 보관합니다.

WAL-FETCH - 샤프트를 구하세요.

BACKUP-PUSH – 백업을 만듭니다.

BACKUP-FETCH – 백업 시스템에서 백업을 가져옵니다.

실제로 WAL-G는 이러한 백업을 관리합니다. 즉, 현재 더 이상 필요하지 않은 기록과 백업을 기록에 나열하고 삭제하는 기능도 있습니다.

우리에게 중요한 기능 중 하나는 델타 복사본을 생성하는 기능입니다.

델타 복사본은 전체 클러스터의 전체 백업을 생성하지 않고 클러스터에서 변경된 파일의 변경된 페이지만 생성한다는 의미입니다. 기능적으로 이는 WAL을 사용하여 복구하는 기능과 매우 유사해 보입니다. 하지만 WAL 단일 스레드 델타 백업을 병렬로 롤업할 수 있습니다. 따라서 토요일에 기본 백업을 만들고 매일 델타 백업을 하고 목요일에 실패하면 4개의 델타 백업과 10시간의 WAL을 롤업해야 합니다. 델타 백업이 병렬로 진행되기 때문에 거의 같은 시간이 소요됩니다.

LSN 기반 델타 - 이는 백업을 생성할 때 변경된 내용을 이해하기 위해 각 페이지를 결합하고 해당 LSN을 이전 백업의 LSN과 확인해야 함을 의미합니다. 변경된 데이터를 잠재적으로 포함할 수 있는 모든 페이지가 델타 백업에 있어야 합니다.

내가 말했듯이 병렬성에 많은 관심이 기울여졌습니다.

그러나 PostgreSQL의 아카이브 API는 일관성이 있습니다. PostgreSQL은 하나의 WAL 파일을 보관하고 복원 시 하나의 WAL 파일을 요청합니다. 그러나 데이터베이스가 "WAL-FETCH" 명령을 사용하여 하나의 WAL 파일을 요청하면 "WAL-PREFETCH" 명령을 호출하여 객체 저장소에서 데이터를 병렬로 가져오기 위해 다음 8개 파일을 준비합니다.

그리고 데이터베이스가 하나의 파일을 보관하라고 요청하면 archive_status를 보고 다른 WAL 파일이 있는지 확인합니다. 그리고 우리는 또한 WAL을 병렬로 다운로드하려고 노력하고 있습니다. 이는 상당한 성능 향상을 제공하고 보관되지 않은 WAL 수의 거리를 크게 줄입니다. 많은 백업 시스템 개발자는 PostgreSQL API가 아닌 코드 내부 지식에 의존하기 때문에 이것이 매우 위험한 시스템이라고 생각합니다. PostgreSQL은 우리에게 archive_status 폴더의 존재를 보장하지 않으며 WAL 파일에 대한 준비 신호의 의미, 존재 여부도 보장하지 않습니다. 그럼에도 불구하고 우리는 소스 코드를 연구하고 있으며 이것이 사실임을 확인하고 이를 활용하려고 노력하고 있습니다. 그리고 PostgreSQL이 개발되는 방향을 제어하며, 갑자기 이 메커니즘이 중단되면 사용을 중단합니다.

순수한 형태의 LSN 기반 WAL 델타에서는 이전 백업 이후 파일 시스템의 모드 시간이 변경된 모든 클러스터 파일을 읽어야 합니다. 우리는 거의 XNUMX년 동안 이것을 가지고 살았습니다. 그리고 결국 우리는 WAL 델타가 있다는 결론에 도달했습니다.

이는 마스터에 WAL을 보관할 때마다 이를 압축하고 암호화하여 네트워크로 보낼 뿐만 아니라 동시에 읽는다는 의미입니다. 우리는 그 안에 있는 기록을 분석하고 읽습니다. 어떤 블록이 변경되었는지 파악하고 델타 파일을 수집합니다.

델타 파일은 특정 범위의 WAL 파일을 설명하고, 이 WAL 범위에서 어떤 블록이 변경되었는지에 대한 정보를 설명합니다. 그런 다음 이러한 델타 파일도 보관됩니다.

여기서 우리는 모든 것을 매우 빠르게 병렬화했지만 순차적 기록을 병렬로 읽을 수 없다는 사실에 직면했습니다. 왜냐하면 특정 세그먼트에서 아직 연결할 것이 없는 이전 WAL 레코드의 끝을 만날 수 있기 때문입니다. 병행 읽기를 통해 우리는 아직 과거가 없는 미래를 먼저 분석하게 되었습니다.

결과적으로 우리는 이해할 수 없는 부분을 _delta_partial 파일에 넣어야 했습니다. 결과적으로 과거로 돌아가면 WAL 레코드 조각을 하나로 묶은 다음 이를 구문 분석하고 변경된 내용을 이해하게 됩니다.

샤프트 구문 분석 기록에 무슨 일이 일어나고 있는지 이해하지 못하는 지점이 하나 이상 있으면 다음 백업 중에 일반 LSN에서와 마찬가지로 전체 클러스터를 다시 읽어야 합니다. - 기반 델타.

결과적으로 우리의 모든 고통은 WAL-G 구문 분석 라이브러리를 오픈 소스화한다는 사실로 이어졌습니다. 내가 아는 한 아직 아무도 사용하고 있지 않지만 누군가가 쓰고 사용하고 싶다면 공개 도메인에 있습니다. (업데이트된 링크 https://github.com/wal-g/wal-g/tree/master/internal/walparser)

결과적으로 모든 정보 흐름이 상당히 복잡해 보입니다. 우리의 마스터는 샤프트를 보관하고 델타 파일을 보관합니다. 그리고 백업 복사본을 만드는 복제본은 백업 사이에 경과된 시간 동안 델타 파일을 받아야 합니다. 이 경우 전체 기록이 큰 세그먼트에 맞지 않기 때문에 기록의 일부를 대량으로 추가하고 구문 분석해야 합니다. 그 후에만 복제본이 전체 델타 백업을 보관할 수 있습니다.

그래프에서는 모든 것이 훨씬 단순해 보입니다. 이것은 실제 클러스터 중 하나에서 다운로드한 것입니다. 우리는 LSN 기반으로 하루 만에 만들어졌습니다. 그리고 LSN 기반 델타 백업이 오전 20시부터 오전 XNUMX시까지 실행되고 있음을 알 수 있습니다. 이는 프로세서 코어 수의 부하입니다. WAL-delta는 여기까지 약 XNUMX분 정도 걸렸습니다. 즉, 속도가 훨씬 빨라졌지만 동시에 네트워크를 통한 교환이 더 강렬해졌습니다.

우리는 데이터베이스 기록에서 어떤 블록이 언제 변경되었는지에 대한 정보를 갖고 있으므로 더 나아가 "pg_prefaulter"라는 PostgreSQL 확장 기능을 통합하기로 결정했습니다.

이는 대기 기지가 복원 명령을 실행할 때 WAL-G에게 다음 WAL 파일을 가져오라고 지시한다는 의미입니다. 우리는 WAL 복구 프로세스가 가까운 미래에 어떤 데이터 블록에 액세스하고 이러한 블록에 대한 읽기 작업을 시작할지 대략적으로 이해합니다. 이는 SSD 컨트롤러의 성능을 높이기 위해 수행되었습니다. WAL 롤이 변경이 필요한 페이지에 도달하기 때문입니다. 이 페이지는 디스크에 있으며 페이지 캐시에는 없습니다. 그리고 그는 이 페이지가 도착할 때까지 동시에 기다릴 것입니다. 그러나 근처에는 WAL-G가 있습니다. WAL-G는 다음 수백 메가바이트의 WAL에서 특정 페이지가 필요하다는 것을 알고 동시에 워밍업을 시작합니다. 병렬로 실행되도록 여러 디스크 액세스를 시작합니다. 이는 SSD 드라이브에서는 잘 작동하지만, 불행하게도 하드 드라이브에는 전혀 적용되지 않습니다. 왜냐하면 우리는 프롬프트로만 간섭하기 때문입니다.

이것이 지금 코드에 있는 내용입니다.

추가하고 싶은 기능이 있습니다.

이 그림은 WAL-delta가 상대적으로 짧은 시간이 소요됨을 보여줍니다. 그리고 이것은 하루 동안 데이터베이스에서 발생한 변경 사항을 읽는 것입니다. WAL-delta는 더 이상 중요한 부하 소스가 아니기 때문에 밤에만 수행할 수 있는 것이 아닙니다. WAL-delta는 저렴하기 때문에 매분 읽을 수 있습니다. XNUMX분 안에 클러스터에 발생한 모든 변경 사항을 스캔할 수 있습니다. 그리고 이것은 "인스턴트 WAL-델타"라고 불릴 수 있습니다.

요점은 클러스터를 복원할 때 순차적으로 롤업해야 하는 스토리 수를 줄이는 것입니다. 즉, PostgreSQL이 롤링하는 WAL의 양은 상당한 시간이 걸리기 때문에 줄여야 합니다.

하지만 그게 전부는 아닙니다. 일부 블록이 백업 일관성 지점으로 변경될 것이라는 것을 알고 있으면 과거에 변경할 수 없습니다. 즉, 이제 WAL-delta 전달의 파일별 최적화가 가능해졌습니다. 즉, 예를 들어 화요일에 일부 테이블이 완전히 삭제되거나 일부 파일이 테이블에서 완전히 삭제된 경우 월요일에 델타 롤오버가 이루어지고 토요일의 pg_basebackup이 복원되면 이 데이터도 생성되지 않습니다.

우리는 이 기술을 페이지 수준으로 확장하고 싶습니다. 즉, 파일의 일부가 월요일에 변경되었지만 수요일에 덮어쓰게 되면 목요일에 특정 지점으로 복원할 때 페이지의 처음 몇 버전을 디스크에 쓸 필요가 없습니다.

하지만 이는 아직 우리 내부에서 활발하게 논의되고 있는 아이디어이지만, 아직 코드에는 도달하지 못했습니다.

우리는 WAL-G에 기능을 하나 더 만들고 싶습니다. 우리는 다양한 데이터베이스를 지원해야 하고 동일한 방식으로 백업 관리에 접근할 수 있기를 원하기 때문에 확장 가능하게 만들고 싶습니다. 그러나 문제는 MySQL API가 근본적으로 다르다는 것입니다. MySQL에서 PITR은 물리적 WAL 로그가 아닌 binlog를 기반으로 합니다. 그리고 MySQL에는 이 binlog가 완료되었으며 보관해야 함을 일부 외부 시스템에 알리는 보관 시스템이 없습니다. 데이터베이스가 있는 cron 어딘가에 서서 준비된 것이 있는지 확인해야 합니까?

그리고 마찬가지로, MySQL 복원 중에 이러한 파일이 필요하다는 것을 시스템에 알릴 수 있는 복원 명령이 없습니다. 클러스터 재구축을 시작하기 전에 어떤 파일이 필요한지 알아야 합니다. 어떤 파일이 필요할지 스스로 추측해야 합니다. 그러나 이러한 문제는 어떻게든 회피될 수 있습니다. (설명: MySQL은 이미 지원됩니다.)

보고서에서는 WAL-G가 귀하에게 적합하지 않은 경우에 대해서도 이야기하고 싶었습니다.

동기 복제본이 없는 경우 WAL-G는 마지막 세그먼트가 보존된다는 것을 보장하지 않습니다. 그리고 보관이 기록의 마지막 몇 부분보다 뒤처진다면 이는 위험합니다. 동기식 복제본이 없으면 WAL-G를 사용하지 않는 것이 좋습니다. 그러나 이는 주로 클라우드 설치용으로 설계되었으며, 이는 커밋된 마지막 바이트의 안전을 담당하는 동기식 복제본을 갖춘 고가용성 솔루션을 의미합니다.

WAL-G와 WAL-E를 동시에 실행하려는 사람들을 자주 봅니다. 우리는 WAL-G가 WAL-E에서 파일을 복원하고 WAL-E에서 만든 백업을 복원할 수 있다는 점에서 이전 버전과의 호환성을 지원합니다. 그러나 두 시스템 모두 병렬 wal-push를 사용하기 때문에 서로 파일을 훔치기 시작합니다. WAL-G에서 수정해도 여전히 WAL-E에 남아 있습니다. WAL-E에서는 아카이브 상태를 확인하고 완성된 파일을 확인하고 이를 아카이브하는 반면, 다른 시스템은 이 WAL 파일이 존재했다는 사실을 알지 못합니다. PostgreSQL은 두 번째로 아카이브를 시도하지 않기 때문입니다.

여기서 WAL-G 측에서 무엇을 수정할까요? 우리는 이 파일이 병렬로 전송되었다는 사실을 PostgreSQL에 알리지 않을 것이며, PostgreSQL이 우리에게 파일을 보관하라고 요청할 때 우리는 이 모드 시간과 이 md5를 가진 파일이 이미 보관되었다는 것을 이미 알고 있을 것이며 간단하게 PostgreSQL -이라고 말할 것입니다. 자, 본질적으로 아무것도 하지 않고도 모든 것이 준비되었습니다.

하지만 이 문제는 WAL-E 측에서 해결될 가능성이 낮기 때문에 현재 WAL-G와 WAL-E 모두에서 파일을 보관하는 보관 명령을 만드는 것은 불가능합니다.

또한 현재 WAL-G가 귀하에게 적합하지 않은 경우가 있지만 반드시 수정해 드리겠습니다.

첫째, 현재 백업 확인 기능이 내장되어 있지 않습니다. 백업이나 복구 중에는 검증이 없습니다. 물론 이는 클라우드에서 구현됩니다. 하지만 이는 단순히 클러스터를 복원하여 사전 확인만으로 구현됩니다. 이 기능을 사용자에게 제공하고 싶습니다. 그러나 확인을 통해 WAL-G에서 클러스터를 복원하고 시작하고 연기 테스트를 실행할 수 있다고 가정합니다. pg_dumpall에서 /dev/null로, amcheck 인덱스 확인입니다.

현재 WAL-G에는 WAL에서 하나의 백업을 연기할 수 있는 방법이 없습니다. 즉, 우리는 일부 창을 지원합니다. 예를 들어 지난 XNUMX일 동안의 저장, 최근 XNUMX개의 백업 저장, 최근 XNUMX개의 전체 백업 저장 등이 있습니다. 꽤 자주 사람들이 와서 이렇게 말합니다. "새해에 일어난 일에 대한 백업이 필요하며 영원히 보관하고 싶습니다." WAL-G는 아직 이 작업을 수행하는 방법을 모릅니다. (참고 - 이 문제는 이미 수정되었습니다. 자세히 알아보기 - 백업 표시 옵션 https://github.com/wal-g/wal-g/blob/master/PostgreSQL.md)

그리고 PITR을 검증할 때 모든 샤프트 세그먼트에 대한 페이지 체크섬 및 무결성 검사가 없습니다.

이 모든 것에서 나는 Google Summer of Code 프로젝트를 구성했습니다. Go로 무언가를 작성하고 문자 "G"가 있는 회사로부터 수천 달러를 받고 싶은 똑똑한 학생들을 알고 있다면 그들에게 우리 프로젝트를 추천하세요. 저는 이 프로젝트의 멘토 역할을 할 것입니다. 그들은 할 수 있습니다. 학생이 없으면 여름에 제가 직접 가져가겠습니다.

그리고 우리는 점차적으로 노력하고 있는 다른 많은 작은 문제들을 가지고 있습니다. 그리고 꽤 이상한 일들이 일어납니다.

예를 들어, WAL-G에 빈 백업을 제공하면 단순히 삭제됩니다. 예를 들어, 빈 폴더를 백업해야 한다고 말하면 됩니다. pg_control 파일은 거기에 없습니다. 그리고 그는 자신이 뭔가를 이해하지 못한다고 생각할 것입니다. 이론적으로 이 경우 사용자에게 도구 사용 방법을 설명하는 일반 메시지를 작성해야 합니다. 그러나 이것은 프로그래밍의 특징이 아니라 훌륭하고 이해하기 쉬운 언어의 특징입니다.

오프라인 백업 방법을 모르겠습니다. 데이터베이스가 거짓말을 하고 있으면 백업할 수 없습니다. 하지만 여기서는 모든 것이 매우 간단합니다. 시작되면 LSN으로 백업을 호출합니다. 기본 베이스의 LSN은 제어 파일에서 읽어야 합니다. 그리고 이것은 실현되지 않은 기능입니다. 많은 백업 시스템은 기본 데이터베이스를 백업할 수 있습니다. 그리고 그것은 편리합니다.

현재는 백업 공간 부족을 제대로 처리할 수 없습니다. 왜냐하면 우리는 보통 집에서 대규모 백업 작업을 하기 때문입니다. 그리고 그들은 그것에 대해 이해하지 못했습니다. 하지만 누군가 지금 당장 Go로 프로그래밍하고 싶다면 버킷에 공간 부족 오류 처리 기능을 추가하세요. 풀 리퀘스트를 꼭 살펴보겠습니다.

그리고 우리가 가장 걱정하는 점은 다양한 시나리오를 확인하는 가능한 한 많은 도커 통합 테스트를 원한다는 것입니다. 지금은 기본 시나리오만 테스트하고 있습니다. 커밋할 때마다 지원하는 모든 기능을 커밋별로 확인하고 싶습니다. 특히, 예를 들어 PostgreSQL 9.4-9.5에 대한 지원이 충분할 것입니다. 커뮤니티가 PostgreSQL을 지원하기 때문에 이를 지원하지만 모든 것이 손상되지 않았는지 확인하기 위해 커밋별로 확인하지는 않습니다. 그리고 이것은 다소 심각한 위험인 것 같습니다.

Yandex 데이터베이스 관리에는 천 개가 넘는 클러스터에서 WAL-G가 실행되고 있습니다. 그리고 매일 수백 테라바이트의 데이터를 백업합니다.

우리 코드에는 TODO가 많이 있습니다. 프로그래밍을 하고 싶다면 오세요. 풀 리퀘스트와 질문을 기다리고 있습니다.

질문

좋은 저녁이에요! 감사합니다! 내 생각에는 WAL-delta를 사용하는 경우 아마도 전체 페이지 쓰기에 크게 의존하고 있을 것입니다. 그렇다면 테스트를 실행했습니까? 아름다운 그래프를 보여주셨네요. FPW를 끄면 얼마나 더 아름다워질까요?

전체 페이지 쓰기가 활성화되어 있지만 비활성화하려고 시도하지 않았습니다. 즉, 저는 개발자로서 이 기능을 끄려고 시도한 적이 없습니다. 조사한 시스템 관리자는 아마도 이 문제를 조사했을 것입니다. 하지만 우리에게는 FPW가 필요합니다. 이를 비활성화하는 사람은 거의 없습니다. 그렇지 않으면 복제본에서 백업을 수행하는 것이 불가능하기 때문입니다.

신고해 주셔서 감사합니다! 두 가지 질문이 있습니다. 첫 번째 질문은 테이블스페이스는 어떻게 될까요?

우리는 끌어오기 요청을 기다리고 있습니다. 우리 데이터베이스는 SSD 및 NMVE 디스크에 있으므로 이 기능은 실제로 필요하지 않습니다. 나는 지금 당장은 그 일을 잘하기 위해 진지한 시간을 보낼 준비가 되어 있지 않습니다. 나는 우리가 이것을 지지할 것을 진심으로 옹호합니다. 지지하시는 분들도 계시지만, 자신에게 맞는 방식으로 지지해 주셨습니다. 그들은 포크를 만들었지만 풀 리퀘스트를 하지 않습니다. (버전 0.2.13에 추가됨)

그리고 두 번째 질문. 처음에 WAL-G는 단독으로 작동하며 래퍼가 필요하지 않다고 가정했다고 말씀하셨습니다. 나는 래퍼를 직접 사용합니다. 왜 사용하면 안되나요?

우리는 그것이 발랄라이카처럼 단순하길 원합니다. 이는 발랄라이카 외에는 아무것도 필요하지 않음을 의미합니다. 우리는 시스템이 단순해지기를 원합니다. 스크립트에서 수행해야 하는 기능이 있는 경우 와서 알려주십시오. Go에서 수행하겠습니다.

좋은 저녁이에요! 신고해 주셔서 감사합니다! WAL-G가 GPG 암호 해독과 작동하도록 할 수 없습니다. 정상적으로 암호화되지만 해독을 원하지 않습니다. 우리에게 맞지 않은 일인가요? 상황은 우울하다.

GitHub에서 문제를 만들고 알아봅시다.

즉, 이런 일이 발생하지 않았습니까?

WAL-G가 해당 파일이 어떤 종류의 파일인지 이해하지 못할 때 "암호화된 것일 수 있나요?"라고 묻는 오류 보고서 기능이 있습니다. 아마도 문제는 암호화가 전혀 아닐 수도 있습니다. 이 주제에 대한 로깅을 개선하고 싶습니다. 그는 그것을 해독해야 합니다. 우리는 공개 키와 개인 키를 얻기 위한 시스템이 구성되는 방식이 별로 마음에 들지 않는다는 의미에서 현재 이 주제를 다루고 있습니다. 외부 GPG를 호출하여 키를 제공하기 때문입니다. 그런 다음 이 키를 가져와 WAL-G 내부에서 컴파일된 공개 PGP인 내부 GPG로 전송하고 거기서 암호화라고 부릅니다. 이에 대해 우리는 시스템을 개선하고 Libsodium 암호화를 지원하고자 합니다(버전 0.2.15에 추가됨). 물론 해독이 작동해야 합니다. 알아봅시다. 몇 단어보다 더 많은 증상이 필요합니다. 가끔 발표자실에 모여서 시스템을 살펴보실 수도 있습니다. (외부 GPG 없이 PGP 암호화 - v0.2.9)

안녕하세요! 신고해 주셔서 감사합니다! 두 가지 질문이 있습니다. 두 공급자에서 pg_basebackup 및 WAL 로그인을 수행하려는 이상한 욕구가 있습니다. 즉, 하나의 클라우드와 다른 클라우드를 수행하고 싶습니다. 이를 수행할 수 있는 방법이 있습니까?

지금은 존재하지 않지만 흥미로운 아이디어입니다.

저는 단지 한 제공자를 신뢰하지 않고 만약을 대비해 다른 제공자를 신뢰하고 싶습니다.

아이디어는 흥미 롭습니다. 기술적으로 이것은 구현하기 전혀 어렵지 않습니다. 아이디어가 사라지는 것을 방지하기 위해 GitHub에 문제를 만들어 달라고 부탁해도 될까요?

네, 물론입니다.

그런 다음 학생들이 Google Summer of Code에 오면 프로젝트에 추가하여 더 많은 것을 얻을 수 있도록 할 것입니다.

그리고 두 번째 질문. GitHub에 문제가 있습니다. 이미 문을 닫은 것 같아요. 복원하는 동안 패닉이 발생합니다. 그리고 그것을 물리치기 위해 별도의 어셈블리를 만들었습니다. 문제가 맞습니다. 그리고 하나의 스레드에서 다양한 환경을 수행하는 옵션이 있습니다. 그렇기 때문에 매우 느리게 작동합니다. 이 문제가 발생했는데 아직 해결되지 않았습니다.

문제는 어떤 이유에서든 높은 동시성이 발생하면 스토리지(CEPH)가 연결을 재설정한다는 것입니다. 이에 대해 무엇을 할 수 있습니까? 재시도 논리는 다음과 같습니다. 파일을 다시 다운로드하려고 합니다. 한 번에 많은 파일이 다운로드되지 않았으므로 로그인하지 않은 모든 사용자를 위해 두 번째 파일을 만들 것입니다. 그리고 반복마다 최소한 하나의 파일이 로드되는 한 우리는 반복하고 반복합니다. 재시도(지수 백오프) 논리를 개선했습니다. 그러나 단순히 스토리지 시스템 측에서 연결이 끊어진다는 사실을 어떻게 해야 할지 완전히 명확하지 않습니다. 즉, 하나의 스트림에 업로드해도 이러한 연결이 끊어지지 않습니다. 여기서 무엇을 개선할 수 있나요? 네트워크 제한 기능이 있어 전송하는 바이트 수에 따라 각 연결을 제한할 수 있습니다. 그렇지 않으면 객체 스토리지를 통해 병렬로 다운로드하거나 다운로드할 수 없다는 사실을 어떻게 처리해야 할지 모르겠습니다.

SLA가 없나요? 그들이 어떻게 고통을 받는지 기록되어 있지 않습니까?

요점은 이 질문을 하는 사람들은 대개 자신만의 금고를 가지고 있다는 것입니다. 즉, Amazon이나 Google Cloud, Yandex Object Storage 출신은 아무도 없습니다.

어쩌면 그 질문이 더 이상 당신을 위한 것이 아닐 수도 있나요?

이 경우의 질문은 누구에게 중요하지 않습니다. 이 문제를 해결하는 방법에 대한 아이디어가 있으면 WAL-G에서 실행해 보겠습니다. 하지만 지금까지는 이 문제를 어떻게 처리해야 할지에 대한 좋은 아이디어가 없습니다. 백업 목록을 다르게 지원하는 일부 Object Storage가 있습니다. 객체 목록을 요청하면 거기에 폴더를 추가합니다. WAL-G는 이에 겁을 먹습니다. 여기에 파일이 아닌 어떤 것이 있어서 복원할 수 없습니다. 이는 백업이 복원되지 않았음을 의미합니다. 즉, 실제로 완전히 복원된 클러스터가 있지만 Object Storage가 완전히 이해하지 못한 이상한 정보를 반환했기 때문에 잘못된 상태를 반환합니다.

이것은 메일 클라우드에서 일어나는 일입니다.

복제품을 만들 수 있다면...

꾸준히 재생산되고 있습니다..

재현이 있다면 재시도 전략을 실험하고 재시도 방법을 파악하고 클라우드가 우리에게 요구하는 것이 무엇인지 이해할 것이라고 생각합니다. 어쩌면 세 개의 연결이 안정적이고 연결을 끊지 않을 수도 있습니다. 그런 다음 조심스럽게 세 개에 도달할 것입니다. 이제 연결을 매우 빠르게 끊기 때문입니다. 즉, 16개 스레드로 복구를 시작한 경우 첫 번째 재시도 후에는 8개 스레드, 4개 스레드, 2개 스레드 및 7,5개의 스레드가 있게 됩니다. 그런 다음 파일을 하나의 스트림으로 가져옵니다. 7,5 스레드가 펌핑하기에 가장 좋은 것과 같은 몇 가지 마법의 값이 있다면, 우리는 그것에 머물면서 또 다른 XNUMX 스레드를 만들려고 노력할 것입니다. 여기에 아이디어가 있습니다.

신고해 주셔서 감사합니다! WAL-G 작업을 위한 전체 워크플로는 어떤 모습인가요? 예를 들어, 페이지 전체에 델타가 없는 어리석은 경우입니다. 그리고 초기 백업을 가져와 제거한 다음 전면이 파란색이 될 때까지 샤프트를 보관합니다. 내가 이해하는 바에 따르면 여기에 고장이 있습니다. 어떤 시점에서는 페이지의 델타 백업을 만들어야 합니다. 즉, 일부 외부 프로세스가 이를 주도하고 있거나 어떻게 이런 일이 발생합니까?

델타 백업 API는 매우 간단합니다. 거기에는 숫자가 있습니다. 최대 델타 단계라고 합니다. 기본값은 3입니다. 즉, 백업 푸시를 수행할 때마다 전체 백업이 다운로드됩니다. 이를 양수(예: 3)로 변경하면 다음에 백업 푸시를 수행할 때 이전 백업 기록을 확인합니다. 그는 당신이 XNUMX개의 삼각주 사슬을 초과하지 않는 것을 보고 삼각주를 만듭니다.

즉, WAL-G를 시작할 때마다 전체 백업을 시도한다는 것입니까?

아니요, 우리는 WAL-G를 실행하며 정책이 허용하는 경우 델타를 만들려고 시도합니다.

대략적으로 말하면, 매번 XNUMX으로 실행하면 pg_basebackup처럼 동작할까요?

아니요, 압축과 병렬 처리를 사용하므로 더 빠르게 실행됩니다. Pg_basebackup이 샤프트를 당신 옆에 놓을 것입니다. WAL-G는 아카이브가 구성되어 있다고 가정합니다. 그리고 구성되지 않은 경우 경고가 표시됩니다.

Pg_basebackup은 샤프트 없이 실행될 수 있습니다.

예, 그러면 그들은 거의 동일하게 행동할 것입니다. Pg_basebackup은 파일 시스템에 복사합니다. 그런데 제가 언급하지 않은 새로운 기능이 있습니다. 이제 pg_basebackup에서 파일 시스템으로 백업할 수 있습니다. 이것이 왜 필요한지는 모르겠지만 거기에 있습니다.

예를 들어 CephFS에서. 모든 사람이 Object Storage를 구성하고 싶어하는 것은 아닙니다.

네, 아마도 그래서 우리가 할 수 있도록 이 기능에 대해 질문을 한 것 같습니다. 그리고 우리는 해냈습니다.

신고해 주셔서 감사합니다! 파일 시스템에 복사하는 것에 대한 질문이 있습니다. 예를 들어, 데이터 센터에 선반이 있거나 다른 곳에 있는 경우 기본적으로 원격 스토리지로의 복사를 지원합니까?

이 공식에서 이것은 어려운 질문입니다. 예, 지원합니다. 하지만 이 기능은 아직 어떤 릴리스에도 포함되어 있지 않습니다. 즉, 모든 시험판에서는 이를 지원하지만 릴리스 버전에서는 지원하지 않습니다. 이 기능은 버전 0.2에 추가되었습니다. 알려진 버그를 모두 수정하는 대로 곧 출시될 예정입니다. 하지만 지금은 시험판에서만 가능합니다. 시험판에는 두 가지 버그가 있습니다. WAL-E 복구 문제, 아직 해결되지 않았습니다. 그리고 최신 시험판에는 델타 백업에 대한 버그가 추가되었습니다. 따라서 모든 사람이 릴리스 버전을 사용하는 것이 좋습니다. 사전 출시 버전에서 더 이상 버그가 없으면 Google Cloud, S3 호환 항목 및 파일 저장소를 지원한다고 말할 수 있습니다.

안녕하세요, 신고해 주셔서 감사합니다. 제가 알기로는 WAL-G는 바텐더와 같은 일종의 중앙 집중식 시스템이 아닌가요? 이 방향으로 움직일 계획이신가요?

문제는 우리가 이 방향에서 멀어졌다는 것이다. WAL-G는 기본 호스트, 클러스터 호스트 및 클러스터의 모든 호스트에 있습니다. 수천 개의 클러스터로 이전했을 때 바텐더가 많이 설치되었습니다. 그리고 그 안에 뭔가가 무너질 때마다 그것은 큰 문제입니다. 복구해야 하기 때문에 현재 백업이 없는 클러스터를 이해해야 합니다. 백업 시스템용 물리적 하드웨어 방향으로 WAL-G를 개발할 계획은 없습니다. 커뮤니티가 여기에 몇 가지 기능을 원하더라도 전혀 상관하지 않습니다.

우리에게는 스토리지를 담당하는 팀이 있습니다. 그리고 우리가 아니라 파일이 안전한 곳에 우리 파일을 넣어주는 특별한 사람들이 있다는 사실이 너무 기분이 좋습니다. 그들은 특정 수의 파일이 손실되는 것을 견디기 위해 온갖 종류의 영리한 코딩을 수행합니다. 그들은 네트워크 대역폭을 담당합니다. 바텐더가 있으면 트래픽이 많은 소규모 데이터베이스가 동일한 서버에 모여 있는 것을 갑자기 발견할 수 있습니다. 공간이 많은 것 같지만 어떤 이유로 모든 것이 네트워크에 맞지 않습니다. 그 반대의 결과가 나올 수도 있습니다. 거기에는 많은 네트워크가 있고 프로세서 코어가 있지만 여기에는 디스크가 없습니다. 그리고 우리는 무언가를 저글링해야 하는 필요성에 지쳤고, 데이터 저장은 별도의 특별한 사람들이 책임을 지는 별도의 서비스라는 사실로 전환했습니다.

P.S 새로운 버전이 출시되었습니다. 0.2.15, 기본적으로 postgres 홈 디렉터리에 있는 .walg.json 구성 파일을 사용할 수 있습니다. Bash 스크립트를 포기할 수 있습니다. 이번 호에는 .walg.json 예제가 포함되어 있습니다. https://github.com/wal-g/wal-g/issues/545

비디오 :

출처 : habr.com