// 1. mysql 설치 및 확인
brew install mysql
mysql --version // 설치 확인
// 2. server start
mysql.server start
// 3. 환경설정 작업
mysql_secure_installation
VALIDATE PASSWORD COMPONENT ( 복잡한 비밀번호 Y/N) : n
2. set the password (비밀번호 설정 & 확인)
3. Remove anonymous users? (익명 사용자 삭제) : y (n일경우는 mysql 만으로 접속 가능)
4. Disallow root login remotely? (원격 접속 허용하지 않을지) : y(localhost 외 다른 IP에서의 접속을 허용하지 않게 된다.)
5. Remove test database and access to it? (test DB 삭제 여부) : n(n면 삭제되지 않는다.)
6) Reload privilege tables now? (변경된 권한을 반영하여 테이블 다시 로드) : y
// 4. mysql 접속
mysql -u root -p
// 5. mysql 접속 종료
exit
// 6. server stop
mysql.server stop
// 7. mysql 경로
which mysql
> /opt/homebrew/bin/mysql
HBase와 MongoDB는 특정 유스케이스에 적합한 DBMS인 반면, MySQL 서버와 같은 RDBMS는 범용 DBMS 영역에 속한다.
어떤 서비스를 개발하든 초기에는 범용 DBMS를 선택하고, 사용량이나 데이터가 커지면 일부 도메인 또는 테이블의 데이터만 전용 DBMS로 이전해서 확장하는 형태를 대부분 회사에서 선택하고 있다.
그래서 어떤서비스를 개발하더라도 RDBMS 선택을 피할 수 없으며, 그 선택의 첫 번째 후보로 MySQL 서버가 견고하게 자리잡고 있다. 이는 다른 DBMS보다 MySQL 서버의 노력과 시간 투자 대비 효율이 가장 높다는 것을 의미하며, 서비스 개발자라면 MySQL 서버를 이해하기 위해서 시간을 투자해야 하는 이유다.
최근에는 다양한 프로그래밍 언어에서 ORM 도구를 지원하고 있으며, 많은 프로젝트에서 ORM 기능을 채택하고 있다. 더 나아가서 SQL 문장을 직접 작성하는 것보다 ORM을 통해서 간접적으로 DBMS를 접근하는 것을 더 선호하는 개발자들도 많아졌다.
그러나 ORM은 DBMS와의 인터렉션을 블랙박스로 만들어 버리기 때문에 ORM 도구가 DBMS로 어떤 쿼리를 실행하는지를 알기 어렵다.
ORM이 만들어 내는 쿼리가 여러분이 직접 작성하는 쿼리보다 더 나은 성능을 보일 것이라는 기대를 해서는 안 되며, 유스케이스별로 ORM이 생성한 쿼리들을 검토해볼 것을 권장한다. 즉 ORM이 최적은 아니어도 최악의 쿼리를 만들어내는 경우를 회피하기 위해 서비스 개발자는 RDBMS와 쿼리 처리 방식을 이해할 필요가 있다.
“어떤 DBMS를 사용해야 할까?”
→ 자기가 가장 잘 활용할 수 있는 DBMS가 가장 좋은 DBMS 다.
→ ‘안전성, 성능과 기능, 커뮤니티나 인지도’ 를 기준으로 고려하자.
1-1. 들어가기 전에
초기 버전의 MySQL 서버는 엔터프라이즈 에디션과 커뮤니티 에디션으로 나뉘어 있기만 했지만, 실제 MySQL 서버의 기능에 차이가 있었던 것이 아니라 기술 지원의 차이만 있었다.
하지만 MySQL 5.5 버전부터는 커뮤니티와 엔터프라이즈 에디션의 기능이 달라지면서 소스코드도 달라졌고, MySQL 엔터프라이즈 에디션의 소스코드는 더이상 공개되지 않는다.
하지만 MySQL 서버의 상용화 전략은 핵심 내용은 엔터프라이즈 에디션과 커뮤니티 에디션 모두 동일하며, 특정 부가 기능들만 상용 버전인 엔터프라이즈 에디션에 포함되는 방식이다.
이런 상용화 방식을 오픈 코어 모델(Open Core Model) 이라고 한다.
1-2. MySQL 설치
이미 이전에 brew로 설치하여 설치 과정은 생략한다.
[디렉토리]
bin : MySQL 서버와 클라이언트 프로그램, 유틸리티를 위한 디렉터리
data : 로그 파일과 데이터 파일들이 저장되는 디렉터리
include : C/C++ 헤더 파일들이 저장된 디렉터리
lib : 라이브러리 파일들이 저장된 디렉터리
share : 다양한 지원 파일들이 저장되어 있으며, 에러 메시지나 샘플 설정 파일(my.cnf)이 있는 디렉터리
** 클린 셧다운(Clean Shutdown) : 모든 커밋된 데이터를 파일에 적용하고 종료하는 것
** MySQL 서버가 시작되거나 종료될 때는 MySQL서버(InnoDB 스토리지 엔진)의 버퍼 풀 내용을 백업하고 복구하는 과정이 내부적으로 실행된다. 실제 버퍼 풀의 내용을 백업하는 것이 아니라, 버퍼 풀에 적재돼 있던 데이터 파일의 데이터 페이지에 대한 메타 정보를 백업하기 때문에 용량이 크지 않으며, 백업 자체는 매우 빠르게 완료된다. 하지만 MySQL 서버가 새로 시작될 때는 디스크에서 데이터 파일들을 모두 읽어서 적재해야 하므로 상당한 시간이 걸릴 수도 있다. MySQL 서버의 시작 시간이 오래 걸린다면 MySQL 서버가 버퍼 풀의 내용을 복구하고 있는지 확인해보는 것이 좋다.
SHOW DATABASES;
: 생성된 데이터베이스 목록 확인
[업그레이드 방법]
- MySQL 서버의 데이터 파일을 그대로 두고 업그레이드 하는 방법 (인플레이스 업그레이드)
- mysqldump 도구 등을 이용해 MySQL 서버의 데이터를 SQL 문장이나 텍스트 파일로 덤프한 후, 새로 업데이트된 버전의 MySQL 서버에서 덤프된 데이터를 적재하는 방법 (논리적 업그레이드)
인플레이스 업그레이드 : 여러 제약 사항이 있지만, 시간을 크게 단축할 수 있음
논리적 업그레이드 : 버전 간 제약 사항이 거의 없지만 업그레이드 시간이 많이 소요
[업그레이드 하기 전 체크할 것들]
- 사용자 인증 방식 변경 : Caching SHA-2 Authentication 을 기본 인증 방식
- MySQL 8.0 과의 호환성 체크 : 손상된 FRM 파일이나 호환되지 않는 데이터 타입, 함수가 있는지 mysqlcheck 유틸리티 사용
- 외래키 이름의 길이 : MySQL 8.0부터는 64글자로 제한
- 인덱스 힌트 :
- GROUP BY 에 사용된 정렬 옵션
- 파티션을 위한 공용 테이블베이스
[MySQL 8.0 업그레이드]
- 데이터 딕셔너리 업그레이드
- 서버 업그레이드
- 내 컴퓨터 my.cnf 위치 :
/opt/homebrew/etc
실제 MySQL 서버는 단 하나의 설정 파일(my.cnf)만 사용하지만 설정 파일이 위치한 디렉터리는 여러 곳일 수 있다.
이러한 특성은 MySQL 사용자를 상당히 혼란스럽게 하는 부분이기도 하다.
[정적 변수와 동적 변수]
: MySQL 서버가 기동 중인 상태에서 변경 가능한지에 따라 동적 변수와 정적 변수로 나뉜다.
: MySQL 서버의 시스템 변수는 디스크에 저장돼 있는 설정 파일(my.cnf)을 변경하는 경우와 이미 기동 중인 MySQL 서버의 메모리에 있는 MySQL 서버의 시스템 변수를 변경하는 경우로 구분할 수 있다. 디스크에 저장된 설정 파일의 내용은 변경하더라도 MySQL 서버가 재시작하기 전에는 적용되지 않는다.
SET 명령을 통해 변경되는 시스템 변숫값이 MySQL의 설정 파일인 my.cnf 파일에 반영되는 것은 아니기 때문에 현재 기동 중인 MySQL 인스턴스에서만 유효하다. 그러나 MySQL 8.0부터는 SET PERSIST 명령을 이용하여 실행 중인 MySQL 서버의 시스템 변수를 변경함과 동시에 자동으로 설정 파일로도 기록된다.
SHOW나 SET 명령에서 GLOBAL 키워드를 사용하면 글로벌 시스템 변수의 목록과 내용을 읽고 변경할 수 있으며, GLOBAl 키워드를 빼면 자동으로 세션 변수를 조회하고 변경한다.
ex) SET GLOBAL max_connections=5000;
이렇게 변경한 후 MySQL 서버의 설정 파일에서도 이 내용을 적용해야 하는데, 응급조치를 하다 보면 MySQL 서버의 설정 파일에 변경 내용을 적용하는 것을 잊게되면 이로 인한 장애가 반복적으로 발생하게 된다.
그래서 MySQL 8.0 부터는 아래와 같이 SET PERSIST 명령을 도입했다.
ex) SET PERSIST max_connections=5000;
현재 실행 중인 MySQL 서버에는 변경 사항을 저장하지 않고 다음 재시작을 위해 mysqld-auto.cnf 파일에만 변경 내용을 길고해두고자 할 때는 아래와 같이 쓴다.
ex) SET PERSIST_ONLY max_connection=5000;
SET PERSIST, SET PERSIST_ONLY 명령으로 시스템 변수를 변경하면 JSON 포멧의 mysqld-auto.cnf 파일이 생성된다.