07. 데이터 암호화

• MySQL 5.7 버전: 데이터 암호화 기능 지원 시작. 데이터 파일(테이블스페이스) 암호화만 가능
• MySQL 8.0 버전: 데이터 파일 뿐만 아니라 Redo, Undo 로그, 복제를 위한 바이너리 로그 등도 암호화 기능 지원

데이터 암호화 여부는 보안 감사에서 필수적으로 언급되는 부분이며, 핀테크 서비스처럼 중요한 정보를 저장하는 서비스에서는 응용 프로그램에서 암호화한 데이터를 데이터베이스 서버에서 다시 암호화하는 이중 암호화 방법을 선택하기도 한다. 응용 프로그램의 암호화는 주로 중요 정보를 가진 컬럼 단위로 암호화를 수행하며, 데이터베이스 수준에서는 테이블 단위로 암호화를 적용한다.

7.1 MySQL 서버의 데이터 암호화

MySQL 서버의 암호화 기능은 데이터베이스 서버와 디스크 사이의 데이터 읽고 쓰기 지점에서 암호화 또는 복호화를 수행한다. 그래서 디스크 입출력 이외의 부분에서는 암호화 처리가 전혀 필요하지 않다. 즉, MySQL 서버(InnoDB 스토리지 엔진)의 I/O 레이어에서만 데이터의 암호화 및 복호화 과정이 실행된다.

 

MySQL 서버의 디스크 입출력

 

사용자의 쿼리를 처리하는 과정에서 테이블의 데이터가 암호화돼 있는지 여부를 식별할 필요가 없으며, 암호화된 테이블도 그렇지 않은 테이블과 동일한 처리 과정을 거친다. 데이터 암호화 기능이 활성화돼 있다고 하더라도 MySQL 내부와 사용자 입장에서는 아무런 차이가 없기 때문에 이러한 암호화 방식을 가리켜 TDE(Transparent Data Encryption)이라고 한다. 또한 "Data at Rest Encryption"라고도 하는데, "Data at Rest"는 메모리(In-Process)나 네크워크 전송(In-Transit) 단계가 아닌 디스크에 저장(At Rest)된 단계에서만 암호화된다는 의미로 사용되는 표현이다.

2단계 키 관리

MySQL 서버의 TDE에서 암호화 키는 키링(KeyRing) 플러그인에 의해 관리되며, 8.0 버전에서 지원되는 키링 플러그인은 다음과 같다. 커뮤니티 에디션에서는 keyring_file 플러그인만 사용 가능하고, 나머지 플러그인은 모두 엔터프라이즈 에디션에서만 사용 가능하다.

• keyring_file : File-Based 플러그인
• keyring_encrypted_file : Keyring 플러그인
• keyring_okv : KMIP 플러그인
• keyring_aws : Amazon Web Services Keyring 플러그인

다양한 플러그인이 제공되지만 마스터 키를 관리하는 방법만 다를 뿐 서버 내부적으로 작동하는 방식은 모두 동일하다.

MySQL 서버의 키링 플러그인은 2단계(2-Tier) 키 관리 방식을 사용한다.

 

2단계 키 (2-Tier Key)

• 마스터 키 (master key)
• 테이블 스페이스 키 (tablespace key): 프라이빗 키(private key) 라고도 한다. 

 

2단계 암호화 아키텍처

 

1. MySQL 서버는 HashiCorp Vault 같은 외부 키 관리 솔루션(KMS, Key Management Service) 또는 디스크 파일(keyring_file 또는 keyring_encrypted_file 플러그인 사용시)에서 마스터 키를 가져오고, 암호화된 테이블이 생성될 때마다 해당 테이블을 위한 임의의 테이블스페이스 키를 발급한다.
2. 마스터키를 이용해 테이블스페이스 키를 암호화해서(in I/O 레이어) 각 테이블의 데이터 파일 헤더에 저장한다.

테이블스페이스 키는 한 번 생성되면 테이블이 삭제되지 않는 이상 절대 변경되지 않는다. 그리고 서버 외부로 노출되지 않기 때문에 주기적으로 변경하지 않아도 보안상 취약점이 되지 않는다.

반면에 마스터 키는 외부의 파일을 이용하기 때문에 노출될 가능성이 있다. 그래서 주기적인 변경이 필요하다.

 

-- // 마스터 키 변경 명령
mysql> ALTER INSTANCE ROTATE INNODB MASTER KEY;

 

