PostgreSQL의 팽창을 초래하는 애플리케이션의 일반적인 오류입니다. 안드레이 살니코프

Andrey Salnikov가 쓴 2016년 초 보고서의 기록인 "PostgreSQL에서 팽창을 초래하는 애플리케이션의 일반적인 오류"를 읽어 보시기 바랍니다.

본 리포트에서는 애플리케이션 코드를 설계하고 작성하는 단계에서 발생하는 애플리케이션의 주요 오류를 분석해 보겠습니다. 그리고 PostgreSQL에서 부풀림을 유발하는 오류만 처리하겠습니다. 일반적으로 이는 처음에는 이에 대한 전제 조건이 표시되지 않았지만 시스템 전체 성능의 끝의 시작입니다.

모두를 환영하게 되어 기뻐요! 이 보고서는 내 동료가 작성한 이전 보고서만큼 기술적이지 않습니다. 이 보고서는 클라이언트 수가 상당히 많기 때문에 주로 백엔드 시스템 개발자를 대상으로 합니다. 그리고 그들은 모두 같은 실수를 저지릅니다. 나는 그들에 대해 당신에게 말할 것입니다. 이러한 실수가 어떤 치명적이고 나쁜 결과를 가져오는지 설명하겠습니다.

실수는 왜 일어나는가? 이는 두 가지 이유 때문에 수행됩니다. 무작위로 작동할 수도 있고 데이터베이스와 애플리케이션 사이는 물론 데이터베이스 자체에서 발생하는 일부 메커니즘을 무시하기 때문입니다.

상황이 얼마나 나빠졌는지에 대한 끔찍한 그림과 함께 세 가지 예를 들어보겠습니다. 거기서 일어나는 메커니즘에 대해 간략하게 말씀드리겠습니다. 그리고 이러한 문제를 어떻게 처리해야 하는지, 언제 발생했는지, 실수를 방지하기 위해 어떤 예방 방법을 사용해야 하는지 알아보세요. 보조 도구에 대해 설명하고 유용한 링크를 제공하겠습니다.

저는 두 개의 테이블이 있는 테스트 데이터베이스를 사용했습니다. 한 접시에는 고객 계정이 있고 다른 접시에는 이 계정의 거래가 있습니다. 그리고 일정 빈도로 이러한 계정의 잔액을 업데이트합니다.

플레이트의 초기 데이터: 2MB로 매우 작습니다. 데이터베이스, 특히 표지판의 응답 시간도 매우 좋습니다. 그리고 상당히 좋은 부하 - 플레이트에 따르면 초당 2개의 작업입니다.

그리고 이 보고서를 통해 무슨 일이 일어나고 있는지 명확하게 이해할 수 있도록 그래프를 보여 드리겠습니다. 그래프가 포함된 슬라이드는 항상 2개입니다. 첫 번째 슬라이드는 서버에서 일반적으로 일어나는 일입니다.

그리고 이 상황에서 우리는 실제로 작은 표시가 있다는 것을 알 수 있습니다. 인덱스는 2MB로 작습니다. 왼쪽의 첫 번째 그래프입니다.

서버의 평균 응답 시간도 안정적이고 짧습니다. 오른쪽 상단 그래프입니다.

왼쪽 하단 그래프는 가장 긴 트랜잭션을 보여줍니다. 거래가 빠르게 완료되는 것을 볼 수 있습니다. 그리고 Autovacuum은 시작 테스트였기 때문에 여기서는 아직 작동하지 않습니다. 이는 계속 작동하며 우리에게 유용할 것입니다.

두 번째 슬라이드는 항상 테스트 중인 플레이트 전용입니다. 이 상황에서 우리는 고객의 계좌 잔액을 지속적으로 업데이트합니다. 그리고 업데이트 작업의 평균 응답 시간이 XNUMX밀리초 미만으로 상당히 좋은 것을 볼 수 있습니다. 프로세서 리소스(오른쪽 상단 그래프)도 고르게 소모되고 매우 적은 양으로 소비되는 것을 볼 수 있습니다.

오른쪽 하단 그래프는 업데이트하기 전에 원하는 라인을 검색하기 위해 수행하는 작업 및 디스크 메모리의 양을 보여줍니다. 그리고 부호에 따른 연산 횟수는 처음에 말씀드린 대로 초당 2번입니다.

그리고 이제 우리에게는 비극이 생겼습니다. 어떤 이유에서인지 오랫동안 잊혀진 거래가 있습니다. 그 이유는 일반적으로 모두 진부합니다.

• 가장 일반적인 것 중 하나는 애플리케이션 코드에서 외부 서비스에 액세스하기 시작했다는 것입니다. 그리고 이 서비스는 우리에게 응답하지 않습니다. 즉, 트랜잭션을 열고 데이터베이스를 변경한 후 애플리케이션에서 메일을 읽거나 인프라 내의 다른 서비스로 이동했는데 어떤 이유로 응답하지 않습니다. 그리고 우리 세션은 언제 해결될지 알 수 없는 상태에 갇혀 있습니다.
• 두 번째 상황은 어떤 이유로 인해 코드에서 예외가 발생한 경우입니다. 그리고 예외적으로 우리는 거래 종료를 처리하지 않았습니다. 그리고 우리는 공개 거래로 인해 중단된 세션으로 끝났습니다.
• 그리고 마지막 경우도 상당히 흔한 경우입니다. 품질이 낮은 코드입니다. 일부 프레임워크는 트랜잭션을 엽니다. 응답이 중단되고 응용프로그램에서 응답이 중단되었음을 알 수 없을 수도 있습니다.

그런 일이 어디로 이어지나요?

테이블과 인덱스가 극적으로 부풀어오르기 시작할 정도입니다. 이것은 정확히 동일한 팽창 효과입니다. 데이터베이스의 경우 이는 데이터베이스 응답 시간이 매우 급격히 증가하고 데이터베이스 서버의 로드가 증가한다는 것을 의미합니다. 결과적으로 우리의 애플리케이션은 어려움을 겪게 될 것입니다. 데이터베이스 요청 시 코드에서 10밀리초, 논리에서 10밀리초를 소비했다면 함수를 완료하는 데 20밀리초가 걸렸기 때문입니다. 그리고 이제 당신의 상황은 매우 슬플 것입니다.

그리고 무슨 일이 일어나는지 봅시다. 왼쪽 하단 그래프는 길고 긴 거래를 보여줍니다. 그리고 왼쪽 위 그래프를 보면 테이블 크기가 갑자기 300MB에서 XNUMXMB로 급증한 것을 알 수 있습니다. 동시에 테이블의 데이터 양은 변경되지 않았습니다. 즉, 거기에 상당히 많은 양의 쓰레기가 있습니다.

