CentOS 환경에서 Hive 설치&테스트를 위해서 MySQL 설치가 선행되어야 했었습니다. 
  MySQL 사용이 주목적이 아닌 관계로 yum을 이용해 최신 버전의 MySQL(8.0.17)을 쉽게 설치할 수 있었지만, 지금은 Hive metastore로 사용할 목적이므로 Hive와의 안정적인 호환성을 고려하여 5.7 버전을 다운로드 받아 설치하고자 합니다.

  자세한 설치 환경 정보는 아래와 같습니다.

- MySQL : 5.7.28
- OS : CentOS 8

 

1. 설치 파일 다운로드

  이전 버전의 MySQL community server를 다운로드하기 위해 아래 MySQL Product Archives 사이트에 접속합니다.

* URL : https://downloads.mysql.com/archives/community/

 

  설치하고자 하는 MySQL 버전과 OS 정보를 선택하면 다운로드 가능한 rpm 파일 목록을 볼 수 있습니다. 이 중 모든 패키지가 포함된 bundle을 wget을 이용하여 다운로드합니다. 다운로드 URL은 위 웹페이지의 Download 버튼을 우클릭하여 나타난 팝업 메뉴에서 Link 주소 복사(웹 브라우저별 상이함)를 선택하면 됩니다. 

> wget https://downloads.mysql.com/archives/get/p/23/file/mysql-5.7.28-1.el7.x86_64.rpm-bundle.tar

 

 

2. 설치 파일 압축해제 및 설치

다운로드받은 bundle 파일을 압축해제하고,

> tar xvf mysql-5.7.28-1.el7.x86_64.rpm-bundle.tar

아래와 같이 yum localinstall 명령어를 이용해서 패키지들을 설치해줍니다. rpm 명령어를 사용하여 하나씩 설치해줄 수도 있지만, yum을 사용하면 패키지간의 의존 관계를 참조하여 한번에 설치 가능하므로 여기서는 yum을 이용하여 설치하도록 하겠습니다.

> sudo yum localinstall mysql-community-*

 

 

3. my.cnf

  설치가 정상적으로 완료되면 /etc 디렉토리내 my.cnf 설정 파일이 생성된 것을 확인 할 수 있습니다.

  my.cnf내 기본적으로 설정된 서버 옵션 항목들에 대한 설명은 아래와 같습니다.

서버 옵션 설명
datadir 데이터베이스 디렉토리 저장 경로
socket 소켓 파일명. MySQL 서버에 접속하는 방법에는 소켓 파일을 이용하는 방법과 TCP/IP를 통해 접속하는 방법이 있습니다. 원격에서는 host와 port 정보를 명시하여 TCP/IP를 통해 접속가능합니다. 로컬에서 소켓 파일을 이용한 접속 방식은 "Unix domain socket"을 이용하는 방식으로 서버 내 프로세스 간 통신(IPC)의 일종입니다.
symbolic-links symbolic link를 이용하여 데이터베이스 디렉토리에 존재하는 데이터베이스나 테이블을 다른 경로로 이동 가능합니다. 디스크의 저장용량 관리를 위해서나 성능이 더 좋은 다른 디스크를 사용하고하 할 경우 이용 가능합니다.
해당 값은 현재 disable(0)되어 있으며, 활성화를 원하면 해당 값을 '1'로 설정 후 서버를 restart해야 합니다. 
log-error 시스템 로그 및 에러 내용을 기록하는 파일입니다. MySQL 서버의 시작과 종료에 관한 로그도 기록되며 에러와 같은 특별한 상황에 대한 내용이 기록됩니다.
pid-file Mysql 서버 process id 값을 저장하고 있는 파일입니다.
mysqld_safe 프로세서를 사용해서 MySQL을 구동할 수 있는데, 이 mysqld_safe 프로세스는 mysqld 프로세스를 모니터링하는 프로세스로 mysqld 프로세스가 비정상적으로 종료했을 시 다시 mysqld 프로세스를 구동하는 watcher 프로세스입니다. mysqld_safe 프로세스가 mysqld 프로세스를 감시하기 위해 해당 파일에 mysqld의 process id 값을 저장하고 있는 것입니다.

  그 외 설정 가능한 옵션은 아래 MySQL 홈페이지를 참고하면 됩니다.

 * URL : https://dev.mysql.com/doc/refman/5.7/en/server-option-variable-reference.html

 

 

4. mysql 서비스구동

  각 사용 환경에 맞게 서버 옵션 설정이 완료가 되었으면, mysql 서비스를 구동해 보겠습니다.

> sudo systemctl start mysqld

  mysql 서비스가 정상적으로 시작되었다면 별도의 메세지 없이 다음 명령 입력을 대기하는 prompt가 표시될 것이며, 아래 명령으로 서비스 상태를 확인 할 수 있습니다.