마스터 키를 변경하면 MySQL 서버는 기존의 마스터 키를 이용해 각 테이블의 테이블스페이스 키를 복호화한 다음 새로운 마스터 키로 다시 암호화한다. 마스터 키가 변경되는 동안 MySQL 서버의 테이블스페이스 키 자체와 데이터 파일의 데이터는 전혀 변경되지 않는다. 

 

2단계 암호화 방식을 사용하는 이유는 암호화 키 변경으로 인한 과도한 시스템 부하를 피하기 위해서다.

테이블스페이스 키가 변경된다면 MySQL 서버는 데이터 파일의 모든 데이터를 복호화했다가 다시 암호화해야 한다. 이로 인해 키를 변경할 때마다 엄청난 작업을 해야 하며, 사용자 쿼리를 처리하는 데도 상당한 영향을 미치게 된다.

암호화와 성능

MySQL 서버의 암호화는 TDE(Transparent Data Encryption) 방식이기 때문에 디스크로부터 한 번 읽은 데이터 페이지는 복호화되어 InnoDB 의 버퍼 풀에 적재된다.

 

디스크 -> (복호화) -> InnoDB 버퍼 풀

 

쿼리가 InnoDB 버퍼 풀에 존재하지 않는 데이터를 디스크로부터 읽어야 하는 경우에는 복호화 과정을 거치기 때문에 복호화 시간 동안 쿼리 처리가 지연될 것이다. 그리고 암호화된 테이블이 변경되면 다시 디스크로 동기화될 때 암호화돼야 하기 때문에 디스크에 저장할 때도 추가로 시간이 더 걸린다.

하지만 데이터 페이지 저장은 사용자의 쿼리를 처리하는 스레드가 아닌 백그라운드 스레드가 수행하기 때문에 실제 사용자 쿼리가 지연되는 것은 아니다. SELECT 뿐만 아니라 UPDATE, DELETE 명령 또한 변경하고자 하는 레코드를 InnoDB 버퍼 풀로 읽어와야 하기 때문에 새롭게 디스크에서 읽어야 하는 데이터 페이지 개수에 따라 그만큼의 복호화 지연이 발생한다. 

 

AES(Advanced Encryption Standard) 암호화 알고리즘

• 암호화하고자 하는 평문(데이터)의 길이가 짧은 경우 암호화 키의 크기에 따라 암호화된 결과의 용량이 더 커질 수도 있지만, 이미 데이터 페이지는 암호화 키보다 훨씬 크기 때문에 암호화 결과가 평문의 결과와 동일한 크기의 암호문을 반환한다.
• 그래서 TDE 를 적용한다고 해도 데이터 파일의 크기는 암호화 되지 않은 테이블과 동일한 크기를 가진다. 즉, 암호화한다고 해서 버퍼 풀의 효율이 달라지거나 메모리 사용 효율이 떨어지는 현상은 발생하지 않는다.

 

같은 테이블에 대해 암호화와 압축이 동시에 적용하면 MySQL 서버는 다음과 같은 순서로 실행한다.

1. 압축
2. 암호화

일반적으로 암호화된 결과문은 아주 랜덤한 바이트의 배열을 가지는데, 이는 압축률을 상당히 떨어뜨린다. 그래서 최대한 압축 효율을 높이기 위해 사용자의 데이터를 그대로 압축해서 용량을 최소화한 후 암호화를 적용한다.

또한 암호화된 테이블의 데이터 페이지는 복호화된 상태로 버퍼 풀에 저장되지만, 압축된 데이터 페이지는 압축 또는 압축 해제의 모든 상태로 버퍼 풀에 존재할 수 있다. 그래서 암호화 -> 압축 순으로 실행한다면 버퍼 풀에 존재하는 데이터 페이지에 대해서도 매번 암복호화 작업을 수행해야 한다.

 

암호화된 테이블은 그렇지 않은 테이블에 비해 디스크 읽기 쓰기 속도가 느린 편이지만 크게 체감되지 않을 수도 있다.

암호화와 복제

MySQL 서버의 복제에서 레플리카 서버는 소스 서버의 모든 사용자 데이터를 동기화하기 때문에 실제 데이터 파일도 동일할 것이라 생각할 수 있다. 하지만 TDE 를 이용한 암호화 사용 시 마스터 키와 테이블스페이스 키는 그렇지 않다.

