MySQL은 추락하고 시작되지 않습니다


19

우리의 프로덕션 mysql 서버가 방금 추락하여 다시 나타나지 않습니다. segfault 오류가 발생했습니다. 나는 재부팅을 시도했지만 다른 무엇을 시도 해야할지 모르겠다. 스택 추적은 다음과 같습니다.

140502 14:13:05 [참고] 플러그인 'FEDERATED'가 비활성화되었습니다.
InnoDB : 로그 스캔이 체크 포인트 lsn 108 1057948207을 지나서 진행되었습니다.
140502 14:13:06 InnoDB : 데이터베이스가 정상적으로 종료되지 않았습니다!
InnoDB : 응급 복구 시작.
InnoDB : .ibd 파일에서 테이블 스페이스 정보 읽기 ...
InnoDB : 이중 쓰기에서 가능한 반 쓰기 데이터 페이지 복원
InnoDB : 버퍼 ...
InnoDB : 복구 중 : 로그 시퀀스 번호 108 1058059648까지 스캔
InnoDB : 롤백 또는 정리해야하는 1 개의 트랜잭션
InnoDB : 실행 취소 할 총 15 개의 행 작업
InnoDB : Trx ID 카운터는 0 562485504
140502 14:13:06 InnoDB : 데이터베이스에 로그 레코드 일괄 적용 시작 ...
InnoDB : 퍼센트 진행률 : 45 5678 9 10 11 12 1314 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 
InnoDB : 배치 적용 완료
InnoDB : 커밋되지 않은 트랜잭션의 롤백 백그라운드에서 시작
140502 14:13:06 InnoDB : ID 0 562485192, 실행 취소를 위해 15 행으로 trx 롤백
140502 14:13:06 InnoDB : 시작됨; 로그 시퀀스 번호 108 1058059648
140502 14:13:06 InnoDB : 파일 ../../../storage/innobase/fsp/fsp0fsp.c 1593 행의 스레드 1873206128에서 어설 션 실패
InnoDB : 실패한 주장 : frag_n_used> 0
InnoDB : 의도적으로 메모리 트랩을 생성합니다.
InnoDB : 자세한 버그 보고서를 http://bugs.mysql.com에 제출하십시오.
InnoDB : 반복 된 어설 션 오류나 충돌이 발생하더라도
InnoDB : mysqld가 시작된 직후에
InnoDB : InnoDB 테이블 스페이스가 손상되었습니다. 참조하십시오
InnoDB : http://dev.mysql.com/doc/refman/5.1/en/forcing-recovery.html
InnoDB : 복구 강제.
140502 14:13:06-mysqld는 신호 6을 얻었다;
버그가 발생했기 때문일 수 있습니다. 이 바이너리는
또는 연결된 라이브러리 중 하나가 손상되었거나 잘못 구축되었거나
또는 잘못 구성되었습니다. 이 오류는 하드웨어 오작동으로 인해 발생할 수도 있습니다.
진단에 도움이 될만한 정보를 긁어 내기 위해 최선을 다할 것입니다.
문제는 있지만 이미 충돌했기 때문에 무언가 잘못되었습니다
실패 할 수 있습니다.

key_buffer_size = 16777216
read_buffer_size = 131072
max_used_connections = 0
max_threads = 151
threads_connected = 0
mysqld는 최대 
key_buffer_size + (read_buffer_size + sort_buffer_size) * max_threads = 345919K
메모리 바이트
괜찮 으시길 바랍니다. 그렇지 않은 경우 방정식에서 일부 변수를 줄입니다.

