

# Aurora MySQL 데이터베이스 로그 파일
<a name="USER_LogAccess.Concepts.MySQL"></a>

Amazon RDS 콘솔, Amazon RDS API, AWS CLI 또는 AWS SDK를 통해 Aurora MySQL 로그를 직접 모니터링할 수 있습니다. 또한, 주 데이터베이스에 있는 데이터베이스 테이블로 로그를 전송하고 그 테이블을 쿼리하여 MySQL 로그에 액세스할 수 있습니다. mysqlbinlog 유틸리티를 사용하여 이진 로그를 다운로드할 수 있습니다.

파일 기반 데이터베이스 로그 보기, 다운로드 및 조사 방법에 대한 자세한 내용은 [Amazon Aurora 로그 파일 모니터링](USER_LogAccess.md) 단원을 참조하십시오.

**Topics**
+ [Aurora MySQL 데이터베이스 로그 개요](USER_LogAccess.MySQL.LogFileSize.md)
+ [AuroraMySQL 로그 출력을 표로 보내기](Appendix.MySQL.CommonDBATasks.Logs.md)
+ [단일 AZ 데이터베이스의 Aurora MySQL 이진 로깅 구성](USER_LogAccess.MySQL.BinaryFormat.md)
+ [MySQL 이진 로그 액세스](USER_LogAccess.MySQL.Binarylog.md)

# Aurora MySQL 데이터베이스 로그 개요
<a name="USER_LogAccess.MySQL.LogFileSize"></a>

다음 유형의 Aurora MySQL 로그 파일을 모니터링할 수 있습니다.
+ 오류 로그
+ 느린 쿼리 로그
+ 일반 로그
+ 감사 로그
+ 인스턴스 로그
+ IAM 데이터베이스 인증 오류 로그

Aurora MySQL 오류 로그는 기본적으로 생성됩니다. DB 파라미터 그룹에서 파라미터를 설정하여 느린 쿼리 및 일반 로그를 생성할 수 있습니다.