기본적으로 모든 노드는 각자의 마스터 키를 할당해야 한다. 데이터베이스 서버의 로컬 디렉터리에 마스터 키를 관리하는 경우에는 소스 서버와 레플리카 서버가 다른 키를 가질 수 밖에 없겠지만, 원격으로 키 관리 솔루션을 사용하는 경우에도 소스 서버와 레플리카 서버는 서로 다른 마스터 키를 갖도록 설정해야 한다.

마스터 키 자체가 레플리카로 복제되지 않기 때문에 테이블스페이스 키 또한 레플리카로 복제되지 않는다. 결국 소스 서버와 레플리카 서버는 각자의 마스터 키와 테이블 스페이스 키를 관리하기 때문에 복제 멤버들의 데이터 파일은 암호화 되기 전의 값이 동일하더라도 실제로 암호화 되면 완전히 달라진다.

 

-- // 복제 소스 서버의 마스터 키 변경 명령
ALTER INSTANCE ROTATE INNODB MASTER KEY;

 

해당 명령 자체는 레플리카 서버로 복제되지만 실제 소스 서버의 마스터 키가 레플리카 서버로 전달되는 것은 아니다. 그래서 마스터 키 로테이션을 실행하면 소스 서버와 레플리카 서버가 각각 서로 다른 마스터 키를 새로 발급받는다.

 

MySQL 서버의 백업에서 TDE 의 키링(Key Ring) 파일을 백업하지 않는 경우가 있는데,  이 경우 키링 파일을 찾기 못하면 데이터 복구를 할 수 없게 된다. 키링 파일을 데이터와 별도로 백업한다면 마스터 키 로테이션 명령으로 TDE 의 마스터 키가 언제 변경됐는지 까지 기억해야 한다. 물론 보안을 위해 키링 파일을 데이터 파일과 별도로 보관하는 것을 권장하지만 복구를 감안하고 백업 방식을 선택해야 한다. 마스터 키도 계속 변경될 수 있기 때문에 백업마다 키링 파일의 백업도 함께 고려하자.

7.2 keyring_file 플러그인 설치

MySQL 서버의 데이터 암호화 기능인 TDE 의 암호화 키 관리는 플러그인 방식으로 제공된다. 커뮤니티 에디션에서는 keyring_file 플러그인만 사용할 수 있다. keyring_file 플러그인은 테이블스페이스 키를 암호화하기 위한 마스터 키를 디스크의 파일로 관리하는데, 이때 마스터 키는 평문으로 디스크에 저장된다. 즉 마스터 키가 저장된 파일이 외부에 노출된다면 데이터 암호화는 무용지물이 된다. 

 

참고: keyring_file 플러그인의 보안 문제

 keyring_file 플러그인은 마스터 키를 암호화하지 않은 상태의 평문으로 로컬 디스크에서 저장하기 때문에 그다지 보안 요건을 충족시켜주진 않는다. 그럼에도 꼭 keyring_file 플러그인을 사용하고자 한다면 MySQL서버가 시작될 때만 키링 파일을 다른 서버로부터 다운로드해서 로컬 디스크에 저장한 후 사용하는 방법을 고려해보자. MySQL 서버가 시작되면 마스터 키를 메모리에 캐시하기 때문에 로컬 디스크의 키링 파일을 삭제해도 서버가 작동하는 데는 아무런 문제가 없다. 마스터 키를 로테이션(변경)하는 경우에는 로컬의 키링 파일이 최신이 되므로 다시 외부 서버에 복사해 둬야 한다.

Percona Server는 HashiCorp Vault를 연동하는 키 관리 플러그인을 오픈소스로 제공한다. 커뮤니티 에디션에서도 문제 없이 사용할 수 있으므로 Percona Server의 keyring_vault 플러그인도 함께 검토해볼 것을 권장한다.

 

초기화 설정 - 서버 설정 파일(my.cnf)

-- //keyring_file 플러그인을 위한 라이브러리
early-plugin-load = keyring_file.so

-- // keyring_file 플러그인이 마스터 키를 저장할 키링 파일의 경로
keyring_file_data = /very/secure/directory/tde_master.key

 

MySQL 서버의 다른 플러그인과는 달리 TDE 플러그인의 경우 MySQL 서버가 시작하는 단계에서도 가장 빨리 초기화돼야 한다. keyring_file 플러그인이 초기화되면 MySQL 서버는 플러그인의 초기화와 동시에 keyring_file_data 시스템 변수의 경로에 빈 파일을 생성한다. 플러그인 초기화만 된 상태일 뿐, 아직 마스터 키를 사용한 적이 없기 때문에 실제 키링 파일의 내용은 비어 있다. 데이터 암호화 기능을 사용하는 테이블을 생성하거나 마스터 로테이션을 실행하면 키링 파일의 마스터키가 초기화 된다.

 

