25.6.4 Summary of NDB Cluster Start Phases

25.6.4 NDB Cluster 시작 단계 요약

이 섹션은 NDB Cluster 데이터 노드가 시작될 때 관련되는 단계들을 단순화하여 개괄적으로 설명합니다. 보다 완전한 정보는 NDB Internals Guide 의 NDB Cluster Start Phases에서 확인할 수 있습니다.

이 단계들은 관리 클라이언트에서 node_id STATUS 명령의 출력에 보고되는 내용과 동일합니다(관리 클라이언트에 대한 내용은 Section 25.6.1, “Commands in the NDB Cluster Management Client” 참고). 이러한 시작 단계들은 ndbinfo.nodes 테이블의 start_phase 칼럼에도 보고됩니다.

Start types.

아래 목록과 같이 여러 가지 서로 다른 스타트업 타입 및 모드가 있습니다:

• Initial start.

  클러스터가 모든 데이터 노드에서 깨끗한 파일 시스템으로 시작합니다. 이는 클러스터가 처음으로 시작될 때이거나, 모든 데이터 노드가 --initial 옵션을 사용하여 재시작될 때 발생합니다.

참고

디스크 데이터 파일은 --initial을 사용하여 노드를 재시작할 때 제거되지 않습니다.

• System restart.

  클러스터가 시작되며 데이터 노드에 저장된 데이터를 읽습니다. 이는 클러스터가 사용된 이후에 셧다운 되었고, 클러스터가 이전에 중단되었던 시점부터 작업을 재개하기를 원하는 경우에 발생합니다.

• Node restart.

  클러스터 자체는 실행 중인 상태에서 클러스터 노드를 온라인으로 재시작하는 것입니다.

• Initial node restart.

  노드 재시작과 동일하지만, 노드가 재초기화되고 깨끗한 파일 시스템으로 시작된다는 점이 다릅니다.

Setup and initialization (phase -1).

스타트업 이전에 각 데이터 노드( ndbd 프로세스)는 초기화되어야 합니다. 초기화는 다음 단계들로 구성됩니다:

1. 노드 ID 획득

2. 설정 데이터 가져오기

3. 노드 간 통신에 사용될 포트 할당

4. 설정 파일로부터 얻은 설정에 따라 메모리 할당

데이터 노드 또는 SQL 노드가 매니지먼트 노드에 처음 연결될 때 클러스터 노드 ID를 예약합니다. 다른 노드가 동일한 노드 ID를 할당하지 못하도록 보장하기 위해, 해당 노드가 클러스터에 연결하는 데 성공하고 적어도 하나의 ndbd 가 이 노드가 연결되었음을 보고할 때까지 이 ID는 유지됩니다. 이 노드 ID의 유지(retention)는 해당 노드와 ndb_mgmd 간의 연결에 의해 보호됩니다.

각 데이터 노드가 초기화를 완료하면, 클러스터 스타트업 프로세스를 진행할 수 있습니다. 이 과정에서 클러스터가 거치는 단계들은 다음과 같습니다:

• Phase 0.

  NDBFS 및 NDBCNTR 블록이 시작됩니다. --initial 옵션으로 시작된 데이터 노드에서는 데이터 노드 파일 시스템이 초기화(삭제)됩니다.

• Phase 1.

  이 단계에서는 나머지 모든 NDB 커널 블록이 시작됩니다. NDB Cluster 연결이 설정되고, 블록 간 통신이 구성되며, 하트비트가 시작됩니다. 노드 재시작의 경우 API 노드 연결도 점검됩니다.

참고

일부 노드가 Phase 1에서 멈추고 나머지 노드가 Phase 2에서 멈추는 경우는 종종 네트워크 문제를 의미합니다. 이러한 문제의 한 가지 가능한 원인은 하나 이상의 클러스터 호스트가 여러 네트워크 인터페이스를 가지고 있는 경우입니다. 또 다른 흔한 원인은 클러스터 노드 간 통신에 필요한 TCP/IP 포트가 차단되는 것입니다. 후자에서는 잘못 구성된 방화벽이 자주 원인이 됩니다.

• Phase 2.

  NDBCNTR 커널 블록이 모든 기존 노드의 상태를 점검합니다. 마스터 노드가 선택되고, 클러스터 스키마 파일이 초기화됩니다.

• Phase 3.

  DBLQH 및 DBTC 커널 블록이 서로 간 통신을 설정합니다. 스타트업 타입이 결정되며, 재시작인 경우 DBDIH 블록이 재시작을 수행할 권한을 획득합니다.

• Phase 4.

  Initial start 또는 initial node restart의 경우 리두 로그 파일이 생성됩니다. 이러한 파일의 개수는 NoOfFragmentLogFiles와 같습니다.

  System restart의 경우:

  • 스키마를 읽습니다.
  • 로컬 체크포인트에서 데이터를 읽습니다.
  • 최신 복구 가능 글로벌 체크포인트에 도달할 때까지 모든 리두 정보를 적용합니다.

  Node restart의 경우, 리두 로그의 테일을 찾습니다.

• Phase 5.

  데이터 노드 시작과 관련된 데이터베이스 측 작업의 대부분은 이 단계에서 수행됩니다. Initial start 또는 system restart의 경우 로컬 체크포인트가 실행되고 이어서 글로벌 체크포인트가 실행됩니다. 이 단계 동안 정기적인 메모리 사용량 점검이 시작되며, 필요한 경우 노드 테이크오버가 수행됩니다.

• Phase 6.

  이 단계에서 노드 그룹이 정의되고 설정됩니다.

• Phase 7.

  Arbitrator 노드가 선택되어 동작을 시작합니다. 다음 백업 ID와 백업 디스크 쓰기 속도가 설정됩니다. 이 스타트 페이즈에 도달한 노드는 Started 로 표시됩니다. 이제 API 노드(SQL 노드 포함)가 클러스터에 연결할 수 있습니다.

• Phase 8.

  System restart인 경우, 모든 인덱스가 재구축됩니다(DBDIH에 의해).

• Phase 9.

  노드 내부 스타트업 변수들이 리셋됩니다.

• Phase 100 (OBSOLETE).

  과거에는 노드 재시작 또는 initial node restart 동안 이 시점에서 API 노드가 노드에 연결할 수 있었고 이벤트를 받기 시작할 수 있었습니다. 현재 이 페이즈는 아무 작업도 하지 않습니다.

• Phase 101.

  노드 재시작 또는 initial node restart 시점에서, 이벤트 전달이 클러스터에 합류하는 노드로 넘겨집니다. 새로 합류한 노드는 자신의 프라이머리 데이터를 구독자에게 전달하는 책임을 인계받습니다. 이 페이즈는 SUMA 핸드오버 페이즈라고도 불립니다.

Initial start 또는 system restart에 대해 이 과정이 완료되면 트랜잭션 처리(transaction handling)가 활성화됩니다. 노드 재시작 또는 initial node restart의 경우, 스타트업 프로세스의 완료는 해당 노드가 이제 트랜잭션 코디네이터 역할을 수행할 수 있음을 의미합니다.