Id

NodeId 는 데이터 노드의 식별시에 사용이 권장되는 매개 변수 이름입니다. 오래된 Id 는 하위 호환성을 계속 지원하지만 현재는 비추천이며, 사용시 경고를 생성합니다. Id 는 MySQL Cluster의 향후 릴리스에서 제거 될 예정입니다.

NodeId

NodeId 는 데이터 노드의 식별시에 사용이 권장되는 매개 변수 이름입니다. Id 는 하위 호환성을 계속 지원하지만 현재는 비추천이며, 사용시 경고를 생성합니다. 또한 MySQL Cluster의 향후 버전에서 제거 될 예정입니다.

ExecuteOnComputer

이것은 [computer] 섹션에 정의 된 하나의 컴퓨터에 설정되어있는 Id 를 참조하십시오.

HostName

이 매개 변수를 지정하면 데이터 노드를 배치하는 컴퓨터의 호스트 이름이 정의됩니다. localhost 이외의 호스트 이름을 지정하려면이 매개 변수 또는 ExecuteOnComputer 중 하나가 필요합니다.

ServerPort

그러나 데이터 노트와 API 노드 (SQL 노드 포함) 사이의 통신을 허용하도록 방화벽에서 특정 포트를 열어야하는 경우, config.ini 파일의 [ndbd] 섹션 또는 (여러 데이터 노드에 대해 이렇게 필요가있는 경우) [ndbd default] 섹션에서이 매개 변수를 필요한 포트 번호로 설정하면 SQL 노드 API 노드 또는 둘 다에서 들어오는 연결을 위해 그 번호의 포트를 열 수 있습니다.

TcpBind_INADDR_ANY

이 매개 변수를 TRUE 또는 1 로 설정하면 IP_ADDR_ANY 가 바인딩 된 모든 위치에서 연결 할 수 있습니다 (자동 생성 연결의 경우). 기본값은 FALSE ( 0 )입니다.

NodeGroup

NodeGroup 매개 변수의 주된 용도는 롤링 재시작을 수행하지 않고 실행중인 MySQL Cluster에 새로운 노드 그룹을 추가하는 것입니다. 그러기 위해서는이를 65536 (최대 값)로 설정합니다. NodeGroup 값은 모든 클러스터 데이터 노드가 아니라 나중에 시작되고 새로운 노드 그룹으로 클러스터에 추가되는 노드에만 설정해야합니다. 자세한 내용은 섹션 18.5.13.3 "MySQL Cluster 데이터 노드의 온라인 추가 : 자세한 예제" 를 참조하십시오.

NoOfReplicas

노드 그룹은 암묵적으로 형성됩니다. 첫 번째 노드 그룹은 노드 ID가 가장 작은 데이터 노드 세트에서 형성된 다음 노드 그룹은 노드 ID가 다음 데이터 노드의 집합으로 형성됩니다 (이하 동일). 예를 들어, 4 개의 데이터 노드가 있고, NoOfReplicas 가 2로 설정되어 있다고합니다. 4 개의 데이터 노드의 ID는 각각 2,3,4 및 5입니다. 이 경우 첫 번째 노드 그룹은 노드 2와 3으로 형성되고, 두 번째 노드 그룹은 노드 4와 5에서 형성됩니다. 하나의 하드웨어 장애로 인해 전체 클러스터가 작동 중지 동일한 노드 그룹의 노드가 같은 컴퓨터에 배치되지 않도록 클러스터를 구성하는 것이 중요합니다.

노드 ID가 지정되어 있지 않으면 데이터 노드의 순서가 노드 그룹의 결정 요인이됩니다. 명시적인 할당이 행해졌는지 여부에 관계없이 관리 클라이언트의 SHOW 명령의 출력에 표시됩니다.

NoOfReplicas 의 기본값은 2입니다. 이것은 대부분의 일반적인 사용 시나리오에서 권장되는 설정입니다.

지정 가능한 최대 값은 4이며, 현재 실제로 지원되는 값은 1과 2뿐입니다.

이 매개 변수의 값은 클러스터의 데이터 노드의 수 등분해야합니다. 예를 들어, 데이터 노드가 2 개의 경우 2 / 3과 2/4는 모두 소수하므로 NoOfReplicas 는 1 또는 2 일 필요가 있습니다. 데이터 노드가 4 개의 경우 NoOfReplicas 는 1, 2 또는 4 일 필요가 있습니다.

DataDir

기본값은 데이터 노드 프로세스의 작업 디렉토리입니다.

FileSystemPath

MySQL Cluster의 권장 디렉토리 계층은 /var/lib/mysql-cluster 가 포함되어 있으며,이 아래에 노드의 파일 시스템 디렉토리가 생성됩니다. 이 하위 디렉토리 이름에는 노드 ID가 포함됩니다. 예를 들어, 노드 ID가 2 인 경우이 서브 디렉토리의 이름은 ndb_2_fs 입니다.

BackupDataDir

데이터 메모리, 인덱스 메모리, 그리고 스트링 메모리

DataMemory 및 IndexMemory 는 실제 레코드와 인덱스를 저장하는 데 사용되는 메모리 세그먼트의 크기를 지정하는 [ndbd] 매개 변수입니다. 이 값을 설정하는 경우, DataMemory 및 IndexMemory 가 어떻게 사용되는지를 이해하는 것이 중요합니다. 이들은 일반적으로 클러스터의 실제 사용 상황을 반영하여 업데이트 할 필요가 있기 때문입니다.

DataMemory

DataMemory 가 할당 한 메모리는 실제 레코드와 인덱스를 모두 저장하는 데 사용됩니다. 각 레코드에는 16 바이트의 오버 헤드가 있습니다. 각 레코드는 128 바이트 페이지 오버 헤드를 포함한 32K 바이트의 페이지에 저장되기 때문에 각 레코드에 추가 금액이 발생합니다 (다음을 참조하십시오). 또한 각 레코드가 하나의 페이지 만 저장되기 때문에 페이지마다 소량의 낭비가 발생합니다.

가변 크기의 테이블 속성은 DataMemory 에서 할당 된 별도의 데이터 페이지에 데이터가 저장됩니다. 가변 길이 레코드는 가변 크기 부분을 참조하기 위해 4 바이트의 추가 오버 헤드를 포함한 고정 크기 부분을 사용합니다. 가변 크기 부분은 2 바이트의 오버 헤드와 특성 당 2 바이트가 포함됩니다.

최대 레코드 크기는 14000 바이트입니다.

DataMemory 에 의해 정의 된 메모리 공간은 순서화 된 인덱스를 저장하는 데 사용됩니다. 여기에는 레코드 당 약 10 바이트가 사용됩니다. 각 테이블 행은 정렬 된 인덱스로 표시됩니다. 사용자들 사이에서 공통적으로 모든 인덱스가 IndexMemory 가 할당 한 메모리에 저장된다는 오해가 있지만, 이것은 올바르지 않습니다. 기본 키 및 고유 해시 인덱스 만이 메모리를 사용합니다. 정렬 된 인덱스는 DataMemory 가 할당 한 메모리를 사용합니다. 그러나 기본 키 또는 고유 해시 인덱스를 만들 때 인덱스 생성 구문에 USING HASH 를 지정하지 않은 경우는 같은 키에 정렬 된 인덱스도 생성됩니다. 이것은 관리 클라이언트에서 ndb_desc -d db_name table_name 를 실행하면 확인할 수 있습니다.