**Topics**
+ [Aurora MySQL 오류 로그](#USER_LogAccess.MySQL.Errorlog)
+ [Aurora MySQL 느린 쿼리 로그 및 일반 로그](#USER_LogAccess.MySQL.Generallog)
+ [Aurora MySQL 감사 로그](#ams-audit-log)
+ [Aurora MySQL 인스턴스 로그](#ams-instance-log)
+ [Aurora MySQL용 로그 교체 및 보존](#USER_LogAccess.AMS.LogFileSize.retention)
+ [Amazon CloudWatch Logs에 Aurora MySQL 로그 게시](#USER_LogAccess.MySQLDB.PublishAuroraMySQLtoCloudWatchLogs)

## Aurora MySQL 오류 로그
<a name="USER_LogAccess.MySQL.Errorlog"></a>

Aurora MySQL은 `mysql-error.log` 파일에 오류를 기록합니다. 각 로그 파일이 생성된 시간(UTC)이 파일 이름에 추가됩니다. 로그 파일에는 타임스탬프도 포함되어 있어, 로그 항목이 작성된 시간을 확인하는 데 도움이 됩니다.

Aurora MySQL에서는 시작, 종료 및 오류 발생 시에만 오류 로그에 데이터가 로그됩니다. DB 인스턴스는 오류 로그에 새 항목이 기록되지 않는 상태로 몇 시간이나 며칠씩 작동할 수 있습니다. 최근 항목이 보이지 않으면 이는 서버에서 로그에 입력될 만한 오류가 발생하지 않았기 때문입니다.

기본적으로 오류 로그는 오류와 같은 예기치 않은 이벤트만 표시되도록 필터링됩니다. 그러나 오류 로그에는 쿼리 진행률과 같이 표시되지 않는 몇 가지 추가 데이터베이스 정보도 포함되어 있습니다. 따라서 실제 오류가 없더라도 진행 중인 데이터베이스 작업으로 인해 오류 로그의 크기가 커질 수 있습니다. 그리고 AWS Management Console에서 오류 로그의 특정 크기(바이트 또는 킬로바이트)를 볼 수 있지만 다운로드할 때 0바이트일 수 있습니다.

Aurora MySQL은 5분마다 `mysql-error.log`를 디스크에 씁니다. 또한, 로그의 콘텐츠를 `mysql-error-running.log`에 추가합니다.

Aurora MySQL은 `mysql-error-running.log` 파일을 1시간마다 교체합니다.

**참고**  
로그 보존 기간은 Amazon RDS와 Aurora 간에 다릅니다.

## Aurora MySQL 느린 쿼리 로그 및 일반 로그
<a name="USER_LogAccess.MySQL.Generallog"></a>

Aurora MySQL 느린 쿼리 로그와 일반 로그를 파일이나 데이터베이스 테이블에 기록할 수 있습니다. 그러려면 DB 파라미터 그룹의 파라미터를 설정합니다. DB 파라미터 그룹의 생성 및 변경에 대한 자세한 내용은 [Amazon Aurora의 파라미터 그룹](USER_WorkingWithParamGroups.md) 단원을 참조하십시오. 이런 파라미터를 설정해야 Amazon RDS 콘솔에서 느린 쿼리 로그 또는 일반 로그를 볼 수 있습니다. 아니면 Amazon RDS API, Amazon RDS CLI 또는 AWS SDK를 사용하여 볼 수 있습니다.

이 목록에 있는 파라미터를 사용하여 Aurora MySQL 로깅을 제어할 수 있습니다.
+ `slow_query_log`: 느린 쿼리 로그를 만들려면 1로 설정합니다. 기본값은 0입니다.
+ `general_log`: 일반 로그를 만들려면 1로 설정합니다. 기본값은 0입니다.
+ `long_query_time`: 빠르게 실행되는 쿼리가 느린 쿼리 로그에 기록되지 않도록 하려면 로깅할 쿼리의 최단 런타임 값(초)을 지정합니다. 기본값은 10초이고, 최소값은 0초입니다. log\$1output = FILE인 경우에는 마이크로초 단위까지 부동 소수점 값을 지정할 수 있습니다. log\$1output = TABLE인 경우에는 초 단위로 정수 값을 지정해야 합니다. 런타임이 `long_query_time` 값을 초과하는 쿼리만 로깅됩니다. 예를 들어 `long_query_time`을 0.1로 설정하면 100밀리초 미만의 시간 동안 작동하는 쿼리가 로그에 기록되지 않습니다.
+ `log_queries_not_using_indexes`: 인덱스를 사용하지 않는 모든 쿼리를 느린 쿼리 로그에 기록하려면 1로 설정합니다. 인덱스를 사용하지 않는 쿼리는 런타임이 `long_query_time` 파라미터의 값보다 짧아도 로깅됩니다. 기본값은 0입니다.
+ `log_output option`: `log_output` 파라미터에 대해 다음 옵션 중 하나를 지정할 수 있습니다.
  + **TABLE** – 일반 쿼리를 `mysql.general_log`테이블에 쓰고 느린 쿼리를 `mysql.slow_log` 테이블에 씁니다.
  + **FILE** – 일반 쿼리 로그와 느린 쿼리 로그를 모두 파일 시스템에 씁니다.
  + **NONE** – 로깅을 비활성화합니다.

  Aurora MySQL 버전 2 및 3의 경우 `log_output`의 기본값은 `FILE`입니다.

느린 쿼리 데이터가 Amazon CloudWatch Logs에 표시되려면 다음 조건을 충족해야 합니다.
+ 느린 쿼리 로그를 포함하도록 CloudWatch Logs를 구성해야 합니다.
+ `slow_query_log`를 활성화해야 합니다.
+ `log_output`/를 로 설정해야 합니다.`FILE`
+ 쿼리는 `long_query_time`에 구성된 시간보다 오래 걸릴 수 있습니다.

느린 쿼리 및 일반 로그에 대한 자세한 내용은 MySQL 문서에서 다음 항목을 참조하십시오.
+ [느린 쿼리 로그](https://dev.mysql.com/doc/refman/8.0/en/slow-query-log.html)
+ [일반 쿼리 로그](https://dev.mysql.com/doc/refman/8.0/en/query-log.html)

## Aurora MySQL 감사 로그
<a name="ams-audit-log"></a>

Aurora MySQL에 대한 감사 로깅을 고급 감사라고 합니다. 고급 감사를 켜려면 특정 DB 클러스터 파라미터를 설정합니다. 자세한 내용은 [Amazon Aurora MySQL DB 클러스터에서 고급 감사 사용](AuroraMySQL.Auditing.md) 섹션을 참조하세요.

## Aurora MySQL 인스턴스 로그
<a name="ams-instance-log"></a>

Aurora는 자동 일시 중지가 사용 설정된 DB 인스턴스에 대해 별도의 로그 파일을 만듭니다. 이 instance.log 파일은 예상 시 이러한 DB 인스턴스를 일시 중지할 수 없는 이유를 기록합니다. 인스턴스 로그 파일 동작 및 Aurora 자동 일시 중지 기능에 대한 자세한 내용은 [Aurora Serverless v2 일시 중지 및 재개 활동 모니터링](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-serverless-v2-administration.html#autopause-logging-instance-log)을 참조하시기 바랍니다.

## Aurora MySQL용 로그 교체 및 보존
<a name="USER_LogAccess.AMS.LogFileSize.retention"></a>

로깅을 사용하는 경우 Amazon Aurora는 로그 파일을 정기적으로 교체하거나 삭제합니다. 이러한 예방 조치를 취하면 데이터베이스 사용에 방해가 되거나 성능에 영향을 미치는 큰 로그 파일이 생성될 가능성을 줄일 수 있습니다. Aurora MySQL은 교체 및 삭제를 다음과 같이 처리합니다.
+ Aurora MySQL 오류 로그 파일 크기는 DB 인스턴스 로컬 스토리지의 15% 이하로 제한됩니다. 이 임계값을 유지하기 위해 매시간 로그가 자동으로 교체됩니다. Aurora MySQL은 30일 후 또는 디스크 공간의 15%가 차면 로그를 제거합니다. 오래된 로그 파일을 제거한 후 로그 파일의 총 크기가 임계값을 초과하는 경우에는 로그 파일의 전체 크기가 임계값 이하로 작아질 때까지 가장 오래된 로그 파일부터 차례대로 삭제됩니다.
+ Aurora MySQL는 24시간 후 또는 스토리지의 15%가 사용된 후 감사, 일반 및 느린 쿼리 로그를 제거합니다.
+ `FILE` 로깅을 사용하는 경우 일반 로그 및 느린 쿼리 로그 파일은 매시간 검사되며 24시간 이상 지난 로그 파일은 삭제됩니다. 삭제 후 남은 결합 로그 파일 크기가 DB 인스턴스에 할당된 로컬 공간 중 15%의 임계값을 초과하는 경우도 있습니다. 이 경우 로그 파일의 전체 크기가 임계값 이하로 작아질 때까지 가장 오래된 로그 파일부터 차례대로 삭제됩니다.
+ `TABLE` 로깅을 사용하는 경우 로그 테이블이 교체되거나 삭제되지 않습니다. 결합된 모든 로그의 크기가 너무 크면 로그 테이블이 잘립니다. 공간 확보를 위해 로그 테이블을 수동으로 교체하거나 삭제해야 할 때 알림을 받기 위해 `low storage` 이벤트 범주를 구독할 수 있습니다. 자세한 내용은 [Amazon RDS 이벤트 알림 작업](USER_Events.md) 섹션을 참조하세요.

  `mysql.rds_rotate_general_log` 절차를 호출하면 수동으로 `mysql.general_log` 테이블을 교체할 수 있습니다. `mysql.slow_log` 절차를 호출하면 `mysql.rds_rotate_slow_log` 테이블을 순환할 수 있습니다.

  로그 테이블을 수동으로 교체하면 현재 로그 테이블이 백업 로그 테이블에 복사되고 현재 로그 테이블의 항목이 제거됩니다. 백업 로그 테이블이 이미 존재할 경우, 현재 로그 테이블이 백업으로 복사되기 전에 백업 로그 테이블이 삭제됩니다. 필요하다면 백업 로그 테이블을 쿼리할 수 있습니다. `mysql.general_log` 테이블에 대한 백업 로그 테이블 이름은 `mysql.general_log_backup`으로 지정됩니다. `mysql.slow_log` 테이블에 대한 백업 로그 테이블 이름은 `mysql.slow_log_backup`으로 지정됩니다.
+ Aurora MySQL 감사 로그는 파일 크기가 100MB에 도달하면 교체되고 24시간 후에 제거됩니다.
+ Amazon RDS는 10MB보다 큰 IAM 데이터베이스 인증 오류 로그 파일을 교체합니다. Amazon RDS는 5일 이상 또는 100MB 이상의 IAM 데이터베이스 인증 오류 로그 파일을 제거합니다.

Amazon RDS 콘솔, Amazon RDS API, Amazon RDS CLI 또는 AWS SDK에서 로그를 사용하여 작업하려면 `log_output` 파라미터를 FILE로 설정합니다. Aurora MySQL 오류 로그와 마찬가지로, 이러한 로그 파일은 매시간 교체됩니다. 이전의 24시간 동안 생성된 로그 파일이 보존됩니다. 보존 기간은 Amazon RDS와 Aurora 간에 다릅니다.

## Amazon CloudWatch Logs에 Aurora MySQL 로그 게시
<a name="USER_LogAccess.MySQLDB.PublishAuroraMySQLtoCloudWatchLogs"></a>

Amazon CloudWatch Logs의 로그 그룹에 로그 데이터를 게시하도록 Aurora MySQL DB 클러스터를 구성할 수 있습니다. CloudWatch Logs를 통해 로그 데이터에 대한 실시간 분석을 수행할 수 있고, CloudWatch를 사용하여 경보를 만들고 지표를 볼 수 있습니다. CloudWatch Logs를 사용하여 내구성이 뛰어난 스토리지에 로그 레코드를 저장할 수 있습니다. 자세한 내용은 [Amazon CloudWatch Logs에 Amazon Aurora MySQL 로그 게시](AuroraMySQL.Integrating.CloudWatch.md) 섹션을 참조하세요.

# AuroraMySQL 로그 출력을 표로 보내기
<a name="Appendix.MySQL.CommonDBATasks.Logs"></a>

DB 파라미터 그룹을 만들고 `log_output` 서버 파라미터를 `TABLE`로 설정하여 일반 및 느린 쿼리 로그를 DB 인스턴스 상의 테이블로 전송할 수 있습니다. 그러면 일반 쿼리는 `mysql.general_log` 테이블에, 느린 쿼리는 `mysql.slow_log` 테이블에 로그가 기록됩니다. 이들 테이블을 쿼리하여 로그 정보에 액세스할 수 있습니다. 이 로깅을 활성화하면 데이터베이스에 기록되는 데이터의 양이 증가하여 성능이 저하될 수 있습니다.

일반 로그와 느린 쿼리 로그는 모두 기본적으로 비활성화됩니다. 테이블에 대한 로깅을 활성화하려면 `general_log` 및 `slow_query_log` 서버 파라미터도 `1`로 설정해야 합니다.

관련 파라미터를 `0`으로 설정하여 각 로깅 활동을 해제할 때까지 로그 테이블은 계속 커집니다. 흔히 대량의 데이터가 시간 경과에 따라 누적되어 할당된 스토리지 공간 중 상당한 비율을 사용할 수 있습니다. Amazon Aurora에서는 로그 테이블을 자를 수 없지만 테이블의 콘텐츠를 이동할 수 있습니다. 테이블을 순환하면 그 내용이 백업 테이블에 저장된 다음 빈 로그 테이블이 새로 생성됩니다. 다음 명령줄 프로시저로 로그 테이블을 수동으로 순환시킬 수 있으며, 이때 명령 프롬프트는 `PROMPT>`로 표시됩니다.

```
PROMPT> CALL mysql.rds_rotate_slow_log;
PROMPT> CALL mysql.rds_rotate_general_log;
```

오래된 데이터를 완전히 제거하고 디스크 공간을 회수하려면 알맞은 프로시저를 두 번 연속으로 호출합니다.

# 단일 AZ 데이터베이스의 Aurora MySQL 이진 로깅 구성
<a name="USER_LogAccess.MySQL.BinaryFormat"></a>

*이진 로그*는 Aurora MySQL 서버 인스턴스의 데이터 수정에 대한 정보를 포함하는 로그 파일 세트입니다. 이진 로그에는 다음과 같은 정보가 포함되어 있습니다.
+ 테이블 생성 또는 행 수정과 같은 데이터베이스 변경 사항을 설명하는 이벤트
+ 데이터를 업데이트한 각 문의 기간에 대한 정보
+ 데이터를 업데이트할 수 있었지만 업데이트하지 않은 문에 대한 이벤트

이진 로그는 복제 중 전송된 문을 기록합니다. 일부 복구 작업에도 필요합니다. 자세한 내용은 MySQL 설명서의 [바이너리 로그](https://dev.mysql.com/doc/refman/8.0/en/binary-log.html) 단원을 참조하십시오.

바이너리 로그는 복제본이 아닌 프라이머리 DB 인스턴스에서만 액세스할 수 있습니다.

Amazon Aurora의 MySQL은 *행 기반*, *문 기반*, *혼합* 바이너리 로깅 형식을 지원합니다. 특정한 binlog 형식이 필요한 경우가 아니면 혼합하는 것이 좋습니다. 다양한 Aurora MySQL 이진 로그 형식에 대한 자세한 내용은 MySQL 설명서의 [Binary Logging Formats](https://dev.mysql.com/doc/refman/8.0/en/binary-log-formats.html)을 참조하세요.

복제를 사용하려는 경우 바이너리 로깅 형식은 원본에 기록되고 복제 대상으로 전송되는 데이터 변경 내용의 레코드를 확인하므로 중요합니다. 복제와 관련된 다양한 바이너리 로깅 형식의 장/단점에 대한 자세한 내용은 MySQL 설명서의 [Advantages and Disadvantages of Statement-Based and Row-Based Replication](https://dev.mysql.com/doc/refman/8.0/en/replication-sbr-rbr.html)을 참조하십시오.

**중요**  
MySQL 8.0.34에서 MySQL이 `binlog_format` 파라미터를 더 이상 사용하지 않습니다. 이후 MySQL 버전에서 MySQL은 파라미터를 제거하고 행 기반 복제만 지원할 계획입니다. 따라서 새 MySQL 복제 설정에 행 기반 로깅을 사용하는 것이 좋습니다. 자세한 내용은 MySQL 설명서의 [binlog\$1format](https://dev.mysql.com/doc/refman/8.0/en/replication-options-binary-log.html#sysvar_binlog_format)을 참조하세요.  
MySQL 버전 8.0 및 8.4는 `binlog_format` 파라미터를 수락합니다. 이 파라미터를 사용하면 MySQL에서 사용 중단 경고가 표시됩니다. 향후 메이저 릴리스에서 MySQL로부터 `binlog_format` 파라미터가 제거될 예정입니다.  
명령문 기반 복제를 수행하면 원본 DB 클러스터와 읽기 전용 복제본 간에 불일치가 발생할 수 있습니다. 자세한 내용은 MySQL 설명서의 [Determination of Safe and Unsafe Statements in Binary Logging](https://dev.mysql.com/doc/refman/8.0/en/replication-rbr-safe-unsafe.html)을 참조하십시오.  
이진 로깅을 활성화하면 DB 클러스터에 대한 평균 디스크 쓰기 I/O 작업 수가 증가합니다. ```VolumeWriteIOPs` CloudWatch 지표를 사용하여 IOPS 사용량을 모니터링할 수 있습니다.

**MySQL 이진 로깅 형식을 설정하려면**

1. [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)에서 Amazon RDS 콘솔을 엽니다.

1. 탐색 창에서 **파라미터 그룹**을 선택합니다.

1. 수정할 DB 클러스터와 연결된 DB 클러스터 파라미터 그룹을 선택합니다.

   기본 파라미터 그룹을 수정할 수 없습니다. DB 클러스터가 기본 파라미터 그룹을 사용하고 있는 경우 새 파라미터 그룹을 생성하여 DB 클러스터와 연결합니다.

   파라미터 그룹에 대한 자세한 정보는 [Amazon Aurora의 파라미터 그룹](USER_WorkingWithParamGroups.md) 단원을 참조하십시오.

1. **작업**에서 **편집**을 선택합니다.

1. `binlog_format` 파라미터를 선택한 이진 로깅 형식(`ROW`, `STATEMENT`, 또는 `MIXED`)으로 설정합니다. `OFF` 값을 사용하여 이진 로깅을 해제할 수도 있습니다.
**참고**  
DB 클러스터 파라미터 그룹에서 `binlog_format`을 `OFF`로 설정하면 `log_bin` 세션 변수가 비활성화됩니다. 그러면 Aurora MySQL DB 클러스터에 대한 이진 로깅이 비활성화되며, 이는 다시 `binlog_format` 세션 변수를 데이터베이스의 기본값인 `ROW` 값으로 재설정합니다.

1. **변경 내용 저장**을 선택하여 업데이트를 DB 클러스터 파라미터 그룹에 저장합니다.

이 단계를 수행한 후 변경 사항을 적용하기 위해 DB 클러스터에서 라이터 인스턴스를 재부팅해야 합니다. Aurora MySQL 버전 2.09 이하에서는 라이터 인스턴스를 재부팅하면 DB 클러스터의 모든 리더 인스턴스도 재부팅됩니다. Aurora MySQL 버전 2.10 이상에서는 모든 리더 인스턴스를 수동으로 재부팅해야 합니다. 자세한 내용은 [Amazon Aurora DB 클러스터 또는 Amazon Aurora DB 인스턴스 재부팅](USER_RebootCluster.md) 섹션을 참조하세요.

**중요**  
DB 클러스터 파라미터 그룹을 변경하면 해당 파라미터 그룹을 사용하는 모든 DB 클러스터에 영향을 미칩니다. AWS 리전의 다양한 Aurora MySQL DB 클러스터에 대해 서로 다른 이진 로깅 형식을 지정하려면 DB 클러스터에서 서로 다른 DB 클러스터 파라미터 그룹을 사용해야 합니다. 이러한 파라미터 그룹은 다양한 로깅 형식을 식별합니다. 각 DB 클러스터에 적절한 DB 클러스터 파라미터 그룹을 할당합니다. Aurora MySQL 파라미터에 대한 자세한 내용은 [Aurora MySQL 구성 파라미터](AuroraMySQL.Reference.ParameterGroups.md) 단원을 참조하십시오.

# MySQL 이진 로그 액세스
<a name="USER_LogAccess.MySQL.Binarylog"></a>

mysqlbinlog 유틸리티를 사용하여 RDS for MySQL DB 인스턴스에서 이진 로그를 다운로드하거나 스트리밍할 수 있습니다. 이진 로그를 로컬 컴퓨터로 다운로드하면 mysql 유틸리티를 사용하여 로그를 재생하는 것과 같은 작업을 수행할 수 있습니다. mysqlbinlog 유틸리티 사용에 대한 자세한 내용은 MySQL 설명서의 [mysqlbinlog를 사용하여 이진 로그 파일 백업](https://dev.mysql.com/doc/refman/8.0/en/mysqlbinlog-backup.html)을 참조하세요.

Amazon RDS 인스턴스에 대해 mysqlbinlog 유틸리티를 실행하려면 다음 옵션을 사용합니다.
+ `--read-from-remote-server` - 필수입니다.
+ `--host` – 인스턴스의 엔드포인트에서 DNS 이름.
+ `--port` – 인스턴스에서 사용되는 포트.
+ `--user` - `REPLICATION SLAVE` 권한이 부여된 MySQL 사용자.
+ `--password` – MySQL 사용자의 암호. 또는 유틸리티에서 암호 입력을 요구하는 메시지가 표시되도록 암호 값을 생략.
+ `--raw` - 파일을 이진 형식으로 다운로드합니다.
+ `--result-file` - 원시 출력을 수신할 로컬 파일.
+ `--stop-never` - 이진 로그 파일을 스트리밍합니다.
+ `--verbose` - `ROW` binlog 형식을 사용할 경우 이 옵션을 포함하면 행 이벤트를 유사 SQL 문으로 볼 수 있습니다. `--verbose` 옵션에 대한 자세한 내용은 MySQL 설명서의 [mysqlbinlog 행 이벤트 표시](https://dev.mysql.com/doc/refman/8.0/en/mysqlbinlog-row-events.html)를 참조하세요.
+ 하나 이상의 이진 로그 파일의 이름을 지정합니다. 사용 가능한 로그의 목록을 획득하려면 SQL 명령 `SHOW BINARY LOGS`를 사용합니다.

mysqlbinlog 옵션에 대한 자세한 내용은 MySQL 설명서의 [mysqlbinlog - 이진 로그 파일 처리용 유틸리티](https://dev.mysql.com/doc/refman/8.0/en/mysqlbinlog.html)를 참조하세요.

다음 예시에서는 mysqlbinlog 유틸리티를 사용하는 방법을 보여줍니다.

대상 LinuxmacOS, 또는Unix:

```
mysqlbinlog \
    --read-from-remote-server \
    --host=MySQLInstance1.cg034hpkmmjt.region.rds.amazonaws.com \
    --port=3306  \
    --user ReplUser \
    --password \
    --raw \
    --verbose \
    --result-file=/tmp/ \
    binlog.00098
```

Windows의 경우:

```
mysqlbinlog ^
    --read-from-remote-server ^
    --host=MySQLInstance1.cg034hpkmmjt.region.rds.amazonaws.com ^
    --port=3306  ^
    --user ReplUser ^
    --password ^
    --raw ^
    --verbose ^
    --result-file=/tmp/ ^
    binlog.00098
```

mysqlbinlog 유틸리티가 바이너리 로그에 액세스할 수 있도록 DB 인스턴스에서 바이너리 로그를 계속 사용할 수 있어야 합니다. 가용성을 보장하기 위해 [mysql.rds\$1set\$1configuration](mysql-stored-proc-configuring.md#mysql_rds_set_configuration) 저장 프로시저를 사용하고 로그를 다운로드할 수 있는 충분한 시간을 지정합니다. 이 구성이 설정되지 않은 경우 Amazon RDS가 이진 로그를 가능한 한 빨리 제거하므로 mysqlbinlog 유틸리티에서 검색하는 바이너리 로그에 간극이 발생합니다.

다음 예제에서는 보존 기간을 1일로 설정합니다.

```
call mysql.rds_set_configuration('binlog retention hours', 24);
```

현재 설정을 표시하려면 [mysql.rds\$1show\$1configuration](mysql-stored-proc-configuring.md#mysql_rds_show_configuration) 저장 프로시저를 사용합니다.

```
call mysql.rds_show_configuration;
```