평균 서버 응답 시간에 관한 일반적인 상황도 몇 배나 달라졌습니다. 즉, 서버의 모든 요청이 완전히 중단되기 시작했습니다. 동시에 내부 Postgres 프로세스가 autovacuum 형태로 시작되어 무언가를 시도하고 리소스를 소비하고 있습니다.

우리 간판에 무슨 일이 일어나고 있는 걸까요? 똑같다. 표지판에 따른 평균 응답 시간이 몇 배나 늘어났습니다. 특히 소비되는 리소스 측면에서 보면 프로세서의 부하가 크게 증가한 것을 알 수 있습니다. 오른쪽 상단 그래프입니다. 그리고 프로세서가 필요한 라인을 찾기 위해 수많은 쓸모없는 라인을 분류해야 하기 때문에 그 수가 증가했습니다. 오른쪽 하단 그래프입니다. 결과적으로 데이터베이스가 동일한 수의 요청을 처리할 시간이 없었기 때문에 초당 호출 수가 크게 줄어들기 시작했습니다.

우리는 다시 삶으로 돌아가야 합니다. 우리는 온라인에 접속하여 긴 거래로 인해 문제가 발생한다는 사실을 알아냈습니다. 우리는 이 거래를 찾아서 종료합니다. 그리고 우리에게는 모든 것이 정상화되고 있습니다. 모든 것이 정상적으로 작동합니다.

우리는 진정했지만 잠시 후 애플리케이션이 긴급 상황 이전과 같은 방식으로 작동하지 않는다는 것을 깨닫기 시작했습니다. 요청은 여전히 ​​더 느리게 처리되며 상당히 느립니다. 내 예에서는 특히 XNUMX배에서 XNUMX배 더 느립니다. 서버 부하도 사고 전보다 높아졌다.

그리고 질문은 "지금 이 순간 기지에 무슨 일이 일어나고 있는 걸까요?" 그리고 베이스에서는 다음과 같은 상황이 발생합니다. 거래 차트를 보면 정지된 상태이고 실제로 장기 거래가 없는 것을 확인할 수 있습니다. 하지만 사고로 인해 표지판의 크기가 치명적으로 커졌습니다. 그 이후로 그들은 감소하지 않았습니다. 기지에서의 평균 시간이 안정되었습니다. 그리고 응답은 우리가 받아들일 수 있는 속도로 적절하게 나오는 것 같습니다. autovacuum은 더 활성화되어 더 많은 데이터를 조사해야 하므로 기호를 사용하여 작업을 시작했습니다.

특히 잔액을 변경하는 계정 테스트 플레이트에 따르면 요청에 대한 응답 시간이 정상으로 돌아온 것 같습니다. 그러나 실제로는 XNUMX배 더 높습니다.

그리고 프로세서의 로드를 보면 프로세서의 로드가 충돌 이전에 필요한 값으로 반환되지 않았음을 알 수 있습니다. 그리고 그 이유는 오른쪽 하단 그래프에 정확하게 나와 있습니다. 거기에서 일정량의 메모리가 검색되고 있는 것을 볼 수 있습니다. 즉, 필요한 라인을 찾기 위해 불필요한 데이터를 정리하면서 데이터베이스 서버의 자원을 낭비하게 된다. 초당 거래 수가 안정화되었습니다.

전반적으로 좋은데, 상황은 예전보다 더 나쁩니다. 이 데이터베이스와 함께 작동하는 애플리케이션의 결과로 데이터베이스 성능 저하를 제거합니다.

그리고 거기에서 무슨 일이 일어나고 있는지 이해하기 위해 이전 보고서에 참석하지 않았다면 이제 약간의 이론을 살펴 보겠습니다. 내부 프로세스에 대한 이론. 자동차 진공청소기는 왜, 그리고 어떤 역할을 합니까?

이해를 위해 말 그대로 간략하게 설명합니다. 어느 시점에서 우리는 테이블을 갖게됩니다. 테이블에 행이 있습니다. 이 라인은 활성화되어 있고 살아 있을 수 있으며 지금 우리에게 필요한 것입니다. 사진에서 녹색으로 표시되어 있습니다. 그리고 이미 해결되고 업데이트되었으며 새 항목이 나타난 데드라인이 있습니다. 그리고 더 이상 데이터베이스에 관심이 없는 것으로 표시됩니다. 그러나 Postgres 기능으로 인해 표에 포함되었습니다.

왜 자동차 진공 청소기가 필요합니까? 어느 시점에서 autovacuum이 와서 데이터베이스에 액세스하고 "현재 데이터베이스에 열려 있는 가장 오래된 트랜잭션의 ID를 알려주세요."라고 묻습니다. 데이터베이스는 이 ID를 반환합니다. 그리고 이를 기반으로 autovacuum이 테이블의 행을 정렬합니다. 그리고 훨씬 오래된 트랜잭션으로 인해 일부 라인이 변경된 것을 발견하면 거기에 새 데이터를 작성하여 나중에 재사용할 수 있는 라인으로 표시할 권리가 있습니다. 이는 백그라운드 프로세스입니다.

현재 우리는 계속해서 데이터베이스 작업을 수행하고 테이블을 일부 변경하고 있습니다. 그리고 재사용할 수 있는 이 줄에 새로운 데이터를 씁니다. 즉, 항상 죽은 오래된 줄이 나타날 때마다 그 대신 필요한 새 줄을 작성합니다. 이는 PostgreSQL이 작동하는 정상적인 상태입니다.

사고 중에 무슨 일이 일어났나요? 그곳에서는 이 과정이 어떻게 진행됐나요?

우리는 어떤 상태의 표지판을 가지고 있었고 일부는 살아 있고 일부는 데드라인이었습니다. 자동차 진공청소기가 도착했습니다. 그는 데이터베이스에 가장 오래된 트랜잭션이 무엇인지, 해당 트랜잭션의 ID가 무엇인지 물었습니다. 저는 이 ID를 받았습니다. 이는 몇 시간 전, 어쩌면 XNUMX분 전일 수도 있습니다. 이는 데이터베이스의 로드가 얼마나 무거운지에 따라 다릅니다. 그리고 그는 재사용된 것으로 표시할 수 있는 라인을 찾았습니다. 그리고 우리 테이블에서는 그런 줄을 찾지 못했습니다.

