MariaDB Xpand Documentation

Space shortcuts

Page tree

Versions Compared

Old Version 6

changes.mady.by.user Christine Lieu

Saved on

compared with

New Version 7

changes.mady.by.user Christine Lieu

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Published by Scroll Versions from space ML1 and version 6.0
Sv translation
languageen

Table of Contents
stylenone

What is a Group Change?

Xpand uses a distributed group membership protocol to maintain the static set of all nodes known to the cluster and checks that the nodes maintain active communication between each other. Xpand refers to this as a Group.

When the set of nodes changes, there is a change in the group and a Group Change occurs. During a Group Change, Xpand performs tasks to ensure:

  • Data consistency

  • Data availability

  • Effective query distribution  

When Does a Cluster Experience a Group Change?

When Node(s) are Added to a Cluster

A Group Change occurs in conjunction with Expanding Your Cluster's Capacity - Flex Up. Following the Group Change, the Rebalancer will work in the background to move slices to the new node(s). You may notice a slight degradation of performance during that time.

When Node(s) Leave the Cluster

When reducing a cluster’s capacity using the Flex Down procedure, the ALTER CLUSTER REFORM command, used to remove nodes, will invoke a Group Change.

A cluster will also Group Change if node(s) are dropped using the emergency procedure of ALTER CLUSTER DROP.

Additionally, there are several unscheduled events that can cause a cluster to Group Change:

  • A cluster experiences unexpected node failure(s) due to hardware failure, network failure, or kernel panic.

  • A node or node(s) are unable to be reached during a regular heartbeat check of the cluster.

Following a node loss, if the node was not previously soft-failed, the Rebalancer will automatically work to reprotect all data and ensure all data has sufficient copies throughout the cluster. You may notice performance degradation during the reprotect process.

What Happens During a Group Change?

If Xpand detects a change in its group, it will recover automatically as long as a quorum of nodes is available. Your cluster will experience a brief period during which the group is being reformed and the consistency of the database is ensured. Connections from applications to surviving nodes will remain but transactions and queries for those connections will be temporarily paused. 

The cluster can recover from multiple simultaneous node failures if the total number of failed nodes does not exceed the value configured for max_failures.

Details of a Group Change

Group Changes are relatively short (generally measured in seconds), though the duration of each Group Change depends on factors such as the number of containers, workload, and cluster size. The underlying steps of a Group Change are the same, regardless of cluster size and workload.

Cluster Pauses Processing and Performs Internal Operations

When there is a Group Change, the cluster pauses all processing and determines whether a quorum of nodes is available. If true, Xpand performs a series of internal operations in preparation for the new group. Together these operations may take a few seconds, or 10s or seconds, depending on how large the cluster is, how large the database is, and how many transactions were in-process when the Group Change occurred. These steps ensure that the consistency of the database is guaranteed despite having lost a member of the cluster.

  • Initializing subsystems such as flow control and the Rebalancer.

  • Synchronizing global cluster state, including internal system catalogs and global variables.

  • Resolving (or re-resolving) in-process transactions, including rolling back transactions that were interrupted by the Group Change.

  • Invalidating or rebuilding internal caches, such as the Query Plan Cache.

  • Creating recovery queues for downed replicas, or "flipping" queues that are no longer needed.

  • Performing checks for licensing and nResiliency.

  • Resizing device files if necessary.

Cluster Forms New Group

Once the cluster is ready to resume operations, a new group is formed and the clustrix.log will contain an informational message that includes details of the new group:

[INFO] Node 1 has new group effffe: { 1-4 down: 5 }

This example shows a cluster that has re-grouped without node 5. The database then resumes its operations.

What Happens to Processes That Were Running?

If any of the following processes were running when a Group Change occurred, they will be impacted as shown:

Process

Result

Queries (DML and DDL)

If a transaction or statement is interrupted by a Group Change before it has a chance to commit, it will receive an error.

If the global autoretry is true and a transaction was submitted with autocommit enabled, the database will automatically retry. If the retried statements cannot be executed successfully, the application will receive another error.

Replication

Replication processes will automatically restart at the proper binlog location following a Group Change.

Other Connections

Connections to nodes that are still in quorum will be maintained and will not experience any errors. Connections to non-communicative nodes will be lost.

Special Considerations

In-Memory tables may be impacted by a Group Change. See In-Memory Tables for more information.

Sv translation
languageko

Table of Contents
stylenone

그룹 변경(Group Change)이란 무엇입니까?

ClustrixDB는 분산 그룹 멤버십 프로토콜(distributed group membership protocol)을 사용하여 클러스터에 알려진 모든 노드의 정적 집합을 유지 관리하고 노드가 서로 간에 통신을 유지하는지 확인합니다. Clustrix는 이를 그룹(Group)으로 지칭합니다.

노드 집합이 변경되면 그룹이 변경되고 "Group Change"가 발생합니다. "Group Change" 중에 ClustrixDB는 다음을 보장하는 작업을 수행합니다.

  • 데이터 일관성

  • 데이터 가용성

  • 효과적인 쿼리 분산  

클러스터에 "Group Change"가 언제 발생합니까?

노드가 클러스터에 추가될 때

"Group Change"는 Expanding Your Cluster's Capacity - Flex Up과 함께 발생합니다. "Group Change" 후, Rebalancer는 백그라운드에서 새 노드로 슬라이스를 이동합니다. 그 시간 동안 성능이 약간 저하될 수 있습니다.

