1. 서론
mysql 데이터베이스의 파티션이 커지면 데이터베이스 파일을 새로운 파티션에 옮기고 심볼릭 링크를 걸어서 용량을 확보하는 방법이 있다. 한편 우분투에서는 apparmor라고 하는 권한 관리 시스템이 존재하여서, 심볼릭 링크 후에 새로운 경로(파티션)에 대한 권한을 줄 필요가 있다.
여기서 apparmor가 설치된 mysql 환경에서 어떻게 파티션을 만들고, 공간을 확장하는지 알아 본다.
2. 수행 방법
1) 추가할 디스크 마운팅 및 포멧
# fdisk -l // 파티션 할당 상태 확인
# fdisk /dev/xvdb // /dev/xvdb : 추가된 디스크 주소
n 누루고 파티션 설정(primary partition, cylinder etc)
w 눌러서 저장
# mkfs.ext4 /dev/xvdb1 // ext4로 포멧
# mount /dev/xvdb1 /mnt/mysql_disk1 // 마운팅
# blkid // 추가된 /dev/xvdb1 의 UUID 확인
# vi /etc/fstab // 재부팅시 바로 자동 마운팅을 위해 설정
UUID=<> /mnt/mysql_disk1 ext4 rw 0 0 # 제일 아래줄에 추가
# df -h // 디스크 용량 확인
2) Apparmor 설정파일 변경 [1]
– 우분투는 접근관리를 좀 더 잘 하기 위해 파일에 권한을 사용자 단위로 지정하는 것이 아니라, 실행되어 있는 프로그램이 어디에 접근할 수 있는지를 설정함으로써 해결하고자 하였다. 이 편이 관리 측면에서 더 이득이 크다.
# vi /etc/apparmor.d/user.sbin.mysqld
# 제일 아래줄에 추가
/mnt/mysql_disk1/mysql_data r,
/mnt/mysql_disk1/mysql_data/** rwk,
3) sql 서버 종료
# service mysql stop
4) 데이터파일을 새로 저장할 큰 용량의 디스크로 복사 (ubuntu mysql은 /var/lib/mysql 에 있음)
# cd /var/lib/mysql
# cp -R * /mnt/mysql_disk1/mysql_data
5) 기존 파일 백업
# mv /var/lib/mysql /var/lib/mysql_bak
6) 심볼릭 링크 연결
# cd /var/lib
# ln -s /mnt/mysql_disk1/mysql_data mysql
7) sql 서버 다시 켜기
# service mysql start
8) DB에 잘 접속되나 테스트
3. 정 리
파일 복사하는데 꽤 시간이 걸리기 때문에 추후에는 mysql서버를 하나 더 준비하여 데이터를 옮기도록 작업하는 것이 더 좋을 것으로 예상된다. 그리고 데이터 베이스 파일을 하나로 하지 않고 여러개로 나누어서, 파일 단위로 심볼릭 링크를 걸어서 해결하는 방향이 더 좋을 것이라고 생각한다.
4. 관련 자료
[1] Recover an Innodb mysql database from an EBS on Ec2, Stack Exchange : http://dba.stackexchange.com/questions/57424/recover-an-innodb-mysql-database-from-an-ebs-on-ec2
[2] https://blogs.oracle.com/jsmyth/entry/running_out_of_physical_disk
예전에 대학교에서 데이터베이스 수업을 들을 때 였다. 나는 이론과목을 좋아했기 때문에 데이터베이스 설계 수업도 재미있게 들을 수 있었다. 주어진 요구사항으로부터 어떤 과정을 통해서 실제 MySQL, OracleDB의 테이블, 릴레이션, 트리거, 프로시져, 인덱스 등등의 물리적인 설계까지 오게 되는지 보는 것은 매우 흥분되는 일이였다. 하지만 수업을 듣는 다른 사람들은 별 생각없이 수업을 듣고 있는 듯 하였으며 나는 그런 모습이 이해가 되지 않았다. 무언가를 만든다면 데이터가 매우 중요한 일인데 다른 학생들은 그렇게 생각하지 않는 듯 했다.
ER다이어그램에 대하여 배우고 나서 교수님께서 실제로 요구사항을 주고 다이어그램을 그려오라는 과제를 내주셨었다. 과제를 끝내고 쉬고 있는데 어떤 친구가 와서 과제 설명 좀 해주고 도와달라고 부탁을 하였다. 그런데 그 친구는 설명을 하고 나서 방향성을 제시해 주었는데 당황스럽게도 내 말을 들으려고 하지를 않았다. 오히려 자기말이 맞다는 것이었다.
ER다이어그램은 Entity-Relationship Diagram(ERD)1의 줄임말으로써 개체와 관계를 통해서 데이터 모델링을 하기위한 도구이다. 이름에도 나와 있듯이 개체(물체, 대상, 명사 등을 의미)와 관계(2개이상의 엔티티 사이의 관계, 동사 등을 의미)를 이용한 모델링이다. 그런데 관계를 만듬에 있어서 엔티티와 엔티티 사이에서 서로 데이터가 어떻게 참여하고 있는지에 대한 것도 포함된다. 예를 들어 "반(班, class)"에 대한 데이터베이스를 만든다고 했을 때 반이라는 엔티티와 학생이라는 엔티티가 존재하게 되며 학생과 교실간에는 속한다라는 관계를 맺게 된다. 마지막으로 1 개 반에 1곳에 대하여 여러명의 학생이 속할 수 있을 것이다. 위의 예제의 경우 반과 학생은 1:N의 관계를 가지고 있다. 이 1:N이라고 하는 것을 맵핑 카디날리티(Mapping Cardinality)라고 부른다. 맵핑 카디날리티가 표현되지 않은 ER 다이어그램은 그리다 만 것과 동일하다. ER 다이어그램으로 그려진 내용은 추후 논리적 모델로 변환하는 과정을 거치게 된다. 논리적 모델링은 우리가 잘 알고 있는 테이블을 이용하여 모델링을 하는 것을 말한다. 그렇게 변화하는 과정에서 맵핑 카디날리티는 중요한 역할을 수행한다. 관계를 테이블과 관계로 표현하기 위해서 어트리뷰트를 어떻게 할 것인지(1:N, 1:1), 엔티티 변환 과정에서 테이블을 합쳐야 하는지(1:1), 추가적으로 맵핑 테이블을 만들어야하는지(N:M)와 같은 것들이 결정된다. 관계에 맵핑 카디날리티를 적는 것이 얼마나 중요한지는 더 이상 말할 필요도 없을 것이다.
다시 돌아와서 그 친구이야기를 계속 해보면 그 친구는 맵핑카디날리티를 ER다이어그램의 관계에 적을 필요가 없다는 이야기였다. 필자는 충분히 맵핑카디날리티의 중요성을 말한 것 같다. 필자의 생각에 그 친구는 교수님의 말씀을 제대로 안들었을 것이다. 교수님께서 설명하실 때 분명히 관계를 표현할 때 관련된 엔티티를 각각 선으로 연결하고 맵핑 카디날리티를 적으라는 이야기를 하셨다. 그때 열심히 듣지도 않고 필자가 열심히 설명해주고 증거를 제시해도 자기가 맞다면서 시간을 빼앗은 것이다. 물론 내가 설명을 잘 못했을 수도 있다는 것을 알고 있기는 하다. 증거제시를 해도 듣지 않았다는 것은 변명거리도 없을 것 같다. 물론 결과적으로 그 친구는 과제 성적을 좋게 받지 못했다.
필자도 사람이기 때문에 틀릴 수 있으며 언제나 그 가정을 아래에 깔고 이야기를 한다. 어떤 지식이라도 내가 잘 못 생각하고 있다는 증거(물적 증거, 논리적 증거, 정황 증거, 다른 가능성 등)를 제시하면 얼마든지 인정할 수도 있다. 하지만 상대방에게 책에 나와있다는 증거를 제시하면서 설득을 했는데도 듣지를 않았다. 그 이후 말을 듣지 않을 것 같으면 내쪽에서 그냥 포기해 버린다. 자기가 무조건적으로 맞다는 사람들은 어떤 증거를 제출하더라도 들을 생각을 안한다는 생각을 가지게 되었기 때문이다. 이전에는 모든 사람들이 잘 못 생각하고 있는 것에 대해서 증거를 대고 따지고 바로 고치기 위해서 노력했지만 이제는 그런 무의미한 설득을 위한 시간 낭비가 불필요하다고 생각하게 된 것이다.
참고자료
- Wikipedia (Entity-Relationship model) ,http://en.wikipedia.org/wiki/Entity%E2%80%93relationship_model ↩