# 현재 저는 MySQL이 8.0.33 버전이라 버전 업그레이드가 무의미할 수 있겠으나 테스트를 위해서 8.0.35 로 업그레이드를 진행해보겠습니다. 이것은 5.7 버전에서 8.0으로 버전 업그레이드를 한다고 생각하는 것이 좋을 것 같습니다. 버전이 높다고 하여 방법이 달라지는 것은 아니니깐요. 1. mysqldump(export) - 우선 기존 버전의 8.0.33 에서 모든 데이터베이스를 dump 를 하여 백업본을 저장합니다. $ /mysql/local/mysql_8033/bin/mysqldump --all-databases -h localhost -u root -p1234 -S /tmp/mysql_8033.sock > /home/mysql/alldump.sql 2. 8.0.35 설치 - MySQL 8..

로그파일을 확인하였을 때 아래와 같은 문구를 문뜩 마주칠 경우가 있습니다. 뭔가 에러는 아닌것이 Aborted connection 이라는 문구때문에 잘못된 것이 아닌가라는 생각을 가지게 되었습니다. 이것은 wait_timeout 과 연관되어 있습니다. 해당 내용은 여기를 참조해주세요. timeout으로 설정한 시간을 초과했을 경우, 연결을 끊으면서 mysql로그 파일에 찍히게 되는 경우입니다. 만약 우리 디비에는 해당 로그가 안찍히고 있다라고 한다면, verbosity 설정값을 확인해 보시길 바랍니다. 세션을 제대로 close 하지 않아 보여지는 경우가 종종 보입니다. 타계정 또는 스크립트에 심어진 부분이라면 정확하게 찾기가 많이 힘들 것입니다. 이런 부분을 전부 찾아서 close를 해주고 해결하는 것이..

# innodb_large_prefix는 인덱스를 생성할 수 있는 최대 크기 입니다. 설정값을 ON으로 하였을 경우 인덱스의 최대 크기는 3072 byte, OFF일 경우 767 byte의 값을 갖게 됩니다. 예를 들자면 a_col varchar(255) 라는 컬럼이 있다고 가정한다면, 아래와 같이 최대 크기의 byte를 저장할 수가 있습니다. utf8일 경우 : 255 * 3byte = 765 byte utf8mb4일 경우 : 255 * 4byte = 1020 byte - varchar(255) 라는 의미는 Oracle에서는 255 byte이지만, MySQL에서는 글자길이라서 byte로 변환 한 것입니다. 만약 innodb_large_prefix 의 설정값이 OFF라면 utf8mb4 캐릭터셋으로 255..

# MySQL의 event는 Oracle의 job이라고 보면 됩니다. 즉, DB 내에서의 스케쥴러 입니다. 오늘 event 에 대해서 등록하고 간단하게 확인 하는 방법을 다뤄보도록 하겠습니다. 1. 스케쥴러 설정 SQL> show variables where variable_name = 'event_scheduler'; SQL> show variables like 'event%'; # 설정 set global event_scheduler=on; 2. 프로시저 생성 - 여기 10건 입력하는 프로시져가 있습니다. 이 프로시져를 event에 등록하여 자동 처리가 되는지 확인을 해보겠습니다. mysql> delimiter $$ mysql> drop procedure if exists test.imp_tmp_ev..

# 사용자 실수 또는 어떤 알 수 없는 이유로 인해 테이블 또는 데이터가 삭제가 되는 경우가 있을 것입니다. 특정 테이블을 복구하는 방법을 해보도록 하겠습니다. 1. 준비사항 (1) 백업 파일 (2) dbsake (MySQL 5.x 버전만 해당) 2. 상황 만들기 (1) 테이블 생성 mysql> create table temp_mha2(a int); Query OK, 1 row affected (0.01 sec) mysql> insert into temp_mha2 values(1); Query OK, 1 row affected (0.00 sec) mysql> insert into temp_mha2 values(2); Query OK, 1 row affected (0.01 sec) mysql> insert..

# failover 발생 후 mha 데몬은 어떻게 될까? - 아주 기본적이고 무식한 질문 일 수도 있습니다. - 저의 생각은 mha는 별도 서버에서 모니터링을 하기 때문에 failover 처리 후에도 다음 장애를 대비해 계속 모니터링을 하지 않을까 라는 생각이 문득 들게 되었습니다. - 그래서 failover 발생 시켜 확인해 보았습니다. 1. mha 실행 /usr/local/bin/masterha_manager --conf=/etc/mha.cnf & 2. mha 상태 확인 (running) [mhauser@mha01 ~]$ /usr/local/bin/masterha_check_status --conf=/etc/mha.cnf mha (pid:276453) is running(0:PING_OK), mast..