현재 MySQL Cluster에서는 해시 인덱스 파티션 당 최대 512M 바이트를 사용할 수 있습니다. 즉, 경우에 따라서는 ndb_mgm -e "ALL REPORT MEMORYUSAGE"에서 DataMemory 에 큰 공간이 표시되어 있어도 Table is full 오류가 MySQL 클라이언트 응용 프로그램에서 나타날 수 있습니다. 따라서 데이터의 부하가 높은 노드에서 데이터 노드를 다시 시작할 때 문제가 발생할 수 있습니다. CREATE TABLE 에 MAX_ROWS 옵션을 사용하면 MySQL Cluster 테이블에 추가 파티션을 작성하여 해시 인덱스에 사용할 수있는 메모리를 늘리도록 NDB 에 적용 할 수 있습니다. 일반적으로 테이블에 저장하는 것으로 예상되는 행 수의 2 배의 수치를 MAX_ROWS 로 설정하면 충분합니다. MinFreePct 구성 매개 변수를 사용하여 노드 재부팅 문제를 해결 할 수 있습니다. (Bug # 13436216)

DataMemory 에 의해 할당 된 메모리 공간은 32K 바이트의 페이지로 구성된 테이블 조각에 할당됩니다. 각 테이블은 일반적으로 클러스터의 데이터 노드와 같은 수의 조각으로 분할됩니다. 따라서 각 노드는 NoOfReplicas 의 설정과 같은 몇 조각이 있습니다.

페이지의 할당 후 테이블을 삭제하는 이외의 방법으로 빈 페이지 풀로 반환하는 것은 현재 불가능합니다. (이것은 특정 페이지에 할당 된 DataMemory 페이지를 다른 테이블에서 사용할 수없는 것을 의미합니다.) 데이터 노드 복구를 실행하면 모든 레코드가 다른 실행중인 노드에서 빈 파티션 에 삽입되기 때문에 파티션도 압축됩니다.

DataMemory 메모리 공간에는 Undo 정보도 포함되어 있습니다. 업데이트 때마다 변경되지 않은 레코드 복사본이 DataMemory 에 할당됩니다. 정렬 된 테이블 인덱스에도 각 사본에 대한 참조가 포함되어 있습니다. 고유 해시 인덱스는 고유 인덱스 컬럼이 업데이트 된 경우에만 업데이트됩니다. 이 경우 위탁시에 인덱스 테이블에 새 항목이 삽입되어 오래된 항목이 삭제됩니다. 따라서 클러스터를 사용하는 응용 프로그램에 의해 실행되는 대규모 트랜잭션을 처리 할 수​​있는 충분한 메모리를 할당해야합니다. 어쨌든도 다음의 이유로 소수의 대규모 트랜잭션을 실행하는 것보다 많은 수의 작은 트랜잭션을 사용하는 것이 장점이 있습니다.

DataMemory 의 디폴트 값은 80M 바이트입니다. 최소 1M 바이트입니다. 최대 크기는 아니지만 실제로는 제한에 도달하면 프로세스가 스와핑을 시작하지 않도록 최대 크기를 결정해야합니다. 이 제한은 시스템에서 사용 가능한 실제 RAM의 양과 운영 체제가 하나의 프로세스에 commit 할 수 있는 메모리 양에 따라 결정됩니다. 32 비트 운영 체제에서는 보통 프로세스 당 2-4G 바이트로 제한되지만 64 비트 운영 체제에서 더 많은 메모리를 사용할 수 있습니다. 따라서 대규모 데이터베이스에서는 64 비트 운영 체제를 사용하는 것이 좋습니다.

IndexMemory

해시 인덱스의 크기는이 식을 사용하여 계산할 수 있습니다.

             size = (( fragments * 32K) + ( rows * 18)) 
             * replicas

          

fragments 는 조각의 수, replicas 는 복제 수 (보통 2) rows 행의 수입니다. 테이블에 100 만개의 행 8 개 조각 두 복제본이 포함 된 경우 예상되는 인덱스의 메모리 사용량은 여기에 같이 계산됩니다.

            
   ((8 * 32K) + (1000000 * 18)) * 2 = ((8 * 32768) + (1000000 * 18)) * 2
   = (262144 + 18000000) * 2
   = 18262144 * 2 = 36524288 bytes = ~ 35MB

MySQL Cluster NDB 7.2 이상에서는 정렬 된 인덱스의 인덱스 통계가 (활성화되어있는 경우) mysql.ndb_index_stat_sample 테이블에 저장됩니다. 이 테이블은 해시 인덱스가 있기 때문에 이에 따라 인덱스의 메모리 사용량이 추가됩니다. 특정 정렬 된 인덱스의 행수의 상한은 다음과 같이 계산할 수 있습니다.

   sample_size = key_size + ((key_attributes + 1) * 4)
  
   sample_rows = IndexStatSaveSize 
                 * ((0.01 * IndexStatSaveScale * log2 (rows * sample_size)) + 1) 
                 / sample_size

이전 식에서 key_size 은 정렬 된 인덱스 키의 크기 (바이트) key_attributes 은 정렬 된 인덱스 키의 속성 수, rows 는 기본 테이블의 행수입니다.

테이블 t1 에 100 만 개의 행과 2 개의 4 바이트 정수에 대한 ix1 라는 정렬 된 인덱스가 있다고합니다. 또한 IndexStatSaveSize 과 IndexStatSaveScale 이 기본값 (각각 32K 및 100)에 설정되어 있다고합니다. 이전 두 표현식을 사용하여 다음과 같이 계산할 수 있습니다.

   sample_size = 8 + ((1 + 2) * 4) = 20 bytes
  
   sample_rows = 32K 
                 * ((0.01 * 100 * log 2 (1000000 * 20)) + 1) 
                 / 20 
                 = 32768 * ((1 * ~ 16.811) + 1) / 20
                 = 32768 * ~ 17.811 / 20 
                 = ~ 29182 rows

예상되는 인덱스의 메모리 사용량은 2 * 18 * 29182 = 약 1050550 바이트입니다.

IndexMemory 의 디폴트 값은 18M 바이트입니다. 최소는 1M 바이트입니다.

StringMemory

100 이상의 값은 바이트로 해석됩니다.

기본값은 25 (즉, 기본 최대 25 %)입니다.

대부분의 상황에서 기본값으로 충분하지만, 클러스터 테이블의 수가 매우 많다 (1000 개 이상) 경우 오류 773 Out of string memory, please modify StringMemory config parameter : Permanent error : Schema error가 발생할 수 이 때문에, 그 경우는이 값을 늘리도록하십시오. 25 (25 %)이면 너무 것은 아니라 가장 극단적 인 경우를 제외하고이 오류가 다시 발생하지 않습니다.

다음 예제는 하나의 테이블에 메모리가 어떻게 사용되는지를 보여줍니다. 이 테이블 정의에 대해 생각합니다.

 CREATE TABLE example (
   a INT NOT NULL,
   b INT NOT NULL,
   c INT NOT NULL,
   PRIMARY KEY (a)
   UNIQUE (b)
 ) ENGINE = NDBCLUSTER;

각 레코드에 12 바이트의 데이터와 12 바이트의 오버 헤드가 있습니다. NULL 허용 컬럼이없는 경우는 4 바이트의 오버 헤드를 줄일 수 있습니다. 또한 컬럼 a 와 b 에 2 개의 정렬 된 인덱스가 레코드 당 약 10 바이트가 소모됩니다. 기본 테이블에 기본 키의 해시 인덱스가 레코드 당 약 29 바이트가 사용됩니다. b 를 기본 키로하고 a 를 컬럼으로하는 다른 테이블에 의해 UNIQUE 제약 조건이 구현되어 있습니다. 이 다른 테이블에서는 8 바이트의 레코드 데이터와 12 바이트의 오버 헤드뿐만 아니라, example 테이블에서 레코드 당 29 바이트의 인덱스 메모리가 추가로 소모됩니다.

따라서 100 만개의 레코드에 대한 기본 키 및 고유 제약의 해시 인덱스를 처리하려면 58M 바이트의 인덱스 메모리가 필요합니다. 또한 기본 테이블 레코드 고유 인덱스 테이블, 그리고 두 개의 정렬 된 인덱스 테이블에 64M 바이트가 필요합니다.

해시 인덱스가 상당한 메모리를 차지하지만, 데이터에 대한 액세스는 매우 빨라집니다. 이들은 MySQL Cluster는 고유 제약을 처리하는 데 사용됩니다.

현재 유일한 분할 알고리즘은 해시이며, 정렬 된 인덱스는 각 노드에 로컬로 사용됩니다. 따라서 일반적인 경우 정렬 된 인덱스를 사용하여 고유 제약을 처리 할 수​​ 없습니다.

IndexMemory 및 DataMemory 모두에서 중요한 점은 각 노드 그룹의 모든 데이터 메모리와 인덱스 메모리의 합이 데이터베이스의 총 크기가 될 것입니다. 각 노드 그룹은 복제 된 정보를 저장하는 데 사용되므로 두 개의 복제본을 포함하는 노드가 4 개있는 경우, 2 개의 노드 그룹이 생성됩니다. 따라서 사용 가능한 데이터 메모리의 총 데이터 노드마다 2 * DataMemory 입니다.

모든 노드에서 DataMemory 및 IndexMemory 값을 동일하게 설정하는 것이 좋습니다. 데이터의 분포는 클러스터의 모든 노드에 균등이기 때문에 각 노드에서 사용할 수있는 공간의 최대 크기는 클러스터 내에서 가장 작은 노드의 최대 크기와 동일합니다.

DataMemory 및 IndexMemory 는 변경할 수 있지만,이 중 하나를 줄이는 것은 위험합니다. 이 경우 노드 또는 MySQL Cluster 전체 메모리 공간의 부족으로 다시 시작하지 못할 가능성이 높아집니다. 이 값을 늘리는 것은 문제가되지 않지만 이러한 업그레이드는 소프트웨어 업그레이드와 같은 방법으로 할 것을 권장합니다. 즉, 먼저 구성 파일을 업데이트 한 다음 관리 서버를 시작하고 각 데이터 노드를 차례로 다시 시작합니다.

MinFreePct DataMemory 및 IndexMemory 를 포함한 데이터 노드 자원의 일정 비율 (기본적으로 5 %)는 데이터 노드가 재시작 할 때 그 메모리를 소모하지 않도록 여분으로 남아 있습니다. 이것은 MinFreePct 데이터 노드 구성 매개 변수를 사용하여 조정할 수 있습니다 (기본값은 5).

MaxNoOfConcurrentTransactions

트랜잭션 레코드는 개별 MySQL 서버에 할당됩니다. MySQL 서버에 각 연결은 하나의 트랜잭션 레코드와 연결 액세스되는 테이블마다 추가 트랜잭션 개체가 필요합니다. 즉, 클러스터의 트랜잭션 총 수의 타당한 최소 값을 다음과 같이 나타낼 수 있습니다.

 MinTotalNoOfConcurrentTransactions =
     (maximum number of tables accessed in any single transaction + 1)
     * number of SQL nodes

클러스터를 사용하는 10 개의 SQL 노드가 있다고합니다. 10 개의 테이블이 관여 한 번 결합에는 11 개의 트랜잭션 레코드가 필요합니다. 트랜잭션 내에 이러한 결합이 10 회있는 경우,이 트랜잭션에는 MySQL 서버 당 10 * 11 = 110 개의 트랜잭션 레코드 (또는 총 110 * 10 = 1100 개의 트랜잭션 레코드)가 필요합니다. 각 데이터 노드는 MinTotalNoOfConcurrentTransactions / 데이터 노드가 처리됩니다. 이 경우, 4 개의 데이터 노드를 포함 MySQL Cluster에서는 각 데이터 노드의 MaxNoOfConcurrentTransactions 를 1100/4 = 275으로 설정하는 것입니다.또한 하나의 노드 그룹에서 모든 병렬 트랜잭션에 대응할 수 있도록함으로써 장애 복구를 제공합니다. 즉, 각 데이터 노드의 MaxNoOfConcurrentTransactions을 MinTotalNoOfConcurrentTransactions / 노드 그룹 수와 같은 수의 트랜잭션에 대응할 수있는 충분한 수를 설정합니다. 이 클러스터에 노드 그룹이 하나만있는 경우 MaxNoOfConcurrentTransactions 1100 (전체 클러스터의 병렬 트랜잭션의 수와 동일)로 설정하도록하십시오.

또한 각 트랜잭션에 적어도 하나의 조작이 관여합니다. 따라서 MaxNoOfConcurrentTransactions 에 설정하는 값은 항상 MaxNoOfConcurrentOperations 값 이하로합니다.

이 매개 변수는 모든 클러스터 데이터 노드에 같은 값으로 설정해야합니다. 이것은 데이터 노드의 기능 정지시에 잔존하는 가장 오래된 노드가 작동 중지 된 노드에서 실행 된 트랜잭션의 상태를 다시 작성하는 것입니다.

롤링 재시작을 사용하여이 값을 변경할 수 있지만 실행중인 클러스터의 트래픽은 발생하는 트랜잭션이 신구 중 낮은 수준을 넘지 않는 정도로해야합니다.

기본값은 4096입니다

MaxNoOfConcurrentOperations

이 매개 변수의 값은 트랜잭션의 수와 크기에 맞게 조정하는 것이 좋습니다. 약간 조작과 레코드 만 관여하지 않는 트랜잭션을 실행하는 경우 일반적으로이 매개 변수의 기본값으로 충분합니다. 많은 레코드가 참여하는 대규모 트랜잭션을 수행하는 경우 일반적으로 그 값을 늘려야합니다.

클러스터 데이터를 업데이트하는 각 트랜잭션은 트랜잭션 코디네이터와 실제 업데이트가 실행되는 노드 모두에서 레코드가 유지됩니다. 이러한 레코드에는 롤백, 잠금 큐 및 기타 목적에 사용하는 Undo 레코드를 찾기 위해 필요한 상태 정보가 포함되어 있습니다.

이 매개 변수는 최소한 트랜잭션에서 동시에 업데이트되는 레코드의 수를 클러스터 데이터 노드의 수로 나눈 값으로 설정하도록하십시오. 예를 들어, 4 개의 데이터 노드가 클러스터에서 트랜잭션을 사용하여 100 만건의 병렬 업데이트를 처리 할 것으로 예상되는 경우에는이 값을 1000000/4 = 250000로 설정합니다. 장애 복구 능력을 제공 할 수 있도록이 매개 변수를 각 데이터 노드에서 노드 그룹의 부하를 처리 할 수있는 충분한 크기의 값으로 설정할 것을 권장합니다. 즉, 병렬 작업의 총 수 / 노드 그룹의 수 와 같은 값으로 설정하도록하십시오. (노드 그룹이 하나의 경우 이것은 전체 클러스터의 병렬 작업의 총 수와 동일합니다.)

각 트랜잭션은 항상 하나의 조작이 관여하고 있기 때문에 MaxNoOfConcurrentOperations 값은 항상 MaxNoOfConcurrentTransactions 값 이상합니다.

잠금을 설정하는 읽기 쿼리도 작업 레코드가 생성됩니다. 노드 사이의 분포가 완전하지 않은 경우에 대응할 수 있도록 각 노드에 어느 정도의 추가 공간이 할당됩니다.

쿼리에 고유 해시 인덱스가 사용되면 실제로 트랜잭션의 레코드 당 2 개의 작업 레코드가 사용됩니다. 첫 번째 레코드는 인덱스 테이블의 읽기를 나타내며, 두 번째는 기본 테이블에 대한 작업을 처리합니다.

기본값은 32768입니다.

이 매개 변수는 실제로는 개별적으로 구성 할 수있는 두 가지 값을 처리합니다. 이들 중 첫 번째는 트랜잭션 코디네이터에 의해 배치하는 작업 레코드 수를 지정합니다. 두 번째 부분은 데이터베이스에 로컬로 저장하는 작업 레코드 수를 지정합니다.

8 노드 클러스터에서 실행되는 매우 큰 트랜잭션은 그 트랜잭션에 참여하는 읽기, 업데이트 및 삭제와 같은 수의 작업 레코드가 트랜잭션 코디네이터에 필요합니다. 그러나 이러한 작업 레코드는 8 개의 노드에 분산되어 있습니다. 따라서 하나의 매우 큰 거래를 위해 시스템을 구성 할 필요가있는 경우,이 두 부분을 따로 구성하는 것이 좋습니다. MaxNoOfConcurrentOperations 는 항상 노드의 트랜잭션 코디네이터 부분 작업 레코드 수를 계산하는 데 사용됩니다.

작업 레코드 메모리 요구 사항을 고려하는 것도 중요합니다. 이들은 레코드 당 약 1K 바이트를 소모합니다.

MaxNoOfLocalOperations

기본적으로이 매개 변수는 1.1 * MaxNoOfConcurrentOperations 으로 계산됩니다. 이것은 많은 동시 트랜잭션을 포함하고, 그 모두가 대규모가 아닌 시스템에 적합합니다. 한 번에 하나의 매우 큰 트랜잭션이 실행되어 다수의 노드가있는 경우이 매개 변수를 명시 적으로 지정하고 기본을 무시하는 것이 좋습니다.

MaxDMLOperationsPerTransaction

이 매개 변수는 트랜잭션의 크기를 제한합니다. 이것은보다 많은 DML 작업이 필요할 경우 트랜잭션이 중단됩니다. 트랜잭션 당 최소 조작 수는 32이지만, MaxDMLOperationsPerTransaction 를 0으로 설정하면 트랜잭션 당 DML 작업의 수에 대한 제한을 해제 할 수 있습니다. 최대 (디폴트)은 4294967295입니다.

트랜잭션의 임시 저장소 다음의 일련의 [ndbd] 매개 변수는 클러스터 트랜잭션의 일부인 문 실행시 임시 저장소를 결정하는 데 사용됩니다. 이 문이 완료되고 클러스터가 커밋 또는 롤백을 대기하고있을 때, 모든 레코드가 해제됩니다.

이러한 매개 변수의 기본값은 대부분의 상황에 적합합니다. 그러나 많은 수의 행 또는 조작이 관여하는 트랜잭션을 지원해야하는 경우 값을 늘려 시스템의 병렬성을 높일 필요가있을 수 있습니다. 한편, 비교적 작은 트랜잭션을 필요로하는 응용 프로그램은이 값을 줄여 메모리를 절약 할 수 있습니다.

MaxNoOfConcurrentIndexOperations

고유 해시 인덱스를 사용하는 쿼리는 쿼리의 실행 단계에서 다른 임시 작업 레코드 세트가 사용됩니다. 이 매개 변수는 레코드 풀의 크기를 설정합니다. 따라서이 레코드는 쿼리의 일부를 실행하는 동안에 만 할당됩니다. 이 부분의 실행이 완료된 직후에 레코드가 해제됩니다. 중지와 커밋을 처리하는 데 필요한 상태에서는 정상 작동 레코드가 처리 된 풀 크기는 MaxNoOfConcurrentOperations 파라미터로 설정됩니다.

이 매개 변수의 기본값은 8192입니다. 고유 해시 인덱스를 사용하여 매우 높은 병렬성을 실현시키는 드문 경우에만이 값을 늘려야합니다. 클러스터에 높은 수준의 병렬 처리가 필요하지 않은 DBA가 확신하는 경우 작은 값을 사용하여 메모리를 절약 할 수 있습니다.

MaxNoOfFiredTriggers

MaxNoOfFiredTriggers 의 기본값은 4000입니다. 대부분의 상황에서는 이것으로 충분합니다. 경우에 따라서는 클러스터에 병렬성은 그다지 필요 없다고 DBA가 확신하는 경우 값을 줄일 수 있습니다.

고유 해시 인덱스에 영향을주는 작업을 수행 할 때 레코드가 생성됩니다. 고유 해시 인덱스를 사용하여 테이블의 레코드를 삽입 또는 삭제하거나 고유 한 해시 인덱스의 일부인 열을 업데이트 할 때 인덱스 테이블에서 삽입 또는 삭제가 발생합니다. 생성 된 레코드는이 인덱스 테이블 작업을 발생시킨 원래 작업의 완료를 기다리는 동안 인덱스 테이블 조작을 나타내는 데 사용됩니다. 이 작업은 단기간이지만, 고유의 해시 인덱스 세트를 포함한 기본 테이블에 대해 다수의 병렬 쓰기 작업이 이루어지는 상황에서 레코드 풀에 많은 레코드를 필요로 할 수 있습니다.

TransactionBufferMemory

이 매개 변수의 영향을받는 메모리는 인덱스 테이블의 업데이트와 고유 인덱스를 읽을 때 발생하는 작업을 추적하는 데 사용됩니다. 이 메모리는 이러한 조작 키 및 컬럼 정보를 저장하는 데 사용됩니다. 이 매개 변수의 값을 기본값에서 변경할 필요가있는 것은 매우 드문 경우뿐입니다.

TransactionBufferMemory 의 기본값은 1M 바이트입니다.

일반적인 읽기 및 쓰기 작업에서도 비슷한 버퍼가 사용되지만 그 사용 기간은 더 짧아집니다. 컴파일시의 파라미터 ZATTRBUF_FILESIZE ( ndb/src/kernel/blocks/Dbtc/Dbtc.hpp 에 있습니다)은 4000 * 128 바이트 (500K 바이트)로 설정되어 있습니다. 키 정보의 유사한 버퍼 ZDATABUF_FILESIZE (이것도 Dbtc.hpp 에 있습니다)은 4000 * 16 = 62.5K 바이트의 버퍼 공간이 포함되어 있습니다. Dbtc 트랜잭션의 조정을 취급하는 모듈입니다.

스캔 및 버퍼링 ( ndb/src/kernel/blocks/Dblqh/Dblqh.hpp 의) Dblqh 모듈은 읽기 및 업데이트에 영향을 미치는 추가 [ndbd] 매개 변수가 있습니다. 여기에는 기본적으로 10000 * 128 바이트 (1250K 바이트)로 설정되는 ZATTRINBUF_FILESIZE 와 기본적으로 10000 * 16 바이트 (약 156K 바이트)의 버퍼 공간에 설정되는 ZDATABUF_FILE_SIZE 가 포함되어 있습니다. 지금까지 이러한 컴파일시 제한 중 하나를 늘릴 것을 나타내는 사용자의보고 또는 당사의 대규모 테스트의 결과가 없습니다.

MaxNoOfConcurrentScans

이 매개 변수는 클러스터에서 실행할 수있는 병렬 스캔의 수를 제어하는 데 사용됩니다. 각 트랜잭션 코디네이터는이 매개 변수에 정의 된 수의 병렬 스캔을 할 수 있습니다. 각 검색 쿼리는 모든 파티션을 병렬로 스캔 실행됩니다. 각 파티션 스캔은 파티션이 배치되는 노드의 스캔 레코드가 사용됩니다. 레코드 수는이 파라미터 값에 노드의 수를 곱한 값입니다. 클러스터는 클러스터의 모든 노드에서 동시에 발생한 MaxNoOfConcurrentScans 개의 스캔을 유지할 수 있습니다.

스캔은 실제로 두 가지 경우에 실행됩니다. 이들 중 첫 번째 케이스는 쿼리를 처리하기위한 해시 또는 정렬 된 인덱스가 존재하지 않을 때 발생합니다. 이 경우 전체 테이블 스캔을 실행하면 쿼리가 실행됩니다. 두 번째 사례는 쿼리를 지원하는 해시 인덱스가 존재하지 않고 정렬 된 인덱스가 존재하는 경우에 발생합니다. 정렬 된 인덱스의 사용은 병렬 범위 스캔의 실행을 의미합니다. 이 순서는 로컬 파티션에서만 유지되므로, 모든 파티션에서 인덱스 스캔을 수행해야합니다.

MaxNoOfConcurrentScans 의 기본값은 256입니다. 최대 값은 500입니다.

MaxNoOfLocalScans

많은 검사가 완전히 병렬화되어 있지 않은 경우의 로컬 스캔 레코드 수를 지정합니다. 로컬 스캔 레코드 수를 지정하지 않은 경우에는 다음과 같이 계산됩니다.

4 * MaxNoOfConcurrentScans * [# data nodes] + 2

최소값은 32입니다.

BatchSizePerLocalScan

이 매개 변수는 병렬 스캔 작업을 처리하는 데 사용되는 잠금 레코드 수를 계산하는 데 사용됩니다.

BatchSizePerLocalScan 은 SQL 노드로 정의되는 BatchSize 과 깊은 관계가 있습니다.

LongMessageBuffer

이것은 개별 노드와 노드간에 메시지를 전달하는 데 사용되는 내부 버퍼입니다. 기본은 64M 바이트입니다. (MySQL Cluster NDB 7.3.5 이전에는, 이것은 4M 바이트였습니다.)

대부분의 경우이 매개 변수를 기본값에서 변경할 필요가 없습니다.

MaxParallelScansPerFragment

순차 처리의 대기가 시작되기 전에 허용되는 병렬 스캔 ( TUP 스캔 및 TUX 스캔)의 최대 수를 구성 할 수 있습니다. 이것을 늘려 다수의 스캔을 병렬로 실행할 때 사용되지 않는 CPU를 이용하여 성능을 향상시킬 수 있습니다.

MySQL Cluster NDB 7.3 이상에서는이 매개 변수의 기본값은 256입니다.

NoOfFragmentLogFiles

이 매개 변수는 노드의 Redo 로그 파일의 수 (즉, Redo 로그에 할당 된 공간의 양)을 설정합니다. Redo 로그 파일은 링 형태로 구성되기 때문에 세트의 처음과 마지막 로그 파일 (각각 " head " 와 " tail " 로그 파일이라고도 함)이 교차하지 않는 것이 매우 중요합니다. 이들이 서로 다가 너무 새 로그 레코드를 추가 할 여유가 없기 때문에 노드는 업데이트를 포함한 모든 트랜잭션을 중단하기 시작합니다.

Redo 로그 레코드가 삽입 된 후 필요한만큼의 로컬 체크 포인트가 완료 될 때까지 삭제되지 않습니다. (MySQL Cluster NDB 7.3 이상에서는 2 개의 로컬 체크 포인트 만 필요). 체크 포인트의 빈도는이 장에서 별도로 설명하는 특정 구성 매개 변수 세트에 의해 결정됩니다.

기본 매개 변수 값은 16입니다. 이것은 기본적으로 16M 바이트의 파일 4 개가 16 세트 (총 1024M 바이트) 있음을 의미합니다. 개별 로그 파일의 크기는 FragmentLogFileSize 매개 변수를 사용하여 구성 할 수 있습니다. 많은 업데이트가 필요한 시나리오에서는 Redo 로그에 충분한 공간을 제공하기 위해, NoOfFragmentLogFiles 값을 300 이상으로 설정해야하는 경우가 있습니다.

체크 포인트가 늦게 데이터베이스에 기록이 많기 때문에 로그 파일이 가득 복구에 영향을주지 않고 로그의 끝을 절단 할 수없는 경우 모든 업데이트 트랜잭션이 내부 오류 코드 410 "Out of log file space temporarily " 에 의해 중지됩니다. 이 상태는 체크 포인트가 완료 비상 로그 전에 이동할 수있을 때까지 계속됩니다.

FragmentLogFileSize

이 매개 변수를 설정하면 Redo 로그 파일의 크기를 직접 제어 할 수 있습니다. 이것은 MySQL Cluster가 부하가 높은 상태에서 실행하고 조각 로그 파일을 닫을 때까지 시간이 걸려 새로운 파일을 열 수 없습니다. (한 번에 열 조각 로그 파일은 2 개 뿐이다) 경우에 편리합니다. 조각 로그 파일의 크기를 늘리면 클러스터에서 새로운 조각 로그 파일을 열어야까지의 시간이 길어집니다. 이 매개 변수의 기본값은 16M입니다.

조각 로그 파일의 자세한 내용은 NoOfFragmentLogFiles 의 설명을 참조하십시오.

InitFragmentLogFiles

기본적으로 데이터 노드의 초기 부팅 실행시 조각 로그 파일이 띄엄 띄엄 생성됩니다. 즉, 사용하는 운영 체제 및 파일 시스템은 반드시 모든 바이트가 디스크에 기록되는 것은 아닙니다. 그러나이 매개 변수를 사용하면 사용되는 플랫폼과 파일 시스템의 유형에 관계없이이 동작을 재정의하고 모든 바이트가 강제적으로 기입하도록 설정할 수 있습니다. InitFragmentLogFiles 는 두 값 중 하나를 취합니다.

MaxNoOfOpenFiles

이 매개 변수는 열린 파일에 할당 내부 스레드 수의 상한을 설정합니다. 이 매개 변수의 변경이 필요한 상황이 발생했을 경우, 그것을 버그로보고하도록하십시오 .

기본값은 0입니다.그러나이 매개 변수에 설정할 수있는 최소값은 20입니다.

InitialNoOfOpenFiles

이 매개 변수는 열린 파일에 할당 초기 내부 스레드 수를 설정합니다.

기본값은 27입니다.

MaxNoOfSavedMessages

이 매개 변수는 이전 파일을 덮어 쓰기 전에 유지되는 추적 파일의 최대 개수를 설정합니다. 추적 파일은 어떤 이유로 노드가 충돌 할 때 생성됩니다.

기본값은 25 개의 추적 파일입니다

MaxLCPStartDelay

데이터 노드의 병렬 복구는 사실 테이블 데이터 만 병렬로 복사되고 동기화됩니다. 사전 정보와 체크 포인트 정보 등의 메타 데이터의 동기화는 순차적으로 이루어집니다. 또한 사전 및 체크 포인트 정보 복구는 로컬 체크 포인트의 실행과 병렬로 실행할 수 없습니다. 즉, 많은 데이터 노드를 동시에 시작하거나 다시 시작 할 때 데이터 노드가 로컬 체크 포인트를 실행하는 동안 기다려야 노드 복구 시간이 길어질 수 있습니다.

더 (경우에 따라서는 모든) 데이터 노드에서 메타 데이터의 동기화를 완료 할 수 있도록 로컬 체크 포인트의 지연을 강제 할 수 있습니다. 각 데이터 노드에서 메타 데이터 동기화가 완료된 후에는 로컬 체크 포인트의 실행 중에도 모든 데이터 노드에 병렬로 테이블 데이터를 복구 할 수 있습니다. 이러한 지연을 강제하려면 MaxLCPStartDelay 을 설정합니다. 이것은 데이터 노드에서 메타 데이터의 동기화가 계속되고있는 동안 클러스터가 로컬 체크 포인트의 시작을 기다리는 초 수를 결정합니다. 이 매개 변수는 모든 데이터 노드에서 동일하도록 config.ini 파일의 [ndbd default] 섹션에 설정하도록하십시오. 최대 값은 600, 기본값은 0입니다.

LcpScanProgressTimeout

로컬 체크 포인트의 조각 스캔 워치 독은 로컬 체크 포인트의 일부로 실행되는 각 조각 스캔이 진행되고 있는지 정기적으로 확인하고 특정 시간이 경과해도 진행하지 않으면 그 노드를 종료합니다. MySQL Cluster NDB 7.3.3 이전에는이 ​​간격은 60 초였습니다 (Bug # 16630410). MySQL Cluster NDB 7.3.3 이상에서 LcpScanProgressTimeout 데이터 노드 구성 매개 변수를 사용하여이 간격을 설정할 수 있습니다. 이것은 LCP의 조각 스캔 워치 독 노드가 종료되기 전에 로컬 체크 포인트의 정체가 허용되는 최대 시간을 설정합니다.

기본값은 60 초입니다 (이전 릴리스와의 호환성이 있습니다). 이 매개 변수를 0으로 설정하면 LCP의 조각 스캔 워치 독을 완전히 비활성화됩니다.

메타 데이터 오브젝트 다음의 일련의 [ndbd] 매개 변수는 인덱스, 이벤트 및 클러스터 간 복제에 사용되는 속성 테이블, 인덱스 및 트리거 오브젝트의 최대 개수를 정의하는 데 사용되는 메타 데이터 개체 풀 크기를 정의합니다. 이들은 클러스터에 대한 ' 추천 ' 역할 만하며, 지정되지 않은 것은 모두 표시된 기본값으로 돌아갑니다.

MaxNoOfAttributes

이 매개 변수는 클러스터 정의 할 수있는 속성의 최대 권장 개수를 설정합니다. MaxNoOfTables 뿐만 아니라 엄격한 제한의 역할을위한 것이 아닙니다.

(오래된 MySQL Cluster 릴리스에서는이 매개 변수는 특정 작업에 대한 엄격한 제한으로 간주 할 수있었습니다.이 때문에 MySQL Cluster 복제에 복제 할 수 이상의 테이블을 만들 때 문제가 발생하고 MaxNoOfAttributes 를 보다 많은 속성을 만든 (상황에 따라 할 수없는) 때 혼란을 초래할 수있었습니다.)

기본값은 1000입니다. 지정 가능한 최소 값은 32입니다. 최대는 4294967039입니다. 모든 메타 데이터가 서버에서 완전히 복제되기 때문에 각 속성은 노드 당 200 바이트 정도의 스토리지를 소비합니다.

MaxNoOfAttributes 를 설정할 때 향후 실행 가능성이있는 ALTER TABLE 문을 사전에 준비하는 것이 중요합니다. 이것은 클러스터 테이블에서 ALTER TABLE 을 실행하는 동안 원래의 테이블에 포함 된 3 배나 많은 특성이 사용되기 때문이고,이 숫자의 2 배를 허용하는 것이 좋습니다. 예를 들어, 속성의 수가 가장 많다 ( greatest_number_of_attributes ) MySQL Cluster 테이블에 100 개의 속성이있는 경우, MaxNoOfAttributes 의 적절한 초기 값은 6 * greatest_number_of_attributes = 600 입니다.

또한 테이블 당 평균 속성 수를 예측하고 그것에 MaxNoOfTables 를 바르기도 좋습니다. 이 값이 이전 단락에서 얻어진 값보다 크면 큰 값을 사용하도록하십시오.

MaxNoOfTables

테이블 개체는 클러스터의 각 테이블 및 고유 해시 인덱스마다 할당됩니다. 이 매개 변수는 클러스터 전체의 테이블 오브젝트의 최대 권장 개수를 설정합니다. MaxNoOfAttributes 뿐만 아니라 엄격한 제한의 역할을위한 것이 아닙니다.

(오래된 MySQL Cluster 릴리스에서는이 매개 변수는 특정 작업에 대한 엄격한 제한으로 간주 할 수있었습니다.이 때문에 MySQL Cluster 복제에 복제 할 수 이상의 테이블을 만들 때 문제가 발생하고 MaxNoOfTables 을 개 이상의 테이블을 만든 (상황에 따라 할 수없는) 때 혼란을 초래할 수있었습니다.)

BLOB 데이터 형식의 각 속성은 BLOB 데이터의 대부분을 저장하기 위해 추가 테이블이 사용됩니다. 테이블의 총 수를 정의 할 때 이러한 테이블도 고려할 필요가 있습니다.

이 매개 변수의 기본값은 128입니다. 최소값은 8, 최대 값은 20320입니다. 각 테이블 객체는 노드 당 약 20K 바이트를 소모합니다.

MaxNoOfOrderedIndexes

클러스터의 정렬 된 인덱스에 대해 인덱스 된 내용과 스토리지 세그먼트를 기술하는 객체가 할당됩니다. 기본적으로 그렇게 정의 된 각 인덱스에 따라 정렬 된 인덱스도 정의됩니다. 개별 고유 인덱스 및 기본 키는 정렬 된 인덱스와 해시 인덱스가 모두 포함되어 있습니다. MaxNoOfOrderedIndexes 은 시스템에서 한 번에 사용할 수있는 순서화 된 인덱스의 총 수를 설정합니다.

이 매개 변수의 기본값은 128입니다. 각 인덱스 객체는 노드 당 약 10K 바이트의 데이터를 소비합니다.

MaxNoOfUniqueHashIndexes

기본 키가 아닌 개별 고유 인덱스는 고유 키를 인덱스 된 테이블의 기본 키에 매핑하는 전용 테이블이 할당됩니다. 기본적으로 개별 고유 인덱스에 정렬 된 인덱스도 정의됩니다. 이것을 금지하려면 고유 인덱스를 정의 할 때 USING HASH 옵션을 지정해야합니다.

기본값은 64입니다. 각 인덱스는 노드 당 약 15K 바이트를 소모합니다.

MaxNoOfTriggers

개별 고유 해시 인덱스는 내부 업데이트, 삽입 및 삭제 트리거가 할당됩니다. (이것은 고유 해시 인덱스마다 3 개의 트리거가 생성되는 것을 의미합니다.) 그러나 정렬 된 인덱스에 필요한 트리거 객체는 1 개뿐입니다. 백업에서 클러스터의 보통 테이블마다 3 개의 트리거 오브젝트가 사용됩니다.

클러스터 간의 복제에서도 내부 트리거가 사용됩니다.

이 매개 변수는 클러스터 내의 트리거 오브젝트의 최대 개수를 설정합니다.

기본값은 768입니다.

MaxNoOfIndexes

이 매개 변수는 사용되지 않으며, MySQL Cluster의 향후 버전에서 제거 될 예정입니다. 대신 MaxNoOfOrderedIndexes 및 MaxNoOfUniqueHashIndexes 을 사용하도록하십시오.

이 매개 변수는 고유 해시 인덱스에서만 사용됩니다. 클러스터에 정의 된 고유 해시 인덱스 당 하나의 레코드가이 풀에 존재해야합니다.

이 매개 변수의 기본값은 128입니다.

MaxNoOfSubscriptions

일부 NDB API 응용 프로그램에서는이 매개 변수의 변경이 필요하거나 바람직한 경우가 있습니다. 그러나 SQL 노드 역할을하는 MySQL 서버를 정상적으로 사용하려면 이렇게 필요가 없습니다.

MaxNoOfSubscriptions 의 기본값은 0입니다. 이것은 MaxNoOfTables 와 등가로 취급됩니다. 각 구독은 108 바이트를 소비합니다.

MaxNoOfSubscribers

이 매개 변수는 MySQL Cluster 복제 사용시에만 관련이 있습니다. 기본값은 0입니다.이것은 2 * MaxNoOfTables 로 처리됩니다. 즉, 2 개의 MySQL 서버 (하나는 복제 마스터 역할을하고 다른 하나는 슬레이브로 작동합니다) 각각에 대해 NDB 테이블 당 하나의 구독이 있습니다. 각 가입자는 16 바이트의 메모리를 사용합니다.

순환 복제 다중 마스터 복제 및 3 개 이상의 MySQL 서버가 관여하는 다른 복제 설정을 사용하는 경우에는이 매개 변수를 복제에 포함 된 mysqld 프로세스 수 (이것은 보통 (항상은 아니지만) 클러스터 수와 같습니다)까지 늘리도록하십시오. 예를 들어, 3 개의 MySQL Cluster를 사용하는 순환 복제 설정이 하나의 mysqld 가 각 클러스터에 연결된 이러한 mysqld 프로세스가 각각 마스터 및 슬레이브로 작동하는 경우 MaxNoOfSubscribers 을 3 * MaxNoOfTables 로 설정하도록 하십시오.

자세한 내용은 섹션 18.6 "MySQL Cluster 복제" 를 참조하십시오.

MaxNoOfConcurrentSubOperations

이 매개 변수는 클러스터의 모든 API 노드가 한 번에 수행 할 수있는 작업 수의 상한을 설정합니다. 정상 작동시 기본값 (256)으로 충분하지만, API 노드가 다수있어, 각각이 대량의 작업을 동시에 실행하는 시나리오에서만 조정이 필요할 수 있습니다.

boolean 매개 변수 데이터 노드의 동작은 boolean 값을 가지고 일련의 [ndbd] 매개 변수에도 영향됩니다. 이러한 매개 변수는 TRUE 로 지정하는 경우는 1 또는 Y 로 설정하고 FALSE 로 지정하는 경우는 0 또는 N 으로 설정합니다.

LateAlloc

관리 서버에 연결이 된 후에,이 데이터 노드의 메모리를 할당합니다. 기본적으로 활성화.

LockPagesInMainMemory

Solaris와 Linux를 포함한 여러 운영 체제에서는 프로세스를 메모리에 고정하면 디스크에 스왑을 피할 수 있습니다. 이것을 사용하면 클러스터의 실시간 특성을 보장하기 쉽습니다.

이 매개 변수는 정수 값 0 , 1 또는 2 중 하나를 취합니다. 이러한 기능을 다음의 목록입니다.

권한이없는 사용자가 페이지를 잠글 수 있도록 운영 체제가 구성되어 있지 않은 경우이 매개 변수를 사용하는 데이터 노드 프로세스를 시스템의 root로 실행해야 할 수 있습니다. ( LockPagesInMainMemory 는 mlockall 함수가 사용됩니다 .Linux kernel 2.6.9 이후에서는 권한이없는 사용자가 max locked memory 제한에 따라 메모리를 잠글 수 있습니다. 자세한 내용은 ulimit -l 및 http : //linux.die .net / man / 2 / mlock 을 참조하십시오).

StopOnError

이 매개 변수는 데이터 노드 프로세스에서 오류 조건이 발생했을 때 프로세스를 종료하거나 자동으로 다시 시작하거나 지정합니다.

이 매개 변수의 기본값은 1 입니다. 이것은 기본적으로 오류 발생시 데이터 노드 프로세스가 중지하는 것을 의미합니다.

CrashOnCorruptedTuple

이 매개 변수를 사용하면 손상된 튜플이 검출 된 때 데이터 노드가 강제 종료됩니다. MySQL Cluster NDB 7.3 이상에서는 이것은 기본적으로 활성화되어 있습니다.

Diskless

MySQL Cluster의 테이블을 디스크없는 로 지정할 수 있습니다. 이것은 테이블이 디스크에 체크 포인트되지 않고 로깅이 발생하지 않는 것을 의미합니다. 이러한 테이블은 메인 메모리에만 존재합니다. 디스크없는 테이블을 사용하면 충돌 발생시에 테이블도 테이블의 레코드도 삭제됩니다. 그러나 디스크없는 모드에서 작동 할 때 디스크없는 컴퓨터에서 ndbd 를 실행할 수 있습니다.

이 기능을 사용하면 클러스터의 온라인 백업이 사용됩니다. 또한 클러스터의 부분 시작 수 없습니다.

Diskless 은 기본적으로 비활성화되어 있습니다.

ODirect

이 매개 변수를 사용하면 NDB 가 LCP, 백업 및 Redo 로그에 O_DIRECT 쓰려고 종종 kswapd 및 CPU 사용률이 떨어집니다. Linux에서 MySQL Cluster를 사용할 때 커널 2.6 이상을 사용하는 경우 ODirect 을 사용하십시오.

ODirect 은 기본적으로 비활성화되어 있습니다.

RestartOnErrorInsert

이 기능은 코드의 각 블록을 테스트의 일부로 실행할 때 오류 삽입이 가능한 디버그 버전을 빌드하는 경우에만 사용할 수 있습니다.

이 기능은 기본적으로 비활성화되어 있습니다.

CompressedBackup

사용되는 압축은 gzip --fast 과 같으며 데이터 노드에서 비 압축 백업 파일의 저장에 필요한 공간의 50 % 이상을 절약 할 수 있습니다. 압축 백업은 개별 데이터 노드 또는 ( config.ini 파일의 [ndbd default] 섹션에이 매개 변수를 설정하여) 모든 데이터 노드에서 활성화 할 수 있습니다.

기본값은 0 (해제)입니다.

CompressedLCP

이 매개 변수를 1 로 설정하면 로컬 체크 포인트가 압축됩니다. 사용되는 압축은 gzip --fast 과 같으며 데이터 노드에서 비 압축 체크 포인트 파일의 저장에 필요한 공간의 50 % 이상을 절약 할 수 있습니다. 압축 LCP는 개별 데이터 노드 또는 ( config.ini 파일의 [ndbd default] 섹션에이 매개 변수를 설정하여) 모든 데이터 노드에서 활성화 할 수 있습니다.

기본값은 0 (해제)입니다.

TimeBetweenWatchDogCheck

메인 스레드가 특정 시점에 무한 루프에 빠지는 것을 방지하기 위해 " 감시 " 스레드가 메인 스레드를 확인합니다. 이 매개 변수는 체크 사이의 밀리 초 단위로 지정합니다. 프로세스가 3 회 검사 후에도 동일한 상태의 경우, 감시 스레드는 프로세스를 종료합니다.

이 매개 변수는 실험 또는 로컬 상태에 따라 쉽게 변경할 수 있습니다. 이 노드 단위로 지정할 수 있지만 지정하는 경우는 거의 없습니다.

TimeBetweenWatchDogCheckInitial

This is similar to the TimeBetweenWatchDogCheck parameter, except that TimeBetweenWatchDogCheckInitial controls the amount of time that passes between execution checks inside a database node in the early start phases during which memory is allocated.

The default timeout is 6000 milliseconds (6 seconds).

StartPartialTimeout

이것은 TimeBetweenWatchDogCheck 매개 변수와 거의 동일하지만 TimeBetweenWatchDogCheckInitial 는 메모리 할당이 이루어지는 초기 시작 단계에서 데이터베이스 노드 내부의 실행 체크 사이에 경과 시간을 제어합니다.

기본 시간은 6000 밀리 세컨드 (6 초)입니다.

StartPartitionedTimeout

StartPartialTimeout 밀리 초 대기 후 클러스터를 시작할 수 상태도 아직 분할 된 상태의 가능성이있는 경우 클러스터는이 시간이 경과 할 때까지 기다립니다. StartPartitionedTimeout 를 0으로 설정하면 클러스터는 무기한 대기합니다.

이 매개 변수는 클러스터의 초기 시작 또는 초기 재부팅을 수행 할 때 무시됩니다.

기본 시간 제한은 60000 밀리 초 (60 초)입니다.

StartFailureTimeout

데이터 노드에서이 매개 변수에 지정된 시간 내에 시작 시퀀스가​​ 완료되지 않은 경우 노드의 시작은 실패합니다. 이 매개 변수를 0 (기본값)로 설정하면 데이터 노드의 제한은 적용되지 않습니다.

이 매개 변수는 0이 아닌 값은 밀리 초 단위로 측정됩니다. 많은 데이터를 포함한 데이터 노드에서는이 매개 변수를 늘리도록하십시오. 예를 들어, 수 기가 바이트의 데이터를 포함한 데이터 노드에서 노드를 다시 시작하는데 10 ~ 15 분 (즉, 600000-1000000 밀리 초)의 시간이 필요합니다.

StartNoNodeGroupTimeout

Nodegroup = 65536 에서 데이터 노드를 구성하면 해당 노드는 어떤 노드 그룹에 할당 할 수없는 것으로 간주됩니다. 이 경우 클러스터는 StartNoNodegroupTimeout 밀리 초 기다렸다가 그러한 노드를 --nowait-nodes 옵션에 전달 된 목록에 추가 된 것으로 간주 시작합니다. 기본값은 15000 입니다 (즉, 관리 서버는 15 초 대기합니다). 이 매개 변수를 0 으로 설정하면 클러스터는 무기한 대기합니다.

StartNoNodegroupTimeout 는 클러스터의 모든 데이터 노드에서 동일해야합니다. 따라서 이것은 개별 데이터 노드가 아니라 항상 config.ini 파일의 [ndbd default] 섹션에 설정하도록하십시오.

자세한 내용은 섹션 18.5.13 "MySQL Cluster 데이터 노드의 온라인 추가" 를 참조하십시오.

HeartbeatIntervalDbDb

실패한 노드를 검출하는 주요 방법 중 하나는 하트 비트를 사용하는 것입니다. 이 매개 변수는 하트 비트 신호의 전송 횟수 것으로 예상된다 수신 횟수를 지정합니다. 3 회 연속 하트 비트 간격이 실패하면 그 노드는 데드가 선언됩니다. 따라서 하트 비트 메커니즘에 의한 고장 검출의 최대 시간은 하트 비트 간격의 4 배입니다.

MySQL Cluster NDB 7.3 이상에서는 기본 하트 비트 간격은 5000 밀리 초 (5 초)입니다. 이 매개 변수를 크게 변경하지 마십시오. 또한 노드 간의 차이가 크지 않도록하십시오. 노드가 5000 밀리 초를 사용하고 그것을 감시하는 노드가 1000 밀리 초를 사용하는 경우, 그 노드는 매우 빨리 데드가 선언됩니다. 이 매개 변수는 온라인 소프트웨어 업그레이드 중에 변경할 수 있지만 조금씩 늘리십시오.

네트워크 통신 대기 시간 도 참조하십시오.

HeartbeatIntervalDbApi

각 데이터 노드는 각 MySQL 서버 (SQL 노드)에 하트 비트 신호를 전송하여 연결된 상태인지 확인합니다. MySQL 서버가 시간 내에 하트 비트를 전송하지 못한 경우 " 데드 " 라고 선언됩니다. 이 경우 진행중인 모든 트랜잭션이 완료되고 자원이 해제됩니다. 이전 MySQL 인스턴스가 시작 된 모든 활동이 완료 될 때까지 SQL 노드는 다시 연결할 수 없습니다. 이 판정에 사용되는 3 하트 비트의 조건은 HeartbeatIntervalDbDb 에서 설명한 것과 동일합니다.

기본 간격은 1500 밀리 초 (1.5 초)입니다. 각 데이터 노드는 다른 모든 데이터 노드와 관계없이 연결중인 MySQL 서버를 모니터링하기 위해이 간격은 각 데이터 노드 다를 수 있습니다.

자세한 내용은 네트워크 통신 대기 시간 을 참조하십시오.

HeartbeatOrder

데이터 노드는 각 데이터 노드가 이전 데이터 노드를 모니터하는 순환적인 방식으로 서로 하트 비트를 전송합니다. 하트 비트가 특정 데이터 노드에서 감지되지 않은 경우,이 노드는 순환 직전의 데이터 노드를 " 죽은 " (즉, 클러스터에서 액세스 할 수 없게되었다) 고 선언합니다. 데이터 노드가 죽은하다는 판정은 세계적으로 이루어집니다. 즉, 데이터 노드 데드가 선언되면 그 노드는 클러스터의 모든 노드에서 그렇게 간주됩니다.

다 른 호스트에 배치 된 데이터 노드 간의 하트 비트 (예를 들어, 매우 긴 하트 비트 간격이나 일시적인 연결 문제로) 다른 노드 쌍 사이의 하트 비트에 비해 너무 늦게 위해 데이터 노드가 아직 클러스터의 일부로 기능하고 있음에도 불구하고, 데드가 선언 될 수 있습니다.

이러한 상황에서는 데이터 노드 간의 하트 비트 전송 순서가 특정 데이터 노드가 죽은 선언 여부에 영향을주고있는 가능성이 있습니다. 이 선언이 불필요하게 발생하면, 그것은 노드 그룹의 손실을 초래하고, 또한 클러스터의 장애로 이어질 수 있습니다.

다음 표와 같이 두 개의 호스트 컴퓨터 host1 및 host2 에서 실행되는 4 개의 데이터 노드 A, B, C 및 D가 이러한 데이터 노드가 2 개의 노드 그룹을 구성하고있다 설치 생각합니다.

하트 비트가 A-> B-> C-> D-> A 순으로 전송된다고합니다. 이 경우 호스트간에 하트 비트가 손실되면 노드 B가 노드 A 끊어짐 선언 노드 C가 B 끊어짐 선언합니다. 이 결과, 노드 그룹 0이 손실되므로 클러스터가 작동 중지합니다. 한편, 전송 순서가 A-> B-> D-> C-> A이다 (및 다른 모든 조건이 위에 남아있는 경우) 하트 비트가 손실되면 노트북 A와 D가 데드가 선언됩니다. 이 경우 각 노드 그룹에 하나씩 노드가 남아 있기 때문에 클러스터는 유지됩니다.

HeartbeatOrder 구성 매개 변수는 사용자가 하트 비트 전송 순서를 구성 할 수 있도록합니다. HeartbeatOrder 의 기본값은 0입니다. 모든 데이터 노드에서 기본값을 사용할 수 있도록하면 하트 비트 전송 순서는 NDB 에 의해 결정됩니다. 이 매개 변수를 사용하는 경우 클러스터의 모든 데이터 노드에 0 이외의 값 (65535)으로 설정해야합니다. 또한이 값은 각 데이터 노드에서 고유해야합니다. 이로 인해 심장 박동이 HeartbeatOrder 값이 작은 노드에서 큰 노드에 순서대로 전송된다 (이후 HeartbeatOrder 이 가장 큰 노드에서 가장 작은 노드에 전송되어 순환이 완결) 수 있습니다. 예를 들어, 위의 시나리오에서 하트 비트 전송 순서 A-> B-> D-> C-> A를 강제로 값을 연속시킬 필요는 없습니다. 여기에 나타낸 바와 같은 HeartbeatOrder 값을 설정할 수 있습니다.

이 매개 변수를 사용하여 실행중인 MySQL Cluster의 하트 비트 전송 순서를 변경하려면 먼저 글로벌 구성 ( config.ini ) 파일에 클러스터의 각 데이터 노드의 HeartbeatOrder 을 설정해야합니다. 변경 사항을 적용하려면 다음 중 하나를 수행해야합니다.

DUMP 908 을 사용하면 데이터 노드 로그에서이 매개 변수의 효과를 관찰 할 수 있습니다.

ConnectCheckIntervalDelay

이 매개 변수는 데이터 노드 간의 연결 검사를 활성화합니다. ConnectCheckIntervalDelay 초 간격 이내에 응답 할 수없는 데이터 노드 의심치로 간주되며, 이러한 간격이 2 회 계속 된 뒤에서 죽은 것으로 간주됩니다.

이 매개 변수의 기본값은 0입니다. 이것은 MySQL Cluster NDB 7.1에서 변경된 사항입니다.

TimeBetweenLocalCheckpoints

이 매개 변수는 새 로컬 포인트를 시작할 때까지의 대기 시간을 지정하지 않는다는 점에서 예외입니다. 어느 쪽인가하면 상대적으로 적은 갱신 될 클러스터에서 로컬 체크 포인트가 실행되지 않도록하는 데 사용됩니다. 업데이트 횟수가 많은 대부분의 클러스터는 직전의 로컬 체크 포인트가 완료 한 직후에 새로운 로컬 체크 포인트가 시작 될 가능성이 있습니다.

이전 로컬 체크 포인트가 시작된 이후에 실행 된 모든 쓰기 작업의 크기가 추가됩니다. 이 매개 변수는 4 바이트 워드의 수의 바닥 2의 대수로 지정되는 점에서도 예외입니다. 따라서 기본값 20은 4M 바이트 (4 * 2 ²⁰ )의 쓰기 작업을 의미하고 21은 8M 바이트를 의미하고, 최대 값 31는 8G 바이트의 쓰기 작업과 동일합니다.

클러스터의 모든 쓰기 작업이 함께 추가됩니다. TimeBetweenLocalCheckpoints 를 6 이하로 설정하면 로컬 체크 포인트는 클러스터의 워크로드와 관계없이 끊김없이 연속적으로 실행됩니다.

TimeBetweenGlobalCheckpoints

트랜잭션이 커밋되면 데이터가 미러링 된 노드의 메인 메모리에 커밋됩니다. 그러나 트랜잭션 로그 레코드는 커밋의 일부로 디스크에 플러시되지 않습니다. 트랜잭션을 적어도 2 개의 자립적 인 호스트 시스템에서 안전하게 커밋하여 지속 가능성에 대한 합리적인 기준이 충족 될 것이라는 것이이 동작의 근거입니다.

또한 최악의 경우 (클러스터의 완전한 충돌)도 적절히 처리되도록하는 것이 중요합니다. 이 수행을 보장하기 위해 특정 거리 이내에 이루어지는 모든 거래는 글로벌 체크 포인트에 포함됩니다. 이것은 디스크에 플래시 된 커밋 된 트랜잭션으로 간주 될 수 있습니다. 즉, 트랜잭션은 커밋 프로세스의 일부로서 글로벌 체크 포인트 그룹에 포함됩니다. 그 후,이 그룹의 로그 레코드가 디스크로 플러시되면 트랜잭션 그룹 전체 클러스터의 컴퓨터에서 디스크에 안전하게 커밋됩니다.

이 매개 변수는 글로벌 체크 포인트 사이의 간격을 정의합니다. 기본값은 2000 밀리 초입니다.

TimeBetweenGlobalCheckpointsTimeout

이 매개 변수는 글로벌 체크 포인트 사이의 최소 시간 제한을 정의 합니다. 기본값은 120000밀리 초입니다.

This parameter was added in MySQL Cluster NDB 7.3.9 and MySQL Cluster 7.4.5. (Bug #20069617)

TimeBetweenEpochs

이 매개 변수는 MySQL Cluster 복제 동기화 신기원 사이의 간격을 정의합니다. 기본값은 100 밀리 초입니다.

TimeBetweenEpochs 는 MySQL Cluster 복제 성능을 향상시키는 데 사용할 수있는 " micro-GCP " 구현의 일부입니다.

TimeBetweenEpochsTimeout

이 매개 변수는 MySQL Cluster 복제 동기화 신기원의 시간을 정의합니다. 이 매개 변수 결정된 시간 내에 노드가 글로벌 체크 포인트에 참석하지 못한 경우 노드는 종료됩니다. MySQL Cluster NDB 7.3 이상에서는 기본값은 0입니다 (즉, 시간 제한이 비활성화되어 있습니다).

TimeBetweenEpochsTimeout 는 MySQL Cluster 복제 성능을 향상시키는 데 사용할 수있는 " micro-GCP " 구현의 일부입니다.

GCP의 저장에 1 분 이상 소요되거나 GCP의 저장에 10 초 이상의 시간이 걸린 경우에는 항상이 매개 변수의 현재 값과 경고가 클러스터 로그에 기록됩니다.

이 매개 변수를 0으로 설정하면 저장 시간, 위탁의 제한 또는 둘 다에 의해 발생하는 GCP의 정지를 해제합니다. 이 매개 변수의 최대 값은 256,000 밀리 초입니다.

MaxBufferedEpochs

구독 노드가 연기 할 처리되지 않은 신기원 수. 이 수를 초과하면 지연 가입자가 절단됩니다.

대부분의 일반 작업에서는 기본값 100으로 충분합니다. 구독 노드의 지연으로 인해 손실이 발생하는 경우, 그 원인은 일반적으로 프로세스 또는 스레드에 대한 네트워크 또는 스케줄링 문제입니다. (드문 경우이지만, NDB 클라이언트의 버그로 인해이 문제가 발생할 수 있습니다.) 신기원이 큰 경우에는이 값을 기본값보다 작게 설정하는 것이 바람직 할 수 있습니다.

절단하여 클라이언트의 문제로 인해 데이터 노드 서비스가 영향을 받아 데이터를 버퍼링하기위한 메모리가 부족하여 결국 종료 할 수 없습니다. 대신, 절단의 결과로 (예를 들어, 바이너리 로그의 격차 이벤트에 의해) 클라이언트에 영향을 클라이언트가 강제로 프로세스를 다시 연결하거나 다시 시작합니다.

MaxBufferedEpochBytes

이 노드가 신기원을 버퍼링하는데 할당 바이트의 합계 수.

TimeBetweenInactiveTransactionAbortCheck

타임 아웃 처리는 각 트랜잭션의 타이머를 매개 변수로 지정된 간격마다 한 번씩 체크하고 실행됩니다. 따라서이 파라미터를 1000 밀리 초로 설정하면 모든 트랜잭션 제한 시간이 1 초에 한번씩 체크됩니다.

기본값은 1000 밀리 초 (1 초)입니다.

TransactionInactiveTimeout

이 매개 변수는 트랜잭션이 중지 될 때까지 동일한 트랜잭션에서 작업간에 경과가 허용되는 최대 시간을 지정합니다.

이 매개 변수의 기본값은 4G (최대도 마찬가지입니다). 트랜잭션이 잠금을 보유하는 기간이 너무 길지 않게 할 필요가있는 실시간 데이터베이스의 경우,이 매개 변수를 비교적 낮은 값으로 설정하도록하십시오. 단위는 밀리 초입니다

TransactionDeadlockDetectionTimeout

노드는 트랜잭션을 포함한 쿼리를 실행할 때 클러스터의 다른 노드가 응답 할 때까지 기다린 후 작업을 계속합니다. 응답의 실패는 다음 중 하나의 이유로 발생합니다.

이 시간 초과 매개 변수는 트랜잭션이 중단 될 때까지 트랜잭션 코디네이터가 다른 노드에 의한 쿼리의 실행을 기다리는 시간을 지정하는 것으로, 노드 장애 처리 및 교착 상태 감지에 중요합니다.

기본 시간 초과 값은 1200 밀리 초 (1.2 초)입니다.

이 매개 변수의 최소 50 밀리 초입니다.

DiskSyncSize

이것은 로컬 체크 포인트 파일에 데이터를 플래시까지 저장되는 최대 바이트 수입니다. 이것은 성능을 크게 저하시킬 수있는 쓰기 버퍼링을 금지하기 위해 이루어집니다. 이 매개 변수는 TimeBetweenLocalCheckpoints 대신 사용하기위한 것이 아닙니다 .

기본값은 4M (4 메가 바이트)입니다.

DiskCheckpointSpeed

로컬 체크 포인트 동안 디스크에 전송되는 데이터의 양 (바이트 / 초). 이 할당은 DML 작업과 백업 (백업 기록은 제외)에서 공유됩니다. 이것은 집약적 인 DML 실행 중에 시작된 백업이 Redo 로그 버퍼의 대량 발생에 의해 저지되어 충돌이 심각한 경우 완전히 실패 할 가능성이 있다는 것을 의미합니다.

기본값은 10M (10 메가 바이트 / 초)입니다.

MySQL Cluster 7.4.1 이후 버전에서는이 매개 변수는 사용되지 않으며 대신 구성 매개 변수 MinDiskWriteSpeed ​​, MaxDiskWriteSpeed ​​, MaxDiskWriteSpeedOtherNodeRestart 및 MaxDiskWriteSpeedOwnRestart 을 사용하여 LCP 및 백업의 쓰기 속도를 제어 할 수 있습니다.

DiskCheckpointSpeedInRestart

다시 시작 작업의 일부인 로컬 체크 포인트 동안 디스크에 전송되는 데이터의 양 (바이트 / 초).

기본값은 100M (100 메가 바이트 / 초)입니다.

MySQL Cluster 7.4.1 이후 버전에서는이 매개 변수는 사용되지 않으며 대신 구성 매개 변수 MinDiskWriteSpeed ​​, MaxDiskWriteSpeed ​​, MaxDiskWriteSpeedOtherNodeRestart 및 MaxDiskWriteSpeedOwnRestart 을 사용하여 LCP 및 백업의 쓰기 속도를 제어 할 수 있습니다.

NoOfDiskPagesToDiskAfterRestartTUP

이 매개 변수는 사용되지 않으며, MySQL Cluster의 향후 버전에서 제거 될 예정입니다. 대신 DiskCheckpointSpeedInRestart 및 DiskSyncSize 를 사용하십시오. MySQL Cluster 7.4.1 이후에서는, 대신에 그 릴리스에서 도입 된 구성 매개 변수 MinDiskWriteSpeed ​​, MaxDiskWriteSpeed ​​, MaxDiskWriteSpeedOtherNodeRestart 및 MaxDiskWriteSpeedOwnRestart 을 사용하도록하십시오.

MaxDiskWriteSpeed

Set the maximum rate for writing to disk, in bytes per second, by local checkpoints and backup operations when no restarts (by this data node or any other data node) are taking place in this MySQL Cluster.

For setting the maximum rate of disk writes allowed while this data node is restarting, use MaxDiskWriteSpeedOwnRestart. For setting the maximum rate of disk writes allowed while other data nodes are restarting, use MaxDiskWriteSpeedOtherNodeRestart. The minimum speed for disk writes by all LCPs and backup operations can be adjusted by setting MinDiskWriteSpeed.

MaxDiskWriteSpeed was added in MySQL Cluster NDB 7.4.1.

MaxDiskWriteSpeedOtherNodeRestart

이 MySQL Cluster에 포함 된 노드 이외의 1 개 이상의 데이터 노드가 다시 시작하는 경우 로컬 체크 포인트 및 백업 작업에 의한 디스크 쓰기 최대 속도 (바이트 / 초)을 설정합니다.

이 데이터 노드를 다시 시작하는 동안 허용되는 디스크 쓰기 최대 속도를 설정하려면 MaxDiskWriteSpeedOwnRestart 을 사용합니다. 클러스터에서 데이터 노드가 다시 시작되지 않은 경우에 허용되는 디스크 쓰기 최대 속도를 설정하려면 MaxDiskWriteSpeed ​​을 사용합니다. 모든 LCP 및 백업 작업에 의한 디스크 쓰기의 최소 속도를 조정하려면 MinDiskWriteSpeed ​​을 설정합니다.

MaxDiskWriteSpeedOtherNodeRestart 은 MySQL Cluster NDB 7.4.1에서 추가되었습니다.

MaxDiskWriteSpeedOwnRestart

이 데이터 노드를 다시 시작 로컬 체크 포인트 및 백업 작업에 의한 디스크 쓰기 최대 속도 (바이트 / 초)을 설정합니다.

다른 데이터 노드를 다시 시작하는 동안 허용되는 디스크 쓰기 최대 속도를 설정하려면 MaxDiskWriteSpeedOtherNodeRestart 을 사용합니다. 클러스터에서 데이터 노드가 다시 시작되지 않은 경우에 허용되는 디스크 쓰기 최대 속도를 설정하려면 MaxDiskWriteSpeed ​​을 사용합니다. 모든 LCP 및 백업 작업에 의한 디스크 쓰기의 최소 속도를 조정하려면 MinDiskWriteSpeed ​​을 설정합니다.

MaxDiskWriteSpeedOwnRestart 은 MySQL Cluster NDB 7.4.1에서 추가되었습니다.

MinDiskWriteSpeed

로컬 체크 포인트 및 백업 작업에 의한 디스크 쓰기의 최소 속도 (바이트 / 초)을 설정합니다.

다양한 조건에서 LCP 및 백업에 허용되는 디스크 쓰기 최대 속도는 파라미터 MaxDiskWriteSpeed ​​, MaxDiskWriteSpeedOwnRestart 및 MaxDiskWriteSpeedOtherNodeRestart 를 사용하여 조정할 수 있습니다. 자세한 내용은 이러한 매개 변수의 설명을 참조하십시오.

MinDiskWriteSpeed ​​은 MySQL Cluster NDB 7.4.1에서 추가되었습니다.

NoOfDiskPagesToDiskAfterRestartACC

이 매개 변수는 사용되지 않으며, MySQL Cluster의 향후 버전에서 제거 될 예정입니다. MySQL Cluster NDB 7.3에서는 대신 DiskCheckpointSpeedInRestart 및 DiskSyncSize 를 사용하십시오. MySQL Cluster NDB 7.4.1 이상에서는 매개 변수 MinDiskWriteSpeed ​​, MaxDiskWriteSpeed ​​, MaxDiskWriteSpeedOtherNodeRestart 및 MaxDiskWriteSpeedOwnRestart 을 사용하도록하십시오.

NoOfDiskPagesToDiskDuringRestartTUP (DEPRECATED)

이 매개 변수는 사용되지 않으며, MySQL Cluster의 향후 버전에서 제거 될 예정입니다. MySQL Cluster NDB 7.3에서는 대신 DiskCheckpointSpeedInRestart 및 DiskSyncSize 를 사용하십시오. MySQL Cluster NDB 7.4.1 이상에서는 매개 변수 MinDiskWriteSpeed ​​, MaxDiskWriteSpeed ​​, MaxDiskWriteSpeedOtherNodeRestart 및 MaxDiskWriteSpeedOwnRestart 을 사용하도록하십시오.

NoOfDiskPagesToDiskDuringRestartACC (DEPRECATED)

이 매개 변수는 사용되지 않으며, MySQL Cluster의 향후 버전에서 제거 될 예정입니다. MySQL Cluster NDB 7.3에서는 대신 DiskCheckpointSpeedInRestart 및 DiskSyncSize 를 사용하십시오. MySQL Cluster NDB 7.4.1 이상에서는 매개 변수 MinDiskWriteSpeed ​​, MaxDiskWriteSpeed ​​, MaxDiskWriteSpeedOtherNodeRestart 및 MaxDiskWriteSpeedOwnRestart 을 사용하도록하십시오.

ArbitrationTimeout

이 매개 변수는 데이터 노드가 중재 메시지에 대한 중재자의 응답을 기다리는 시간을 설정합니다. 이를 초과하는 경우는 네트워크가 끊어진 것으로 간주됩니다.

MySQL Cluster NDB 7.3 이상에서는 기본값은 7500 밀리 초 (7.5 초)입니다.

Arbitration

Arbitration 매개 변수를 사용하여이 매개 변수에 사용할 수있는 세 가지 값 중 하나에 해당하는 중재 제도를 선택할 수 있습니다.

버퍼링 및 로깅 고급 사용자는 몇 가지 [ndbd] 구성 매개 변수를 사용하면함으로써 노드 프로세스가 사용하는 자원을보다 효율적으로 관리하고 필요에 따라 다양한 버퍼 크기를 조정할 수 있습니다.

이러한 버퍼는 로그 레코드를 디스크에 기록 할 때 파일 시스템에 대한 프론트 엔드로 사용됩니다. 노드가 디스크없는 모드에서 실행되는 경우는 NDB 스토리지 엔진의 파일 시스템 추상화 계층에서 디스크 쓰기 " 위장 " 되기 때문에 페널티없이이 매개 변수를 최소로 설정할 수 있습니다.

UndoIndexBuffer

이 매개 변수 크기가 설정되는 Undo 인덱스 버퍼는 로컬 체크 포인트 중에 사용됩니다. NDB 스토리지 엔진은 사용 가능한 Redo 로그와 체크 포인트의 일관성에 기반 복구 체계를 사용합니다. 시스템 전체의 쓰기를 차단하지 않고 일관성있는 체크 포인트를 만들기 위해 로컬 체크 포인트를 실행하는 동안 Undo 로깅이 이루어집니다. Undo 기록은 한 번에 하나의 테이블 조각에 대해 활성화됩니다. 이 최적화가 가능한 것은 테이블이 모두 메인 메모리에 저장되어 있기 때문입니다.

Undo 인덱스 버퍼는 기본 키의 해시 인덱스 업데이트 사용됩니다. 삽입과 삭제는 해시 인덱스가 재구성됩니다. NDB 스토리지 엔진은 모든 육체적 인 변화를 시스템 재부팅시에 취소 할 수 있도록 변경 사항을 하나의 인덱스 페이지에 매핑 Undo 로그 레코드를 기록합니다. 또한 로컬 체크 포인트를 시작할 때 각 조각의 활성 삽입 작업을 기록합니다.

읽기 및 업데이트에서는 록 비트가 설정되어 해시 인덱스 항목의 헤더가 업데이트됩니다. 이러한 변경은 페이지 쓰기 알고리즘에 의해 처리되기 때문에 이러한 작업 Undo 로깅이 필요하지 않습니다.

이 버퍼는 기본적으로 2M 바이트입니다. 최소 1M 바이트입니다. 대부분의 어플리케이션에서는 이것으로 충분합니다. 대규모 트랜잭션이나 대규모 기본 키와 함께 매우 크거나 다수의 삽입 및 삭제를 수행하는 응용 프로그램이 버퍼의 크기를 늘릴 필요가있을 수 있습니다. 이 버퍼가 너무 작 으면 NDB 스토리지 엔진은 내부 오류 코드 677 "Index UNDO buffers overloaded" 를 발행합니다.

UndoDataBuffer

이 매개 변수는 Undo 데이터 버퍼의 크기를 설정합니다. Undo 데이터 버퍼는 Undo 인덱스 버퍼와 거의 동일한 기능을 수행하지만, 인덱스 메모리가 아닌 데이터 메모리에 대해 사용됩니다. 이 버퍼는 조각의 로컬 체크 포인트 단계에서 삽입, 삭제 및 업데이트를 위해 사용됩니다.

Undo 로그 항목을 기록하는 작업이 증가함에 따라 커지는 경향이 있으므로이 버퍼에도 대응하는 인덱스 메모리보다 큽니다 (기본값은 16M 바이트입니다).

일부 응용 프로그램이 메모리 양이 불필요하게 큰 경우가 있습니다. 그런 경우이 크기를 최소 1M 바이트로 줄일 수 있습니다.

대부분의 경우이 버퍼의 크기를 늘릴 필요가 없습니다. 그런 필요가있는 경우 데이터베이스의 갱신 활동에 의해 발생하는 부하를 디스크가 실제로 처리 할 수​​ 있는지 여부를 확인하는 것이 좋습니다. 이 버퍼 크기를 늘려도 디스크 공간 부족을 해소 할 수 없습니다.

이 버퍼가 너무 작아 과밀 상태가 된 경우, NDB 스토리지 엔진은 다음 내부 오류 코드를 발행합니다 : 891 ( Data UNDO buffers overloaded ).

RedoBuffer

갱신 활동도 모두 기록해야합니다. Redo 로그는 시스템이 재부팅 될 때마다 이러한 업데이트를 재현 할 수 있습니다. NDB 복구 알고리즘은 Undo 로그와 데이터의 " 퍼지 " 체크 포인트를 사용하여 Redo 로그를 적용하여 복원 시점까지의 모든 변경을 재현합니다.

RedoBuffer 은 Redo 로그가 기록되는 버퍼의 크기를 설정합니다. 기본값은 32M 바이트입니다. 최소 1M 바이트입니다.

이 버퍼가 너무 작 으면 NDB 스토리지 엔진은 내부 오류 코드 1221 ( REDO log buffers overloaded )를 발행합니다. 따라서 클러스터 구성의 온라인 변경의 일부로 RedoBuffer 값을 줄이려고하는 경우주의하십시오.

ndbmtd 는 LDM 스레드마다 별도의 버퍼를 할당합니다 ( ThreadConfig 를 참조하십시오). 예를 들어, 4 개의 LDM 스레드가있는 경우 ndbmtd 데이터 노드는 실제로는 4 개의 버퍼가 있으며 각각 RedoBuffer 바이트 (총 4 * RedoBuffer 바이트)가 할당됩니다.

EventLogBufferSize

데이터 노드 내부의 NDB 로그 이벤트에 사용되는 순환 버퍼 크기를 제어합니다.

로그 메시지의 제어 클러스터 관리는 stdout 로 전송되는 다양한 이벤트 유형의 로그 메시지 수를 제어 할 수있는 것이 매우 중요합니다. 이벤트 범주마다 16 개의 설정 가능한 이벤트 레벨 (번호 0-15)이 있습니다. 특정 이벤트 범주의 이벤트 보고서를 레벨 15로 설정하면 해당 범주의 모든 이벤트 보고서가 stdout 로 전송됩니다. 0으로 설정하면 해당 카테고리의 이벤트 보고서를 전혀하지 않게됩니다.

기본적으로 부팅 메시지 만 stdout 에 전송되고 나머지 이벤트 보고서의 수준은 기본 0으로 설정됩니다. 이것은 이러한 메시지가 관리 서버의 클러스터 로그에 전송되기 때문입니다.

관리 클라이언트에서 유사한 수준의 세트를 설정하면 클러스터 로그에 기록 할 이벤트 수준을 지정할 수 있습니다.

LogLevelStartup

프로세스를 시작하는 동안 생성되는 이벤트의보고 수준.

기본 레벨은 1입니다.

LogLevelShutdown

노드의 정상적인 종료의 일부로 생성되는 이벤트의보고 수준.

기본 레벨은 0입니다

LogLevelStatistic

기본 키 읽기의 수, 업데이트 수, 삽입 수, 버퍼 사용량에 대한 정보 등의 통계 이벤트의보고 수준.

기본 레벨은 0입니다.

LogLevelCheckpoint

로컬 및 글로벌 체크 포인트에 의해 생성되는 이벤트의보고 수준.

기본 레벨은 0입니다.

LogLevelNodeRestart

노드를 다시 시작할 때 생성되는 이벤트의보고 수준.

기본 레벨은 0입니다.

LogLevelConnection

클러스터 노드 사이의 연결에 의해 생성되는 이벤트의보고 수준.

기본 레벨은 0입니다.

LogLevelError

전체 클러스터의 오류 및 경고에 ​​의해 생성되는 이벤트의보고 수준. 이러한 오류는 노드 장애의 원인이되지는 않지만보고 할 가치는 있다고 생각됩니다.

기본 레벨은 0입니다.

LogLevelCongestion

혼잡에 의해 생성되는 이벤트의보고 수준. 이러한 오류는 노드 장애의 원인이되지는 않지만보고 할 가치는 있다고 생각됩니다.

기본 레벨은 0입니다.

LogLevelInfo

클러스터의 일반적인 상태 정보로 생성되는 이벤트의보고 수준.

기본 레벨은 0입니다.

MemReportFrequency

이 매개 변수는 데이터 노드의 메모리 사용 상황 보고서를 클러스터 로그에 기록하는 빈도를 제어합니다. 이 보고서 사이의 초 수를 나타내는 정수 값입니다.

각 데이터 노드의 데이터 메모리와 인덱스 메모리 사용량은 config.ini 파일에 설정된 DataMemory 및 IndexMemory 의 비율과 32K 바이트의 페이지 모두에서 각각 기록됩니다. 예를 들어, DataMemory 가 100M 바이트이며 특정 데이터 노드가 데이터 메모리 스토리지로 50M 바이트를 사용하는 경우 클러스터 로그의 해당 행이있게됩니다.

2006-12-24 01:18:16 [MgmSrvr] INFO -- Node 2: Data usage is 50%(1280 32K pages of total 2560)

MemReportFrequency 는 필수 매개 변수가 없습니다. 사용하는 경우, config.ini 의 [ndbd default] 섹션에서 모든 클러스터 데이터 노드에 설정하거나 구성 파일의 해당 [ndbd] 섹션에서 각 데이터 노드에 설정하거나 재정의 할 수 합니다. 최소 (기본 값도 동일)은 0입니다. 이 경우 섹션 18.5.6.2 "MySQL Cluster 로그 이벤트 ' 통계 이벤트 설명에서 지적했듯이, 메모리 사용량이 특정 비율 (80 %, 90 % 및 100 %)에 달했다 때만 메모리의 보고서가 기록됩니다.

StartupStatusReportFrequency

--initial 을 지정하고 데이터 노드를 시작하면 시작 단계 4 ( 섹션 18.5.1 "MySQL Cluster의 시작 단계 요약" 을 참조하십시오)에서 Redo 로그 파일이 초기화됩니다. NoOfFragmentLogFiles , FragmentLogFileSize 또는 둘 모두에 매우 큰 값을 설정하면이 초기화 시간이 오래 걸릴 수 있습니다. StartupStatusReportFrequency 구성 매개 변수를 사용하여이 프로세스의 진행에 관한 보고서를 정기적으로 기록하도록 강제 할 수 있습니다. 이 경우에는 여기에 같이 초기화 된 파일의 수와 공간의 양에 대한 진행 상황을 클러스터 로그에보고됩니다.

2009-06-20 16:39:23 [MgmSrvr] INFO -- Node 1: Local redo log file initialization status:
#Total files: 80, Completed: 60
#Total MBytes: 20480, Completed: 15557
2009-06-20 16:39:23 [MgmSrvr] INFO -- Node 2: Local redo log file initialization status:
#Total files: 80, Completed: 60
#Total MBytes: 20480, Completed: 15570

이 보고서는 시작 단계 4에서 StartupStatusReportFrequency 초마다 기록됩니다. StartupStatusReportFrequency 이 0 (디폴트)의 경우, Redo 로그 파일의 초기화 프로세스의 시작과 완료시에만 보고서가 클러스터 로그에 기록됩니다.

디버그 매개 변수 MySQL Cluster NDB 7.3 이상에서는 DictTrace 을 사용하여 테이블 만들기 및 삭제에 의해 생성 된 이벤트의 추적을 기록 할 수 있습니다. 이 매개 변수는 NDB 커널 코드를 디버깅하는 경우에만 유용합니다. DictTrace 는 정수 값을 취합니다. 현재 지원되는 유일한 값은 0 (기본. 로깅 없음) 1 (로깅 사용)입니다.

백업 매개 변수 이 절에서 설명하는 [ndbd] 파라미터는 온라인 백업 수행을 위해 확보 된 메모리 버퍼를 정의합니다.

BackupDataBufferSize

백업 생성은 데이터를 디스크에 전송하는 데 사용되는 2 개의 버퍼가 있습니다. 백업 데이터 버퍼는 노드의 테이블을 스캔하여 기록 된 데이터를 작성하는 데 사용됩니다. 이 버퍼에 쓸 BackupWriteSize 에서 지정된 레벨에 도달하면 페이지가 디스크로 전송됩니다. 백업 프로세스는 데이터를 디스크로 플러시하면서 공간이 없어 질 때까지이 버퍼에 쓰기 계속할 수 있습니다. 이것이 발생하면 백업 프로세스에서 검색을 일시 중지하고 디스크 쓰기가 어느 정도 완료 메모리가 해제되지 스캔을 계속할 수있을 때까지 기다립니다.

이 매개 변수의 기본값은 16M 바이트입니다.

BackupLogBufferSize

백업 로그 버퍼는 백업 데이터 버퍼와 같은 역할을하지만 백업이 실행되는 동안 열린 테이블 쓰기 로그를 생성하는 데 사용됩니다. 이 페이지의 쓰기는 백업 데이터 버퍼와 같은 원칙이 적용되지만 백업 로그 버퍼 공간이 부족하면 백업이 실패합니다. 따라서 백업 로그 버퍼의 크기는 백업 실행중인 쓰기 활동에 의해 발생하는 부하를 처리하기에 충분한 크기 일 필요가 있습니다. 섹션 18.5.3.3 "MySQL Cluster 백업 구성" 을 참조하십시오.

대부분의 응용 프로그램에서는이 매개 변수의 기본값으로 충분합니다. 실제 백업 로그 버퍼가 가득 찼을 경우보다 디스크 쓰기 속도가 불충분 한 경우가 더 백업이 실패 할 가능성이 높습니다. 디스크 서브 시스템이 응용 프로그램에서 발생하는 쓰기 부하에 맞게 구성되어 있지 않으면 클러스터가 필요한 작업을 수행 할 수 없을 가능성이 높아집니다.

디스크 나 네트워크 연결보다 프로세서가 병목 같은 방법으로 클러스터 노드를 구성하는 것이 좋습니다.

이 매개 변수의 기본값은 16M 바이트입니다.

BackupMemory

이 매개 변수는 단순히 BackupDataBufferSize 과 BackupLogBufferSize 의 합계입니다.

MySQL Cluster NDB 7.3 이상에서는이 매개 변수의 기본값은 16M 바이트 + 16M 바이트 = 32M 바이트입니다.

BackupReportFrequency

이 매개 변수는 백업하는 동안 관리 클라이언트에서 백업 상태 보고서를 발행하는 빈도와 같은 보고서를 클러스터 로그에 기록 빈도를 제어합니다 (클러스터 이벤트 로깅 허용하도록 구성되어있는 경우 로깅과 체크 포인트 를 참조하십시오). BackupReportFrequency 백업 상태 보고서 사이의 시간 (초)을 나타냅니다.

BackupWriteSize

이 매개 변수는 백업 로그와 백업 데이터 버퍼에 의해 디스크에 기록 된 메시지의 디폴트 크기를 지정합니다.

이 매개 변수의 기본값은 256K 바이트입니다.

BackupMaxWriteSize

이 매개 변수는 백업 로그와 백업 데이터 버퍼가 디스크에 기록되는 메시지의 최대 크기를 지정합니다.

이 매개 변수의 기본값은 1M 바이트입니다.

BackupDataBufferSize >= BackupWriteSize + 188KB

BackupLogBufferSize >= BackupWriteSize + 16KB

BackupMaxWriteSize >= BackupWriteSize

LockExecuteThreadToCPU

ndbd 에서 사용하는 경우이 매개 변수 (현재는 문자열)은 NDBCLUSTER 의 실행 스레드를 처리하기 위해 할당 된 CPU의 ID를 지정합니다. ndbmtd 에서 사용하는 경우이 매개 변수의 값은 실행 스레드를 처리하기 위해 할당 된 CPU ID의 쉼표로 구분 된 목록입니다. 목록의 각 CPU ID는 0-65535의 (이들을 포함) 범위의 정수로합니다.

지정하는 ID의 수는 MaxNoOfExecutionThreads 에 의해 지정되는 실행 스레드 수와 일치하도록하십시오. 그러나이 매개 변수를 사용하면 특정 순서로 스레드가 CPU에 할당되는 보증은 없습니다. ThreadConfig 를 사용하면 이러한보다 세부적으로 제어 할 수 있습니다.

LockExecuteThreadToCPU 기본값은 없습니다.

LockMaintThreadsToCPU

이 매개 변수는 NDBCLUSTER 관리 스레드를 처리하기 위해 할당 된 CPU의 ID를 지정합니다.

이 매개 변수의 값은 0-65535의 (이들을 포함) 사이의 정수입니다. MySQL Cluster NDB 7.3 이상에서는 기본값은 없습니다.

RealtimeScheduler

이 매개 변수를 1로 설정하면 데이터 노드 스레드의 실시간 스케줄링이 활성화됩니다.

MySQL Cluster NDB 7.3.3 이전 버전에서는이 매개 변수는 ndbmtd 을 실행하는 노드에서 제대로 작동하지 않았습니다. (Bug # 16961971)

SchedulerExecutionTimer

이 매개 변수는 스레드 스케줄러 실행에서 보낸 시간 (밀리 초)을 지정합니다. 이것을 0으로 설정하면 응답 시간이 최소화됩니다. 처리량을 향상시키기 위해이 값을 늘릴 수 있지만, 그 대가로 응답 시간은 길어집니다.

기본값은 50 마이크로 초입니다. 당사의 테스트에서는 이로 인해 고부하의 경우 실질적으로 요구를 지연시키지 않고 처리량이 약간 향상하는 것을 알 수 있습니다.

SchedulerSpinTimer

이 매개 변수는 스레드 스케줄러 실행에서 잠들기까지의 시간 (밀리 초)을 지정합니다.

기본값은 0입니다.

BuildIndexThreads

이 매개 변수는 시스템 또는 노드를 시작하는 동안 정렬 된 인덱스 재 구축시 및 ndb_restore --rebuild-indexes 를 실행할 때 작성하는 스레드 수를 지정합니다. 이것은 데이터 노드 당 여러 조각이 테이블에 존재하는 경우 (예를 들어, CREATE TABLE 에서 MAX_ROWS 옵션이 사용 된 경우)에만 지원됩니다.

이 매개 변수를 0 (기본값)로 설정하면 멀티 스레드에 의한 정렬 된 인덱스의 구축이 해제됩니다.

이 매개 변수는 ndbd 또는 ndbmtd 를 사용할 때 지원됩니다.

데이터 노드의 초기 재부팅 중에 멀티 스레드에 의한 구축을 활성화하려면 TwoPassInitialNodeRestartCopy 데이터 노드 구성 매개 변수를 TRUE 로 설정합니다.

TwoPassInitialNodeRestartCopy

데이터 노드의 초기 재부팅 멀티 스레드에 의한 정렬 된 인덱스의 구축을 활성화하려면이 구성 매개 변수를 TRUE 로 설정합니다. 이렇게하면 노드의 초기 다시 시작하는 동안 데이터의 2 경로 복사가 활성화됩니다.

동시에 BuildIndexThreads 를 0 이외의 값으로 설정해야합니다.

Numa

NDB 는 Non-Uniform Memory Access 설정과 (발생 시간 초과) 멀티 CPU 시스템의 영향을 상당히 민감합니다. 이 사실과 대부분의 MySQL Cluster 사용자가 numactl 을 채용하지 않기 때문에, Linux 시스템에서 ndbd 를 실행하는 경우, NUMA 지원은 기본적으로 무시됩니다. Linux 시스템이 NUMA를 지원하여 데이터 노드의 메모리를 NUMA으로 제어 할 필요가있는 경우에는이 매개 변수를 0으로 설정할 수 있습니다.

Numa 구성 매개 변수는 libnuma.so 가 설치되어있는 Linux 시스템에서만 지원됩니다.

멀티 스레드 구성 매개 변수 (ndbmtd) ndbmtd 는 기본적으로 단일 스레드 프로세스로 실행하기 위해 두 가지 방법 중 하나를 사용하여 다중 스레드를 사용하도록 구성해야합니다. 두 경우 모두, config.ini 파일에 구성 매개 변수를 설정해야합니다. 첫 번째 방법은 MaxNoOfExecutionThreads 구성 매개 변수에 적절한 값을 설정합니다. MySQL Cluster NDB 7.3 이상에서는 ThreadConfig 를 사용하여 ndbmtd 멀티 스레드에 대한 더 복잡한 규칙을 설정할 수있는 두 번째 방법도 지원됩니다. 이 매개 변수와 멀티 스레드 데이터 노드에서의 사용에 대해 다음 몇 단락에서 설명합니다.

MaxNoOfExecutionThreads

이 매개 변수는 ndbmtd 의해 사용되는 실행 스레드의 수를 제어합니다. 최대 72입니다 (MySQL Cluster NDB 7.3.3 이전에는, 이것은 36이었습니다). 이 매개 변수는 config.ini 파일의 [ndbd] 또는 [ndbd default] 섹션에 설정되지만 ndbmtd 전용이며 ndbd 에는 적용되지 않습니다.

MaxNoOfExecutionThreads 을 설정하면 storage / ndb / kernel / src / vm / mt_thr_config.cpp 파일의 매트릭스에서 결정되는 각 유형의 스레드 수가 설정됩니다. 이 테이블은 MySQL Cluster NDB 7.4.3 이상에서 MaxNoOfExecutionThreads 에 사용할 수있는 값에 대응하는 이러한 스레드 수를 보여줍니다 (Bug # 75220, Bug # 20215689). (이전 버전의 MySQL Cluster에 적용되는 매트릭스에 대한 정보를 나타내는 표는이 뒤에 있습니다.) MySQL Cluster NDB 7.4.3에서 변경된 값을 포함하는 행은 강조 표시 텍스트로 보여줍니다.

다음 표는 MySQL CLuster NDB 7.4.2 이전 MaxNoOfExecutionThreads 의 값에 대응하는 각 유형의 스레드 수를 취득하는 방법을 보여줍니다. 이 표는 MySQL Cluster NDB 7.3.2 이전에도 사용할 수 있지만,이 버전에서는 MaxNoOfExecutionThreads 의 최대치가 36이기 때문에이 표 36보다 큰 값에 해당하는 행은 MySQL Cluster NDB 7.3.3보다 이전에는 적용되지 않습니다

MySQL Cluster NDB 7.3 이상에서는 SUMA (복제) 스레드가 항상 하나 존재합니다.

LDM 스레드의 수가 NoOfFragmentLogParts 를 초과하지 않도록해야합니다. 따라서이 매개 변수의 값이 기본 (4)의 경우는 MaxNoOfExecutionThreads 을 16 이상으로 설정하면이 값도 늘려야합니다. 즉, NoOfFragmentLogParts 을 위의 표에 나타난 MaxNoOfExecutionThreads 이 매개 변수의 값에 대응하는 LDM 스레드 수의 값으로 설정하십시오.

스레드 유형은이 섹션 뒷부분합니다 ( ThreadConfig 를 참조하십시오).

이 매개 변수를 허용 범위를 벗어난 값으로 설정하면 관리 서버 시작이 중단되고 다음 오류가 발생합니다 : Error line Number : Illegal value value for parameter MaxNoOfExecutionThreads .

MaxNoOfExecutionThreads 는 값 0 또는 1은 NDB 내부에서 2로 반올림되기 때문에 2이 매개 변수의 디폴트 값 및 최소값으로 간주됩니다.

MaxNoOfExecutionThreads 는 일반적으로 사용 가능한 CPU 스레드 수와 동일한 값으로 설정하고 각 유형의 스레드 수를 일반적인 워크로드에 맞게 할당하는 것을 목적으로하고 있습니다. 지정된 CPU에 특정 스레드를 할당하지는 않습니다. 제공되는 설정을 변경하는 것이 바람직하거나 스레드를 CPU에 바인딩하려면 대신 필요한 유형, CPU 또는 둘 다에 직접 스레드를 할당 할 수 ThreadConfig 을 사용하도록하십시오.

멀티 스레드 데이터 노드 프로세스는 적어도 여기에 나타내는 5 개의 스레드를 항상 생성합니다.

LDM 스레드의 수를 변경하려면이 매개 변수와 ThreadConfig 중 어느 것을 사용하여 변경하는 경우에도 항상 시스템을 다시 시작해야합니다. 클러스터의 IndexMemory 의 사용률이 50 %를 초과하는 경우이를 변경하려면 클러스터의 초기 다시 시작해야합니다. (이런 경우는 최대 30-35 %의 IndexMemory 사용률이 권장됩니다.) 그렇지 않으면 노드간에 리소스 활용도 및 LDM 스레드 할당의 균형을 유지하지 못하고, 결과적으로 LDM 스레드의 이용이 불충분하거나 과도하게되고, 결국 데이터 노드에 오류가 발생합니다.

NoOfFragmentLogParts

이 ndbmtd 에 속하는 Redo 로그의 로그 파일 그룹의 수를 설정합니다. MySQL Cluster NDB 7.3.3 이전에는이 ​​값은 4에서 16까지 (이들을 포함) 4의 짝수 배수 여야합니다. MySQL Cluster NDB 7.3.3 이상에서 최대 32입니다. 이전과 마찬가지로, 값은 4의 짝수 배수 여야합니다.

ndbmtd 가 사용하는 LQH 스레드의 수가 NoOfFragmentLogParts 를 초과하지 않도록해야합니다. 또한 MaxNoOfExecutionThreads 을 늘리면이 수가 증가하는 경우가 있습니다. 자세한 내용은이 매개 변수의 설명을 참조하십시오.

ThreadConfig

이 매개 변수는 ndbmtd 에서 다른 유형의 스레드를 다른 CPU에 할당하는 데 사용됩니다. 이 값은 다음 구문을 가지는 형식의 문자열입니다.

ThreadConfig := entry[,entry[,...]]

entry := type={param[,param[,...]]}

type := ldm | main | recv | send | rep | io

param := count=number | cpubind=cpu_list

매개 변수의 목록을 둘러싸는 중 괄호 ( { ... } )는 목록에 매개 변수가 1 개 밖에없는 경우에도 필요합니다.

param (매개 변수)는 특정 유형의 스레드 수 ( count ) 특정 ​​유형의 스레드가 바인딩되는 CPU ( cpubind ) 또는 둘 모두를 지정합니다.

type 속성은 NDB 스레드 유형을 나타냅니다. MySQL Cluster NDB 7.3 이상에서 지원되는 스레드 유형과 각 유형에 허용되는 count 값의 범위를 다음 목록을 보여줍니다.