MySQL 공식 내보내기 도구 mysqlpump 사용

소개

mysqlpump는 mysqldump의 파생이고 그 자체도 mydumper의 사고방식을 참고하여 병렬 도출 데이터를 지원하기 때문에 도출 데이터의 효율은 mysqldump보다 훨씬 높다.

사용 설명

mysqlpump의 절대 다수의 매개 변수는 mysqldump와 같고 전체적인 사용 방법은 mysqldump와 큰 차이가 없다.여기에 mysqlpump에서 비교적 중요하고 자주 사용하는 매개 변수를 보여 줍니다.
매개 변수
설명
--default-parallelism=#
병렬 내보내기 병렬 설정,single-transaction과 충돌
--single-transaction
모든 테이블을 내보낼 단독 사무를 만듭니다
--exclude-databases=name
내보낼 때 일부 라이브러리를 제외하고 쉼표로 구분된 여러 라이브러리
--exclude-tables=name
내보낼 때 일부 테이블을 제외하고, 여러 테이블을 쉼표로 구분합니다
--include-databases=name
내보낼 때 쉼표로 구분된 여러 라이브러리가 포함된 라이브러리
--include-tables=name
내보낼 때 쉼표로 구분된 여러 테이블이 포함된 테이블

실제 체험

여기서 mysqlpump에 대해 간단한 테스트를 하고 목표 실례는 MySQL 5.7을 선택하며 매개 변수에single-transaction과default-parallelism를 동시에 사용하여 이 충돌 효과를 시험해 본다.
mysqlpump 측면의 출력은 다음과 같은 정보를 참조하십시오.


root@VM-64-10-debian:~# mysqlpump -h172.100.10.10 -uroot -p --single-transaction --default-parallelism=16 --set-gtid-purged=OFF -B sbtest > sbtest.sql
Dump progress: 0/1 tables, 250/987400 rows
Dump progress: 0/5 tables, 117250/3946600 rows
Dump progress: 1/5 tables, 258750/3946600 rows
Dump progress: 1/5 tables, 385500/3946600 rows
Dump progress: 1/5 tables, 516750/3946600 rows
Dump progress: 1/5 tables, 639250/3946600 rows
Dump progress: 1/5 tables, 757000/3946600 rows
Dump progress: 1/5 tables, 885000/3946600 rows
Dump progress: 1/5 tables, 1005750/3946600 rows
Dump progress: 1/5 tables, 1114250/3946600 rows
Dump progress: 1/5 tables, 1223250/3946600 rows
Dump progress: 2/5 tables, 1312500/3946600 rows
Dump progress: 2/5 tables, 1430750/3946600 rows
Dump progress: 2/5 tables, 1553000/3946600 rows
Dump progress: 2/5 tables, 1680250/3946600 rows
Dump progress: 2/5 tables, 1809500/3946600 rows
Dump progress: 2/5 tables, 1940750/3946600 rows
Dump progress: 2/5 tables, 2060000/3946600 rows
Dump progress: 2/5 tables, 2175250/3946600 rows
Dump progress: 2/5 tables, 2295250/3946600 rows
Dump progress: 3/5 tables, 2413500/3946600 rows
Dump progress: 3/5 tables, 2554500/3946600 rows
Dump progress: 3/5 tables, 2693500/3946600 rows
Dump progress: 3/5 tables, 2818750/3946600 rows
Dump progress: 3/5 tables, 2941500/3946600 rows
Dump progress: 4/5 tables, 3056000/3946600 rows
Dump progress: 4/5 tables, 3172750/3946600 rows
Dump progress: 4/5 tables, 3280000/3946600 rows
Dump progress: 4/5 tables, 3372000/3946600 rows
Dump progress: 4/5 tables, 3444750/3946600 rows
Dump completed in 126555 milliseconds

이 두 파라미터가 동시에 사용될 때, mysqlpump는 실제로는 하나의 테이블에서 내보내는 것을 볼 수 있습니다.single-transaction의 우선순위는default-parallelism보다 높습니다.
single-transaction을 제거하고 테스트를 진행할 때 비교적 재미있는 현상을 발견할 수 있습니다. MySQL의processlist를 살펴보면 다음과 같은 결과가 있습니다.


