--bind-address= host [: port ]

이 옵션을 지정하면 관리 클라이언트가 관리 서버에 연결이 지정된 호스트 이름 또는 IP 주소 (및 포트 (지정된 경우)) 클라이언트 제한됩니다. 이 경우 다른 주소에서 관리 서버에 연결을 시도하는 관리 클라이언트는 다음과 같은 오류가 발생하고 실패합니다. Unable to setup port : host : port !

port 를 지정하지 않는 경우, 관리 클라이언트는 포트 1186를 사용하는 것을 시도합니다.

--no-nodeid-checks

노드 ID 검사를 수행하지 않습니다.

--configdir= path

클러스터 관리 서버의 구성 캐시 디렉토리를 지정합니다. --config-dir 은이 옵션의 별칭입니다.

--config-cache

이 옵션 (기본값은 1 (또는 TRUE , ON ))는 관리 서버가 시작할 때마다 config.ini 에서 구성이 읽도록 ( 섹션 18.3.2 "MySQL Cluster 구성 파일" 을 참조하십시오 ) 구성 캐시를 비활성화하기 위해 사용할 수 있습니다. 이렇게하려면 다음 옵션 중 하나를 지정하여 ndb_mgmd 프로세스를 시작합니다.

열거 된 옵션 중 하나를 사용 활성화되는 것은 관리 서버가 시작되었을 때에 저장되어있는 구성이없는 경우입니다. 관리 서버가 구성 캐시 파일을 찾을 때 --config-cache 옵션 또는 --skip-config-cache 옵션은 무시됩니다. 따라서 구성 캐시를 비활성화하려면 관리 서버를 처음 시작할 때이 옵션을 사용하십시오. 그렇지 않으면, 즉 구성 캐시가 이미 작성되어있는 관리 서버의 구성 캐시를 비활성화하려면 관리 서버를 중지하고 기존 구성 캐시 파일을 수동으로 삭제하고, --skip-config-cache 를 지정하고 (또는 --config-cache 0, OFF 또는 FALSE 를 설정하고) 관리 서버를 다시 시작해야합니다.

구성 캐시 파일은 일반적으로 설치 디렉토리 아래의 mysql-cluster 라는 디렉토리에 생성됩니다 ( --configdir 옵션을 사용하여이 위치를 재정의되지 않은 경우). 관리 서버가 구성 데이터를 업데이트 할 때마다 새로운 캐시 파일이 생성됩니다. 이 파일은 다음 형식을 사용하여 만든 순으로 연속 된 이름이 있습니다.

ndb_node-id_config.bin.seq-number

node-id 는 관리 서버의 노드 ID이며, seq-number 는 1부터 시작 시퀀스 번호입니다. 예를 들어, 관리 서버의 노드 ID가 5의 경우, 처음 세 개의 구성 캐시 파일이 생성 될 때 ndb_5_config.bin.1 , ndb_5_config.bin.2 및 ndb_5_config.bin.3 라는 이름을 붙일 수 있습니다.

실제로 캐시를 비활성화하지 않고 구성 캐시를 제거 또는 다시로드하는 경우, --skip-config-cache 옵션 대신 --reload 옵션 또는 --initial 옵션 중 하나를 지정하여 ndb_mgmd를 시작합니다 하십시오.

구성 캐시를 다시 활성화하려면 구성 캐시를 비활성화하기 위해 이전에 사용 된 --config-cache 옵션 또는 --skip-config-cache 옵션을 지정하지 않고 관리 서버를 다시 시작합니다.

