필자의 부끄러운 삽질 고백이 되는 포스팅이 되겠습니다. 작성하고 나서 처음에는 비공개로 저장 했다가, 그래도 누군가에게 작은 도움을 줄 수도 있겠다는 생각에 공개로 전환하였습니다. 아.. 삽질은 진짜 싫습니다.. 그래도 그것 때문에 더 깊이 배우게 됩니다.


  CentOS 8에서 MySQL 5.7 버전을 설치하고 구동하는 과정에서 아래와 같은 에러가 발생했습니다.

Job for mysqld.service failed because the control process exited with error code.
See "systemctl status mysqld.service" and "journalctl -xe" for details.

  위 메세지에서 설명한대로 systemctl status와 journalctl 명령을 수행해보았지만 간략한 상태 설명만으로는 정확한 원인 파악은 불가능하였습니다.

● mysqld.service - MySQL Server
   Loaded: loaded (/usr/lib/systemd/system/mysqld.service; enabled; vendor preset: disabled)
   Active: activating (start-pre) since Wed 2020-03-11 14:57:26 KST; 1s ago
     Docs: man:mysqld(8)
           http://dev.mysql.com/doc/refman/en/using-systemd.html
  Process: 12993 ExecStart=/usr/sbin/mysqld --daemonize --pid-file=/var/run/mysqld/mysqld.pid $MYSQLD_OPTS (code=exited, status=1/FAILURE)
Cntrl PID: 13009 (mysqld_pre_syst)
    Tasks: 2 (limit: 23999)
   Memory: 51.9M
   CGroup: /system.slice/mysqld.service
           ├─13009 /bin/bash /usr/bin/mysqld_pre_systemd
           └─13026 /usr/libexec/platform-python -Es /usr/sbin/semanage fcontext -a -e /var/lib/mysql /var/lib/mysql-files

 3월 11 14:57:26 hmng systemd[1]: Starting MySQL Server...

 

  자세한 원인 파악을 위해 mysql 로그를 확인해 보았습니다.
  mysql의 로그 파일위치는 my.cnf 설정에서 확인 가능합니다. (기본 위치 : /etc/my.cnf)

 

  mysqld.log 로그파일 내용을 살펴보니 아래 내용이 기록되어 있었습니다.

2020-03-11T06:10:21.372491Z 0 [ERROR] InnoDB: Unsupported redo log format. The redo log was created with MariaDB 10.3.17. Please follow the instructions at http://dev.mysql.com/doc/refman/5.7/en/upgrading-downgrading.html
2020-03-11T06:10:21.372510Z 0 [ERROR] InnoDB: Plugin initialization aborted with error Generic error
2020-03-11T06:10:21.994333Z 0 [ERROR] Plugin 'InnoDB' init function returned error.
2020-03-11T06:10:21.994443Z 0 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
2020-03-11T06:10:21.994484Z 0 [ERROR] Failed to initialize builtin plugins.
2020-03-11T06:10:21.994709Z 0 [ERROR] Aborting

 

  지원하지않는 redo log format이라고 하네요. MySQL 설치 후 처음으로 구동하는 과정이라 redo log가 존재하면 안되는 상황이었습니다. 그것도 MariaDB 10.3.17 에서 생성된 redo log가 존재한다고 로그가 친절히 알려줬습니다.

  이실직고하면 Hive metastore로 사용하기 위해 MariaDB 최신버전인 10.3.17를 설치했다가 호환성 등의 이유로 삭제하고 downgrade하여 MySQL 5.7 버전을 설치하다가 이런 에러를 만나게 된 것입니다.
  MariaDB를 삭제할 때 단순하게 yum remove 명령을 사용하였는데, 이 명령만으로는 MariaDB에서 생성한 데이터 파일과 로그 파일 등은 삭제되지 않고 계속 존재하였던 것입니다.

  my.cnf 설정에서 데이터파일 저장 경로를 확인한 후

  해당 디렉토리에 저장된 파일을 살펴보았습니다.

  위 파일의 최종 수정 시간을 확인해보니 MySQL 설치 시점 이전에 생성된(3월 7일) 파일들도 존재하였습니다. 이전에 설치 후 삭제된 Mariadb와 관련된 파일이 삭제되지 않고 그대로 유지된 채 몇몇 파일은 Overwrite된 것입니다.

  참고로 위에 저장된 파일을 살펴보도록 하겠습니다.