그러나 현재 우리는 테이블 작업을 계속하고 있습니다. 우리는 그 안에서 뭔가를 하고, 업데이트하고, 데이터를 변경합니다. 이때 데이터베이스는 무엇을 해야 합니까? 그녀는 기존 테이블 끝에 새 줄을 추가하는 것 외에는 선택의 여지가 없습니다. 따라서 테이블 크기가 부풀어오르기 시작합니다.

실제로 작동하려면 녹색 선이 필요합니다. 그러나 이러한 문제가 발생하는 동안 전체 테이블에서 녹색 선의 비율이 매우 낮은 것으로 나타났습니다.

그리고 쿼리를 실행할 때 데이터베이스는 원하는 라인을 찾기 위해 빨간색과 녹색의 모든 라인을 통과해야 합니다. 그리고 쓸모없는 데이터로 테이블을 부풀리는 효과를 "부풀림"이라고 하며, 이는 디스크 공간도 소모합니다. 2MB였는데 300MB가 되었다는 사실을 기억하시나요? 이제 메가바이트를 기가바이트로 변경하면 모든 디스크 리소스가 빠르게 손실됩니다.

우리에게는 어떤 결과가 있을 수 있습니까?

• 내 예에서는 테이블과 인덱스가 150배 증가했습니다. 우리 고객 중 일부는 단순히 디스크 공간이 부족해지기 시작했을 때 더 치명적인 사례를 겪었습니다.
• 테이블 자체의 크기는 결코 줄어들지 않습니다. 경우에 따라 Autovacuum은 데드라인만 있는 경우 테이블의 꼬리를 잘라낼 수 있습니다. 그러나 지속적인 회전이 있기 때문에 녹색 선 하나가 끝 부분에서 멈춰 업데이트되지 않을 수 있으며, 다른 모든 선은 플레이트 시작 부분 어딘가에 기록됩니다. 하지만 이는 테이블 자체의 크기가 줄어들 가능성이 매우 낮은 이벤트이므로 기대해서는 안 됩니다.
• 데이터베이스는 쓸모없는 줄 전체를 정렬해야 합니다. 그리고 우리는 디스크 자원과 프로세서 자원, 전력을 낭비합니다.
• 이는 애플리케이션에 직접적인 영향을 미칩니다. 왜냐하면 처음에 요청에 10밀리초, 코드에 10밀리초를 소비했다면 충돌 중에 요청에 10초, 코드에 20밀리초를 소비하기 시작했기 때문입니다. 애플리케이션 성능의 규모가 감소했습니다. 그리고 사고가 해결되자 우리는 요청에 10밀리초, 코드에 XNUMX밀리초를 소비하기 시작했습니다. 이는 생산성이 여전히 XNUMX배나 떨어졌다는 것을 의미합니다. 그리고 이것은 모두 우리의 잘못으로 인해 얼어붙은 거래 하나 때문에 발생한 것입니다.
• 그리고 질문: "어떻게 하면 모든 것을 되돌릴 수 있나요?" 모든 것이 잘되고 사고 전처럼 요청이 빨리 들어올 수 있도록 말이죠.

이를 위해 특정 작업 주기가 수행됩니다.

먼저 문제가 있는 부풀어 오른 테이블을 찾아야 합니다. 우리는 일부 테이블에서는 녹음이 더 활발하고 다른 테이블에서는 덜 활발하다는 것을 알고 있습니다. 이를 위해 우리는 확장을 사용합니다 pgstattuple. 이 확장 기능을 설치하면 상당히 비대해진 테이블을 찾는 데 도움이 되는 쿼리를 작성할 수 있습니다.

이러한 테이블을 찾았으면 압축해야 합니다. 이를 위한 도구가 이미 있습니다. 우리 회사에서는 세 가지 도구를 사용합니다. 첫 번째는 내장된 VACUUM FULL입니다. 그는 잔인하고 가혹하며 무자비하지만 때로는 매우 유용합니다. Pg_repack и pgcompactable - 테이블 압축을 위한 타사 유틸리티입니다. 그리고 그들은 데이터베이스를 더 조심스럽게 다룹니다.

귀하에게 더 편리한 것이 무엇인지에 따라 사용됩니다. 하지만 이에 대해서는 맨 마지막에 말씀 드리겠습니다. 가장 중요한 것은 세 가지 도구가 있다는 것입니다. 선택할 수 있는 것이 많습니다.

모든 것을 수정하고 모든 것이 정상인지 확인한 후에는 앞으로 이러한 상황을 방지하는 방법을 알아야 합니다.

• 아주 쉽게 예방할 수 있습니다. 마스터 서버의 세션 기간을 모니터링해야 합니다. 트랜잭션 상태에서 유휴 상태일 때 특히 위험한 세션. 이들은 방금 트랜잭션을 열었고, 어떤 작업을 하고 떠났거나, 그냥 매달렸거나, 코드에서 길을 잃은 사람들입니다.
• 그리고 개발자로서 이러한 상황이 발생할 때 코드를 테스트하는 것이 중요합니다. 어렵지 않습니다. 이것은 유용한 점검이 될 것입니다. 긴 트랜잭션과 관련된 수많은 "유치한" 문제를 피할 수 있습니다.

이 그래프에서는 이 경우 VACUUM FULL로 기호를 처리한 후 데이터베이스의 기호와 동작이 어떻게 변경되는지 보여주고 싶었습니다. 이것은 나에게 생산이 아닙니다.

테이블 크기는 즉시 몇 메가바이트의 정상 작동 상태로 돌아왔습니다. 이는 서버의 평균 응답 시간에 큰 영향을 미치지 않았습니다.

그러나 특히 계정 잔액을 업데이트한 테스트 표지판의 경우 표지판의 데이터 업데이트 요청에 대한 평균 응답 시간이 긴급 상황 이전 수준으로 단축되었음을 알 수 있습니다. 이 요청을 완료하기 위해 프로세서가 소비하는 리소스도 충돌 이전 수준으로 떨어졌습니다. 그리고 오른쪽 하단 그래프는 이제 테이블이 압축되기 전에 존재했던 데드 라인 더미를 거치지 않고 바로 필요한 라인을 정확히 찾는 것을 보여줍니다. 그리고 평균 요청 시간도 거의 같은 수준으로 유지되었습니다. 하지만 여기서는 오히려 내 하드웨어에 오류가 있습니다.

