서버 설정을 몇 가지 바꿔야 했는데 그동안은 기본 설정 파일을 직접 고쳐 왔다. 그러다 보니 나중에 무엇을 우리가 바꾼 것인지 알 수 없었다. 기본값이 무엇이었는지도 남아 있지 않았다.
Table of contents
Open Table of contents
직접 고치면 안 보인다
/etc/mysql/my.cnf 를 직접 고치고 있었다. 기본값 사이에 우리 값이 섞여서 500줄 중 어느 것을 바꿨는지 안 보였다.
판을 올릴 때 그 파일이 어떻게 되는지는 패키징에 달려 있었다. RPM 은 %config 로 표시된 파일이 고쳐져 있으면 그것을 .rpmsave 로 밀고 새 파일을 깔고 %config(noreplace) 면 반대로 새 파일을 .rpmnew 로 옆에 떨어뜨린다. dpkg 쪽은 Debian Policy 가 업그레이드 때 로컬 수정 보존을 의무로 두어 어떻게 할지 물어본다. 어느 쪽이든 적용되던 값과 새 기본값이 갈라져서 손으로 합쳐야 하는데 무엇을 왜 바꿨는지가 안 남아 있으면 그 병합을 할 수가 없었다.
별도 파일에 우리 값만
그래서 기본 파일은 그대로 두고 /etc/mysql/conf.d/99-ours.cnf 에 우리 값만 넣게 했다.
# 99-ours.cnf
[mysqld]
innodb_buffer_pool_size = 8G # 기본 128M. 장비 메모리 32G 중 할당
max_connections = 500 # 기본 151. 워커 수 x 여유
slow_query_log = 1
long_query_time = 1우리가 바꾼 것만 있으니 한눈에 보인다.
각 항목 옆에 innodb_buffer_pool_size 의 기본이 128M 이라는 것처럼 기본값과 왜 바꿨는지를 주석으로 적었다. 그러면 나중에 되돌릴 때 무엇으로 되돌릴지가 그 자리에 있다. 이유를 안 적으면 다음 사람이 그 값을 지워도 되는지 판단할 수 없다.
읽는 순서를 이름으로
conf.d 안의 파일이 여러 개면 나중에 읽는 것이 이긴다.
/etc/mysql/conf.d/
50-server.cnf 배포판 기본
99-ours.cnf 우리 것이름 순서로 읽으므로 숫자가 필요했다.
그래서 10- 이나 20- 처럼 이름 앞에 숫자를 붙여 순서가 이름에서 드러나게 했다. 나중에 파일이 하나 더 늘어도 어디에 끼워야 할지가 정해진다. 순서가 중요한 곳에서는 그 순서를 이름이 말하게 하는 것이 안전했다.
검증 — 적용됐는지 되읽기
파일에 적은 것과 실제로 적용된 것은 다를 수 있었다. 잘못된 구역에 넣으면 오류 없이 그냥 무시된다.
그래서 다시 띄운 뒤에 SHOW VARIABLES 로 실제 값을 봤다.
$ mysql -e "SHOW VARIABLES LIKE 'innodb_buffer_pool_size'"
innodb_buffer_pool_size 8589934592적은 값과 되읽은 값을 대조해야 적용됐다고 말할 수 있다. 실제로 한 항목을 [mysqld] 가 아니라 클라이언트 구역인 [mysql] 에 넣어 무시되고 있던 것을 그 확인으로 찾았다.
판을 올릴 때의 확인
판을 올린 뒤에 우리 설정이 그대로 유효한지 확인하는 것을 만들었다. 새 판에서 항목 이름이 바뀌면 우리 값이 무시될 수 있기 때문이다.
만들고 나서 일부러 한 항목을 틀리게 적어 놓고 그 확인이 잡는지 봤다. 잡히는 것을 보고 나서야 그 확인을 믿을 수 있었다. 마지막으로 우리 파일만 git 에 넣었는데 기본 설정 파일은 판마다 바뀌므로 넣으면 매번 충돌이 난다.
정리
- 기본 설정 파일을 직접 고치면 무엇을 바꿨는지 안 보인다
- 판을 올리면 적용되던 값과 새 기본값이 갈라진다
- 원본을 두고
conf.d의 별도 파일에 우리 값만 넣는다 - 기본값과 바꾼 이유를 옆에 적는다
- 이름에
10-같은 숫자를 넣어 읽는 순서를 정한다 - 적은 것과 적용된 것은 다르다
- 잘못된 구역에 넣으면 조용히 무시된다
- 우리 파일만
git에 넣는다