MariaDB 서비스를 계속 시작하지 못했습니다.

MariaDB 서비스를 계속 시작하지 못했습니다.

MariaDB가 설치된 서버에 문제가 있습니다.

며칠 전 처음으로 mariadb 프로세스가 갑자기 정지되어 재부팅하려고 하면

sudo service mariadb restart

나는 이 출력을 받는다.

Redirecting to /bin/systemctl restart mariadb.service
Job for mariadb.service failed because the control process exited with error cod                                                                                                     e. See "systemctl status mariadb.service" and "journalctl -xe" for details.
[root@web-customer-01 ~]# systemctl status mariadb.service
● mariadb.service - MariaDB database server
   Loaded: loaded (/usr/lib/systemd/system/mariadb.service; enabled; vendor preset: disabled)
   Active: failed (Result: exit-code) since Tue 2018-02-13 15:43:56 UTC; 24s ago
  Process: 10529 ExecStartPost=/usr/libexec/mariadb-wait-ready $MAINPID (code=exited, status=1/FAILURE)
  Process: 10528 ExecStart=/usr/bin/mysqld_safe --basedir=/usr (code=exited, status=0/SUCCESS)
  Process: 10498 ExecStartPre=/usr/libexec/mariadb-prepare-db-dir %n (code=exited, status=0/SUCCESS)
 Main PID: 10528 (code=exited, status=0/SUCCESS)

Feb 13 15:43:54 web-customer-01.customer.it systemd[1]: Starting MariaDB database server...
Feb 13 15:43:54 web-customer-01.customer.it mariadb-prepare-db-dir[10498]: Database MariaDB is probably initialized in /var/lib/mysql already, nothing is done.
Feb 13 15:43:54 web-customer-01.customer.it mysqld_safe[10528]: 180213 15:43:54 mysqld_safe Logging to '/var/log/mariadb/mariadb.log'.
Feb 13 15:43:54 web-customer-01.customer.it mysqld_safe[10528]: 180213 15:43:54 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
Feb 13 15:43:56 web-customer-01.customer.it systemd[1]: mariadb.service: control process exited, code=exited status=1
Feb 13 15:43:56 web-customer-01.customer.it systemd[1]: Failed to start MariaDB database server.
Feb 13 15:43:56 web-customer-01.customer.it systemd[1]: Unit mariadb.service entered failed state.
Feb 13 15:43:56 web-customer-01.customer.it systemd[1]: mariadb.service failed.

임시 해결책으로 이러한 파일을 삭제하면 서비스가 재부팅된다는 것을 알게 되었습니다만, 이것이 적절한 솔루션인지 잘 모르겠습니다.

/var/lib/mysql/ib_logfile0
/var/lib/mysql/ib_logfile1

나는 mariadb 로그에서 이 많은 대사들을 발견했다.

180213 15:53:29  InnoDB: Error: page 16392 log sequence number 19972774982
InnoDB: is in the future! Current system log sequence number 731248348.
InnoDB: Your database may be corrupt or you may have copied the InnoDB
InnoDB: tablespace but not the InnoDB log files. See
InnoDB: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html
InnoDB: for more information.

그리고 위의 링크에서 설명한 바와 같이 my.cnf에 innodb_force_recovery를 추가했습니다.

[mysqld]
innodb_force_recovery = 1

문제를 조사하려고 했지만 가능한 원인을 알 수 없어서 정확한 해결책을 찾을 수 없습니다.

--편집

이것은 나의 /etc/my.cnf입니다(obv는 최근 innodb_force_recovery를 추가했습니다).

[mysqld]
innodb_force_recovery = 1
innodb_buffer_pool_size=256M
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
# Disabling symbolic-links is recommended to prevent assorted security risks
symbolic-links=0
# Settings user and group are ignored when systemd is used.
# If you need to run mysqld under a different user or group,
# customize your systemd unit file for mariadb according to the
# instructions in http://fedoraproject.org/wiki/Systemd
skip-name-resolve

[mysqld_safe]
log-error=/var/log/mariadb/mariadb.log
pid-file=/var/run/mariadb/mariadb.pid