참고: ALTER INSTANCE ROTATE INNODB MASTER KEY 명령을 실행하고 바이너리 로그를 보면, 해당 이벤트의 Event_type 컬럼 값이 "Query" 인 것을 알 수 있다. 즉, 마스터 키 로테이션을 실행하면 SQL 문장이 레플리카 서버로 전달되며, 이는 새로 생성된 마스터 키의 값이 바이너리 로그로 전달되지 않음을 의미한다.

 

7.3 테이블 암호화

키링 플러그인은 마스터 키를 생성하고 관리하는 부분까지만 담당하기 때문에 어떤 키링 플러그인을 사용하든 관계없이 암호화된 테이블을 생성하고 활용하는 방법은 모두 동일하다.

테이블 생성

TDE 를 이용하는 테이블 생성

일반적인 테이블 생성 구문과 동일, ENCRYPTION='Y' 옵션만 추가

mysql> CREATE TABLE tab_encrypted (
      id INT,
      data VARCHAR(100),
      PRIMARY KEY(id)
    ) ENCRYPTION='Y';
    
mysql> INSERT INTO tab_encrypted VALUES (1, 'test_data');

mysql> SELECT * FROM tab_encrypted;
+----+-----------+
| id | data      |
+----+-----------+
|  1 | test_data |
+----+-----------+

 

이 테이블의 데이터가 디스크로 기록될 때는 데이터가 자동으로 암호화되어 저장되고, 다시 디스크에서 메모리로 읽어올 때 복호화된다. MySQL 서버에서 암호화된 테이블만 검색할 때는 information_schema 의 TABLES 뷰를 이용하면 된다.

 

information_schema. tables

 

참고: default_table_encryption 시스템 변수를 ON으로 설정하면 ENCRYPTION 옵션을 별도로 설정하지 않아도 암호화된 테이블로 생성된다.

응용 프로그램 암호화와의 비교

응용 프로그램에서 직접 암호화해서 MySQL 서버에 저장하는 경우도 있는데, 이 경우 저장되는 컬럼 값이 이미 암호화된 것인지 여부를 MySQL 서버는 인지하지 못한다. 그래서 응용 프로그램에서 암호화된 컬럼은 인덱스를 생성하더라도 인덱스의 기능을 100% 활용할 수 없다. 

 

app_user 테이블 생성

 

암호화된 컬럼(인덱스) 쿼리

 

첫 번째 쿼리는 동일 값만 검색하는 쿼리이기 때문에 "enc_birth_year=#{encryptedYear}" 조건으로 검색할 수 있다.

하지만 두 번째 쿼리처럼 출생 연도 범위의 사용자를 검색한다거나, 세 번째 쿼리처럼 출생 연도를 기준으로 정렬해서 상위 10개만 가져오는 등의 쿼리는 할 수 없다. MySQL 서버는 이미 암호화된 값을 기준으로 정렬했기 때문에 암호화되기 전의 값을 기준으로 정렬할 수 없기 때문이다. 하지만 응용 프로그램에서 직접 암호화하지 않고 MySQL 서버의 암호화 기능(TDE)을 사용한다면 인덱스 관련 작업을 모두 처리한 후 최종 디스크에서 데이터 페이지를 저장할 때만 암호화하기 때문에 이같은 제약은 없다.

 

응용 프로그램의 암호화와 MySQL 서버의 암호화 기능 중 선택해야 한다면 MySQL 서버의 암호화 기능을 권장한다. 물론 두 기능의 목적과 용도는 조금 다르다. MySQL 서버의 TDE 기능으로 암호화한다면 실행 중인 MySQL 서버에 로그인할 수 있다면 모든 데이터를 평문으로 확인할 수 있다. 응용 프로그램 암호화는 MySQL 서버에 로그인할 수 있다고 하더라도 평문의 내용을 확인할 수 없다. 그래서 응용 프로그램에서의 암호화 기능은 서비스의 요건과 성능을 고려하여 선택해야 하고, MySQL 서버의 암호화 기능과 혼합해서 사용한다면 더 안전한 서비스를 구축할 수 있을 것이다.

테이블스페이스 이동