여기서 첫 번째 이야기가 끝납니다. 가장 일반적입니다. 그리고 이런 일은 고객의 경험이나 프로그래머의 자격에 관계없이 모든 사람에게 발생합니다. 조만간 이런 일이 발생합니다.

두 번째 이야기는 부하를 분산하고 서버 리소스를 최적화하는 것입니다.

• 우리는 이미 성장하여 진지한 남자가 되었습니다. 그리고 우리는 복제본이 있고 로드 균형을 맞추는 것이 좋을 것임을 이해합니다. 즉, 마스터에 쓰고 복제본에서 읽는 것입니다. 그리고 일반적으로 이러한 상황은 일부 보고서나 ETL을 준비하려고 할 때 발생합니다. 그리고 기업은 이에 대해 매우 만족하고 있습니다. 그는 정말 복잡한 분석이 많이 포함된 다양한 보고서를 원합니다.
• 복잡한 분석은 밀리초 단위로 계산할 수 없기 때문에 보고서를 작성하는 데 많은 시간이 걸립니다. 우리는 용감한 사람들처럼 코드를 작성합니다. 삽입 애플리케이션에서는 마스터에서 녹음을 수행하고 복제본에서 보고서를 실행합니다.
• 부하를 분산합니다.
• 모든 것이 완벽하게 작동합니다. 우리는 훌륭합니다.

그리고 이 상황은 어떤 모습일까요? 특히 이 그래프에서는 트랜잭션 기간 동안 복제본의 트랜잭션 기간도 추가했습니다. 다른 모든 그래프는 마스터 서버만 참조합니다.

이때쯤에는 보고서 게시판이 커졌습니다. 더 많은 것이 있습니다. 평균 서버 응답 시간이 안정적인 것을 확인할 수 있습니다. 복제본에는 2시간 동안 실행되는 장기 실행 트랜잭션이 있음을 알 수 있습니다. 데드라인을 처리하는 Autovacuum의 조용한 작동을 볼 수 있습니다. 그리고 우리는 모든 것이 괜찮습니다.

특히, 테스트된 플레이트에 따라 우리는 그곳의 계정 잔액을 계속 업데이트합니다. 또한 요청에 대한 안정적인 응답 시간과 안정적인 리소스 소비도 제공됩니다. 우리는 모든 것이 괜찮습니다.

복제 충돌로 인해 이러한 보고서가 다시 실행되기 전까지는 모든 것이 정상입니다. 그리고 그들은 일정한 간격으로 반격합니다.

우리는 온라인에 접속하여 왜 이런 일이 일어나는지 읽기 시작합니다. 그리고 우리는 해결책을 찾습니다.

첫 번째 해결 방법은 복제 대기 시간을 늘리는 것입니다. 우리는 보고서가 3시간 동안 실행된다는 것을 알고 있습니다. 복제 지연을 3시간으로 설정했습니다. 모든 것을 출시하고 있지만 여전히 보고서가 취소되는 문제가 계속 발생하고 있습니다.

우리는 모든 것이 완벽하기를 원합니다. 우리는 더 올라갑니다. 그리고 우리는 인터넷에서 hot_standby_feedback이라는 멋진 설정을 찾았습니다. 켜봅시다. Hot_standby_feedback을 사용하면 마스터에서 autovacuum을 억제할 수 있습니다. 따라서 복제 충돌을 완전히 제거합니다. 그리고 보고서를 사용하면 모든 것이 잘 작동합니다.

그리고 지금 마스터 서버에서는 무슨 일이 벌어지고 있는 걸까요? 그리고 우리는 마스터 서버에 완전히 문제가 있습니다. 이제 이 두 설정을 모두 활성화하면 그래프가 표시됩니다. 그리고 우리 복제본의 세션이 어떻게든 마스터 서버의 상황에 영향을 미치기 시작했다는 것을 알 수 있습니다. 그녀는 데드라인을 없애는 자동 진공 작업을 일시 중지했기 때문에 효과가 있었습니다. 우리 테이블 크기가 다시 급증했습니다. 전체 데이터베이스의 평균 쿼리 실행 시간도 급증했습니다. 자동 진공이 약간 강화되었습니다.

특히, 우리 플레이트에서 데이터 업데이트도 하늘로 뛰어오르는 것을 볼 수 있습니다. CPU 소비도 마찬가지로 크게 증가했습니다. 우리는 다시 수많은 쓸모없고 쓸모없는 라인을 겪고 있습니다. 그리고 이 표시에 대한 응답 시간과 거래 수가 감소했습니다.

내가 전에 무슨 말을 했는지 모른다면 어떤 모습일까요?

• 우리는 문제를 찾기 시작합니다. 첫 번째 부분에서 문제가 발생하면 이것이 긴 트랜잭션으로 인한 것일 수 있음을 알고 마스터로 이동합니다. 마스터에 문제가 있습니다. 그를 소시지로 만든다. 뜨거워지고 부하 평균은 약 XNUMX입니다.
• 요청은 느리지만 장기 실행 트랜잭션은 표시되지 않습니다. 그리고 우리는 문제가 무엇인지 이해하지 못합니다. 우리는 어디를 봐야할지 모르겠습니다.
• 서버 장비를 점검합니다. 어쩌면 우리 습격이 무너졌을 수도 있어요. 어쩌면 메모리 스틱이 다 타버릴 수도 있습니다. 예, 어떤 일이든 일어날 수 있습니다. 하지만 아니요, 서버는 새 서버이고 모든 것이 잘 작동합니다.
• 관리자, 개발자, 이사 등 모두가 달리고 있습니다. 아무것도 도움이 되지 않습니다.
• 그리고 어느 시점에서 갑자기 모든 것이 스스로 교정되기 시작합니다.

이때 복제본에 대한 요청이 처리되어 떠났습니다. 우리는 보고서를 받았습니다. 사업은 여전히 ​​행복합니다. 보시다시피, 우리 간판은 다시 성장했으며 줄어들지 않을 것입니다. 세션 그래프에서는 상황이 안정될 때까지 걸리는 시간을 추정할 수 있도록 복제본에서 이 긴 트랜잭션의 일부를 남겨 두었습니다.

세션이 끝났습니다. 그리고 얼마 후에야 서버가 어느 정도 순서대로 작동합니다. 그리고 마스터 서버의 요청에 대한 평균 응답 시간이 정상으로 돌아옵니다. 왜냐하면 마침내 autovacuum이 이러한 데드 라인을 정리하고 표시할 수 있기 때문입니다. 그리고 그는 자신의 일을 시작했습니다. 그리고 그가 얼마나 빨리 그 일을 하는지, 우리는 너무 빨리 순서를 정할 것입니다.