mysql> show processlist;
+---------+------+--------------------+------+---------+------+-------------------+----------------------------------------------------+
| Id      | User | Host               | db   | Command | Time | State             | Info                                               |
+---------+------+--------------------+------+---------+------+-------------------+----------------------------------------------------+
| 2763496 | root | 172.100.10.10:49086 | NULL | Query   |    0 | starting          | show processlist                                   |
| 2763585 | root | 172.100.10.10:49192 | NULL | Sleep   |  126 |                   | NULL                                               |
| 2763586 | root | 172.100.10.10:49194 | NULL | Sleep   |  126 |                   | NULL                                               |
| 2763587 | root |172.100.10.10:49196 | NULL | Sleep   |  126 |                   | NULL                                               |
| 2763588 | root | 172.100.10.10:49198 | NULL | Sleep   |  126 |                   | NULL                                               |
| 2763589 | root | 172.100.10.10:49200 | NULL | Sleep   |  126 |                   | NULL                                               |
| 2763590 | root | 172.100.10.10:49202 | NULL | Sleep   |  126 |                   | NULL                                               |
| 2763591 | root | 172.100.10.10:49204 | NULL | Sleep   |  126 |                   | NULL                                               |
| 2763592 | root | 172.100.10.10:49206 | NULL | Sleep   |  126 |                   | NULL                                               |
| 2763593 | root | 172.100.10.10:49208 | NULL | Sleep   |  126 |                   | NULL                                               |
| 2763594 | root | 172.100.10.10:49210 | NULL | Sleep   |  126 |                   | NULL                                               |
| 2763595 | root | 172.100.10.10:49212 | NULL | Query   |  125 | Sending to client | SELECT `id`,`k`,`c`,`pad`  FROM `sbtest`.`sbtest5` |
| 2763596 | root | 172.100.10.10:49214 | NULL | Query   |  125 | Sending to client | SELECT `id`,`k`,`c`,`pad`  FROM `sbtest`.`sbtest4` |
| 2763597 | root | 172.100.10.10:49216 | NULL | Query   |  125 | Sending to client | SELECT `id`,`k`,`c`,`pad`  FROM `sbtest`.`sbtest3` |
| 2763598 | root | 172.100.10.10:49218 | NULL | Query   |  125 | Sending to client | SELECT `id`,`k`,`c`,`pad`  FROM `sbtest`.`sbtest2` |
| 2763599 | root | 172.100.10.10:49220 | NULL | Query   |  125 | Sending to client | SELECT `id`,`k`,`c`,`pad`  FROM `sbtest`.`sbtest1` |
| 2763600 | root | 172.100.10.10:49222 | NULL | Sleep   |  125 |                   | NULL                                               |
| 2763601 | root | 172.100.10.10:49224 | NULL | Sleep   |  125 |                   | NULL                                               |
+---------+------+--------------------+------+---------+------+-------------------+----------------------------------------------------+
18 rows in set (0.00 sec)

mysql>

뚜렷하게 알 수 있듯이 mysqlpump의'병행 내보내기'는 실제적으로 표 단계의 병행 내보내기만 바탕으로 하고 하나의 큰 표가 존재할 때 내보내는 시간은 심각한 영향을 받고 단판 효과가 존재한다.
추가 의문: default-parallelism과single-transaction이 충돌하면 병렬 내보내기를 할 때 데이터 일치성을 확인할 수 없습니까?
진실을 실천하여general_ 열기log 내보내기 작업 보기:


2021-05-12T11:54:09.033215Z        75 Connect   [email protected] on  using SSL/TLS
2021-05-12T11:54:09.075347Z        75 Query     FLUSH TABLES WITH READ LOCK // 
2021-05-12T11:54:09.103132Z        75 Query     SHOW WARNINGS
2021-05-12T11:54:09.106382Z        75 Query     SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ
2021-05-12T11:54:09.106553Z        75 Query     SHOW WARNINGS
2021-05-12T11:54:09.106640Z        75 Query     START TRANSACTION WITH CONSISTENT SNAPSHOT
2021-05-12T11:54:09.108115Z        75 Query     SHOW WARNINGS
2021-05-12T11:54:09.127277Z        76 Connect   [email protected] on  using SSL/TLS
2021-05-12T11:54:09.127452Z        76 Query     SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ
2021-05-12T11:54:09.127590Z        76 Query     SHOW WARNINGS
2021-05-12T11:54:09.127680Z        76 Query     START TRANSACTION WITH CONSISTENT SNAPSHOT
2021-05-12T11:54:09.127790Z        76 Query     SHOW WARNINGS
......
2021-05-12T11:54:10.018813Z        90 Connect   [email protected] on  using SSL/TLS
2021-05-12T11:54:10.018944Z        90 Query     SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ
2021-05-12T11:54:10.019047Z        90 Query     SHOW WARNINGS
2021-05-12T11:54:10.019150Z        90 Query     START TRANSACTION WITH CONSISTENT SNAPSHOT
2021-05-12T11:54:10.019226Z        90 Query     SHOW WARNINGS
2021-05-12T11:54:10.025833Z        91 Connect   [email protected] on  using SSL/TLS
2021-05-12T11:54:10.025934Z        91 Query     SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ
2021-05-12T11:54:10.026048Z        91 Query     SHOW WARNINGS
2021-05-12T11:54:10.026141Z        91 Query     START TRANSACTION WITH CONSISTENT SNAPSHOT
2021-05-12T11:54:10.026219Z        91 Query     SHOW WARNINGS
2021-05-12T11:54:10.026293Z        75 Query     UNLOCK TABLES  // 
2021-05-12T11:54:10.026406Z        75 Query     SHOW WARNINGS

병렬 내보내기 전에 하나의 라인에 전역 읽기 자물쇠를 추가한 다음에 모든 병렬 내보내기가 시작된 후에야 테이블을 잠그는 것을 볼 수 있기 때문에 병렬 내보내는 데도 데이터가 일치합니다.

장단점

이점:

데이터베이스와 데이터베이스의 대상을 병행 백업하여 mysqldump보다 효율적으로..

데이터베이스와 데이터베이스 대상(표, 저장 프로세스, 사용자 계정)의 백업을 더욱 잘 제어할 수 있습니다

백업 진행 가시화..

단점:

시계급까지만 병행할 수 있다. 만약에 시계 데이터량이 매우 많으면 매우 심각한 단판효과가 존재한다..

내보낸 데이터는 한 파일에 저장되어 있으며, 가져오는 것은 여전히 단일 루틴으로 효율이 비교적 낮다

현재 백업에 대응하는 binlog 위치를 가져올 수 없습니다.

총결산

비록 mysqlpump는 아직도 매우 부족하지만 원시적인 mysqldump에 비해 매우 큰 발전을 이루었다. 이 도구의 발표에서 알 수 있듯이 Oracle은 마침내 MySQL의 생태 도구를 중시하기 시작했고 정부에서 더욱 우수한 생태 도구를 제공하기를 기대한다.
이상은 MySQL 공식 내보내기 도구 mysqlpump의 사용에 대한 상세한 내용입니다. mysqlpump의 사용에 대한 더 많은 자료는 저희 다른 관련 글을 주목해 주십시오!

이 내용에 흥미가 있습니까?

현재 기사가 여러분의 문제를 해결하지 못하는 경우 AI 엔진은 머신러닝 분석(스마트 모델이 방금 만들어져 부정확한 경우가 있을 수 있음)을 통해 가장 유사한 기사를 추천합니다:

Redash를 사용할 때 몰랐던 SQL을 쓰는 법을 배웠습니다.

최근 redash에서 sql을 쓸 기회가 많고, 이런 쓰는 방법이 있었는지와 sql에 대해 공부를 다시하고 있기 때문에 배운 것을 여기에 씁니다. Redash란? 월별로 데이터를 표시하고 싶습니다 주별로 데이터를 표...

텍스트를 자유롭게 공유하거나 복사할 수 있습니다.하지만 이 문서의 URL은 참조 URL로 남겨 두십시오.

CC BY-SA 2.5, CC BY-SA 3.0 및 CC BY-SA 4.0에 따라 라이센스가 부여됩니다.

Ch07: Arrays and ArrayLists

17298 오큰수 - python

좋은 웹페이지 즐겨찾기

개발자 우수 사이트 수집

개발자가 알아야 할 필수 사이트 100선 추천 우리는 당신을 위해 100개의 자주 사용하는 개발자 학습 사이트를 정리했습니다