Galera 클러스터에서의 커밋 후의 노드 상태

Galera 클러스터에서의 커밋 후의 노드 상태

Galera 설명서에서 설명한 바와 같이 클러스터는 동기식 복제를 사용합니다.그러나 좀 더 자세히 살펴보면, Galera는 "실질적으로" 동기화되어 있을 뿐이라는 진술이 있습니다.노드에서는 커밋이 물리 커밋 대신 "인증"을 통과해야 합니다.애플리케이션 아키텍처를 계획하려면 이 부분을 꼭 이해해야 합니다.

그래서 다음 중 어떤 경우에 해당되는지 알아보겠습니다.

스크립트 A는UPDATE약 5초 정도 걸리는 트랜잭션에서COMMIT몇 초면 끝납니다.스크립트 A가 즉시 종료되면 스크립트 B가 뒤따릅니다.예를 들어 HTTP-POST-Request 후 HTTP-Redirect를 1초 이내에 실행합니다.스크립트 B는 스크립트 A와 다른 노드를 쿼리합니다.

1. 스크립트 B는 다음 명령어를 사용하기 전에UPDATE왜냐하면UPDATE끝나려면 아직 4초 정도 걸립니다.
2. 스크립트 B는 다음 시간 후에 상태를 가져옵니다.UPDATE왜냐하면COMMIT는 모든 노드의 상태가 동기화되면 종료됩니다.

만약 있다면 어떤 것이 사실일까요?또는 동작은 구성에 따라 달라집니까?

이벤트 시퀀스:

-- Node 1:
BEGIN;  (or otherwise start a transaction)
Do some writes
COMMIT;
Node 1 sends the entire transaction (via RBR) to the other nodes.
The other nodes say "OK, there won't be any conflicts".
Node 1 receives the OKs.
Node 1 responds OK to the client.
-- (eventually) on the other nodes:
Actually finish writing the data disk, etc.

각 노드에 대한 라운드 트립은 1개뿐이며, 그 후에 발생합니다.COMMIT제어가 클라이언트에 반환되기 전에, 및 를 참조해 주세요.그것은 갈레라의 비밀 소스입니다.

모든 노드에 데이터가 있고 쓰기가 성공한 후에만 클라이언트가 OK를 받는다는 점에서 동기화됩니다.

일부 작업(일반적으로 I/O 집약적)이 아직 수행되지 않았다는 점에서 이는 '가상'입니다.

예를 들어 '중요 읽기'란 사용자가 블로그 엔트리를 투고하고 그 엔트리를 참조하는 것입니다(단, 다른 슬레이브/노드에 접속하는 경우가 있습니다).그는 그것이 거기에 있기를 기대한다.통상의 레플리케이션에서는, 이 레플리케이션을 정지시키는 깨끗한 방법은 없습니다.SELECT슬레이브가 따라잡을 때까지요갈레라에서는SET wsrep_sync_wait = 31하기 전에SELECT이것에 의해, 「가상」이 「실제」가 됩니다.

'31'은 비트 마스크입니다.필요한 비트가 적을 수 있습니다.wsrep_sync_wait 를 참조해 주세요.

이것으로 노드 A와 노드 B가 무엇을 할 수 있는지 알 수 있는 충분한 정보를 얻을 수 있기를 바랍니다.

와 함께autocommit=ON, 및 noBEGIN글을 생각해 보세요(예:UPDATE)의 존재BEGIN; write; COMMIT;그럼 위의 리스트는 그대로 적용됩니다.

제 생각에는 거래하는데 5초가 너무 길어요.나는 그것의 어느 부분이 가장 긴지 알아내서 최적화하려고 노력할 것이다.

언급URL : https://stackoverflow.com/questions/32456734/what-is-the-node-status-after-a-commit-in-a-galera-cluster