계정 잔액을 업데이트하는 테스트된 태블릿에 따르면 정확히 동일한 그림이 표시됩니다. 평균 계정 업데이트 시간도 점차 정상화되고 있습니다. 프로세서가 소비하는 리소스도 줄어듭니다. 그리고 초당 트랜잭션 수가 정상으로 돌아옵니다. 그러나 다시 우리는 사고 이전과 같지 않고 정상으로 돌아왔습니다.

어쨌든 첫 번째 경우처럼 성능이 XNUMX배에서 XNUMX배, 때로는 그 이상 저하됩니다.

우리는 모든 일을 올바르게 한 것 같습니다. 부하를 분산시키십시오. 장비가 유휴 상태가 아닙니다. 우리는 마음대로 요청을 나누었지만 여전히 모든 것이 좋지 않았습니다.

• hot_standby_feedback을 활성화하지 않으시겠습니까? 예, 특별히 강력한 이유 없이는 전원을 켜지 않는 것이 좋습니다. 이 트위스트는 마스터 서버에 직접적인 영향을 미치고 그곳에서 autovacuum 작업을 일시 중지하기 때문입니다. 일부 복제본에서 이를 활성화하고 잊어버리면 마스터를 종료하고 애플리케이션에 큰 문제가 발생할 수 있습니다.
• max_standby_streaming_delay를 늘리시겠습니까? 예, 보고서의 경우 이는 사실입니다. XNUMX시간짜리 보고서가 있고 복제 충돌로 인해 보고서가 충돌하는 것을 원하지 않으면 지연 시간을 늘리면 됩니다. 장기 보고서에는 현재 데이터베이스에 도착한 데이터가 필요하지 않습니다. XNUMX시간 동안 사용했다면 이전 데이터 기간 동안 실행하는 것입니다. 그리고 귀하에게는 XNUMX시간 지연이 있든 XNUMX시간 지연이 있든 별 차이가 없습니다. 그러나 귀하는 지속적으로 보고서를 받게 되며 보고서가 떨어지는 데 아무런 문제가 없을 것입니다.
• 당연히 복제본의 긴 세션을 제어해야 합니다. 특히 복제본에서 hot_standby_feedback을 활성화하기로 결정한 경우 더욱 그렇습니다. 무슨 일이든 일어날 수 있으니까요. 우리는 개발자가 요청을 테스트할 수 있도록 이 복제본을 개발자에게 제공했습니다. 그는 미친 요청을 썼습니다. 그는 그것을 발사하고 차를 마시러 나갔고 우리는 확고한 스승을 얻었습니다. 아니면 거기에 잘못된 응용 프로그램을 넣었을 수도 있습니다. 상황은 다양합니다. 복제본의 세션은 마스터에서와 마찬가지로 주의 깊게 모니터링해야 합니다.
• 그리고 복제본에 대해 빠르고 긴 쿼리가 있는 경우 이 경우에는 쿼리를 분할하여 로드를 분산하는 것이 좋습니다. Streaming_delay에 대한 링크입니다. 빠른 경우에는 복제 지연이 작은 복제본 하나를 사용하세요. 장기 실행 보고 요청의 경우 6시간 또는 하루 지연될 수 있는 복제본을 보유하세요. 이것은 완전히 정상적인 상황입니다.

같은 방식으로 결과를 제거합니다.

• 부풀어 오른 테이블을 찾습니다.
• 그리고 우리에게 가장 편리한 도구를 사용하여 압축합니다.

두 번째 이야기는 여기서 끝납니다. 세 번째 이야기로 넘어가겠습니다.

마이그레이션을 수행하는 경우에도 매우 일반적입니다.

• 모든 소프트웨어 제품이 성장하고 있습니다. 이에 대한 요구 사항이 변경되고 있습니다. 어쨌든 우리는 발전하고 싶습니다. 그리고 테이블의 데이터를 업데이트해야 하는 경우가 있습니다. 즉, 개발의 일부로 도입하는 새로운 기능에 대한 마이그레이션 측면에서 업데이트를 실행해야 하는 경우가 있습니다.
• 이전 데이터 형식은 만족스럽지 않습니다. 이제 이 계정에 대한 거래가 있는 두 번째 테이블을 살펴보겠습니다. 그리고 그것이 루블에 있다고 가정하고 정확도를 높이고 코펙으로 수행하기로 결정했습니다. 이를 위해서는 업데이트가 필요합니다. 즉, 필드에 거래 금액을 XNUMX으로 곱해야 합니다.
• 오늘날 우리는 자동화된 데이터베이스 버전 제어 도구를 사용합니다. 의 말을하자 리퀴베이스. 거기에 마이그레이션을 등록합니다. 우리는 테스트 베이스에서 이를 테스트합니다. 모든 것이 괜찮습니다. 업데이트가 진행되고 있습니다. 잠시 동안 작업이 차단되지만 업데이트된 데이터를 얻습니다. 그리고 이에 대한 새로운 기능을 출시할 수 있습니다. 모든 것이 테스트되고 확인되었습니다. 모든 것이 확인되었습니다.
• 계획된 작업을 수행하고 마이그레이션을 수행했습니다.

다음은 업데이트가 제시된 마이그레이션입니다. 이것은 내 계정 거래이므로 플레이트는 15GB였습니다. 그리고 모든 줄을 업데이트했기 때문에 모든 줄을 다시 작성했기 때문에 업데이트로 테이블 크기를 두 배로 늘렸습니다.

마이그레이션 중에는 이 플레이트에 대한 모든 요청이 대기열에 추가되어 이 업데이트가 완료될 때까지 기다렸기 때문에 이 플레이트에 대해 아무 것도 할 수 없었습니다. 하지만 여기서는 세로축에 있는 숫자에 주목하고 싶습니다. 즉, 마이그레이션 전 평균 요청 시간은 약 5밀리초이고 프로세서 로드는 크며 디스크 메모리를 읽는 블록 작업 수는 7,5개 미만입니다.

마이그레이션을 수행했는데 또 문제가 발생했습니다.

마이그레이션이 성공했지만 다음과 같습니다.

• 이제 이전 기능을 완료하는 데 시간이 더 걸립니다.
• 테이블의 크기가 다시 커졌습니다.
• 서버의 부하가 다시 이전보다 커졌습니다.
• 그리고 물론, 우리는 잘 작동했던 기능을 여전히 고치고 있으며, 조금 개선했습니다.

