mysqldump가 진행률 표시 줄을 지원합니까?

mysqldump가 진행률 표시 줄을 지원합니까?

---

mysqldump실행중인 동안 백업이 완료되었거나 남은 양을 확인할 수있는 방법이 있습니까?

---

예, 2010 년 3 월 27 일에 패치가 적용되었습니다 .

이 새 패치에는 기본적으로 10,000으로 설정되는 추가 매개 변수 --show-progress-size가 있습니다. 따라서 --verbose를 사용하면 10,000 줄마다 덤프 된 특정 테이블의 행 수에 대한 일반 상태 출력을 얻을 수 있습니다.

따라서 버전을 확인하고 필요한 경우 업데이트하고 즐기십시오.

---

설치 및 사용 pv(CentOS 용 yum 패키지로 사용 가능)

http://www.ivarch.com/programs/pv.shtml

PV ( "파이프 뷰어")는 파이프 라인을 통해 데이터 진행 상황을 모니터링하는 도구입니다. 두 프로세스 사이의 일반 파이프 라인에 삽입하여 데이터가 얼마나 빨리 전달되는지, 얼마나 오래 걸 렸는지, 얼마나 완료되었는지, 완료 될 때까지의 예상 시간을 시각적으로 표시 할 수 있습니다.

결과로 생성되는 dumpfile.sql 파일의 예상 크기가 100m (100MB)이라고 가정하면 pv다음과 같이 사용 됩니다.

mysqldump <parameters> | pv --progress --size 100m > dumpfile.sql

콘솔 출력은 다음과 같습니다.

[===> ] 20%

man pv더 많은 옵션 은 man 페이지 를 참조 하십시오 . 전송 속도, 경과 된 시간 또는 전송 된 바이트 수 등을 표시 할 수 있습니다.

덤프 파일의 크기를 모르는 경우 table_schema에서 MySQL 데이터베이스의 크기를 얻을 수있는 방법이 있습니다. 덤프 파일의 크기는 아니지만 필요에 따라 충분히 근접 할 수 있습니다.

SELECT table_schema AS "Database", ROUND(SUM(data_length + index_length) / 1024 / 1024, 2) AS "Size (MB)" FROM information_schema.TABLES GROUP BY table_schema;

최신 정보

내 경험상 전체 MySQL 서버를 덤프 할 때 mysql 덤프의 실제 압축되지 않은 크기 (mysqldump --hex-blob 옵션 사용)는 information_schema에서 얻은 MySQL 데이터의 실제 크기의 약 75 %에서 85 % 사이입니다. 따라서 일반적인 솔루션을 위해 다음을 시도 할 수 있습니다.

SIZE_BYTES=$(mysql --skip-column-names <parameters> <<< 'SELECT ROUND(SUM(data_length) * 0.8) AS "size_bytes" FROM information_schema.TABLES;')

mysqldump <parameters> --hex-blob | pv --progress --size $SIZE_BYTES > dumpfile.sql

---

Russell E Glaue 답변 의 전체 버전 . pv가 정수만 허용하고 @mtoloo 주석에 따라 인덱스없이 데이터 길이를 계산하므로 반올림 된 db 크기를 가져옵니다 .

db_size=$(mysql  -h"$DB_HOST" \
    -u"$DB_USERNAME" \
    -p"$DB_PASSWORD" \
    --silent \
    --skip-column-names \
    -e "SELECT ROUND(SUM(data_length) / 1024 / 1024, 0) \
        FROM information_schema.TABLES \
        WHERE table_schema='$DB_NAME';")

타임 스탬프가있는 파일 이름으로 백업을 만듭니다.

mysqldump -h"$DB_HOST" \
    -u"$DB_USERNAME" \
    -p"$DB_PASSWORD" \
    --single-transaction \
    --order-by-primary \
    --compress \
    $DB_NAME | pv --progress --size "$db_size"m > "$(date +%Y%m%d)"_backup.sql

---

비슷한 도구 (PV)를 찾고 있었지만 DB를 버리지 않았습니다. 몇 가지 추가 계산 및 공식을 사용하여 두 개의 대형 데이터베이스를 병합하는 동안 프로세스는 TOP 또는 HTOP 유틸리티에 나열되지 않고 헤더에만 io %로 표시됩니다 (시작 프로세스에서만 목록에 표시되고 사라짐). 항상 높은 사용량을 표시하지만이 경우 IO 측에 있으며 다른 프로세스가 표시하는 것처럼 유틸리티의 본문 목록에 나열되지 않습니다. 출력 데이터베이스의 쓰기 진행 상황을보기 위해 대신 IOSTAT를 사용해야했지만 실제로 파일에 쓰기를 수행하고 있는지 확인할 수 없었습니다 (xfer 속도 만 표시). 나는 Filezilla FTP를 사용하여 소스 데이터베이스 크기를 비교하는 이전 방법을 알아 냈고, Im이 병합을 수행했기 때문에 파일이 병합되는 동안 출력 파일이 표시되어야했습니다. 프로세스가 성공적으로 끝날 때까지 filezilla 디렉토리 내용을 새로 고칠 때 증가하는 것을 볼 수 있었고 두 DB의 합계 크기가 예상대로 병합되었습니다. (실제로 분당 새로 고침을 수행하고 하드웨어 io xfer 및 처리 속도의 시간을 수동으로 계산할 수 있습니다)

MySQL 디렉토리로 이동했습니다 (실제 데이터베이스가 파일로 저장되는 곳, 제 경우에는 ../mysql/database/tablename.MYD ... (MYSQL의 파일은 테이블 형식 데이터를 포함하는 해당 .FRM 파일로 저장 됨) , 데이터베이스 색인 역할을하는 .MYI 파일) 출력 병합 파일의 실제 크기를 볼 수 있도록 페이지를 새로 고치고 실제로 저를 위해 작동했습니다.

그건 그렇고, TOP과 HTOP는 MYSQLD가 일부 배경 프로세스를 수행하는 것을 보여 주었지만 작업은 출력을 위해 IO 측으로 전송되었습니다. 내 병합 DB 모두 약 2 천만 행이 각각 약 5 기가였으며, 내 CPU 듀얼 코어에서 병합하는 데 몇 시간이 걸렸고, 아무데도 진행 상황이 전혀 표시되지 않았습니다 (phpmyadmin조차도 시간이 초과되었지만 프로세스는 계속되었습니다). PID 번호를 사용하여 PV를 사용하려고 시도했지만 덤프를 수행하지 않기 때문에 파이프로의 전송이 없습니다. 어쨌든 출력 파일 생성 진행 상황을 확인하는 효과적이고 쉬운 방법을 찾는 사람을 위해 이것을 작성하십시오. 덤프 및 복원에도 작동합니다. 인내심을 가지십시오. 일단 시작되면 완료됩니다. SQL sintax에 대한 오류가없는 한 확실합니다. (이전에 나에게 일어났던 일이 이전 시도에서 전혀 병합되지 않았고, 달콤한 시간이 걸렸지 만 끝에 아무 일도 일어나지 않았습니다. 도구,

Not completely answering your question on progress bar on a c++ program, but you can take this to grab file size of the MYD file created and calculate a progress bar using source file size divided by xfer rate to calculate remaining time. Best Regards.

참고URL : https://stackoverflow.com/questions/4852933/does-mysqldump-support-a-progress-bar