MariaDB
 sql >> база данни >  >> RDS >> MariaDB

ClusterControl - Разширено управление на архивиране - mariabackup част I

ClusterControl може, наред с другото, да действа като чудесен инструмент, който да ви помогне да проектирате и изпълните графика за архивиране. Налични са множество функции, включително проверка на архивиране, прозрачно криптиране на архивиране и много други. Това, което доста често липсва, е способността на ClusterControl да настройва инструменти за архивиране, които използваме за създаване на архива. В този блог бихме искали да разгледаме някои от настройките, които могат да бъдат приложени към MariaBackup. Да започваме.

Първоначална настройка

Първоначалната настройка е MariaDB клъстер с един главен и една реплика, която е изостава в този момент поради импортирането на данните, работещи във фонов режим.

Имаме два ProxySQL възела и два Keepalived възела, осигуряващи виртуален IP и гарантиращи, че ProxySQL е достъпен. Ние запълваме клъстера (по този начин изоставането) с данни, генерирани от sysbench. Използвахме следната команда, за да задействаме този процес:

sysbench /root/sysbench/src/lua/oltp_read_write.lua --threads=4 --mysql-host=10.0.0.111 --mysql-user=sbtest --mysql-password=sbtest --mysql-port=6033 --tables=32 --table-size=1000000 prepare

Това ще генерира около 7,6 GB данни, върху които ще тестваме различни настройки за архивиране.

Настройки за компресия

Както споменахме, има доста настройки, които можете да използвате, за да настроите MariaBackup и други инструменти, участващи в процеса на архивиране.

В тази публикация в блога бихме искали да се съсредоточим върху нивото на компресия и да видим ако има някакво реално въздействие върху нашия процес на архивиране. Променя ли продължителността на архивирането? Променя ли размера на архива? Как? Има ли смисъл всъщност да използвате нещо друго освен настройката по подразбиране? Нека го разгледаме накратко.

Ще стартираме архивиране, използвайки всички настройки от падащото меню Ниво на компресия:

Архивните копия ще се съхраняват на възела локално, за да се сведе до минимум причиненото въздействие от мрежата. Ще използваме пълен MariaBackup. Данните в базата данни не са криптирани или компресирани по никакъв начин.

Ще стартираме 9 задания за архивиране, всяка с различна настройка на нивото на компресия. Тази настройка се предава на gzip, който се използва по подразбиране за компресиране на данните. Това, което очакваме да видим, е увеличаване на времето за изпълнение на резервното копие и намаляване на размера на архива, когато увеличим тази настройка.

Както виждате, с изключение на резервно копие 4, което можем просто се брои като преходна флуктуация, времето за изпълнение на архивиране се увеличава от 3 минути и 41 секунди до 17 минути и 57 секунди. Размерът на резервното копие намалява от 3,5 GB на 3,3 GB. Можем също да проверим точния размер на архива:

du -s /root/backups/*
3653288 /root/backups/BACKUP-1
3643088 /root/backups/BACKUP-2
3510420 /root/backups/BACKUP-3
3486304 /root/backups/BACKUP-4
3449392 /root/backups/BACKUP-5
3437504 /root/backups/BACKUP-6
3429152 /root/backups/BACKUP-7
3425492 /root/backups/BACKUP-8
3405348 /root/backups/BACKUP-9

Това потвърждава, че размерът на архива всъщност намалява с всяко ниво на компресия, но разликите са доста малки между първото и последното ниво, което тествахме. Най-малкият архив има 93,2% от размера на най-големия. От друга страна, времето за изпълнение (1077 секунди) е почти 5 пъти по-дълго от времето за изпълнение на най-голямото резервно копие (221 секунди).

Моля, имайте предвид, че вашият пробег ще варира. Можете да използвате данни, които компресират по-добре, което прави въздействието на нивото на компресия по-значително. Въз основа на резултата от този тест, за набор от данни sysbench едва ли има смисъл да се използва ниво на компресия по-високо от 3.

Кпресия на Qpress

Друга опция, която бихме искали да тестваме днес, е компресията на Qpress. Qpress е метод за компресиране, който може да се използва за замяна на gzip.

Както виждате, определено е по-бърз от gzip, но идва с значително увеличение на размера на данните. След 100 секунди компресиране получихме 4,6 GB данни.

Изборът на най-подходящия метод за компресиране може да изисква серия тестове, но, както се надяваме, че можете да видите, определено има смисъл да го направите. За големи набори от данни възможността за търгуване на малко по-голям архив за почти 5 пъти по-бърз процес на архивиране може да е доста удобна. Ако обмислим използването на Qpress, можем да търгуваме с дисково пространство дори за 10 пъти по-бърз процес на архивиране. Това може да означава разлика между 20 часа архивиране и 2 часа архивиране. Разбира се, увеличаването на дисковото пространство, необходимо за съхранение на такива данни, ще бъде видимо, но тогава, когато се замислите, получаването на по-голям дисков обем е възможно. Добавянето на допълнителни часове към деня, когато 24 часа не са достатъчни за извършване на архивирането, не е.

Надяваме се, че този кратък блог е бил проницателен за вас и ще ви насърчи да играете с различни настройки, които могат да се използват за MariaBackup. Ако искате да споделите своя опит с тях, ще се радваме да видим вашите коментари.


  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. Преглед на клъстерирането на ProxySQL в ClusterControl

  2. Автоматизирайте проверка на обекта на схемата на базата данни

  3. MariaDB JSON_COMPACT() Обяснено

  4. Как работи CONVERT_TZ() в MariaDB

  5. MariaDB JSON_LOOSE() Обяснено