그리고 이것은 다시 부풀어 올라 우리 삶을 다시 망치게 됩니다.

여기서는 이전 두 사례와 마찬가지로 테이블이 이전 크기로 돌아가지 않음을 보여줍니다. 평균 서버 로드는 적당한 것 같습니다.

그리고 계정이 포함된 테이블을 살펴보면 이 테이블의 평균 요청 시간이 두 배로 늘어난 것을 볼 수 있습니다. 프로세서의 부하와 메모리에서 정렬된 라인 수는 7,5 이상으로 뛰었지만 더 낮았습니다. 그리고 프로세서의 경우 2배, 블록 작업의 경우 1,5배, 즉 서버 성능이 저하되었습니다. 결과적으로 애플리케이션 성능이 저하됩니다. 동시에 통화 수는 거의 같은 수준으로 유지되었습니다.

여기서 가장 중요한 것은 이러한 마이그레이션을 올바르게 수행하는 방법을 이해하는 것입니다. 그리고 그것들은 반드시 이루어져야 합니다. 우리는 이러한 마이그레이션을 꽤 일관되게 수행합니다.

• 이러한 대규모 마이그레이션은 자동으로 발생하지 않습니다. 그들은 항상 통제되어야 합니다.
• 지식이 풍부한 사람의 감독이 필요합니다. 팀에 DBA가 있다면 DBA에게 맡기세요. 그게 그의 직업이에요. 그렇지 않다면 데이터베이스 작업 방법을 아는 가장 경험이 많은 사람에게 맡기십시오.
• 새로운 데이터베이스 스키마는 하나의 열을 업데이트하더라도 항상 단계적으로 준비합니다. 즉, 새 버전의 애플리케이션이 출시되기 전에 미리 준비합니다.
• 업데이트된 데이터를 기록할 새 필드가 추가되었습니다.
• 우리는 데이터를 이전 필드에서 새 필드로 작은 부분으로 전송합니다. 우리는 왜 이런 일을 하는 걸까요? 첫째, 우리는 항상 이 프로세스의 프로세스를 제어합니다. 우리는 이미 너무 많은 배치를 전송했고 너무 많은 배치가 남아 있다는 것을 알고 있습니다.
• 두 번째 긍정적인 효과는 이러한 각 배치 사이에서 트랜잭션을 닫고 새 트랜잭션을 열면 Autovacuum이 플레이트에 따라 작동하고 재사용을 위한 데드라인을 표시할 수 있다는 것입니다.
• 애플리케이션이 실행되는 동안 표시되는 줄의 경우(기존 애플리케이션이 여전히 실행 중임) 새 필드에 새 값을 쓰는 트리거를 추가합니다. 우리의 경우 이는 이전 값에 XNUMX을 곱하는 것입니다.
• 완전히 완고하고 동일한 필드를 원하는 경우 모든 마이그레이션이 완료되고 새 버전의 애플리케이션을 출시하기 전에 필드 이름을 바꾸기만 하면 됩니다. 이전 필드에는 새로운 이름이 부여되고 새 필드에는 이전 필드의 이름이 변경됩니다.
• 그 후에야 새 버전의 애플리케이션을 출시합니다.

동시에 우리는 부풀어 오르지 않을 것이며 성능 측면에서 고통받지 않을 것입니다.

세 번째 이야기는 여기서 끝납니다.

https://github.com/dataegret/pg-utils/blob/master/sql/table_bloat.sql

https://github.com/dataegret/pg-utils/blob/master/sql/table_bloat_approx.sql

이제 첫 번째 이야기에서 언급한 도구에 대해 좀 더 자세히 설명하겠습니다.

bloat를 검색하기 전에 확장 프로그램을 설치해야 합니다. pgstattuple.

귀하가 쿼리를 내놓을 필요가 없도록 우리는 이미 작업에 이러한 쿼리를 작성했습니다. 당신은 그들을 사용할 수 있습니다. 여기에는 두 가지 요청이 있습니다.

• 첫 번째 작업은 작업하는 데 꽤 오랜 시간이 걸리지만 테이블에서 정확한 팽창 값을 보여줍니다.
• 두 번째 방법은 더 빠르게 작동하며 표에 따라 팽창이 있는지 여부를 신속하게 평가해야 할 때 매우 효과적입니다. 또한 Postgres 테이블에는 팽창이 항상 존재한다는 점도 이해해야 합니다. 이는 MVCC 모델의 특징입니다.
• 그리고 대부분의 경우 테이블의 20% 팽창은 정상입니다. 즉, 이 테이블을 걱정하거나 압축할 필요가 없습니다.

쓸모없는 데이터로 가득 찬 테이블을 식별하는 방법을 알아냈습니다.

이제 팽창을 해결하는 방법에 대해 알아보십시오.

• 작은 태블릿과 좋은 디스크, 즉 최대 기가바이트의 태블릿이 있는 경우 VACUUM FULL을 사용하는 것이 가능합니다. 그는 몇 초 동안 테이블 위의 독점 자물쇠를 가져갈 것입니다. 그러나 그는 모든 것을 빠르고 가혹하게 할 것입니다. VACUUM FULL의 기능은 무엇인가요? 테이블에 배타적 잠금을 적용하고 이전 테이블의 라이브 행을 새 테이블에 다시 씁니다. 그리고 결국 그는 그들을 교체합니다. 오래된 파일을 삭제하고 오래된 파일을 새 파일로 교체합니다. 그러나 작업 기간 동안에는 테이블에 대한 배타적 잠금이 필요합니다. 이는 이 테이블에 대해 어떤 작업도 할 수 없음을 의미합니다. 테이블에 쓰거나 읽거나 수정할 수도 없습니다. 그리고 VACUUM FULL은 데이터를 쓰기 위해 추가 디스크 공간이 필요합니다.
• 다음 도구 pg_repack. 원칙적으로는 VACUUM FULL과 매우 유사합니다. 이전 파일의 데이터를 새 파일로 다시 쓰고 테이블에서 교체하기 때문입니다. 그러나 동시에 작업 초기에는 테이블에 대한 배타적 잠금을 수행하지 않고 파일을 교체하기 위해 이미 데이터가 준비된 순간에만 잠금을 수행합니다. 디스크 리소스 요구 사항은 VACUUM FULL의 요구 사항과 유사합니다. 추가 디스크 공간이 필요하며 테라바이트 테이블이 있는 경우 이는 때때로 중요합니다. 그리고 I/O와 적극적으로 작동하기 때문에 프로세서를 많이 사용합니다.
• 세 번째 유틸리티는 pgcompactable. 약간 다른 원리에 따라 작동하기 때문에 리소스에 더 주의를 기울입니다. pgcompacttable의 주요 아이디어는 테이블의 업데이트를 사용하여 모든 활성 행을 테이블의 시작 부분으로 이동한다는 것입니다. 그런 다음 이 테이블에서 진공 상태를 실행합니다. 왜냐하면 시작 부분에는 활성 행이 있고 끝 부분에는 데드 행이 있다는 것을 알고 있기 때문입니다. 그리고 진공 자체가 이 꼬리를 잘라냅니다. 즉, 추가 디스크 공간이 많이 필요하지 않습니다. 동시에 자원 측면에서도 여전히 압박을 받을 수 있습니다.

