Loading...
MySQL 9.5 Reference Manual 9.5의 7.1.19 The Server Shutdown Process의 한국어 번역본입니다.
아래의 경우에 피드백에서 신고해주신다면 반영하겠습니다.
감사합니다 :)
서버 shutdown 프로세스는 다음과 같이 진행됩니다:
shutdown 프로세스가 시작됩니다.
이는 여러 가지 방법으로 시작될 수 있습니다. 예를 들어,
SHUTDOWN 권한을 가진 사용자는
mysqladmin shutdown 명령을 실행할 수 있습니다.
mysqladmin은
MySQL이 지원하는 어떤 플랫폼에서도 사용할 수 있습니다.
기타 운영 체제별 shutdown 시작 방법도 가능합니다:
Unix에서는 서버가 SIGTERM 시그널을 수신하면 shutdown됩니다.
Windows에서 서비스로 실행 중인 서버는 서비스 관리자(services manager)가
shutdown을 지시하면 종료됩니다.
필요한 경우 서버가 shutdown 스레드를 생성합니다.
shutdown이 어떻게 시작되었는지에 따라, 서버는 shutdown 프로세스를 처리하기 위한
스레드를 생성할 수 있습니다. shutdown이 클라이언트에 의해 요청된 경우,
shutdown 스레드가 생성됩니다. shutdown이 SIGTERM 시그널 수신의 결과인 경우,
시그널 스레드가 직접 shutdown을 처리할 수도 있고, 이를 위해 별도의 스레드를
생성할 수도 있습니다. 서버가 shutdown 스레드 생성을 시도했으나 (예를 들어
메모리가 고갈되어) 생성할 수 없는 경우, 에러 로그에 다음과 같은
진단 메시지를 기록합니다:
1Error: Can't create thread to kill server
서버가 새로운 커넥션 수락을 중지합니다.
shutdown 중에 새로운 액티비티가 시작되는 것을 방지하기 위해, 서버는 일반적으로 커넥션을 대기(listen)하는 네트워크 인터페이스에 대한 핸들러를 닫아서 새로운 클라이언트 커넥션 수락을 중지합니다: TCP/IP 포트, Unix 소켓 파일, Windows 네임드 파이프, 그리고 Windows의 공유 메모리입니다.
서버가 현재 액티비티를 종료합니다.
클라이언트 커넥션과 연관된 각 스레드에 대해, 서버는 클라이언트와의 커넥션을
끊고 해당 스레드를 killed 상태로 표시합니다. 스레드는 자신이 이렇게 표시된
것을 인지하면 종료됩니다. idle 커넥션의 스레드는 빠르게 종료됩니다.
현재 문장을 처리 중인 스레드는 자신의 상태를 주기적으로 확인하므로
종료까지 더 오래 걸립니다. 스레드 종료에 대한 추가 정보는
Section 15.7.8.4, “KILL Statement”를 참조하십시오. 특히
killed REPAIR TABLE 또는
OPTIMIZE TABLE 작업이
MyISAM 테이블에서 수행되는 경우에 대한 지침을 참고하십시오.
열린 트랜잭션을 가진 스레드의 경우, 해당 트랜잭션은 롤백됩니다.
스레드가 비트랜잭션 테이블을 업데이트하는 중이었다면,
다중 행 UPDATE나
INSERT와 같은 작업은
완료 전에 종료될 수 있으므로 테이블이 부분적으로만 업데이트된 상태로 남을 수 있습니다.
서버가 복제 소스 서버인 경우, 현재 연결된 레플리카와 연관된 스레드를 다른 클라이언트 스레드와 동일하게 취급합니다. 즉, 각각을 killed로 표시하고 다음에 자신의 상태를 확인할 때 종료됩니다.
서버가 레플리카 서버인 경우, 클라이언트 스레드를 killed로 표시하기 전에
활성 상태라면 복제 I/O 및 SQL 스레드를 중지합니다.
SQL 스레드는 (복제 문제를 방지하기 위해) 현재 문장을
완료하도록 허용된 후 중지됩니다. 이 시점에 SQL 스레드가 트랜잭션 중간인
경우, 서버는 현재 복제 이벤트 그룹(있다면)의 실행이 완료되거나,
사용자가 KILL QUERY 또는
KILL CONNECTION 문장을
실행할 때까지 대기합니다. 또한
Section 15.4.2.5, “STOP REPLICA Statement”도
참조하십시오. 비트랜잭션 문장은 롤백될 수 없으므로,
크래시 세이프 복제를 보장하려면 트랜잭션 테이블만 사용해야 합니다.
참고
레플리카에서 크래시 세이프를 보장하려면,
--relay-log-recovery가
활성화된 상태로 레플리카를 실행해야 합니다.
또한 Section 19.2.4, “Relay Log and Replication Metadata Repositories”)를 참조하십시오.
서버가 스토리지 엔진을 shutdown하거나 close합니다.
이 단계에서 서버는 테이블 캐시를 플러시하고 모든 열린 테이블을 닫습니다.
각 스토리지 엔진은 자신이 관리하는 테이블에 대해 필요한 작업을 수행합니다.
InnoDB는 버퍼 풀을 디스크로 플러시하고
(단, innodb_fast_shutdown
값이 2인 경우는 제외), 현재 LSN을 테이블스페이스에 기록하며,
자체 내부 스레드를 종료합니다. MyISAM은 테이블에 대해
대기 중인 인덱스 쓰기를 플러시합니다.
서버가 종료(exits)합니다.
관리 프로세스에 정보를 제공하기 위해, 서버는 다음 목록에 설명된 exit 코드 중 하나를 반환합니다. 괄호 안의 문구는, systemd가 서버를 관리하는 플랫폼에서 systemd가 해당 코드에 응답하여 수행하는 동작을 나타냅니다.
0 = 정상 종료(successful termination) (재시작 없음)
1 = 비정상 종료(unsuccessful termination) (재시작 없음)
2 = 비정상 종료(unsuccessful termination) (재시작 수행됨)
7.1.18 Server Tracking of Client Session State
7.2 The MySQL Data Directory