노드가 클러스터를 빠질 때

Flex Down 절차를 사용하여 클러스터의 용량을 줄이면 노드를 제거하는 데 사용되는 ALTER CLUSTER REFORM 명령이 "Group Change"를 유발합니다.

ALTER CLUSTER DROP의 응급 절차를 사용하여 노드를 삭제하면 클러스터는 "Group Change" 됩니다.

또한, 클러스터에서 "Group Change"를 유발할 수 있는 몇 가지 예기치 않은 이벤트가 있습니다.

  • 클러스터에 하드웨어 장애, 네트워크 장애 또는 커널 패닉으로 인해 예기치 않은 노드 장애가 발생합니다.

  • 노드(들)이 클러스터의 일반적인 하트비트 검사 중에 통신할 수 없습니다.

노드 손실 후 노드가 이전에 "soft-fail" 되지 않은 경우 Rebalancer는 자동으로 모든 데이터를 재보호하고 모든 데이터가 클러스터 전체에 충분한 복사본을 가지고 있는지 확인합니다. 재보호 프로세스 중에 성능이 저하될 수 있습니다.

"Group Change" 중에 어떤 일이 발생합니까?

ClustrixDB가 그룹의 변경을 감지하면 노드의 쿼럼이 사용 가능한 이상 자동으로 복구됩니다. 그룹이 재구성되는 동안 트랜잭션이 일시 중지되고 데이터베이스의 일관성이 유지됩니다. 응용 프로그램에서 정상 노드로 연결은 유지되지만, 해당 연결에 대한 트랜잭션 및 쿼리는 일시적으로 중지됩니다. 

실패한 노드의 총수가 max_failures에 설정한 값을 초과하지 않으면 클러스터는 동시 멀티 노드 장애로부터 복구될 수 있습니다.

"Group Change" 세부 사항

"Group Change" 지속 시간은 컨테이너의 수, 워크로드 및 클러스터 크기와 같은 요소에 따라 달라지지만, 상대적으로 짧습니다 (대략 수(십)초 이내). 클러스터 크기 및 워크로드에 관계없이 "Group Change"의 기본 단계는 동일합니다.

클러스터가 처리를 일시 중지하고 내부 작업을 수행합니다

"Group Change"가 있으면 클러스터는 모든 처리를 일시 중지하고 노드 쿼럼을 사용할 수 있는지를 결정합니다. 사용할 수 있으면 ClustrixDB는 새 그룹을 준비하기 위해 일련의 내부 작업을 수행합니다. 클러스터의 크기, 데이터베이스의 크기 및 "Group Change"가 발생했을 때 진행 중인 트랜잭션 수에 따라 이러한 작업은 함께 수행되는 데 몇 초 또는 십여 초가 걸릴 수 있습니다. 이 단계는 클러스터 멤버를 잃어버렸음에도 불구하고 데이터베이스의 일관성을 보장합니다.

  • 흐름 제어 및 Rebalancer와 같은 하위 시스템 초기화.

  • 내부 시스템 카탈로그 및 전역 변수를 포함하여 글로벌 클러스터 상태 동기화.

  • "Group Change"로 인해 중단된 트랜잭션을 롤백하는 것을 포함하여 인-프로세스(in-process) 트랜잭션을 해결하거나 다시 해결합니다.

  • 쿼리 플랜 캐시와 같은 내부 캐시를 무효화 하거나 다시 작성합니다.

  • 다운된 복제본에 대한 복구 큐를 만들거나 더 이상 필요 없는 큐를 "제거"합니다.

  • 라이센싱 및 nResiliency에 대한 검사를 수행합니다.

  • 필요한 경우 장치 파일의 크기를 조정합니다.

클러스터는 새 그룹을 형성합니다

클러스터가 작업을 재개할 준비가 되면 새 그룹이 형성되고 clustrix.log에는 새 그룹의 세부 사항을 포함하는 정보 메시지가 포함됩니다.

[INFO] Node 1 has new group effffe: { 1-4 down: 5 }

이 예제에서는 노드 5 없이 다시 그룹화된 클러스터를 보여줍니다. 그런 다음 데이터베이스는 작업을 재개합니다.

실행 중인 프로세스는 어떻게 됩니까?

"Group Change"가 발생할 때 다음 프로세스 중 하나라도 실행 중이면 아래에 표시된 대로 영향을 받습니다.

프로세스

결과

쿼리 (DML 및 DDL)

트랜잭션이나 명령문이 변경 사항을 커밋하기 전에 "Group Change"에 의해 중단되면 오류가 발생합니다.

전역 변수 autoretry가 true이고 autocommit이 활성화된 상태로 트랜잭션이 제출되면 데이터베이스는 자동으로 재시도합니다. 다시 시도한 명령문을 성공적으로 실행할 수 없으면 응용 프로그램에 다른 오류가 발생합니다.

복제

복제 프로세스는 "Group Change" 후 적절한 binlog 위치에서 자동으로 다시 시작됩니다.

기타 커넥션

여전히 쿼럼에 있는 노드에 대한 커넥션은 유지되며 오류가 발생하지 않습니다. 통신할 수 없는 노드에 대한 연결은 끊어집니다.

특별 고려 사항

In-Memory 테이블은 "Group Change"의 영향을 받을 수 있습니다. 자세한 내용은 In-Memory Tables를 참조하십시오.