테이블은 다른 서버로 복사해야 하는 경우 또는 특정 테이블의 데이터 파일만 백업했다가 복구하는 경우라면 테이블스페이스 이동(Export & Import) 기능이 레코드를 덤프했다가 복구하는 방식보다 훨씬 효율적이고 빠르다.

그런데 TDE 가 적용되어 암호화된 테이블의 경우 MySQL 서버와 목적지 MySQL 서버의 암호화 키(마스터 키)가 다르기 때문에 신경써야 할 부분이 있다. 

 

테이블스페이스 Export

mysql> FLUSH TABLES source_table FOR EXPORT;

 

• source_table의 저장되지 않은 변경 사항을 모두 디스크로 기록
• source_table에 접근할 수 없게 잠금
• source_table의 구조를 source_table.cfg 파일로 기록
• source_tavle.ibd 파일과 source_table.cfg 파일을 목적지 서버로 복사
• UNLOCK TABLES 명령으로 잠금 해제

TDE로 암호화된 테이블에 대해 위 명령을 실행하면 위의 과정과 더불어 임시로 사용할 마스터 키를 발급해서 source_table.cfp 라는 파일로 기록한다. 그리고 암호화된 테이블의 테이블스페이스 키를 기존 마스터 키로 복호화한 후, 임시로 발급한 마스터 키를 이용해 다시 암호화해서 데이터 파일의 헤더 부분에 저장한다. 그래서 암호화된 테이블의 경우 테이블스페이스 이동 기능을 사용할 때는 반드시 데이터 파일과 임시 마스터 키가 저장된 *.cfp 파일을 함께 복사해야 한다. *.cfg 파일은 단순히 테이블 구조만 가지고 있기 때문에 파일이 없어져도 경고만 발생하고 테이블스페이스를 복구할 수 있지만 *.cfp 파일이 없어지면 복구가 불가능해진다.

7.4 언두 로그 및 리두 로그 암호화

테이블에 암호화를 적용하더라도 디스크로 저장되는 데이터만 암호화되고 MySQL 서버의 메모리에 존재하는 데이터는 복호화된 평문으로 관리되며, 이 평문 데이터가 테이블의 데이터 파일 이외의 디스크 파일로 기록되는 경우에도 여전히 평문으로 저장된다. 그래서 테이블 암호화를 적용해도 리두 로그나 언두 로그, 그리고 복제를 위한 바이너리 로그에는 평문으로 저장되는 것이다. 8.0.16 버전 부터는 innodb_undo_log_encrypt 시스템 변수와 innodb_redo_log_encrypt 시스템 변수를 이용해 InnoDB 스토리지 엔진의 리두 로그와 언두 로그를 암호화된 상태로 저장할 수 있게 되었다.

 

테이블 암호화는 테이블 하나에 대해 암호화가 적용되면 해당 테이블의 모든 데이터가 암호화돼야 한다. 하지만 리두 로그나 언두 로그는 그렇게 적용할 수가 없다. 실행 중에 언두 로그나 리두 로그를 활성화한다고 하더라도 이전에 저장된 리두 로그나 언두 로그의 데이터까지 한 번에 암호화해서 다시 저장할 수 없다. 그래서 리두 로그나 언두 로그를 평문으로 저장하다가 암호화가 활성화되면 그때부터 생성되는 리두 로그나 언두 로그만 암호화해서 저장한다. 반대로 리두 로그나 언두 로그가 암호화되는 상태에서 암호화를 비활성화하면 그때부터 저장되는 로그만 평문으로 저장한다. 그래서 리두 로그와 언두 로그는 암호화를 활성화하다가 비활성화한다고 즉시 암호화에 사용된 키가 불필요해지는 것이 아니다. 특히 언두 로그의 경우 암호화를 비활성화한다고 하더라도 기존의 언두 로그는 여전히 암호화된 상태로 남아있기 때문에 상황에 따라 며칠 또는 몇 달동안 여전히 암호화키가 필요할 수도 있다.

 

리두 로그와 언두 로그 암호화

• 테이블스페이스 키를 통해 암호화 : 실제 테이블 암호화에 사용된 테이블스페이스 키가 아닌 리두 로그와 언두 로그 파일을 위한 프라이빗 키
• 테이블스페이스 키는 다시 마스터 키로 암호화되어 로그 파일의 헤더에 저장된다.
• 마스터 키 로테이션 명령 -> 새로운 마스터 키 발급, 새로운 마스터 키에 의해 다시 암호화된다.

7.5 바이너리 로그 암호화

