>데이터 베이스 >MySQL 튜토리얼 >MySQL 최적화 - MySQL 인스턴스를 안전하게 종료하는 방법에 대한 자세한 설명

MySQL 최적화 - MySQL 인스턴스를 안전하게 종료하는 방법에 대한 자세한 설명

黄舟
黄舟원래의
2017-03-10 10:46:341083검색


종료 프로세스:

  • 1. 종료를 시작하고 SIGTERM 신호를 보냅니다.

  • 2. 필요한 경우 새 종료 스레드를 생성하세요.

클라이언트가 종료를 시작하면 전용 종료 스레드가 생성됩니다.

직접 수신되는 경우 SIGTERM 신호가 꺼지면 신호 처리를 담당하는 스레드가 종료 작업을 담당하거나 이 문제를 담당하기 위해 새로운 독립 스레드가 생성됩니다.

독립 종료 스레드를 생성할 수 없는 경우(예: 예, 메모리 부족) MySQL 서버는 다음과 유사한 경고 메시지를 표시합니다.

오류: 서버를 종료할 스레드를 생성할 수 없습니다

  • MySQL 서버 더 이상 새로운 연결 요청에 응답하지 않습니다

TCP/IP 네트워크 모니터링을 닫고 Unix 소켓 및 기타 채널을 닫습니다

  • 4. 및 트랜잭션

유휴 연결은 즉시 종료됩니다.

현재 트랜잭션 및 SQL 활동이 있는 연결은 종료된 것으로 표시되며 상태가 정기적으로 확인됩니다. 다음 검사에서 닫힐 수 있습니다. ( KILL 구문 참조)

현재 활성 트랜잭션이 있는 경우 트랜잭션이 아닌 테이블도 트랜잭션에서 수정되면 해당 트랜잭션이 롤백됩니다. 데이터는 롤백할 수 없으며 일부 변경만 완료될 수 있습니다.

마스터/슬레이브 복제 시나리오에서 마스터인 경우 복제 스레드의 처리는 일반 스레드와 동일합니다. ;

마스터/슬레이브 복제 시나리오에서 슬레이브인 경우 IO 및 SQL 스레드를 차례로 닫습니다. 이 두 스레드가 현재 활성화된 경우에도 종료된 것으로 표시되고 닫힙니다.

슬레이브 서버에서는 SQL 스레드가 현재 SQL 작업을 직접 중지한 다음(복제 문제를 방지하기 위해) 스레드를 닫는 것이 허용됩니다.

MySQl 5.0.80 및 이전 버전에서는 버전에서는 SQL 스레드가 중간에 트랜잭션을 실행하는 경우 트랜잭션이 롤백됩니다. 5.0부터는 사용자가 KILL 작업을 시작하지 않는 한 모든 작업이 끝날 때까지 기다립니다.

비트랜잭션 테이블에서 작업을 수행할 때 슬레이브의 SQL 스레드가 강제로 KILL되면 마스터와 슬레이브 데이터 간에 불일치가 발생할 수 있습니다.

  • MySQL 서버 프로세스가 종료됩니다. 모든 스레드가 종료되고, 모든 스토리지 엔진이 종료됩니다.

모든 테이블 캐시를 새로 고치고, 열려 있는 모든 테이블을 닫습니다.

각 스토리지 엔진은 관련 종료 작업을 담당합니다. 기록 대기 중인 모든 작업은 플러시됩니다. InnoDB는 버퍼 풀을 디스크로 플러시하고(MySQL 5.0.5부터 innodb_fast_shutdown이 2로 설정되지 않은 경우) 현재 LSN을 테이블 공간에 기록한 다음 모든 내부 스레드를 닫습니다.

  • 6. MySQL Server 프로세스 종료

KILL 명령에 대하여

KILL은 5.0부터 두 가지 CONNECTION | QUERY 선택적 옵션:

  • KILL CONNECTION은 원래 것과 동일하며 트랜잭션 롤백을 중지하고 스레드 연결을 닫고 관련 리소스를 해제합니다.

  • KILL QUERY는 스레드가 실행하기 위해 현재 제출한 작업만 중지하고 다른 모든 것은 변경하지 않습니다.

