V předchozí části jsme testovali dobu zálohování a účinnost komprese pro různé úrovně a metody komprese zálohy. V tomto blogu budeme pokračovat v našem úsilí a budeme hovořit o dalších nastaveních, která pravděpodobně většina uživatelů ve skutečnosti nemění, přesto mohou mít viditelný vliv na proces zálohování.
Nastavení je stejné jako v předchozí části:použijeme replikační cluster MariaDB master-slave s ProxySQL a Keepalived.
Vygenerovali jsme 7,6 GB dat pomocí 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 preparePoužití PIGZ
Tentokrát pro naše zálohy povolíme Use PIGZ pro paralelní gzip. Stejně jako předtím otestujeme každou úroveň komprese, abychom viděli, jak funguje.
Zálohu ukládáme lokálně na instanci, instance je nakonfigurována pomocí 4 vCPU.
Výsledek je tak nějak očekávaný. Proces zálohování byl výrazně rychlejší, než když jsme používali pouze jedno jádro CPU. Velikost zálohy zůstává v podstatě stejná, není žádný reálný důvod, aby se výrazně měnila. Je jasné, že použití pigz zkracuje dobu zálohování. Paralelní gzip má však i svou temnou stránku, a to využití CPU:
Jak vidíte, využití procesoru raketově stoupá a dosahuje téměř 100 % pro vyšší úrovně komprese. Zvýšení využití CPU na databázovém serveru není nutně nejlepší nápad, protože obvykle chceme, aby byl CPU pro databázi dostupný. Na druhou stranu, pokud náhodou máme repliku, která je vyhrazena pro zálohování a řekněme těžší dotazy – uzel, který se nepoužívá pro obsluhu provozu typu OLTP, můžeme povolit paralelní gzip, aby se zálohování výrazně snížilo. čas. Jak je jasně vidět, není to volba pro každého, ale rozhodně je to něco, co můžete najít v některých konkrétních scénářích užitečné. Jen mějte na paměti, že využití procesoru je něco, co musíte sledovat, protože ovlivní latenci dotazů a v důsledku toho ovlivní uživatelskou zkušenost – něco, co bychom vždy měli vzít v úvahu při práci s databázemi.
Xtrabackup Parallel Copy Threads
Další nastavení, které chceme zdůraznit, je Xtrabackup Parallel Copy Threads. Abychom pochopili, co to je, pojďme si něco říct o tom, jak Xtrabackup (nebo MariaBackup) funguje. Stručně řečeno, tyto nástroje provádějí dvě akce současně. Zkopírují data, fyzické soubory, z databázového serveru do umístění zálohy, zatímco sledují nové protokoly InnoDB pro případné aktualizace. Záloha se skládá ze souborů a záznamu všech změn InnoDB, ke kterým došlo během procesu zálohování. To se zámky zálohování nebo FLUSH TABLES SE ZÁMEKEM ČTENÍ umožňuje vytvořit zálohu, která je konzistentní v okamžiku, kdy byl přenos dat dokončen. Xtrabackup Parallel Copy Threads definují počet vláken, která budou provádět přenos dat. Pokud jej nastavíme na 1, zkopíruje se současně jeden soubor. Pokud jej nastavíme na 8, teoreticky lze přenést až 8 souborů najednou. Samozřejmě musí existovat dostatečně rychlé úložiště, aby bylo možné z takového nastavení skutečně těžit. Provedeme několik testů a změníme Xtrabackup Parallel Copy Threads z 1 přes 2 a 4 na 8. Spustíme testy na úrovni komprese 6 (výchozí) s povoleným paralelním gzip i bez něj.
První čtyři zálohy (27 - 30) byly vytvořeny bez paralelního gzip, počínaje 1 až 2, 4 a 8 paralelními vlákny kopírování. Poté jsme zopakovali stejný proces pro zálohy 31 až 34, tentokrát pomocí paralelního gzip. Jak vidíte, v našem případě není mezi paralelními kopírovacími vlákny téměř žádný rozdíl. To bude pravděpodobně mít větší dopad, pokud bychom zvětšili velikost souboru dat. Také by se zlepšil výkon zálohování, kdybychom používali rychlejší a spolehlivější úložiště. Jako obvykle se váš počet najetých kilometrů bude lišit a v různých prostředích může toto nastavení ovlivnit proces zálohování více než to, co vidíme zde.
Omezování sítě
Nakonec bychom v této části našeho krátkého seriálu rádi hovořili o schopnosti omezit využití sítě.
Jak jste možná viděli, zálohy lze ukládat lokálně na uzlu resp. lze jej také streamovat do hostitelského řadiče. To se děje přes síť a ve výchozím nastavení to bude provedeno „co nejrychleji“.
V některých případech, kdy je propustnost vaší sítě omezená (například cloudové instance), možná budete chtít snížit využití sítě způsobené MariaBackup nastavením limitu pro přenos sítě. Když to uděláte, ClusterControl použije nástroj „pv“ k omezení dostupné šířky pásma pro proces.
Jak vidíte, první záloha trvala asi 3 minuty, ale když jsme omezil propustnost sítě, zálohování trvalo 13 minut a 37 sekund.
V obou případech jsme použili pigz a úroveň komprese 1. Graf výše ukazuje, že omezení sítě také snížilo využití CPU. Dává to smysl, pokud pigz musí čekat, až síť přenese data, nemusí tvrdě tlačit na CPU, protože musí být většinu času nečinný.
Doufáme, že vás tento krátký blog zaujal a možná vás povzbudí k experimentování s některými nepříliš běžně používanými funkcemi a možnostmi MariaBackup. Pokud byste se chtěli podělit o nějaké své zkušenosti, rádi bychom je slyšeli v komentářích níže.