도구가 있는 모든 것.

더 깊이 파고드는 측면에서 흥미로운 부풀려진 주제를 발견했다면 다음 몇 가지 유용한 링크를 참조하세요.

• https://www.slideshare.net/alexius2Mb/where-is-the-space-postgres - 이것은 내 동료의 보고서입니다. Postgres의 작업과 생활 중에 공간이 어디로 가는지에 대한 일반적인 내용입니다. 그리고 데이터베이스 관리자를 위한 팽창에 관한 매우 방대하고 상세한 기술 자료가 있습니다.
• https://github.com/dataegret/pg-utils – 이것은 데이터베이스 상태를 확인하는 데 유용한 스크립트를 저장하는 저장소에 대한 링크입니다. 여기서 bloat를 검색하는 스크립트를 찾을 수 있습니다.
• 세 번째 и 네번째 표지판을 축소하는 데 도움이 되는 도구에 대한 링크입니다.
• http://blog.dataegret.com/2Mb018/03/postgresql-bloatbusters.html – 이것은 내 동료의 게시물입니다. 그곳에서 그는 관리자와 가까운 수준에서 부풀림을 매우 진지하고 기술적으로 자세히 분석합니다.

나는 개발자들에게 공포스러운 이야기를 보여주려고 더 많은 노력을 기울였습니다. 개발자들은 데이터베이스의 직접적인 고객이고 어떤 행동이 어떤 결과로 이어지는지 이해해야 하기 때문입니다. 나는 성공했으면 좋겠다. 관심을 가져주셔서 감사합니다!

질문

신고해 주셔서 감사합니다! 문제를 식별하는 방법에 대해 이야기하셨습니다. 그들은 어떻게 경고를 받을 수 있습니까? 즉, 일부 외부 서비스에 액세스했기 때문에 요청이 중단되는 상황이 있었습니다. 이것은 단지 거친 조인이었습니다. 작고 무해한 요청이 하루 동안 계속되다가 말도 안되는 일을 시작했습니다. 즉, 당신이 설명하는 것과 매우 유사합니다. 이것을 추적하는 방법은 무엇입니까? 앉아서 어떤 요청이 멈췄는지 계속 지켜보시나요? 이를 어떻게 방지할 수 있나요?

이 경우 이는 회사 관리자의 작업이며 반드시 DBA의 작업은 아닙니다.

저는 관리자입니다.

PostgreSQL에는 매달린 쿼리를 보여주는 pg_stat_activity라는 뷰가 있습니다. 그리고 얼마나 오랫동안 거기에 매달려 있는지 볼 수 있습니다.

5분마다 들어와서 살펴봐야 하나요?

cron을 설정하고 확인하십시오. 장기적인 요청이 있는 경우 편지를 작성하면 끝입니다. 즉, 눈으로 볼 필요 없이 자동화가 가능합니다. 당신은 편지를 받게 될 것이고, 당신은 그것에 반응할 것입니다. 아니면 자동으로 촬영할 수도 있습니다.

이런 일이 발생하는 분명한 이유가 있습니까?

나는 몇 가지를 나열했습니다. 다른 더 복잡한 예. 그리고 오랫동안 대화가 가능합니다.

신고해 주셔서 감사합니다! pg_repack 유틸리티에 대해 명확히 하고 싶었습니다. 독점 잠금을 하지 않으면...

그녀는 독점 잠금을 수행합니다.

... 그러면 잠재적으로 데이터가 손실될 수 있습니다. 이 시간 동안 내 애플리케이션이 아무 것도 기록하지 않아야 합니까?

아니요, 테이블과 원활하게 작동합니다. 즉, pg_repack은 먼저 존재하는 모든 라이브 라인을 전송합니다. 당연히 테이블에 일종의 항목이 발생합니다. 그는 단지 이 포니테일을 던지고 있는 것뿐이다.

즉, 그는 실제로 결국 그렇게 합니까?

결국 그는 이러한 파일을 교환하기 위해 독점 잠금을 사용합니다.

VACUUM FULL보다 더 빠를까요?

VACUUM FULL은 시작하자마자 즉시 독점 잠금을 수행했습니다. 그리고 그가 모든 일을 할 때까지 그는 그녀를 놓아주지 않을 것입니다. 그리고 pg_repack은 파일 교체시에만 배타적 잠금을 취합니다. 지금은 거기에 글을 쓰지 않을 것이지만 데이터는 손실되지 않으며 모든 것이 잘 될 것입니다.

안녕하세요! 당신은 자동차 진공청소기의 작동에 대해 이야기했습니다. 빨간색, 노란색, 녹색 기록 셀이 있는 그래프가 있었습니다. 즉, 노란색입니다. 삭제된 것으로 표시했습니다. 결과적으로 새로운 것이 기록될 수 있습니까?

예. Postgres는 줄을 삭제하지 않습니다. 그는 그런 특이성을 가지고 있습니다. 행을 업데이트하면 이전 행을 삭제된 것으로 표시했습니다. 이 줄을 변경한 트랜잭션의 ID가 거기에 나타나고 새 줄을 작성합니다. 그리고 잠재적으로 이를 읽을 수 있는 세션도 있습니다. 어느 시점에서 그들은 꽤 늙어갑니다. 그리고 autovacuum 작동 방식의 핵심은 이러한 라인을 통과하여 불필요한 것으로 표시한다는 것입니다. 그리고 거기에 데이터를 덮어쓸 수 있습니다.

이해합니다. 그러나 그것은 질문의 내용이 아닙니다. 나는 끝내지 않았다. 테이블이 있다고 가정해 봅시다. 다양한 크기의 필드가 있습니다. 그리고 새로운 것을 삽입하려고 하면 기존 셀에 맞지 않을 수도 있습니다.

