MySQL의 새로운 기능 아카이빙 소개

MySQL 8.0.17이 출시되었습니다. 릴리스 노트를 읽어보니 예상대로 redo 로그 보관 기능이 복원된 것을 확인했습니다. "복구"라고 부르는 이유는 아주 오래된 버전의 InnoDB(MySQL 4.0.6 이전 버전)에 존재했다가 이후 폐지되었기 때문이다. 당시에는 redo 로그 미러링이 계속 지원됐고, 예전 MySQL DBA도 지원했다. 아직도 그런 인상을 받았을지 모르지만, 이 두 기능은 당시에는 거의 사용되지 않았기 때문에 취소되었습니다.

제안 튜토리얼: MySQL 데이터베이스 소개 비디오 튜토리얼

이번 InnoDB는 리두 로그 보관 기능을 다시 시작합니다. 개발팀에 따르면 이는 주로 백업 일관성 문제를 해결하기 위한 것입니다. 문서에는 다음과 같이 나와 있습니다.

Backup utilities that copy redo log records may sometimes fail to keep pacewith redo log generation while a backup operation is in progress, resultingin lost redo log records due to those records being overwritten. The redolog archiving feature addresses this issue by sequentially writing redo logrecords to an archive file. Backup utilities can copy redo log records fromthe archive file as necessary, thereby avoiding the potential loss of data.
in lost redo log records due to those records being overwritten. The redo
log archiving feature addresses this issue by sequentially writing redo log
records to an archive file. Backup utilities can copy redo log records from
the archive file as necessary, thereby avoiding the potential loss of data.

즉, 백업 속도가 Redo 로그 생성 속도를 따라잡을 수 없습니다. 결과적으로 Redo 로그가 덮어쓰여지고, 백업은 일관성을 보장할 수 없습니다. 리두 로그 보관을 사용하면 백업이 시작될 때 동기적으로 리두 로그 보관을 시작하고, 백업이 끝나면 동기적으로 리두 로그 보관을 중지할 수 있습니다. 이렇게 하면 백업이 완료된 후 생성된 리두 로그를 사용할 수 있습니다. 이 기간은 데이터를 복구하는 데 사용됩니다. 　리두 로그 보관 기능을 활성화하려면 innodb_redo_log_archive_dirs 옵션을 설정하면 됩니다. 이 옵션은 온라인 동적 수정을 지원할 수 있습니다. 예:

[root@yejr.me]> SET GLOBAL innodb_redo_log_archive_dirs = "redolog-archiving-for-backup:/data/mysql8-redologs/";

/data/mysql8-redologs/ 지정 /code> 디렉토리는 리두 로그 아카이브 저장 경로로 사용되며 레이블은 <code>"redolog-archiving-for-backup"로 지정됩니다. 이는 이 디렉토리가 리두 로그 아카이브 저장 디렉토리라는 것을 의미합니다. 지원.

innodb_redo_log_archive_dirs选项即可，该选项可支持在线动态修改，例如：

[root@yejr.me]> SET GLOBAL innodb_redo_log_archive_dirs = "redolog-archiving-for-backup:/data/mysql8-redologs1/;redolog-archiving-for-repl:/data/mysql8-redologs2";

　　指定 /data/mysql8-redologs/ 目录作为redo log归档存放路径，并且指定label为 "redolog-archiving-for-backup"，也就是这是专用于备份的redo log归档存放目录。

　　我们还可以指定另一个目录用于未来基于redo log的物理复制用途（我瞎猜的，可能没那么快实现）。

[root@yejr.me]> ls -l /data/mysql8-redologs/20190722-r--r-----. 1 mysql mysql 0 Jul 22 20:54 archive.f0ff5743-97be-11e9-a5d6-0050568bba82.000001.log

　　选项innodb_redo_log_archive_dirs可以指定多个目录作为归档redo log存放位置。不过这个选项有几个限制：

　　设置完后，就可以开始进行redo log归档了。

　　第一个参数是我们之前定义过的一个label，第二个参数是该label对应目录下的子目录，也就是 "/data/mysql8-redologs/20190722" 또한 리두 로그를 기반으로 향후 물리적 복제를 위해 다른 디렉터리를 지정할 수도 있습니다(아마도 곧 구현되지 않을 수도 있습니다).

[root@yejr.me]> DO innodb_redo_log_archive_stop();Query OK, 0 rows affected (0.00 sec)

　innodb_redo_log_archive_dirs 옵션을 사용하면 여러 디렉터리를 아카이브 리두 로그 저장 위치로 지정할 수 있습니다. 그러나 이 옵션에는 몇 가지 제한 사항이 있습니다.

설정 후 리두 로그 보관을 시작할 수 있습니다.

　첫 번째 매개변수는 앞서 정의한 라벨이고, 두 번째 매개변수는 라벨에 해당하는 디렉터리 아래의 하위 디렉터리인 "/data/mysql8-redologs/20190722"입니다. 해당 디렉터리에서 이러한 리두 로그 아카이브 파일을 볼 수 있습니다.

# 测试前的LSNLOG---Log sequence number          27938813989...# 测试后的LSNLOG---Log sequence number          27945024531
---
Log sequence number          27938813989
...

# 测试后的LSN
LOG
---
Log sequence number          27945024531

　 파일 이름에 자주 사용되는 문자열은 이 인스턴스의 UUID입니다. 이때 파일 크기는 0바이트입니다.

다른 세션에서 sysbench oltp 테스트를 시작합니다. sysbench 테스트를 실행한 후 redo 로그 보관 작업을 중지했습니다.

[root@yejr.me]> ls -l /data/mysql8-redologs/20190722-r--r-----. 1 mysql mysql 6213632 Jul 22 21:19 archive.f0ff5743-97be-11e9-a5d6-0050568bba82.000001.log

테스트 전후의 redo 로그 LSN에 변경 사항을 다음과 같이 기록했습니다.

rrreee

두 LSN의 차이는 6210542바이트입니다.

　 그런 다음 리두 로그 아카이브 파일의 크기를 확인합니다.

rrreee

　 파일 크기는 6213632바이트로 위의 6210542바이트와 3090바이트만 차이나는 것을 알 수 있습니다. 이는 리두 로그의 크기와 동일합니다. 이 테스트에서 생성된 . 이 리두 로그를 나중에 데이터 복구에 사용할 수 있습니다(단, 해당 공식 도구는 아직 개발되지 않았으므로 기다려 보겠습니다).

🎜　 일반적인 상황에서는 redo 로그 보관이 성능(순차 쓰기)에 미치는 영향이 상대적으로 적습니다. 동시성 트랜잭션이 많은 시나리오에서는 성능에 미치는 영향이 약간 클 수 있지만 너무 걱정하지 마세요. 나중에 기회가 되면 다시 한번 성능 비교 테스트를 해보겠습니다. 🎜🎜 출시 전에 Yueyue는 MySQL Enterprise Edition의 백업 도구가 이미 리두 보관을 미리 지원한다는 점을 상기시켰습니다. Percona Xtrabackup도 가능한 한 빨리 지원할 수 있기를 바랍니다. 🎜🎜마지막으로 한 가지 더. 또한 MySQL 버전 8.0 이후에는 ORACLE과 점점 더 유사해지는 것을 볼 수 있습니다. 가장 성공적인 상용 데이터베이스인 ORACLE을 통해 우리는 MySQL의 미래에 대해 걱정할 필요가 없습니다. 🎜

위 내용은 MySQL의 새로운 기능 아카이빙 소개의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!