thd : 0x0
역 추적을 시도 중입니다. 다음 정보를 사용하여 찾을 수 있습니다
mysqld가 죽은 곳. 이 후에도 메시지가 표시되지 않으면
끔찍한 잘못 ...
stack_bottom = (nil) thread_stack 0x30000
140502 14:13:06 [참고] 이벤트 스케줄러 :로드 된 0 이벤트
140502 14:13:06 [참고] / usr / sbin / mysqld : 연결 준비가되었습니다.
버전 : '5.1.41-3ubuntu12.10'소켓 : '/var/run/mysqld/mysqld.sock'포트 : 3306 (우분투)
/ usr / sbin / mysqld (my_print_stacktrace + 0x2d) [0xb7579cbd]
/ usr / sbin / mysqld (handle_segfault + 0x494) [0xb7245854]
[0xb6fc0400]
/lib/tls/i686/cmov/libc.so.6 (중단 + 0x182) [0xb6cc5a82]
/ usr / sbin / mysqld (+ 0x4867e9) [0xb74647e9]
/ usr / sbin / mysqld (btr_page_free_low + 0x122) [0xb74f1622]
/ usr / sbin / mysqld (btr_compress + 0x684) [0xb74f4ca4]
/ usr / sbin / mysqld (btr_cur_compress_if_useful + 0xe7) [0xb74284e7]
/ usr / sbin / mysqld (btr_cur_pessimistic_delete + 0x332) [0xb7429e72]
/ usr / sbin / mysqld (btr_node_ptr_delete + 0x82) [0xb74f4012]
/ usr / sbin / mysqld (btr_discard_page + 0x175) [0xb74f41e5]
/ usr / sbin / mysqld (btr_cur_pessimistic_delete + 0x3e8) [0xb7429f28]
/ usr / sbin / mysqld (+ 0x526197) [0xb7504197]
/ usr / sbin / mysqld (row_undo_ins + 0x1b1) [0xb7504771]
/ usr / sbin / mysqld (row_undo_step + 0x25f) [0xb74c210f]
/ usr / sbin / mysqld (que_run_threads + 0x58a) [0xb74a31da]
/ usr / sbin / mysqld (trx_rollback_or_clean_all_without_sess + 0x3e3) [0xb74ded43]
/lib/tls/i686/cmov/libpthread.so.0(+0x596e) [0xb6f9f96e]
/lib/tls/i686/cmov/libc.so.6 (복제 + 0x5e) [0xb6d65a4e]
http://dev.mysql.com/doc/mysql/en/crashing.html의 매뉴얼 페이지에
충돌의 원인을 찾는 데 도움이되는 정보.

어떤 추천?


먼저 첫 번째 것들; 누군가 어떻게 든 MySQL 구성을 변경 했습니까? 최신 수정 날짜를 참조하십시오 /etc/mysql/my.cnf.
Janne Pikkarainen

아니요. mysqldump를 수행하기 위해 innodb_force_recovery = 3을 설정 한 후 DB를 삭제하고 다시 읽었습니다. 이것은 그것을 고쳤다.
tilleryj

답변:


26

아야.

InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: http://dev.mysql.com/doc/refman/5.1/en/forcing-recovery.html
InnoDB: about forcing recovery.

: 제안 된 웹 페이지 확인 http://dev.mysql.com/doc/refman/5.1/en/forcing-recovery.html을 .

기본적으로 복구 모드에서 MySQL 서버시작하고 손상된 테이블을 백업하십시오 .

편집 /etc/my.cnf하고 추가하십시오 :

 innodb_force_recovery = 1

... 데이터베이스에 들어갈 수 있는지 확인하고 데이터를 가져 오거나 손상된 테이블을 찾으십시오.

일반적으로이 문제가 발생하면 다시 빌드됩니다 (적어도 손상된 테이블 중 하나 또는 두 개).

에서 http://chepri.com/mysql-innodb-corruption-and-recovery/ :

  1. 중지하십시오 mysqld( service mysql stop).
  2. 지원 /var/lib/mysql/ib*
  3. 다음 줄을 추가하십시오 /etc/my.cnf.

    innodb_force_recovery = 1
    

    (4를 제안하지만 1로 시작하고 시작하지 않으면 증가하는 것이 가장 좋습니다)

  4. 다시 시작하십시오 mysqld( service mysql start).

  5. 모든 테이블을 덤프하십시오. mysqldump -A > dump.sql
  6. 복구가 필요한 모든 데이터베이스를 삭제하십시오.
  7. 중지하십시오 mysqld( service mysql stop).
  8. 없애다 /var/lib/mysql/ib*
  9. 에 의견 innodb_force_recovery/etc/my.cnf
  10. 다시 시작하십시오 mysqld. mysql 오류 로그를보십시오. 기본적으로 /var/lib/mysql/server/hostname.com.errib*파일을 작성하는 방법을 확인 해야 합니다.
  11. 덤프에서 데이터베이스를 복원하십시오. mysql < dump.sql

먼저 파일 시스템이 손상되었거나 디스크가 불량하다고 생각합니다.
bombcar

1
모든 innodb_force_recovery 값을 최대 6까지 시도하십시오. 그리고 innodb_purge_threads = 0을 추가하십시오.-때때로 주요 스레드가 시작될 수없는 경우 오류 로그에 표시됩니다
akuzminsky

