Amazon Aurora DB - AWS RDS Aurora MySQL(4)

Last Updated on 5월 30, 2021 by 태랑(정현호)


해당 글은 아래 이전 글에서 이어지는 글 입니다.




1. Aurora 엔진 업그레이드

1-1 업그레이드 버전 과 다운타임

Amazon Aurora 는 정기적으로 업데이트를 릴리즈 됩니다. 업그레이드는 시스템 유지 기간 중에  업데이트를 적용할 수 있거나 즉시 적용을 통해 버전을 업데이트를 할 수 있습니다.

포스팅에서 아래와 같이 Aurora MySQL 5.7 2.07.2 버전을 사용하고 있으며 업그레이드 할 버전은 많이 존재하고 있습니다.




포스팅 시점에서 업그레이드 가능한 버전 리스트는 아래와 같습니다.




엔진 업그레이드는 클러스터 기준으로 진행 되는 작업 이라서 다운타임을 발생될 수 밖에 없으며 업그레이드 후에는 데이터베이스를 다시 시작해야 함으로 다운타임은 대략 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 DB는 클러스터 기준으로 업그레이드가 진행이 되게 됩니다.


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-203:00–11:00 UTC
미국 동부(버지니아 북부)us-east-103:00–11:00 UTC
미국 서부(캘리포니아 북부 지역)us-west-106:00–14:00 UTC
미국 서부(오레곤)us-west-206:00–14:00 UTC
아프리카(케이프타운)af-south-103:00–11:00 UTC
아시아 태평양(홍콩)ap-east-106:00–14:00 UTC
아시아 태평양(뭄바이)ap-south-116:30–00:30 UTC
아시아 태평양(오사카-로컬)ap-northeast-300:00–08:00 UTC
아시아 태평양(서울)ap-northeast-213:00–21:00 UTC
아시아 태평양(싱가포르)ap-southeast-114:00–22:00 UTC
아시아 태평양(시드니)ap-southeast-212:00–20:00 UTC
아시아 태평양(도쿄)ap-northeast-113:00–21:00 UTC
캐나다(중부)ca-central-103:00–11:00 UTC
중국(베이징)cn-north-106:00–14:00 UTC
중국(닝샤)cn-northwest-106:00–14:00 UTC
유럽(프랑크푸르트)eu-central-120:00–04:00 UTC
유럽(아일랜드)eu-west-122:00–06:00 UTC
유럽(런던)eu-west-222:00–06:00 UTC
유럽(파리)eu-west-307:29–14:29 UTC
유럽(밀라노)eu-south-102:00–10:00 UTC
유럽(스톡홀름)eu-north-123:00–07:00 UTC
중동(바레인)me-south-106:00–14:00 UTC
남아메리카(상파울루)sa-east-123:00–07:00 UTC
AWS GovCloud(US-East)us-gov-east-117:00–01:00 UTC
AWS GovCloud (US-West)us-gov-west-106: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. 시스템 저장 프로시저

3-1 관리자 계정 권한

Amazon RDS 과 Aurora 관리자 계정은 온프레미스의 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



conclusion

Amazon Aurora 는 PaaS 형 클라우드 서비스로 완전 관리형 데이터베이스 서비스 입니다. 이러한 완전 관리형 데이터베이스는 여러 클라우드 서비스 회사에서 여러가지 기능을 달리하여 서비스가 제공되고 있습니다. 확실히 Aurora 클러스터 DB 는 HA 기능 그리고 복제 기능, 그리고 복제 성능, 복구(복원) 기능 등에 있어서 확실히 다른 클라우드 데이터베이스 서비스에 비해 여러 장점이 있다고 생각 됩니다.


ref link.
amazon.com/rds/Aurora.Managing.Backups.html[L]
amazon.com/rds/Appendix.MySQL.SQLRef.html[L]



연관된 다른 글

 

 

 

3

+백업 하며 백업 보존 기간 동안 백업

는 정기적으로 업데이트를 릴리즈 됩니다. 업그레이드는 시스템 유지 기간 중에  업데이트를 적용할 수



1-1 업그레이드 버전 과 다운타임

에는 모든 Aurora DB 클러스터에서 사용 할 수 있는 Aurora 일반 기능인 특정 기능이 포함되어 있습니다. 


다.

답글 남기기