--skip-config-cache 가 사용 된 경우 ndb_mgmd는 구성 디렉토리 ( --configdir )을 확인하지 않고 만들려고합니다. (Bug # 13428853)

--config-file= filename , -f filename

구성 파일로서 사용해야 할 파일을 관리 서버에 지시합니다. 기본적으로 관리 서버는 ndb_mgmd 실행 파일과 같은 디렉토리에서 config.ini 라는 파일을 찾습니다. 그렇지 않으면 파일 이름과 위치를 명시 적으로 지정해야합니다.

이 옵션은 기본값이 아닌 --reload 또는 --initial 옵션을 지정하고 ndb_mgmd가 시작되었는지 관리 서버가 구성 캐시를 찾을 수 없었기 때문에 관리 서버 구성 파일을 읽도록 강제 된 경우를 제외하고 무시됩니다. 이 옵션은 --config-cache=OFF 를 지정하고 ndb_mgmd가 시작되는 경우도 읽습니다. 자세한 내용은 섹션 18.3.2 "MySQL Cluster 구성 파일" 을 참조하십시오.

이전에는이 ​​옵션을 --initial 와 함께 사용하면 파일을 찾을 수 없어도 구성 캐시가 삭제되었습니다. 이 문제는 MySQL Cluster NDB 7.3.2에서 해결되었습니다. (Bug # 1299289)

--mycnf

my.cnf 파일에서 구성 데이터를 읽습니다.

--daemon , -d

ndb_mgmd에 데몬 프로세스로 시작하도록 지시합니다. 이것은 기본 동작입니다.

이 옵션은 ndb_mgmd를 Windows 플랫폼에서 실행하는 경우는 효과가 없습니다.

--interactive

ndb_mgmd를 대화 형 모드에서 시작합니다. 즉, 관리 서버가 실행되면 즉시 ndb_mgm 클라이언트 세션이 시작됩니다. 이 옵션은 다른 MySQL Cluster 노드를 시작하지 않습니다.

--initial

구성 데이터는 관리 서버가 시작될 때마다 클러스터 글로벌 구성에서 읽은 것이 아니라 내부적으로 캐시됩니다 ( 섹션 18.3.2 "MySQL Cluster 구성 파일" 을 참조하십시오). --initial 옵션을 사용하면이 동작을 재정의 관리 서버가 기존의 캐시 파일을 삭제하고 클러스터 구성 파일에서 구성 데이터를 다시 읽고 새로운 캐시를 작성하도록 강요됩니다.

이것은 두 가지 점에서 --reload 옵션과 다릅니다. 먼저 --reload 을 지정하면 서버가 구성 파일을 캐시와 비교하여 파일의 내용이 캐시와 다른 경우에만 데이터를 다시로드 할 수 강제됩니다. 둘째로, --reload 는 기존의 캐시 파일을 삭제하지 않습니다.

--initial 을 지정하고 ndb_mgmd가 호출되었지만 글로벌 구성 파일이없는 경우 관리 서버를 시작할 수 없습니다.

관리 서버가 시작되면 동일한 MySQL Cluster 내의 다른 관리 서버를 확인하고 다른 관리 서버 구성 데이터를 사용하는 것을 시도합니다. ndb_mgmd는 그것이 실행되는 유일한 관리 서버 인 경우를 제외하고 --initial 을 무시합니다. 이 동작은 여러 관리 노드를 가진 MySQL Cluster에서 롤링 재시작을 수행 할 경우에도 영향을줍니다. 자세한 내용은 섹션 18.5.5 "MySQL Cluster의 롤링 다시 부팅 수행" 을 참조하십시오.

이전에는이 ​​옵션을 --config-file 옵션과 함께 사용하면 파일을 찾을 수 없어도 구성 캐시가 삭제되었습니다. MySQL Cluster NDB 7.3.2 이상에서는 구성 파일이 실제로 발견 된 경우에만 캐시가 그렇게 지워집니다. (Bug # 1299289)

--log-name= name

클러스터 로그에서이 노드에 사용되는 이름을 지정합니다.

--nodaemon

ndb_mgmd에 데몬 프로세스로 시작하지 않도록 지시합니다.

Windows에서 ndb_mgmd의 기본 동작은 포 그라운드에서 실행하기 때문에 Windows 플랫폼에서는이 옵션이 필요하지 않습니다.

--print-full-config , -P

클러스터 구성에 대한 자세한 정보를 표시합니다. 이 옵션을 명령 행에 지정하면 ndb_mgmd 프로세스는 클러스터 구성 정보 (클러스터 구성 섹션의 자세한 목록 및 매개 변수와 값 포함)를 출력합니다. 일반적으로 --config-file ( -f ) 옵션과 함께 사용합니다.

--reload

MySQL Cluster NDB 7.3에서는 구성 데이터는 관리 서버가 시작될 때마다 클러스터 글로벌 구성에서 읽은 것이 아니라 내부에 저장됩니다 ( 섹션 18.3.2 "MySQL Cluster 구성 파일" 을 참조 하십시오). 이 옵션을 사용하면 관리 서버가 내부 데이터 저장소를 클러스터 구성 파일과 비교하고 구성 파일이 캐시와 일치하지 않는 것을 발견 한 경우에는 구성을 다시로드하도록 강요합니다. 기존 구성 캐시 파일은 유지되지만 사용되지 않습니다.

이것은 두 가지 점에서 --initial 옵션과 다릅니다. 첫째, --initial 에서는 모든 캐시 파일이 삭제됩니다. 둘째로, --initial 은 글로벌 구성 파일을 다시 읽고 새로운 캐시를 만들 것을 관리 서버에 적용합니다.

관리 서버가 글로벌 구성 파일을 찾을 수없는 경우 --reload 옵션은 무시됩니다.

관리 서버가 시작되면 동일한 MySQL Cluster 내의 다른 관리 서버를 확인하고 다른 관리 서버 구성 데이터를 사용하는 것을 시도합니다. ndb_mgmd는 그것이 실행되는 유일한 관리 서버 인 경우를 제외하고 --reload 을 무시합니다. 이 동작은 여러 관리 노드를 가진 MySQL Cluster에서 롤링 재시작을 수행 할 경우에도 영향을줍니다. 자세한 내용은 섹션 18.5.5 "MySQL Cluster의 롤링 다시 부팅 수행" 을 참조하십시오.

--nowait-nodes

MySQL Cluster는 시작되면 2 개의 관리 노드로 구성되며, 일반적으로 각 관리 서버는 다른 ndb_mgmd 작동하고 있는지 여부와 다른 관리 서버의 구성이 그 자체의 구성과 일치하는지 여부 을 확인합니다. 그러나 클러스터를 하나의 관리 노드에서만 시작할 수 (및 아마 다른 ndb_mgmd를 나중에 시작하는 것을 허용하는 것)하는 경우도 있습니다. 이 옵션을 지정하면이 옵션에 전달 된 노드 ID를 가진 다른 관리 노드를 관리 노드가 확인하지 않고 부팅 된 관리 노드만을 사용하도록 구성되어있는 것처럼 클러스터가 시작 것을 허용합니다.

설명을 위해, config.ini 파일에 다음 부분이 있다고합니다 (여기에서는이 예에 관련되지 않은 대부분의 구성 매개 변수를 생략합니다).

[ndbd]
NodeId = 1
HostName = 192.168.0.101

[ndbd]
NodeId = 2
HostName = 192.168.0.102

[ndbd]
NodeId = 3
HostName = 192.168.0.103

[ndbd]
NodeId = 4
HostName = 192.168.0.104

[ndb_mgmd]
NodeId = 10
HostName = 192.168.0.150

[ndb_mgmd]
NodeId = 11
HostName = 192.168.0.151

[api]
NodeId = 20
HostName = 192.168.0.200

[api]
NodeId = 21
HostName = 192.168.0.201

노드 ID가 10 에서 IP 주소가 192.168.0.150 호스트에서 실행되는 관리 서버 만 사용하여 클러스터를 시작합니다. (예를 들어, 다른 관리 서버를 실행하려는 호스트 컴퓨터가 하드웨어 장애로 인해 일시적으로 사용하지 못하고 그것이 복구되는 것을 기다리고 있다고 가정합니다). 이 클러스터를 시작하려면 192.168.0.150 기계 명령 행을 사용하여 다음 명령을 입력합니다.

shell> ndb_mgmd --ndb-nodeid=10 --nowait-nodes=11

앞의 예제에 표시된대로 --nowait-nodes 를 사용하는 경우 --ndb-nodeid 옵션도 사용이 ndb_mgmd 프로세스 노드 ID를 지정해야합니다.

그 후, 클러스터의 각 데이터 노드를 일반적인 방법으로 시작할 수 있습니다. 첫 번째 관리 서버에 추가하여 나중에 데이터 노드를 다시 시작하지 않고 두 번째 관리 서버를 시작하고 사용하려면 두 관리 서버를 참조하는 연결 문자열을 다음과 같이 지정 각 데이터 노드를 시작해야합니다.

shell> ndbd -c 192.168.0.150,192.168.0.151

mysqld 프로세스 중이 클러스터에 연결되는 MySQL Cluster SQL 노드로 시작하는 데 사용되는 연결 문자열에 관해서도 마찬가지입니다. 자세한 내용은 섹션 18.3.2.3 "MySQL Cluster의 연결 문자열" 을 참조하십시오.

ndb_mgmd 함께 사용하면이 옵션은 다른 관리 노드에 대해서만 관리 노드의 동작에 영향을줍니다. ndbd 또는 ndbmtd (전량보다 적은 수의 데이터 노드에서 클러스터를 시작할 수)에 사용되는 --nowait-nodes 옵션과 혼동하지 마십시오. 이 옵션을 데이터 노드에 사용하면 다른 데이터 노드에 관련된 동작에만 영향을줍니다.

여러 관리 노드 ID는 쉼표로 구분 된 목록으로이 옵션에 전달할 수 있습니다. 각 노드 ID는 1에서 255까지 여야합니다. 사실, 같은 MySQL Cluster에 3 개 이상의 관리 서버를 사용하는 것은 (또는 그렇게 할 필요가있는 것은) 매우 드문 경우입니다. 대부분의 경우이 옵션을 전달할 필요가있는 클러스터를 시작할 때 사용하지 않는 하나의 관리 서버의 단일 노드 ID뿐입니다.

config.ini 는 클러스터 전체의 구성 파일입니다. 이 파일은 사용자가 만들고 관리 서버에 의해 읽혀집니다. 섹션 18.3 "MySQL Cluster 구성" 에서이 파일을 설치하는 방법을 설명하고 있습니다.

ndb_ node_id _cluster.log 는 클러스터 이벤트 로그 파일입니다. 이러한 이벤트의 예로는 체크 포인트의 시작과 완료 노드의 시작 이벤트 노드의 장애 및 메모리 사용률 수준이 포함됩니다. 클러스터 이벤트의 전체 목록과 그 설명은 섹션 18.5 "MySQL Cluster 관리" 에 있습니다.

클러스터 로그가 백만 바이트에 도달하면 파일이 ndb_ node_id _cluster.log. seq_id 이름 변경됩니다. 여기에서 seq_id 은 클러스터 로그 파일의 시퀀스 번호입니다 (예를 들어, 시퀀스 번호 1,2,3을 가진 파일이 이미 존재하는 경우, 다음 로그 파일 번호 4 를 사용하여 이름을 붙일 수 있습니다).

ndb_ node_id _out.log 은 관리 서버가 데몬으로 실행되고있을 때, stdout 및 stderr 를 위해 사용되는 파일입니다.

ndb_ node_id .pid 은 관리 서버를 데몬으로 실행하는 데 사용되는 프로세스 ID 파일입니다.

--install[= name ]

ndb_mgmd가 Windows 서비스로 설치됩니다. 필요에 따라 서비스의 이름을 지정할 수 있습니다. 설정하지 않으면 서비스 이름은 ndb_mgmd 기본 설정됩니다. 기타 ndb_mgmd 프로그램 옵션은 my.ini 또는 my.cnf 구성 파일에 지정하는 것이 좋습니다되지만, --install 과 함께 사용할 수 있습니다. 그러나 그런 경우 Windows 서비스 설치가 성공하려면 --install 옵션을 먼저 지정하고 다른 옵션을 지정해야합니다.

이 옵션을 --initial 옵션과 함께 사용하는 것은 일반적으로 권장되지 않습니다. 서비스가 중지 및 시작될 때마다 구성 캐시가 삭제되고 다시 생성되기 때문입니다. 관리 서버의 부팅에 영향을 다른 ndb_mgmd 옵션을 사용하는 경우에도주의해야하며, 그것을 할 ​​것을 충분히 이해하고 발생할 수있는 결과에 대해 충분히 준비하고 있는지 제대로 확인 하십시오.

--install 옵션은 Windows 이외의 플랫폼에서는 효과가 없습니다.

--remove[= name ]

Windows 서비스로 이전에 설치된 ndb_mgmd 프로세스가 삭제됩니다. 필요에 따라 제거 할 서비스의 이름을 지정할 수 있습니다. 설정하지 않으면 서비스 이름은 ndb_mgmd 기본 설정됩니다.

--remove 옵션은 Windows 이외의 플랫폼에서는 효과가 없습니다.