В предишната си публикация обясних как да направя логическо архивиране с помощта на помощните програми на обвивката на mysql. В тази публикация ще сравним скоростта на процеса на архивиране и възстановяване.
Тест за скорост на MySQL Shell
Ще направим сравнение на скоростта на архивиране и възстановяване на помощните инструменти на mysqldump и MySQL shell.
Инструментите по-долу се използват за сравнение на скоростта:
- mysqldump
- util.dumpInstance
- util.loadDump
Конфигурация на хардуера
Два самостоятелни сървъра с идентични конфигурации.
Сървър 1
* IP:192.168.33.14
* ЦП:2 ядра
* RAM:4 GB
* ДИСК:200 GB SSD
Сървър 2
* IP:192.168.33.15
* ЦП:2 ядра
* RAM:4 GB
* ДИСК:200 GB SSD
Подготовка на работното натоварване
На сървър 1 (192.168.33.14) заредихме приблизително 10 GB данни.
Сега искаме да възстановим данните от сървър 1 (192.168.33.14) на сървър 2 (192.168.33.15).
Настройка на MySQL
Версия на MySQL:8.0.22
Размер на буферния пул на InnoDB:1 GB
Размер на регистрационния файл на InnoDB:16 MB
Бинарно регистриране:Включено
Заредихме 50 милиона записа с помощта на sysbench.
[[email protected] sysbench]# sysbench oltp_insert.lua --table-size=5000000 --num-threads=8 --rand-type=uniform --db-driver=mysql --mysql-db=sbtest --tables=10 --mysql-user=root --mysql-password=****** prepare
WARNING: --num-threads is deprecated, use --threads instead
sysbench 1.0.20 (using bundled LuaJIT 2.1.0-beta2)
Initializing worker threads...
Creating table 'sbtest3'...
Creating table 'sbtest4'...
Creating table 'sbtest7'...
Creating table 'sbtest1'...
Creating table 'sbtest2'...
Creating table 'sbtest8'...
Creating table 'sbtest5'...
Creating table 'sbtest6'...
Inserting 5000000 records into 'sbtest1'
Inserting 5000000 records into 'sbtest3'
Inserting 5000000 records into 'sbtest7
.
.
.
Creating a secondary index on 'sbtest9'...
Creating a secondary index on 'sbtest10'...Тестов случай 1
В този случай ще направим логическо архивиране с помощта на командата mysqldump.
Пример
[[email protected] vagrant]# time /usr/bin/mysqldump --defaults-file=/etc/my.cnf --flush-privileges --hex-blob --opt --master-data=2 --single-transaction --triggers --routines --events --set-gtid-purged=OFF --all-databases |gzip -6 -c > /home/vagrant/test/mysqldump_schemaanddata.sql.gzначало_време =2020-11-09 17:40:02
end_time =2020-11-09 37:19:08
Отне почти 20 минути и 19 секунди, за да се вземе дъмп на всички бази данни с общ размер от около 10 GB.
Тестов случай 2
Сега нека опитаме с помощната програма за обвивка MySQL. Ще използваме dumpInstance, за да направим пълно архивиране.
Пример
MySQL localhost:33060+ ssl JS > util.dumpInstance("/home/vagrant/production_backup", {threads: 2, ocimds: true,compatibility: ["strip_restricted_grants"]})
Acquiring global read lock
Global read lock acquired
All transactions have been started
Locking instance for backup
Global read lock has been released
Checking for compatibility with MySQL Database Service 8.0.22
NOTE: Progress information uses estimated values and may not be accurate.
Data dump for table `sbtest`.`sbtest1` will be written to 38 files
Data dump for table `sbtest`.`sbtest10` will be written to 38 files
Data dump for table `sbtest`.`sbtest3` will be written to 38 files
Data dump for table `sbtest`.`sbtest2` will be written to 38 files
Data dump for table `sbtest`.`sbtest4` will be written to 38 files
Data dump for table `sbtest`.`sbtest5` will be written to 38 files
Data dump for table `sbtest`.`sbtest6` will be written to 38 files
Data dump for table `sbtest`.`sbtest7` will be written to 38 files
Data dump for table `sbtest`.`sbtest8` will be written to 38 files
Data dump for table `sbtest`.`sbtest9` will be written to 38 files
2 thds dumping - 36% (17.74M rows / ~48.14M rows), 570.93K rows/s, 111.78 MB/s uncompressed, 50.32 MB/s compressed
1 thds dumping - 100% (50.00M rows / ~48.14M rows), 587.61K rows/s, 115.04 MB/s uncompressed, 51.79 MB/s compressed
Duration: 00:01:27s
Schemas dumped: 3
Tables dumped: 10
Uncompressed data size: 9.78 GB
Compressed data size: 4.41 GB
Compression ratio: 2.2
Rows written: 50000000
Bytes written: 4.41 GB
Average uncompressed throughput: 111.86 MB/s
Average compressed throughput: 50.44 MB/s Отне общо 1 минута 27 секунди, за да се вземе дъмп на цялата база данни (същите данни като използвани за mysqldump) и също така показва нейния напредък, което ще бъде наистина полезно, за да разберете колко от архивирането е завършено. Той дава времето, необходимо за извършване на архивирането.
Паралелизмът зависи от броя на ядрата в сървъра. Грубо увеличаване на стойността няма да е полезно в моя случай. (Моята машина има 2 ядра).
Тест за скорост на възстановяване
В частта за възстановяване ще възстановим архива на mysqldump на друг самостоятелен сървър. Архивният файл вече беше преместен на целевия сървър с помощта на rsync.
Тестов случай 1
Пример
[[email protected] vagrant]#time gunzip < /mnt/mysqldump_schemaanddata.sql.gz | mysql -u root -pОтне около 16 минути и 26 секунди за възстановяване на 10 GB данни.
Тестов случай 2
В този случай използваме помощната програма за обвивка mysql, за да заредим архивния файл на друг самостоятелен хост. Вече преместихме архивния файл на целевия сървър. Да започнем процеса на възстановяване.
Пример
MySQL localhost:33060+ ssl JS > util.loadDump("/home/vagrant/production_backup", {progressFile :"/home/vagrant/production_backup/log.json",threads :2})
Opening dump...
Target is MySQL 8.0.22. Dump was produced from MySQL 8.0.22
Checking for pre-existing objects...
Executing common preamble SQL
Executing DDL script for schema `cluster_control`
Executing DDL script for schema `proxydemo`
Executing DDL script for schema `sbtest`
.
.
.
2 thds loading \ 1% (150.66 MB / 9.78 GB), 6.74 MB/s, 4 / 10 tables done
2 thds loading / 100% (9.79 GB / 9.79 GB), 1.29 MB/s, 10 / 10 tables done
[Worker001] [email protected]@@37.tsv.zst: Records: 131614 Deleted: 0 Skipped: 0 Warnings: 0
[Worker002] [email protected]@@37.tsv.zst: Records: 131614 Deleted: 0 Skipped: 0 Warnings: 0
Executing common postamble SQL
380 chunks (50.00M rows, 9.79 GB) for 10 tables in 2 schemas were loaded in 40 min 6 sec (avg throughput 4.06 MB/s)Възстановяването на 10 GB данни отне около 40 минути и 6 секунди.
Сега нека се опитаме да деактивираме дневника за повторно изпълнение и да започнем импортирането на данните с помощта на mysql помощна програма за обвивка.
mysql> alter instance disable innodb redo_log;
Query OK, 0 rows affected (0.00 sec)
MySQL localhost:33060+ ssl JS >util.loadDump("/home/vagrant/production_backup", {progressFile :"/home/vagrant/production_backup/log.json",threads :2})
Opening dump...
Target is MySQL 8.0.22. Dump was produced from MySQL 8.0.22
Checking for pre-existing objects...
Executing common preamble SQL
.
.
.
380 chunks (50.00M rows, 9.79 GB) for 10 tables in 3 schemas were loaded in 19 min 56 sec (avg throughput 8.19 MB/s)
0 warnings were reported during the load.След деактивирането на дневника за повторно изпълнение средната пропускателна способност беше увеличена до 2 пъти.
Забележка:Не деактивирайте повторното регистриране в производствена система. Позволява изключване и рестартиране на сървъра, докато повторното регистриране е деактивирано, но неочаквано спиране на сървъра, докато регистрирането на повторното е деактивирано, може да причини загуба на данни и повреда на екземпляра.
Физически архиви
Както може би сте забелязали, логическите методи за архивиране, дори ако са многонишкови, отнемат доста време дори за малък набор от данни, срещу който ги тествахме. Това е една от причините ClusterControl да предоставя физически метод за архивиране, който се основава на копирането на файловете - в такъв случай ние не сме ограничени от слоя SQL, който обработва логическото архивиране, а по-скоро от хардуера - колко бързо дискът може да чете файловете и колко бързо мрежата може да прехвърля данни между възела на базата данни и резервния сървър.
ClusterControl се предлага с различни начини за прилагане на физическо архивиране, кой метод е наличен ще зависи от типа на клъстера и понякога дори от доставчика. Нека да разгледаме Xtrabackup, изпълняван от ClusterControl, който ще създаде пълно архивиране на данните в нашата тестова среда.
Този път ще създадем ad-hoc архив, но ClusterControl позволява създавате и пълен график за архивиране.
Тук избираме метода за архивиране (xtrabackup), както и хоста, който ще взема резервното копие от. Можем също да го съхраняваме локално на възела или може да се предава поточно към екземпляр на ClusterControl. Освен това можете да качите резервното копие в облака (поддържат се AWS, Google Cloud и Azure).
Архивирането отне около 10 минути. Ето регистрационните файлове от файла cmon_backup.metadata.
[[email protected] BACKUP-9]# cat cmon_backup.metadata
{
"class_name": "CmonBackupRecord",
"backup_host": "192.168.33.14",
"backup_tool_version": "2.4.21",
"compressed": true,
"created": "2020-11-17T23:37:15.000Z",
"created_by": "",
"db_vendor": "oracle",
"description": "",
"encrypted": false,
"encryption_md5": "",
"finished": "2020-11-17T23:47:47.681Z"
}Сега нека опитаме същото за възстановяване с помощта на ClusterControl. ClusterControl> Backup> Restore Backup
Тук избираме опцията за възстановяване на резервно копие, тя ще поддържа времеви и регистрационни файлове възстановяване също.
Тук избираме изходния път на архивния файл и след това целевия сървър. Трябва също така да се уверите, че този хост може да бъде достигнат от възела ClusterControl чрез SSH.
Не искаме ClusterControl да настройва софтуер, затова деактивирахме тази опция. След възстановяване ще поддържа сървъра да работи.
Отне около 4 минути и 18 секунди за възстановяване на 10 GB данни. Xtrabackup не заключва вашата база данни по време на процеса на архивиране. За големи бази данни (100+ GB), той осигурява много по-добро време за възстановяване в сравнение с помощната програма mysqldump/shell. Също така lusterControl поддържа частично архивиране и възстановяване, както обясни един от моите колеги в своя блог:Частично архивиране и възстановяване.
Заключение
Всеки метод има своите плюсове и минуси. Както видяхме, няма един метод, който да работи най-добре за всичко, което трябва да направите. Трябва да изберем нашия инструмент въз основа на нашата производствена среда и целево време за възстановяване.