파일명 설명
aria_log.00000001
aria_log_control
Aria는 MariaDB에서의 저장 엔진 중 하나입니다. MySQL의 MyISAM을 대체하기 위한 용도로 개발되었습니다.
데이터 디렉토리에서 aira로 시작하는 파일은 Aria 저장 엔진에서 생성하는 log control(aria_log_control) 파일과 log(aria_log.%) 파일입니다.
binlog.index  binary log는 데이터베이스내 모든 데이터와 구조의 변경 사항을 기록한 로그 파일입니다.  replication과 백업/복구를 위해 필요한 파일입니다. 
binlog.index는 binary log 파일의 목록을 순차적으로 기록하는 파일입니다.
ib_buffer_pool Mariadb에서 Oracle의 Data Buffer cache 역할을 하는 것이 InnoB Buffer Pool입니다. 데이터를 읽을 때 Disk I/O 비용에 따른 부하를 줄이기 위해 메모리에 액세스하고자 하는 데이터를 올려놓고 사용하게 됩니다. 이 buffer pool은 재가동 뒤에는 초기화 되므로 재가동 직전에 데이터를 액세스하는 작업이 상대적으로 느려지게 될 수 있습니다. 이를 방지하고자 InnoDB는 shutdown 직전에 buffer pool를 dump하며, 이 때 생성되는 파일이 ib_buffer_pool입니다. 그리고 다시 mariadb가 재가동 되면 이 파일을 읽어 shutdown 전의 buffer pool상태로 복구해주게 됩니다.
ib_logfile0 
ib_logfile1 
InnoDB/XtraDB의 복구를 위해 기록되는 relog 파일입니다. 다수의 파일이 순차적으로 switch되어 사용되며, 로그 파일의 수는 innodb_log_files_in_group에 지정된 숫자만큼 생성됩니다.
ibdata1 InnoDB에서 사용되는 시스템 테이블스페이스 정보를 저장하고 있는 파일입니다. 시스템 테이블스페이스에는 data dictionary, change buffer 및 undo 로그 정보 등이 기록됩니다.
metastore  필자가 Hive metastore로 사용하기 위해 생성했던 데이터베이스명입니다. 디렉토리 안에는 해당 데이터베이스에서 생성한 테이블의 데이터 파일(.ibd)과 메타 파일(.frm)이 존재합니다. 
multi-master.info  Mariadb에서는 하나의 서버에 다수의 마스터 DB가 존재하는 Multi-source replication 기능을 제공해줍니다. 이 파일은 서버 내 사용가능한 모든 마스터 접속 정보를 저장하고 있습니다.
mysql  Mariadb 설치 시 기본 생성되는 mysql 데이터베이스를 위한 저장 공간입니다.
mysql_upgrade_info  설치된 Mariadb의 버전이 기록되어 있습니다.
performance_schema Mariadb 설치 시 기본 생성되는 performance_schema 데이터베이스를 위한 저장 공간입니다.

 

  위 데이터 디렉토리 내 파일들이 이전버전의 파일들과 혼재되어 있는 상태이기 때문에 복구가 불가능한 상황입니다. 필자의 경우에는 신규 설치하는 경우라서, 다시 Mysql을 Uninstall하고 재설치 하였습니다. 물론, Uninstall 후 데이터 파일 등을 수동으로 삭제한 뒤 재설치 작업을 진행해줘야 합니다.

 

  PS. datadir내 파일을 삭제하고 다시 설치를 완료한 뒤,  바로 datadir에 명시된 디렉토리를 확인해보았는데 생성된 파일이 없었습니다. mysql을 처음 구동하는 시점에 관련 파일들이 새로 생성되는 것이었습니다. 위 에러 상황에서 datadir 내 파일을 삭제하고 다시 서비스 재시작을 했으면 정상적으로 mysql 서비스가 시작될 수 있었을거라 예상되지만, 그냥 깔끔하게 재설치하는게 마음 편하네요. 

 

 

 

 

 

 

'Database > MariaDB&MySQL' 카테고리의 다른 글

MySQL 5.7 설치 (CentOS 8)  (3) 2020.03.11

+ Recent posts