Apache httpd와 같이 mysql을 정상적으로 다시 시작합니까?


29

다시 시작하기 전에 스레드가 제공되는 httpd와 마찬가지로 mysql을 정상적으로 다시 시작하고 싶습니다. 검색어가 마음에 들지 않습니다.

답변:


37

트랜잭션 테이블에서 진행중인 트랜잭션이 롤백되기 때문에 MySQL의 "요청 된"셧다운 시퀀스 ( kill -9)가 다소 우아 합니다.

참고 : 업그레이드를 위해 서버를 종료하는 경우이 프로세스를 사용하지 마십시오. 대신 이 답변에 설명 된 프로세스를 따르십시오 .

그렇지 않으면, 건강에 해로운 서버를 다시 시작하여 읽기 전용 전역 변수 또는 이와 유사한 것을 변경할 수있는 경우 다음과 같은 우아한 경로가 있습니다.

먼저 innodb_fast_shutdown그렇지 않은 경우 활성화 하십시오. 이것은 시스템 종료의 우아함과 직접 관련이 없지만 서버를 더 빨리 되돌릴 수 있습니다.

mysql> SHOW VARIABLES LIKE 'innodb_fast_shutdown';
+----------------------+-------+
| Variable_name        | Value |
+----------------------+-------+
| innodb_fast_shutdown | 0     |
+----------------------+-------+
1 row in set (0.00 sec)

mysql> SET GLOBAL innodb_fast_shutdown = 1;
Query OK, 0 rows affected (0.01 sec)

다음으로, 현재 실행중인 쿼리가 참조하지 않는 즉시 열려있는 모든 테이블을 닫도록 서버에 지시하십시오. 이 단계는 또한 정상 종료와 관련이 없지만 후속 단계가 더 빨라집니다.

mysql> FLUSH LOCAL TABLES;
Query OK, 0 rows affected (41.12 sec)

FLUSH TABLES(옵션에 문 LOCAL어떤 노예의 불필요한하지만, 그렇지 않으면 해가 높이를 피할 키워드) 차단 및 모든 테이블이 폐쇄 될 때까지 프롬프트 의지는 반환하지. 각 테이블이 "플러시"(닫힘) 된 후 쿼리가 테이블을 참조하는 경우 자동으로 다시 열리지 만 괜찮습니다. 우리가이 단계에서 달성하고있는 것은 마지막 단계에서 더 적은 작업을하는 것입니다.

mysql> FLUSH TABLES WITH READ LOCK;
Query OK, 0 rows affected (13.74 sec)

mysql>

이 명령문은 모든 테이블을 플러시하므로 (이전 단계에서 방해가되지 않는 일부 이점을 얻을 수있는 이점) 글로벌 (서버 전체) 읽기 전용 잠금을 획득합니다.

현재 실행중인 모든 "쓰기"쿼리 (예 : 거의 모든 것 SELECT)가 완료 될 때까지 전역 읽기 잠금을 가질 수 없습니다 . 잠금 요청을 발행하면 기존 쿼리를 완료 할 수 있지만 새 쿼리를 시작할 수는 없습니다.

이 전역 잠금 보유 할 때까지 프롬프트가 반환되지 않으므로 잠금을 요청할 때 진행중인 모든 쿼리를 완료 할 수 있으며 프롬프트가 다시 표시되므로 완료된 것을 알 수 있습니다. 테이블에 무엇이든 쓰려고 시도하는 후속 쿼리는 중단되어 데이터를 변경하지 않고 잠금을 무기한 대기 할 때까지 기다립니다.

  • 다시 시작에 대한 생각을 바꾸고 수동으로 잠금을 해제하십시오 ( UNLOCK TABLES;)
  • 서버를 다시 시작하거나
  • 실수로 또는 의도적으로이 스레드에서 명령 행 클라이언트를 분리하십시오 (그렇지 마십시오). 이 창을 연결하고 mysql 프롬프트에 앉아 있으십시오.

이것을 닫으려는 유혹에 저항하십시오.

mysql>

이 유휴 콘솔 프롬프트는 전역 잠금을 유지하는 것입니다. 이걸 잃어 버려 자물쇠를 잃어 버려

다른 콘솔 창에서 초기화 스크립트 (예 : 로컬 변형 service mysql.server restart)를 사용하거나 mysqladmin shutdown수동으로 다시 시작하여 일반적인 방식으로 MySQL을 다시 시작하십시오.


사용합니까 innodb_fast_shutdown = 1MySQL이 빨리 시작되도록 정말? 문서를 살펴보면 종료 속도가 향상되는 것 같습니다 (시작 속도 비용이 들지 않습니까).
Chris

@Chris의 아이디어는 전체 셧다운 + 스타트 업이 실용적으로 빠르다는 것을 보장하는 데 도움이되지만, 수행되는 작업량이 이론적으로 동일하지만 시퀀스의 다른쪽으로 이동했기 때문에 다소 일화 적입니다. 어떤 이유로 든 시작시 존재하지 않는 종료시 발생하는 방식에 약간의 비 효율성이있는 것처럼 일반적으로 전체적으로 항상 더 빠른 것처럼 보였습니다. 말하기 어렵다.
Michael-sqlbot

2

간단히 말해 MySQL을 종료하기 전에 고려해야 할 모범 사례는 다음과 같습니다.

  1. 실수로 다른 인스턴스를 중지하지 않도록 종료하려는 인스턴스를 확인하십시오.
  2. 슬레이브를 종료하려면 복제를 중지하십시오 mysql> STOP SLAVE;.
  3. 더티 페이지를 미리 플러시하여 종료 시간을 줄 mysql> SET GLOBAL innodb_max_dirty_pages_pct = 0;입니다.
  4. 장기 실행 쿼리를 확인 mysql> SHOW PROCESSLIST;, 그들을 죽일 mysql> kill thread_id;하거나 마칠 때까지 기다립니다.
  5. 종료시 버퍼 풀을 덤프하고 mysql> SET GLOBAL innodb_buffer_pool_dump_at_shutdown = ON;시작시 다시로드 # vi /etc/my.cnf innodb_buffer_pool_load_at_startup = ON 하여 버퍼 풀을 예열하십시오.

그런 다음 이전 사항을 확인한 후 안전하게 MySQL을 다시 시작할 수 있습니다 shell$ service mysql restart

자세한 내용은 내 게시물을 참조하십시오 MySQL을 종료하기 전에 이것들을 확인하십시오!


이것이 왜 하향 조정 되었습니까? 어떤 명령이 나쁜지 알기에는 충분하지 않지만 명령을 피하기 위해 알고 싶습니다.
Jon

위의 어느 것도 나쁜 명령인지 모르겠습니다. 위의 단계를 따르고 있으며 많은 사람들이 있습니다. 4 단계 만주의해야합니다. 수행중인 작업을 확신 할 때까지 쿼리를 종료해서는 안됩니다. 그렇지 않으면 장기 실행 쿼리가 완료 될 때까지 기다리십시오. 시도해보고 도움이된다면, 그것을 피하십시오. 그렇지 않으면 그것을 피하십시오!
Moll
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.