MySQL 데이터베이스 충돌의 일반적인 원인과 해결 방법은 무엇입니까?

MySQL 데이터베이스의 시작 시간을 확인하세요

Linux 시스템의 systemd 및 mysqld_safe는 mysqld 프로세스가 충돌한 후 MySQL 서비스를 자동으로 다시 시작합니다. kill -9를 사용하여 mysqld 프로세스를 자동으로 종료한다는 점에 유의해야 합니다. 시스템을 다시 시작하면 kill 명령만 사용하면 다시 시작되지 않습니다. 왜냐하면 kill 명령이 실행되면 시스템이 mysqld에 SIGTERM 신호를 보내고 mysql 데이터베이스가 정상적으로 종료되며 다음과 유사한 기록이 생성되기 때문입니다. 로그에 표시됨:

2020-10-26T09: 06:48.435181Z 0 [시스템] [MY-010910] [서버] /usr/sbin/mysqld: 종료 완료(mysqld 8.0.19) MySQL 커뮤니티 서버 - GPL .

MySQL 데이터베이스는 충돌 후 다시 시작되므로 때때로 MySQL 데이터베이스가 충돌했는지 알지 못할 수도 있지만 mysql 데이터베이스 시작 시간에서 단서를 찾을 수 있습니다. MySQL 데이터베이스 시작 시간을 확인하는 네 가지 방법은 다음과 같습니다.

MySQL 서비스 상태를 확인하면

scutech@scutech:~$ service mysql status
● mysql.service - MySQL Community Server
   Loaded: loaded (/lib/systemd/system/mysql.service; enabled; vendor preset: enabled)
   Active: active (running) since Wed 2020-10-21 05:54:18 NDT; 4 days ago
  Process: 774 ExecStart=/usr/sbin/mysqld --daemonize --pid-file=/var/run/mysqld/mysqld.pid (code=exited, status=0/SUCCESS)
  Process: 708 ExecStartPre=/usr/share/mysql/mysql-systemd-start pre (code=exited, status=0/SUCCESS)
 Main PID: 791 (mysqld)
    Tasks: 27 (limit: 2328)
   CGroup: /system.slice/mysql.service
           └─791 /usr/sbin/mysqld --daemonize --pid-file=/var/run/mysqld/mysqld.pid

MySQL 데이터베이스가 4일 넘게 실행된 것으로 표시됩니다.

MySQL에서 가동 시간 상태를 확인하세요

mysql> show global status like 'uptime';
+---------------+--------+
| Variable_name | Value  |
+---------------+--------+
| Uptime        | 428334 |
+---------------+--------+
1 row in set (0.32 sec)

이 값은 초 단위입니다. 다음은 일로 변환한 값이 4일 이상입니다.

mysql> select 428334/60/60/24;
+-----------------+
| 428334/60/60/24 |
+-----------------+
|  4.957569444444 |
+-----------------+
1 row in set (0.01 sec)

가동 시간 상태를 쿼리하는 또 다른 방법은 mysqladmin 버전을 사용하거나 mysql 클라이언트에서 "s"를 사용하여 쿼리하는 것입니다.

ps를 사용하여 프로세스 시작 시간 확인

ps 명령을 사용하여 mysqld가 시작된 지 4일, 23시간, 3분 54초 동안 쿼리하고 확인합니다.

scutech@scutech:~$ ps -eo pid,user,args,etime|grep mysqld
  791 mysql    /usr/sbin/mysqld --daemoniz  4-23:03:54

MySQL 로그 확인

키워드 찾기 "연결 준비"를 통해 시작 정보를 찾습니다.

2020-10-21T08:24:18.986765Z 0 [참고] /usr/sbin/mysqld: 연결 준비가 완료되었습니다.
버전: '5.7.28-log' 소켓: '/var/run/mysqld/mysqld. 양말' 포트: 3306 MySQL 커뮤니티 서버(GPL)

MySQL 데이터베이스 충돌의 일반적인 이유

MySQL 데이터베이스 충돌의 가장 일반적인 이유는 두 가지가 있습니다. 하나는 mysql 버그이고, 다른 하나는 mysql이 시스템 리소스를 신청하지 못하거나 메모리 누수.

MySQL 버그

