아직도 MyISAM을 쓰시나요? 안전한 InnoDB 마이그레이션과 서버 튜닝 방법 | 개발노트

InnoDB 전환 전 메모리 설정 최적화

엔진 교체 전 InnoDB 버퍼 풀 사이즈를 확보하여 성능 저하를 예방해야 합니다.

현재 버전 및 메모리 상태 점검

MySQL 5.6 버전은 InnoDB 엔진이 표준으로 자리 잡은 시점으로, 풀 텍스트 검색 지원과 트랜잭션 안전성이 보장되므로 MyISAM을 고집할 이유가 없습니다. 작업 전 현재 버전을 확인하고 엔진 교체 준비를 진행해야 합니다. 가장 먼저 확인해야 할 것은 현재 설정된 메모리 값입니다.

InnoDB는 MyISAM보다 메모리 의존도가 높기 때문에 기본 설정값인 128MB로는 운영 시 성능 저하가 발생할 수 있습니다. 현재 설정된 버퍼 풀 크기는 아래 명령어로 확인할 수 있습니다.

 SELECT VERSION(); SHOW VARIABLES LIKE 'innodb_buffer_pool_size';

innodb_buffer_pool_size 설정 계산

가상 메모리(Swap)를 제외한 물리적 RAM 용량을 기준으로 설정해야 합니다. 가상 메모리는 디스크를 사용하므로 DB 캐시로 사용할 경우 심각한 속도 저하를 유발합니다. 2GB RAM을 사용하는 서버를 예로 들 때, 웹 서버와 DB를 함께 운영한다면 전체 RAM의 25%에서 35% 수준인 512MB가 적절합니다.

설정 파일(my.cnf)을 열어 [mysqld] 항목 아래에 계산된 값을 입력합니다. 설정 변경 후에는 반드시 MySQL 서비스를 재시작해야 적용됩니다. 재시작 후 다시 변수를 조회하여 536870912(Byte)와 같이 변경된 값이 나오는지 확인합니다.

 vi /etc/my.cnf

[mysqld] innodb_buffer_pool_size = 512M

설정 후 서비스 재시작
systemctl restart mysqld

안전한 테이블 엔진 마이그레이션 전략

백업 테이블을 이용한 테스트 후 실제 테이블을 변환하여 리스크를 최소화합니다.

대상 테이블 식별 및 일괄 쿼리 생성

information_schema를 조회하여 현재 데이터베이스 내의 MyISAM 테이블 목록을 확인합니다. 테이블 개수가 많을 경우 일일이 명령어를 입력하는 것보다 CONCAT 함수를 사용하여 변경 구문을 자동으로 생성하는 것이 효율적입니다.

아래 쿼리를 실행하면 변경이 필요한 모든 테이블에 대한 ALTER TABLE 명령어가 생성됩니다. 생성된 결과를 복사하여 실행하면 오타 없이 안전하게 작업을 진행할 수 있습니다.

 SELECT CONCAT('ALTER TABLE ', TABLE_NAME, ' ENGINE=InnoDB;') FROM information_schema.TABLES WHERE TABLE_SCHEMA = '데이터베이스명' AND ENGINE = 'MyISAM';

백업 테이블을 활용한 사전 검증

운영 중인 대용량 테이블을 즉시 변경하는 것은 위험할 수 있습니다. 구조만 복사한 백업 테이블을 생성하고 데이터를 입력한 뒤, 해당 백업 테이블을 먼저 변환해보는 과정을 거쳐야 합니다. 이를 통해 소요 시간과 디스크 용량 부족 여부를 미리 파악할 수 있습니다.

테이블 복사 및 테스트 후 문제가 발생하면 원본 테이블 이름을 변경하고 백업 테이블을 원본으로 교체하는 방식으로 신속한 복구가 가능합니다. 로그 테이블과 같이 용량이 큰 테이블은 트래픽이 적은 시간대에 작업을 수행해야 합니다.

-- 1. 구조 복사 및 데이터 입력 CREATE TABLE eticket_backup LIKE eticket; INSERT INTO eticket_backup SELECT * FROM eticket;

-- 2. 테스트 변환 실행 ALTER TABLE eticket_backup ENGINE = InnoDB;

전환 후 메모리 재할당 및 최적화

불필요해진 MyISAM 메모리를 회수하고 테이블을 정리하여 시스템 효율을 높입니다.

key_buffer_size 축소

모든 테이블이 InnoDB로 전환되었다면 기존 MyISAM에서 사용하던 키 버퍼 메모리는 더 이상 대량으로 필요하지 않습니다. 기존에 수백 MB로 설정되어 있던 key_buffer_size를 8MB에서 16MB 수준으로 과감하게 줄여야 합니다.

확보된 여유 메모리는 운영체제의 파일 시스템 캐시나 웹 서버 프로세스에 할당되어 전체적인 시스템 반응 속도를 향상시킵니다. my.cnf 파일에서 해당 값을 수정한 뒤 서비스를 재시작합니다.

 [mysqld]

MyISAM 사용 중단에 따른 메모리 회수
key_buffer_size = 16M

OPTIMIZE TABLE 실행

엔진 변경 과정에서 데이터가 물리적으로 재배치되지만, 단편화 제거와 인덱스 정렬을 위해 OPTIMIZE TABLE 명령을 수행하는 것이 좋습니다. InnoDB에서는 'Table does not support optimize'라는 메시지와 함께 재생성(recreate)이 진행되는데 이는 정상적인 동작입니다.

 SELECT CONCAT('OPTIMIZE TABLE ', TABLE_NAME, ';') FROM information_schema.TABLES WHERE TABLE_SCHEMA = '데이터베이스명' AND ENGINE = 'InnoDB';

장기적 성능 관리를 위한 로그 설정

잠재적인 성능 병목 구간을 파악하기 위해 슬로우 쿼리 로그를 활성화합니다.

Slow Query Log 활성화

서버 최적화가 끝났더라도 추후 특정 쿼리로 인해 성능 저하가 발생할 수 있습니다. 설정한 시간(예: 3초) 이상 소요되는 쿼리만 별도로 기록하는 슬로우 쿼리 로그를 설정해두면 원인 파악이 매우 수월해집니다.

my.cnf 파일에 아래 세 줄을 추가하면 됩니다. 이 기능은 지정된 시간을 초과하는 쿼리가 발생할 때만 기록하므로 평상시 서버 부하에는 영향을 주지 않습니다.

 [mysqld] slow_query_log = 1 long_query_time = 3 slow_query_log_file = /var/lib/mysql/slow-query.log

동작 확인 및 모니터링

설정 적용 후 의도적으로 지연 쿼리를 실행하여 로그가 정상적으로 남는지 확인해야 합니다. SELECT SLEEP(5); 쿼리를 실행했을 때 5초간 대기 후 로그 파일에 해당 내역이 기록된다면 설정이 완료된 것입니다.

운영 중 사이트가 느려진다고 판단될 때 tail -f 명령어로 로그 파일을 실시간 모니터링하면 병목을 유발하는 쿼리를 즉시 찾아낼 수 있습니다.

-- 테스트 쿼리 SELECT SLEEP(5);
-- 로그 실시간 확인 (터미널) tail -f /var/lib/mysql/slow-query.log