2
이것이 오래된 스레드라는 것을 알고 있지만 복구가 필요한 데이터베이스를 결정하는 데 대한 자세한 설명은 무엇입니까?
nkanderson 2012

@nicolekanderson 또한 그 시점에 대한 설명을 원합니다. mysqldump를 실행 한 후에는 데이터베이스가 손상되었음을 표시하지 않습니다.
앤드류 Thaddeus 마틴

응답의 포인트 10-데이터베이스 서버를 다시 시작하고 오류 로그를 읽으십시오. 충돌 한 테이블의 이름을 지정해야합니다. mysqldump는 당신에게 테이블의 복사본만을 제공합니다.
Jonathan

2

mysql : 5.7 docker image를 사용하는 동안 이와 동일한 오류가 발생했습니다. 주요 실수는 기본적으로 존재하는 루트 사용자를 작성하려고 시도했습니다. 자세한 정보 : https://github.com/docker-library/mysql/issues/129

위의 링크에서 제공된 것처럼 솔루션은 도커 이미지를 시작하는 동안 환경 변수에서 MYSQL_USER 및 MYSQL_PASSWORD를 설정하지 않았습니다.


1

이것은 Laravel Homestead (Mac OS Sierra 10.12.4 (16E195)를 실행하는 커널 패닉 후 방랑자)에서 나에게 일어났습니다.

$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 14.04.3 LTS
Release:    14.04
Codename:   trusty

$ mysql -V
mysql  Ver 14.14 Distrib 5.7.9, for Linux (x86_64) using  EditLine 
wrapper

복구 옵션 중 어느 것도 나를 위해 효과가 없었지만 시도해 볼 수있는 몇 가지 리소스가 있습니다 .

https://dev.mysql.com/doc/refman/5.7/en/forcing-innodb-recovery.html

https://forums.mysql.com/read.php?22,603093,604631#msg-604631

https://support.plesk.com/hc/en-us/articles/213939865-How-to-fix-InnoDB-corruption-cases-for-the-MySQL-database

mysql 설정에 강제 복구를 추가하려고 시도했습니다 (1에서 시작하여 숫자가 높을수록 영구적 손상을 일으킬 수 있으므로 점진적으로 높아집니다).

sudo nano /etc/mysql/my.cnf

[mysqld]
innodb_force_recovery = 1
#innodb-read-only=1
#innodb_purge_threads=0
#key_buffer_size=16M
#event-scheduler=disabled

다른 창에서 다음을 실행하십시오.

tail -f /var/log/mysql/error.log

그런 다음 다양한 옵션을 활성화하여 mysqld를 다시 시작하십시오.

sudo /etc/init.d/mysql restart

시간이 초과되면 다음을 사용하여 mysql 프로세스를 강제로 다시 시작할 수 있습니다.

# process id is first column with number, just ignore lines with grep because they list the process running 'grep mysql'
ps aux | grep mysql
sudo kill -9 <process-id>
sudo /etc/init.d/mysql restart

작동하면 로그에 다음과 같은 내용이 표시됩니다.

Version: '5.7.9' socket: '/var/run/mysqld/mysqld.sock' port: 3306 MySQL Community Server (GPL)

실패하면 로그는 다음과 같이 표시됩니다.

InnoDB: Assertion failure in thread 140049488692992 in file log0recv.cc line 1420


더 나빠질 때 손상되었을 가능성이있는 데이터베이스를 제거하려고했습니다.

sudo ls -alt /var/lib/mysql

내가 작업 한 데이터베이스가 목록의 맨 위에있는 가장 최근에 수정 된 데이터베이스였습니다. 운 좋게도 그날부터 SQL 덤프가 있었으므로 제거 할 수있었습니다.

sudo rm -rf /var/lib/mysql/<database_name>

나는 다른 모든 파일을 남겨두고 mysql은 어쨌든 시작할 수있었습니다.

업데이트 : innodb_force_recovery = 1mysql이 다시 작동 하면 비활성화해야 합니다. 그렇지 않으면 데이터베이스와 테이블을 수정하려고 할 때 오류가 발생합니다.

그런 다음 Sequel Pro를 사용하여 데이터베이스를 다시 만들고 내 데이터를 다시 가져 왔으며 다른 프로젝트에서 모든 데이터베이스를 버리지 않고도 계속 진행할 수있었습니다.

앞으로는 모든 mysql 데이터베이스가 손상되어 매일 백업을 유지하고 데이터베이스 레크리에이션 스크립트를 문서화하거나 지속적인 통합 도구로 코딩해야한다고 가정해야합니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.