KILL 작업을 제출한 후 특수 종료 플래그가 설정됩니다. 실. 종료 플래그 비트는 특정 상황에서만 확인되므로 실제로 스레드를 닫는 데는 시간이 걸립니다.

  • 1 ORDER BY 또는 GROUP BY에서 SELECT 쿼리를 실행할 때. loop , 행 레코드 블록을 읽을 때마다 킬(kill) 표시 비트가 있는지 확인합니다.

  • 2. 매번 원래 테이블에서 일부 행 레코드 블록을 읽은 후 킬(kill) 표시 비트가 존재하는 것으로 확인되면 명령문이 종료되고 임시 테이블이 삭제됩니다. 3. UPDATE 및 DELETE를 실행할 때 일부 행 레코드를 읽을 때마다 행 레코드 블록이 업데이트되거나 삭제된 후 킬 플래그 비트가 존재하는 것으로 확인되면 명령문이 종료되고 트랜잭션이 종료됩니다. 롤백됩니다. 트랜잭션이 아닌 테이블에 있는 경우 변경된 데이터는 롤백되지 않습니다.

  • 4. GET_LOCK() 함수는 NULL을 반환합니다. >

    5. INSERT DELAY 스레드는 메모리에 새 레코드를 빠르게 추가한 다음 종료합니다.
  • 6. 해제되고 종료됩니다.
  • 7. 스레드의 쓰기 작업 호출이 디스크 공간 해제를 기다리고 있으면 "디스크 공간이 가득 참" 오류가 발생하고 종료됩니다. 🎜>
  • 8. REPAIR TABLE 또는 OPTIMIZE TABLE 실행 시 MyISAM 테이블이 KILL되면 테이블이 손상되어 사용할 수 없게 되며 가이드를 사용하여 다시 복구합니다.

  • MySQL을 안전하게 종료하기 위한 몇 가지 제안

  • mysqld 서비스 프로세스를 안전하게 종료하려면 다음 단계를 따르는 것이 좋습니다.
  • 0. MySQL에 연결하려면 SUPER 및 ALL과 같은 가장 높은 권한을 가진 계정을 사용하십시오.

1. 위에서 innodb_fast_shutdown = 1 을 설정하면 InnoDB를 빠르게 종료할 수 있습니다(전체 제거, 버퍼 병합 삽입 없음). MySQL 버전을 업그레이드하거나 다운그레이드하려면 설정하지 마세요.

  • 2. InnoDB가 모든 더티 페이지를 디스크로 플러시하도록 innodb_max_dirty_pages_pct = 0으로 설정합니다.

  • 3. max_connections 및 max_user_connections를 1로 설정합니다. 즉, 현재 연결을 제외하고는 새로운 연결이 생성되지 않습니다. >4 , 상태가 Sleep이고 Time이 1보다 큰 스레드 ID를 모두 닫습니다.

  • 5. SHOW PROCESSLIST를 실행하여 활성 스레드가 있는지 확인합니다. 특히 대규모 데이터 세트가 포함된 SELECT, 대규모 UPDATE 또는 DDL 실행과 같은 테이블 잠금 스레드가 있는 경우에는 특히 주의해야 합니다.

  • 6. History list length 값이 낮다(일반적으로 500 미만), 즉 unPURGEd 트랜잭션이 거의 없음을 확인하고, Log Sequence number, Log Flush up to, Last checkpoint at 값이 확인됨 즉, 모든 LSN 체크포인트가 생성되었습니다.

  • 7. 그런 다음 FLUSH LOCKAL TABLES 작업을 수행하고, 모든 테이블 캐시를 새로 고치고, 열려 있는 테이블을 닫습니다. LOCAL은 이 작업이 BINLOG를 기록하지 않는다는 것입니다) ;

  • 8. SLAVE 서버인 경우 먼저 IO_THREAD를 닫고 RELAY LOG가 모두 소모될 때까지 기다리는 것이 가장 좋습니다. 그런 다음 대규모 트랜잭션을 실행할 때 SQL_THREAD가 종료되지 않도록 SQL_THREAD를 닫습니다. 모든 애플리케이션이 완료된 후 강제 종료해야 하는 경우 SQL_THREAD를 닫기 전에 대규모 트랜잭션이 완료될 때까지 기다리는 것이 가장 좋습니다.

  • 9. 마지막으로 mysqladmin shutdown을 실행합니다.
  • 10. 긴급 상황에서는 innodb_fast_shutdown = 1로 설정한 다음 mysqladmin shutdown을 직접 실행하거나 운영 체제 계층에서 kill 또는 kill -9를 직접 호출하여 mysqld를 종료할 수도 있습니다. 프로세스(innodb_flush_log_at_trx_commit = 0일 때 일부 트랜잭션이 손실될 수 있음)이지만 mysqld 프로세스가 다시 시작되면 CRASH RECOVERY가 수행되므로 이를 측정해야 합니다.
  • 말씀드린 대로, 실제로 정상적인 상황에서는 mysqladmin shutdown을 실행하는 것만으로도 충분합니다. 막힘이 발생하면 위 내용을 참조하여 분석하고 해결하세요.

위 내용은 MySQL 최적화 - MySQL 인스턴스를 안전하게 종료하는 방법에 대한 자세한 설명의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!

성명:
본 글의 내용은 네티즌들의 자발적인 기여로 작성되었으며, 저작권은 원저작자에게 있습니다. 본 사이트는 이에 상응하는 법적 책임을 지지 않습니다. 표절이나 침해가 의심되는 콘텐츠를 발견한 경우 admin@php.cn으로 문의하세요.