Last Updated on 5월 28, 2023 by Jade(정현호)
안녕하세요.
이번 포스팅은 AWS Aurora MySQL 의 네번째 연재글로 아래 글에서 이어지는 글 입니다.
Contents
1. Aurora 엔진 업그레이드
1-1 업그레이드 버전 과 다운타임
Amazon Aurora는 정기적으로 업데이트를 릴리즈 됩니다. 업그레이드는 시스템 유지 기간 중에 업데이트를 적용할 수 있거나 즉시 적용을 통해 버전을 업데이트를 할 수 있습니다.
포스팅에서 아래와 같이 Aurora MySQL 5.7 2.07.2 버전을 사용하고 있으며 업그레이드 할 버전은 많이 존재하고 있습니다.
포스팅 시점에서 업그레이드 가능한 버전 리스트는 아래와 같습니다.
엔진 업그레이드는 클러스터 기준으로 진행 되는 작업 입니다.
그래서 Reader 인스턴스 부터 작업 하고 Failover(Switch Over) 하는 형태로의 작업은 불가능 합니다.
업그레이드를 하면 클러스터 레벨로 작업이 되어 모든 인스턴스가 업그레이드 중으로 되며, 그에 다라서 다운타임을 발생될 수 밖에 없으며 업그레이드 후에는 데이터베이스를 다시 시작해야 함으로 다운 타임은 대략 20초~ 수분, 수십분 간 발행할 수 있습니다.
1-2 Amazon Aurora 버전 식별
Aurora DB 인스턴스는 Aurora 버전 번호와 Aurora 데이터베이스 엔진 번호 등 두가지 버전 번호를 제공하고 있으며 Aurora 버전 번호에는 다음 형식을 사용 합니다.
<major version>.<minor version>.<patch version>
Aurora DB 인스턴스에서 Aurora 버전 번호를 가져오려면 아래와 같이 확인 할 수 있습니다.
mysql> select aurora_version(); -- 또는 mysql> select @@aurora_version; mysql> select aurora_version(), @@aurora_version; +------------------+------------------+ | aurora_version() | @@aurora_version | +------------------+------------------+ | 2.08.1 | 2.08.1 | +------------------+------------------+
1-3 엔진 업데이트
Aurora Database는 클러스터 기준으로 업그레이드가 진행이 되게 됩니다.
1-3-1 Aurora 수정
클러스터 -> 수정 순으로 선택 합니다.
1-3-2 버전 선택
포스팅 시점에서 사용 가능한 버전은 아래와 같습니다.
포스팅에서는 아래 버전으로 진행 하도록 하겠습니다. 버전을 선택 하였다면 하단의 계속 버튼을 선택 합니다.
1-3-3 클러스터 수정
업그레이드 시점에 대해서 선택해야 하며 유지 관리 기간 중에 진행 할 지, 지금 즉시 적용 할 지를 선택을 해야 합니다 포스팅에서는 즉시 적용 을 선택하였습니다.
업그레이드를 진행 하려면 하단의 클러스터 수정 을 클릭 합니다.
1-3-4 업그레이드 완료
업그레이드 를 진행하게 되면 아래와 같이 클러스터와 클러스터내 모든 인스턴스가 같이 업그레이드가 진행 됩니다.
업그레이드가 완료 되면 아래와 같이 상태가 다시 사용가능으로 변경되게 됩니다 포스팅에서는 업그레이드 하는데 약 15분 가량 소요 되었으며 사용중인 Aurora RDS의 스팩과 시스템 상황에 따라 업그레이드 하는데 소요되는 시간은 다르게 됩니다.
2. Aurora DB 백업 및 복구
2-1 백업
Amazon Aurora 클러스터 볼륨을 자동으로 백업 보존 기간 동안 백업데이터를 보관 하게 됩니다.
Aurora 백업은 연속적 또는 증분식으로 이루어지기 때문에 백업 보전 기간 내에 어떤 시점으로도 복구가 가능 합니다. 백업 데이터를 쓰는 중에도 성능에 미치는 영향이 적거나 데이터베이스 중단 등과 같은 일은 일어나지 않습니다. 백업 보존기간은 DB 클러스터를 생성 또는 설정 할때 설정할 수 있으며 1일에서 35일까지 지정할 수 있습니다. 백업은 Amazon S3 에 저장 됩니다.
백업 보존 기간을 넘겨서 백업을 보존하고 싶을 때는 클러스터 볼륨의 데이터를 스냅샷을 캡처하는 것도 한 방법이 될 수 있습니다. Aurora DB는 전체 백업 보존 기간 중 복구 데이터를 누적 보관하기 때문에 백업 보존 기간을 넘어서까지 보관하려는 데이터는 스냅샷을 생성만 하면 됩니다.
2-2 백업 기간
자동 백업은 기본적으로 백업 기간 동안 매일 실행 되고 백업 시간이 할당된 백업 할당 시간보다 오래 걸릴 경우 백업은 완료시 까지 계속 실행됩니다. Aurora 생성시 별도로 지정하지 않았다면 Aurora 의 기본 적으로 30분을 백업 시간으로 할당 하며 각 AWS 리전 별로 8시간 블록 시간중에서 임의로 선택되어 수행되게 됩니다.
대표적으로 서울 리전의 경우 13:00~21:00 UTC 에 수행 되며 한국 GMT+9 로는 22:00~ 그다음날 06:00 사이가 됩니다. 그외 리전의 시간 블록은 아래 표와 링크를 참조하시면 됩니다.
| 리전 이름 | Region | 시간 블록 |
|---|---|---|
| 미국 동부(오하이오) | us-east-2 | 03:00–11:00 UTC |
| 미국 동부(버지니아 북부) | us-east-1 | 03:00–11:00 UTC |
| 미국 서부(캘리포니아 북부 지역) | us-west-1 | 06:00–14:00 UTC |
| 미국 서부(오레곤) | us-west-2 | 06:00–14:00 UTC |
| 아프리카(케이프타운) | af-south-1 | 03:00–11:00 UTC |
| 아시아 태평양(홍콩) | ap-east-1 | 06:00–14:00 UTC |
| 아시아 태평양(뭄바이) | ap-south-1 | 16:30–00:30 UTC |
| 아시아 태평양(오사카-로컬) | ap-northeast-3 | 00:00–08:00 UTC |
| 아시아 태평양(서울) | ap-northeast-2 | 13:00–21:00 UTC |
| 아시아 태평양(싱가포르) | ap-southeast-1 | 14:00–22:00 UTC |
| 아시아 태평양(시드니) | ap-southeast-2 | 12:00–20:00 UTC |
| 아시아 태평양(도쿄) | ap-northeast-1 | 13:00–21:00 UTC |
| 캐나다(중부) | ca-central-1 | 03:00–11:00 UTC |
| 중국(베이징) | cn-north-1 | 06:00–14:00 UTC |
| 중국(닝샤) | cn-northwest-1 | 06:00–14:00 UTC |
| 유럽(프랑크푸르트) | eu-central-1 | 20:00–04:00 UTC |
| 유럽(아일랜드) | eu-west-1 | 22:00–06:00 UTC |
| 유럽(런던) | eu-west-2 | 22:00–06:00 UTC |
| 유럽(파리) | eu-west-3 | 07:29–14:29 UTC |
| 유럽(밀라노) | eu-south-1 | 02:00–10:00 UTC |
| 유럽(스톡홀름) | eu-north-1 | 23:00–07:00 UTC |
| 중동(바레인) | me-south-1 | 06:00–14:00 UTC |
| 남아메리카(상파울루) | sa-east-1 | 23:00–07:00 UTC |
| AWS GovCloud(US-East) | us-gov-east-1 | 17:00–01:00 UTC |
| AWS GovCloud (US-West) | us-gov-west-1 | 06:00–14:00 UTC |
2-3 복구 시점
Aurora 에서 유지되는 백업 데이터나 이전에 저장한 스냅샷에서 새로운 Aurora DB 클러스터를 생성하여 데이터를 복구 할 수 있습니다. 백업 데이터에서 생성된 DB 클러스터인 새로운 복사본은 백업 보존 기간중 임의 시점으로 복구가 가능 합니다. 백업 보존 기간 중에는 Aurora 연속 백업 및 증분 기능의 특성으로 인하여 복구 횟수나 시점을 늘리기 위해서 데이터 스냅샷을 자주 생성(캡처) 할 필요가 없음을 의미 합니다.
Aurora 클러스터 DB 의 최근 또는 가장 빠른 복원 가능 시간을 확인 하려면 RDS 콘솔 -> 유지 관리 및 백업 에서 확인 할 수 있습니다
[참고] UTC 로 써있는 시간은 +9시간을 계산해야 한국 시간 입니다.
최근 복원 시간은 DB 클러스터를 복구 할 수 있는 가장 최근 시점을 의미 하며 보통 5분 이내가 됩니다.
2-4 복구 수행
Aurora 에서는 특정 시점으로 복원하여 새로운 DB 클러스터를 생성할 수 있습니다.
DB 클러스터를 특정 시점으로 복원할 경우 새로운 DB 클러스터에는 기본 DB 보안 그룹으로 적용되어 생성 됩니다. 그래서 사용자 정의(지정) DB 보안그룹을 DB 클러스터에 적용해야할 경우 복원이 완료 된 이후에 AWS 콘솔이나 AWS CLI 를 통해서 ModifyDBCluster 작업을 별도로 수행 해야 합니다.
또한 복원 복원 된 클러스터 DB는 기본 파라미터 및 옵션 그룹으로 자동으로 연결됩니다. 그렇기 때문에 복원 전 사용한 클러스터에서 별도로 설정한 파라미터가 있다면 새로운 파라미터 그룹 생성 그리고 파라미터 변경 그 다음 적용 하는 순으로 별도로 파라미터에 대한 변경 작업이 필요 합니다.
파라미터 그룹 변경 적용은 이전 포스팅을 참조하시면 됩니다.
2-4-1 복구할 테이블 삭제
먼저 테스트를 위해서 기존의 임의의 테이블을 시간 확인 후 삭제를 진행하겠습니다.
MySQL [test]> select sysdate(); +---------------------+ | sysdate() | +---------------------+ | 2021-05-29 12:59:15 | +---------------------+ -- 한국시간으로 21:59 분 경임 MySQL [test]> show tables; +----------------+ | Tables_in_test | +----------------+ | tb_123 | | tb_1234 | | tb_12345 | +----------------+ -- 테이블 삭제 MySQL [test]> drop table tb_123;
2-4-2 특정 시점으로 복원
클러스터 -> 작업 -> 특정 시점으로 복원 순으로 진행 합니다.
2-4-3 복원 시점 지정
먼저 복원 시간을 정해야 하며 가장 복구 가능한 최근 시점을 지정 하거나 사용자가 원하는 시간을 지정할 수 있습니다. 포스팅에서는 한국시간 21시 59분경에 테이블을 삭제 하였기 때문에 21시 55분 시점으로 복구를 시도 하였습니다.
그리고 DB 인스턴스 식별자 정보를 입력 해야 합니다 클러스터 명을 지정하면 됩니다.
2-4-4 DB 인스턴스 크기 지정
DB 인스턴스의 사양을 지정할 수 있으며 포스팅에서는 복구되는 원본 DB 인스턴스와 동일한 사양의 인스턴스를 선택하였습니다.
2-4-5 네트워크 설정
네트워크(연결) 을 선택하는 항목으로 VPC 및 서브넷 그룹, Aurora Port 등을 설정 할 수 있습니다.
2-4-6 인증 및 추가 구성
먼저 데이터베이스 인증 옵션을 선택할 수 있으며 포스팅에서는 암호 인증 을 선택 하여 진행하였습니다. 그 다음 추가 구성에서는 파라미터 그룹 선택을 변경 할 수 있습니다 기본은 default 파라미터로 선택되어 있습니다. 
2-4-7 복원 시작
추가적인 설정을 완료 한 후 하단의 "특정 시점으로 복원" 버튼을 선택 합니다.
2-4-8 복원 완료
복원이 시작하면 아래와 같이 생성 중으로 확인 되며 먼저 클러스터가 생성 된 이후 인스턴스가 생성되는 순서로 진행 됩니다. 복원에 소요 되는 시간은 원본 DB의 사이즈 등에 따라서 차이가 있으며 수십 여분 정도 소요 됩니다.
생성이 완료 된다면 아래와 같이 사용 가능 으로 확인 됩니다. 그리고 관리자 계정은 복원이 되어 생성이되는 클러스터 DB 이기 때문에 복제 원본 DB와 동일 합니다.
복원이 완료 되었기 때문에 테이블의 복원여부도 확인 해보면 아래와 같이 삭제한 테이블이 다시 복원된 것을 확인 할 수 있습니다.
User$ mysql -u admin -p -h myaurora-instance-recovery-cluster.xxx.rds.amazonaws.com Enter password: Server version: 5.7.12 MySQL Community Server (GPL) Type 'help;' or '\h' for help. Type '\c' to clear the current input statement. MySQL [(none)]> use test; Reading table information for completion of table and column names You can turn off this feature to get a quicker startup with -A -- 삭제된 test_123 테이블의 복구 확인 MySQL [test]> show tables; +----------------+ | Tables_in_test | +----------------+ | tb_123 | | tb_1234 | | tb_12345 | +----------------+
3. 시스템 저장 프로시저
Amazon RDS 나 다른 클라우드의 서비스형 DB 특성상 권한에 제약이 있을 수 있으며 그에 따라서 특정 작업을 할 때는 미리 준비된 프로시저를 사용해야 할 경우가 있습니다.
3-1 관리자 계정 권한
Amazon RDS 과 AWS Aurora 관리자 계정은 설치형 MySQL 의 root 계정과 권한 차이가 있으며, 권한 일부가 제외 된 형태로 사용자에게 제공되게 됩니다.
mysql> show grants for 'admin'@'%';
GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, RELOAD, PROCESS, REFERENCES, INDEX, ALTER, SHOW DATABASES, CREATE TEMPORARY TABLES, LOCK TABLES, EXECUTE, REPLICATION SLAVE, REPLICATION CLIENT, CREATE VIEW, SHOW VIEW, CREATE ROUTINE, ALTER ROUTINE, CREATE USER, EVENT, TRIGGER, LOAD FROM S3, SELECT INTO S3, INVOKE LAMBDA, INVOKE SAGEMAKER, INVOKE COMPREHEND ON *.* TO 'admin'@'%' WITH GRANT OPTION
AWS RDS 나 Aurora DB 는 PaaS 형태의 완전 관리형 데이터베이스 서비스를 이용하는 것으로 사용자의 일부 컨트롤의 제약이 발생될 수 밖에 없는 형태 입니다.
3-2 시스템 프로시저
Amazon 생성시 부여 받은 관리자 계정은 일부 권한이 제거된 형태로 생성되어 제공되기 때문에 특정 작업은 RDS에서 제공되는 프로시저를 통해서 수행해야 하며 대표적인 작업이 세션 kill 이 있습니다.
아래와 같이 관리자 계정으로 일반 계정을 kill 을 수행할 경우 수행이 되지 않습니다.
MySQL [test]> show full processlist; +----+----------+--------------------+------+---------+------+-------------+-----------------------+ | Id | User | Host | db | Command | Time | State | Info | +----+----------+--------------------+------+---------+------+-------------+-----------------------+ | 8 | rdsadmin | localhost | NULL | Sleep | 2 | cleaning up | NULL | | 9 | rdsadmin | localhost | NULL | Sleep | 1 | cleaning up | NULL | | 10 | rdsadmin | localhost | NULL | Sleep | 0 | cleaning up | NULL | | 13 | rdsadmin | localhost | NULL | Sleep | 292 | cleaning up | NULL | | 25 | admin | xxxxxxxxxxxx:57420 | test | Query | 0 | starting | show full processlist | | 26 | test | xxxxxxxxxxxx:57636 | NULL | Sleep | 8 | cleaning up | NULL | +----+----------+--------------------+------+---------+------+-------------+-----------------------+ 6 rows in set (0.000 sec) MySQL [test]> kill 26; ERROR 1095 (HY000): You are not owner of thread 26
그래서 rds_kill 이라는 프로시저를 사용 해서 세션(프로세스)를 kill 해야 합니다.
MySQL [test]> use mysql; Reading table information for completion of table and column names You can turn off this feature to get a quicker startup with -A Database changed MySQL [mysql]> call rds_kill(26); Query OK, 0 rows affected (0.003 sec) MySQL [mysql]> show full processlist; +----+----------+--------------------+-------+---------+------+-------------+-----------------------+ | Id | User | Host | db | Command | Time | State | Info | +----+----------+--------------------+-------+---------+------+-------------+-----------------------+ | 8 | rdsadmin | localhost | NULL | Sleep | 5 | cleaning up | NULL | | 9 | rdsadmin | localhost | NULL | Sleep | 1 | cleaning up | NULL | | 10 | rdsadmin | localhost | NULL | Sleep | 0 | cleaning up | NULL | | 13 | rdsadmin | localhost | NULL | Sleep | 190 | cleaning up | NULL | | 25 | admin | 172.31.3.200:57420 | mysql | Query | 0 | starting | show full processlist | +----+----------+--------------------+-------+---------+------+-------------+-----------------------+ 5 rows in set (0.000 sec) MySQL [mysql]>
그외 제공되는 시스템 프로시저는 아래와 같습니다.
복제
mysql.rds_set_master_auto_position
mysql.rds_set_external_master
mysql.rds_set_external_master_with_delay
mysql.rds_set_external_master_with_auto_position
mysql.rds_reset_external_master
mysql.rds_import_binlog_ssl_material
mysql.rds_remove_binlog_ssl_material
mysql.rds_set_source_delay
mysql.rds_start_replication
mysql.rds_start_replication_until
mysql.rds_start_replication_until_gtid
mysql.rds_stop_replication
mysql.rds_skip_transaction_with_gtid
mysql.rds_skip_repl_error
mysql.rds_next_master_log
복제 InnoDB 캐시 워밍
mysql.rds_innodb_buffer_pool_dump_now
mysql.rds_innodb_buffer_pool_load_now
mysql.rds_innodb_buffer_pool_load_abort
복제 추가 구성 관리(예: binlog 파일보관)
mysql.rds_set_configuration
mysql.rds_show_configuration
세션 또는 쿼리 종료
mysql.rds_kill
mysql.rds_kill_query
로깅
mysql.rds_rotate_general_log
mysql.rds_rotate_slow_log
전역적 상태 이력 관리
mysql.rds_enable_gsh_collector
mysql.rds_set_gsh_collector
mysql.rds_disable_gsh_collector
mysql.rds_collect_global_status_history
mysql.rds_enable_gsh_rotation
mysql.rds_set_gsh_rotation
mysql.rds_disable_gsh_rotation
mysql.rds_rotate_global_status_history
4. Hash Join
AWS Aurora for MySQL 에서 Hash Join 이 지원되며 MySQL 5 버전의 호환 버전인 Aurora for MySQL 2 에서는 2.06 버전 부터 Hash Join 을 사용할 수 있습니다.
3 버전에서는 Hash Join 옵티마이저가 기본적으로 활성화 되어있어서 사용하면 되며, 2 버전에서는 기본으로 비활성화 되어 있으므로 SET optimizer_switch 을 통해 활성화 해서 사용해야 합니다.
• Hash Join 활성화
For Aurora MySQL version 1 and 2: mysql> SET optimizer_switch='hash_join=on'; For Aurora MySQL version 3: mysql> SET optimizer_switch='block_nested_loop=on';
자세한 내용은 아래 내용을 참고하시면 됩니다.
5. Conclusion
Amazon Aurora 는 PaaS 형 클라우드 서비스로 완전 관리형 데이터베이스 서비스 입니다.
이러한 완전 관리형 데이터베이스는 여러 클라우드 서비스 회사에서 여러가지 기능을 달리하여 서비스가 제공되고 있습니다.
확실히 Aurora 클러스터 DB 는 HA 기능 그리고 복제 기능, 그리고 복제 성능, 복구(복원) 기능 등에 있어서 확실히 다른 클라우드 데이터베이스 서비스에 비해 여러 장점이 있다고 생각 됩니다.
연관된 이어지는 다음 글
6. Reference
reference link
• amazon.com/Aurora.Managing.Backups
• amazon.com/Appendix.MySQL.SQLRef
연관된 다른 글
제공 되는 서비스의 종류는 사이트에서 확인 해보시면 됩니다. 프리티어 에서 사용가능한 컴퓨팅 의 자격(Spec) 과 제한은 먼저 컴퓨팅은 t2.micro 로 제공 되고 있습니다.
Principal DBA(MySQL, AWS Aurora, Oracle)
핀테크 서비스인 핀다에서 데이터베이스를 운영하고 있어요(at finda.co.kr)
Previous - 당근마켓, 위메프, Oracle Korea ACS / Fedora Kor UserGroup 운영중
Database 외에도 NoSQL , Linux , Python, Cloud, Http/PHP CGI 등에도 관심이 있습니다
purityboy83@gmail.com / admin@hoing.io