테이블 암호화가 적용돼도 바이너리 로그와 릴레이 로그 파일도 리두 로그나 언두 로그처럼 평문을 저장한다.

• 언두 로그 & 리두 로그: 일반적으로 길지 않은 시간 동안의 데이터만을 가짐 -> 보안 민감성 낮음
• 바이너리 로그: 바이너리 로그를 긴 시간 동안 보관하는 서비스, 증분 백업(Incremental Backup) -> 상황에 따라 암호화 중요도가 높아짐

바이너리 로그와 릴레이 로그 파일 암호화 기능은 디스크에 저장된 로그 파일에 대한 암호화만 담당하고, MySQL 서버의 메모리 또는 소스 서버와 레플리카 서버 간의 네트워크 구간에서 로그 데이터를 암호화하지 않는다. 복제 멤버 간의 네트워크 구간에서도 바이너리 로그를 암호화하고자 한다면 MySQL 복제를 위한 계정이 SSL을 사용하도록 설정하면 된다.

복제 시 네트워크 구간으로 전송되는 데이터 암호화 -> 3장 '사용자 및 권한'

바이너리 로그 암호화 키 관리

바이너리 로그 파일의 암호화 방식

 

• 바이너리 로그 암호화 키: 테이블 암호화의 마스터 키와 동일한 역할을 한다. 내부적으로 버전(시권스 번호) 관리가 이루어 진다.
• 파일 키: 바이너리 로그와 릴레이 로그 파일 단위로 자동 생성되어 해당 로그 파일의 데이터 암호화에만 사용된다.
• 로그 파일의 데이터 -> 파일 키(File Key)로 암호화하여 디스크에 저장
• 파일 키 -> 바이너리 로그 암호화 키로 암호화하여 로그 파일의 헤더에 저장

바이너리 로그 암호화 키 변경

바이너리 로그 암호화 키 변경(로테이션)

mysql> ALTER INSTANCE ROTATE BINLOG MASTER KEY;

 

1. 증가된 시퀀스 번호와 함께 새로운 "바이너리 로그 암호화 키" 발급 후 키링 파일에 저장
2. 바이너리 로그 파일과 릴레이 로그 파일 스위치(새로운 로그 파일로 로테이션)
3. 새로 생성되는 바이너리 로그와 릴레이 로그 파일의 암호화를 위해 파일 키를 생성하고, 파일 키는 "바이너리 로그 암호화 키(마스터 키)"로 암호화해서 각 로그 파일에 저장
4. 기존 바이너리 로그와 릴레이 파일의 파일 키를 읽어서 새로운 바이너리 로그 파일 키로 암호화하고 다시 저장 (암호화되지 않은 로그 파일은 무시)
5. 모든 바이너리 로그와 릴레이 로그 파일이 새로운 "바이너리 로그 암호화 키"로 다시 암호화됐다면 기존 "바이너리 로그 암호화 키"를 키링 파일에서 제거 

mysqlbinlog 도구 활용

MySQL 서버에서는 트랜잭션의 내용은 추적하거나 백업 복구를 위해 암호화된 바이너리 로그를 평문으로 복호화할 일이 자주 발생한다. 하지만 바이너리 로그 파일이 암호화되면 바이너리 로그 암호화 키가 없으면 복호화할 수 없다. 그런데 바이너리 로그 암호화 키는 로그 파일을 생성한 MySQL 서버만 가지고 있기 때문에 복호화가 불가능하다. mysqlbinlog 도구를 이용해 암호화된 바이너리 로그 파일의 내용을 SQL 문장으로 풀어보면 암호화된 바이너리 로그 파일을 직접 열어볼 수 없다는 에러 메시지를 출력한다. 예전처럼 다른 서버로 복사하거나 바이너리 로그 파일을 백업하는 것은 무용지물이 됐다.

 

암호화된 바이너리 로그 파일 읽기 오류

 

바이너리 로그 파일의 내용을 볼 수 있는 방법은 현재의 MySQL 서버가 mysql-bin.000011 로그 파일을 가지고 있다는 가정하에 mysqlbinlog 도구가 MySQL 서버에 접속해서 바이너리 로그를 가져오는 방법밖에 없다. 

 

MySQL 서버에 직접 바이너리 로그 요청

 

mysqlbinlog 도구가 직접 mysql-bin.000011 파일을 읽는 것이 아니고 서버에 요청할 바이너리 로그 파일을 명시한 것이다. 

--read-from-remote-server 파라미터와 MySQL 서버 접속 정보를 입력한다.