아니요, 어떤 경우에도 전체 줄이 업데이트됩니다. Postgres에는 두 가지 데이터 저장 모델이 있습니다. 데이터 유형에서 선택합니다. 테이블에 직접 저장되는 데이터가 있고, tos 데이터도 있습니다. 텍스트, json 등 많은 양의 데이터가 있습니다. 그들은 별도의 접시에 저장됩니다. 그리고 이 태블릿에 따르면 부풀어오르는 것과 동일한 이야기가 발생합니다. 즉, 모든 것이 동일합니다. 단지 별도로 나열되어 있을 뿐입니다.

신고해 주셔서 감사합니다! 기간을 제한하기 위해 명령문 시간 초과 쿼리를 사용할 수 있습니까?

매우 수용 가능합니다. 우리는 이것을 어디에서나 사용합니다. 그리고 자체 서비스가 없기 때문에 원격 지원을 제공하고 클라이언트가 상당히 다양합니다. 그리고 모두가 이것에 완전히 만족합니다. 즉, 확인하는 크론 작업이 있습니다. 세션 기간은 단순히 고객과 합의한 것이며 그 전에는 동의하지 않습니다. 10분이 될 수도 있고, XNUMX분이 될 수도 있습니다. 베이스의 하중과 목적에 따라 다릅니다. 하지만 우리 모두는 pg_stat_activity를 사용합니다.

신고해 주셔서 감사합니다! 귀하의 보고서를 내 지원서에 적용하려고 합니다. 그리고 우리는 어디에서나 거래를 시작하고 모든 곳에서 명확하게 완료하는 것처럼 보입니다. 예외가 있으면 롤백이 계속 발생합니다. 그리고 나서 나는 생각하기 시작했습니다. 결국 트랜잭션이 명시적으로 시작되지 않을 수도 있습니다. 이것은 아마도 소녀에게 보내는 힌트일 것이다. 레코드만 업데이트하면 트랜잭션이 PostgreSQL에서 시작되고 연결이 끊어질 때만 완료됩니까?

지금 애플리케이션 수준에 대해 이야기하고 있다면 사용 중인 드라이버, 사용 중인 ORM에 따라 다릅니다. 거기에는 많은 설정이 있습니다. 자동 커밋을 활성화한 경우 트랜잭션이 시작되고 즉시 닫힙니다.

즉, 업데이트 직후에 닫히는 것인가요?

설정에 따라 다릅니다. 하나의 설정에 이름을 붙였습니다. 이것은 자동 커밋입니다. 그것은 매우 흔한 일입니다. 활성화된 경우 트랜잭션이 열리고 닫힌 것입니다. 명시적으로 "트랜잭션 시작" 및 "트랜잭션 종료"라고 말하지 않고 단순히 세션에 요청을 시작한 경우는 제외됩니다.

안녕하세요! 신고해 주셔서 감사합니다! 데이터베이스가 부풀어 오르고 서버 공간이 부족해 졌다고 가정해 보겠습니다. 이 상황을 해결할 수 있는 도구가 있나요?

서버 공간을 제대로 모니터링해야 합니다.

예를 들어, DBA가 차를 마시러 갔거나 리조트에 있었을 때 등이 있습니다.

파일 시스템이 생성되면 데이터가 기록되지 않는 일종의 백업 공간이 생성됩니다.

완전히 영하이면 어떻게 되나요?

이를 예약된 공간이라고 합니다. 즉, 해제할 수 있으며 생성된 크기에 따라 여유 공간을 얻습니다. 기본적으로 얼마나 많은지 알 수 없습니다. 또 다른 경우에는 재구성 작업을 수행할 수 있는 공간을 확보하기 위해 디스크를 제공합니다. 필요하지 않은 일부 테이블을 삭제할 수 있습니다.

다른 도구가 있나요?

항상 손수 만든 것입니다. 그리고 일부 데이터는 중요하고 일부는 중요하지 않기 때문에 로컬에서 무엇을 하는 것이 가장 좋은지 명확해집니다. 그리고 각 데이터베이스와 이를 사용하는 애플리케이션은 비즈니스에 따라 다릅니다. 항상 현지에서 결정됩니다.

신고해 주셔서 감사합니다! 두 가지 질문이 있습니다. 먼저 트랜잭션이 중단되면 테이블스페이스 크기와 인덱스 크기가 모두 증가한다는 것을 보여주는 슬라이드를 보여 주셨습니다. 그리고 보고서에는 태블릿을 패키징하는 많은 유틸리티가 있었습니다. 지수는 어떻습니까?

그들도 포장합니다.

그런데 공백이 지수에는 영향을 주지 않는 걸까요?

일부는 색인을 사용하여 작동합니다. 예를 들어 pg_rapack, pgcompacttable입니다. 진공은 인덱스를 다시 생성하고 영향을 줍니다. VACUUM FULL을 사용하면 모든 것을 덮어쓰는 것이 아이디어입니다. 즉, 모든 사람에게 작동합니다.

그리고 두 번째 질문. 복제본에 대한 보고서가 왜 복제 자체에 그렇게 많이 의존하는지 이해가 되지 않습니다. 보고서를 읽고 복제를 쓰는 것 같았습니다.

복제 충돌의 원인은 무엇입니까? 프로세스가 진행되는 마스터가 있습니다. 자동차 진공청소 작업이 진행 중입니다. Autovacuum은 실제로 무엇을 수행합니까? 그는 오래된 대사 몇 개를 잘라내고 있습니다. 이때 복제본에 이러한 이전 라인을 읽는 요청이 있고 마스터에서 autovacuum이 이러한 라인을 덮어쓸 수 있는 것으로 표시하는 상황이 발생한 경우 이를 덮어썼습니다. 그리고 데이터 패킷을 수신했습니다. 복제본에서 요청에 필요한 행을 다시 작성해야 할 때 복제 프로세스는 사용자가 구성한 시간 초과를 기다립니다. 그런 다음 PostgreSQL은 무엇이 더 중요한지 결정합니다. 그리고 그에게는 요청보다 복제가 더 중요하므로 그는 복제본에 이러한 변경 사항을 적용하기 위해 요청을 처리할 것입니다.

안드레이, 질문이 있어요. 프레젠테이션 중에 보여주신 이 멋진 그래프는 귀하의 일종의 유용성 작업의 결과입니까? 그래프는 어떻게 만들어졌나요?

이것은 서비스입니다 오크미터.

이거 상업용 제품인가요?

예. 이것은 상업용 제품입니다.

출처 : habr.com