MySQL 데이터베이스 충돌의 가장 일반적인 이유 중 하나는 물론 MySQL 버그입니다. 버그의 95%는 특정 SQL과 관련이 있습니다. 일반적으로 MySQL이 충돌하기 전에 실행된 마지막 SQL에 문제가 있으므로 버그를 찾을 때는 마지막 SQL을 기반으로 일반 쿼리 로그를 열어야 합니다.
충돌 원인을 파악한 후에는 일반적으로 고급 검색을 사용하여 MySQL 버그 라이브러리(https://bugs.mysql.com)를 확인하여 유사한 문제가 있는지 확인해야 합니다. 귀하와 관련된 버그를 발견하면 해당 버그가 수정되었는지 확인하세요. 수정된 경우 MySQL을 버그가 수정된 버전으로 업그레이드하세요.

각 버전의 릴리스 노트에 버그 수정 섹션이 있어 수정된 버그를 확인할 수 있습니다.

MySQL이 시스템 리소스를 적용하지 못하거나 메모리 누수

메모리가 부족하거나 MySQL이 시스템 리소스를 적용하지 못하면 디스크 공간이 가득 차거나 디스크의 파일이 손상되는 등 MySQL이 중단될 수 있습니다. 현재 충돌의 근본 원인을 찾는 방법에는 여러 가지가 있습니다.

• MySQL 오류 로그를 주의 깊게 읽으십시오. 이 로그에 있는 프로그램 디버깅 정보 중 일부는 혼란스러워 보일 수 있지만, 진정하고 주의 깊게 살펴보면, 여러 번 단서를 찾습니다.

• 일반 쿼리 로그를 열고 마지막 SQL에서 액세스한 테이블이나 인덱스를 찾아 테이블이나 인덱스를 확인하고 문제가 있으면 다시 빌드하면 일반적으로 문제가 해결됩니다.

• strace, pstack, pmap, gdb를 사용하여 mysqld의 코드를 분석하면 코어 덤프를 열어야 할 수도 있습니다.

• CMake 옵션 -DWITH_DEBUG=1을 사용하여 mysqld를 다시 컴파일한 다음 다시 컴파일된 mysqld를 실행하고 확인하세요. 추적 파일, 문제 해결을 위한 오류 로그.

MySQL 메모리 사용량 계산

글로벌 메모리
innodb_buffer_pool_size innodb_log_buffer_size thread_cache_size table_open_cache table_definition_cache key_buffer_size
스레드 메모리
binlog_cache_size thread_stack
단일 작업 메모리
join_buffer _size read_buffer_size read_rnd_buffer_size tmp_table_size sort_buffer_size

계산식
MySQL 8 계산의 최대 메모리 사용량 참조 값 공식:

SELECT ( @@innodb_buffer_pool_size + @@innodb_log_buffer_size + @@key_buffer_size 
+ @@max_connections * (@@binlog_cache_size + @@thread_stack + @@read_buffer_size 
+ @@read_rnd_buffer_size + @@sort_buffer_size + @@join_buffer_size + @@tmp_table_size ) 
) / 1024 /1024 AS MAX_MEM_MB;

innodb_buffer_pool_size

• key_buffer_size

• max_connections*(sort_buffer_size+read_buffer_size+binlog_cache_size)

• max_connections*2MB

임시 해결책으로 다음 명령을 사용하여 캐시를 해제할 수 있습니다. :

echo 1 > /proc/sys/vm/drop_caches

0 : 0은 기본적으로 메모리가 해제되지 않으며 운영 체제에서 자동으로 관리됨을 의미합니다. 2: 덴트리 및 inode를 모두 해제합니다. 장기적으로는 해당 매개변수를 수정해야 합니다.

MySQL 클라이언트 메모리 누수

MySQL 클라이언트 메모리 누수에는 일반적으로 다음과 같은 메시지가 나타납니다

mysql: 42행 'malloc.c'에서 메모리 부족
mysql: 8136바이트(8k) 필요, 사용 중인 메모리: 12481367바이트(12189k)
ERROR 2008: MySQL 클라이언트에 메모리 부족

이것은 일반적으로 클라이언트가 수신한 반환 결과 집합이 너무 크기 때문에 발생합니다. 해결 방법은 두 가지입니다.

실행 중인 SQL을 확인하여 이렇게 큰 반환 결과 집합이 정말로 필요한지 확인하세요.
--quick 옵션을 사용하여 mysql을 허용하면 클라이언트가 한 번에 수신하는 반환 세트가 줄어들지만 mysqld의 로드가 늘어납니다.

위 내용은 MySQL 데이터베이스 충돌의 일반적인 원인과 해결 방법은 무엇입니까?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!