> sudo systemctl status mysqld

 

  mysql이 처음으로 구동되면 my.cnf의 datadir 옵션에서 설정한 경로에 mysql운영에 필요한 기본 데이터베이스 관련 파일 등이 생성된 것을 확인 할 수 있을 것입니다.

 

 

5. root 계정 비밀번호 변경

* 참고 URL : https://dev.mysql.com/doc/refman/5.7/en/resetting-permissions.html

  mysql의 root 계정의 비밀번호는 설치 시 임의의 값으로 임시 지정되어 있습니다. mysql을 안정적으로 사용하기 위해서는 우선 root 계정의 비밀번호 변경작업을 선행해야 합니다.

  참고로, 임시 비밀번호는 아래와 같이 my.cnf에서 log-error로 설정한 에러로그 파일에서 확인 가능합니다.

> sudo grep 'password' /var/log/mysqld.log

  root계정의 비밀번호를 변경하기 위해서는 무제약모드로 mysql 서비스를 구동해야 합니다. 만약, mysql 서비스가 구동중인 상태라면 먼저 아래 명령을 사용하여 서비스를 중지합니다.

> sudo systemctl stop mysqld

 

그리고 무제약모드로 서비스를 구동하기 위해 아래와 같이 옵션을 설정해줘야 합니다.

> sudo systemctl set-environment MYSQLD_OPTS="--skip-grant-tables"

  --skip-grant-tables 옵션은 용어 그대로 mysql 시스템 데이터베이스 내의 모든  grant table 읽기를 skip하겠다는 설정입니다. 권한 시스템이 없이 서비스가 구동되므로 데이터베이스에 아무런 제약없이 액세스가 가능한 것입니다.

  옵션 변경이 완료되었으면, mysql 서비스를 시작하고 서비스가 제대로 구동되었는지 확인해 보겠습니다.

> sudo systemctl start mysqld
> sudo systemctl status mysqld

  서비스가 정상적으로 올라왔으면 mysql 클라이언트를 사용해 root계정으로 MySQL 서버에 접속해 보겠습니다.

> mysql -u root

  접속에 성공하면 우선 서버가 계정관리명령을 수행할 수 있게 grant table을 재적재하도록 flust privileges 명령을 수행합니다.

mysql> FLUSH PRIVILEGES;

  그리고 ALTER USER 명령을 이용하여 root 계정의 비밀번호를 변경합니다.

mysql> ALTER USER 'root'@'localhost' IDENTIFIED BY '신규비밀번호';

  ALTER USER 명령문 대신에 아래와 같이 직접 USER 테이블 데이터를 UPDATE하는 방법도 존재합니다.

mysql> UPDATE mysql.user SET authentication_string = PASSWORD('신규비밀번호')
      ->
WHERE User = 'root' AND Host = 'localhost';

mysql>
FLUSH PRIVILEGES;

  비밀번호 설정이 완료되었으면 --skip-grant-tables 옵션을 비활성화하기 위해 mysql 서비스를 재가동해줘야 합니다.

> sudo systemctl stop mysqld
> sudo systemctl unset-environment MYSQLD_OPTS
> sudo systemctl start mysqld
> sudo systemctl status mysqld

 

 

6. mysql 서버 접속 및 테스트

  이제 본격적으로 mysql을 사용해 보겠습니다. mysql 클라이언트를 사용해 root 계정으로 접속합니다. 
  참고로 -u 옵션은 로그인 할 사용자 계정을 명시하기 위한 옵션이며, -p 옵션은 로그인 시 비밀번호를 사용하여 접속을 하겠다는 뜻입니다. 정상적으로 접속이 완료되면 아래와 같이 'mysql>' 프로프트를 확인할 수 있을 것입니다.

  mysql이 정상적으로 작동하는지 점검하기 위해 데이터베이스와 테이블을 생성하고, 데이터를 입력한 뒤 조회하는 쿼리문을 실행해 봅니다.

mysql> show databases;                -- 데이터베이스 목록 출력
mysql> create database test;         -- 이름이 test인 데이터베이스 생성
mysql> use test;                            -- 사용할 기본 데이터베이스로 test 데이터베이스를 선택
mysql> create table tab1 (            -- tab1 테이블을 생성
       ->   col1 int,                            -- tab1 테이블은 정수를 저장할 수 있는 int형의 col1 컬럼과
       ->   col2 varchar(20)               -- 20자리의 문자열을 저장할 수 있는 varchar형의 col2 컬럼으로 구성됨.
       ->  );
mysql> insert into tab1               -- tab1 테이블에 데이터 삽입
       -> values (1, 'ABCDE');
mysql> select * from tab1;          -- tab1 테이블의 데이터 조회

  기본 SQL문을 수행하여 MySQL이 정상적으로 동작함을 확인할 수 있습니다.

 

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

MySQL5.7 설치 후 구동 실패 에러  (0) 2020.03.11

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


  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