#
# include all files from the config directory
#
!includedir /etc/my.cnf.d

[client]
port = 3306
socket = =/var/lib/mysql/mysql.sock

innodb_buffer_pool_size=256M1GB의 RAM으로는 너무 클 수 있습니다.64M으로 변경합니다.서버에서 실행 중인 다른 앱이 있습니까?그것은 또한 사물을 심하게 경련시킬 것이다.

의 내용/etc/my.cnf.d그 밖에 너무 크게 조정된 설정을 확인하려면 모든 설정을 확인해야 합니다.

또는 RAM을 증설하는 방안을 검토할 수 있습니다.

얼마 전에 봤는데 어떻게 고쳐졌는지 모르겠어요.

InnoDB는 복구에 사용하는 파일이 3개 있는 것으로 알고 있습니다.

• ibdata1
• ib_logfile0
• ib_logfile1

이러한 디렉토리를 삭제하면 DB가 시작될 가능성이 높지만 파일이 생성된 디렉토리가 다른 DB 관련 디렉토리와 다른 타임스탬프를 가질 경우 디렉토리의 타임스탬프를 백업했을 때와 체크하기 때문에 오류가 발생합니다(이것이 타당하다면).

도움이 될 만한 걸 찾았어요

회복 모드

모드 설명

0 InnoDB가 정상적으로 동작하고 있는 경우의 디폴트모드MariaDB 10.2.7까지는 데이터 변경을 허용하는 유일한 모드였습니다.MariaDB 10.2.7부터는 innodb_force_recovery<=3으로 쓰기 트랜잭션이 허용됩니다.

1 (SRV_FORCE_IGNORE_CORRUPT)를 사용하면, 파손된 페이지가 검출되어도, 서버는 계속 가동할 수 있습니다.redo 로그 기반 복구는 누락된 데이터 파일이나 손상된 데이터 페이지와 같은 특정 오류를 무시하도록 함으로써 이 작업을 수행합니다.영향을 받는 파일 또는 페이지의 redo 로그는 모두 건너뜁니다.테이블 덤프를 쉽게 할 수 있습니다.SELECT * FROM table_name손상된 인덱스 및 페이지를 뛰어넘는 문입니다.

2 )SRV_FORCE_NO_BACKGROUND는 마스터 스레드의 실행을 중지하여 삭제 중에 발생하는 크래시를 방지합니다.삭제가 실행되지 않으므로 실행 취소 로그는 계속 증가합니다.

3 )SRV_FORCE_NO_TRX_UNDO는 크래시 후 는 크래시 복구 후 트랜잭션을 롤백하지 않습니다.현재 활성 트랜잭션의 롤백에는 영향을 주지 않습니다.마리아DB 10.2.7부터는 일부 생성 취소 백그라운드 태스크가 실행되지 않습니다.이러한 작업은 롤백이 방지되고 있는 복구된 불완전한 트랜잭션으로 인해 잠금 대기 상태가 될 수 있습니다.

4)SRV_FORCE_NO_IBUF_MERGE는 테이블 하지 않고 는 테이블 통계정보를 계산하지 않고 버퍼 머지를 삽입하지 않습니다.

5)SRV_FORCE_NO_UNDO_LOG_SCAN는 불완전한 커밋된 할 때 는 불완전한 트랜잭션을 커밋된 것으로 처리하며 시작할 때 실행 취소 로그를 확인하지 않습니다.

6)SRV_FORCE_NO_LOG_REDO 실행하지 는 회복의 일부로서 로그 롤포워드를 다시 실행하지 않습니다.인덱스가 필요한 쿼리 실행은 이 모드를 활성화하면 실패할 수 있습니다.이 되는 「」, 「」를 해 주세요.SELECT * FROM tab ORDER BY primary_key DESC파손된 부분 뒤에 모든 데이터 부분을 덤프합니다.

다른 모드를 사용해 보고 도움이 되는지 확인할 수 있습니다.

★★★★★★★★★★★★★★★★★★★★★★★innodb_additional_mem_pool_size = 128M성공했어.

언급URL : https://stackoverflow.com/questions/48770920/mariadb-service-continuosly-fail-to-start