Poznámka: Tento článek je průvodcem, nikoli procesem krok za krokem. Předpokládá se, že jste obeznámeni se správou systému Linux® a rsync utility.Nespouštějte příkazy v tomto článku, pokud s nimi nejste plně obeznámeni. Ve všech případech se ujistěte, že jste si zálohovali svá data, než budete postupovat podle kroků v této příručce. Účtují se standardní poplatky za šířku pásma.
Tato příručka vám pomůže zkrátit dobu migrace serveru. Pokud aplikace vašeho serveru odpovídají některé z charakteristik zdůrazněných v tomto článku, pak čtěte dále – tento článek vám může zkrátit a předvídat časy rsync. Ukazuje také, jak zkrátit dobu migrace provedením preventivních opatření před tím.
Urychlení procesu rsync
Objem použitého místa na disku na serveru určuje časy rsync. To znamená, že čím více dat zkopírujete, tím déle bude úloha trvat. Dokončení prázdného rsync OS obvykle trvá 10–15 minut. Následující případy použití serveru mohou výrazně prodloužit čas rsync:
- Servery obsahující velké množství malých souborů, jako jsou soubory relací Ruby, soubory mezipaměti, soubory zpráv poštovního serveru nebo miniatury obrázků webového serveru . Migrace takových dat pomocí rsync trvá déle, než byste čekali. To znamená, že počáteční synchronizace trvá déle, ale druhý průchod v záchranném režimu – s přidruženou dobou výpadku – je kratší.
- Servery obsahující více souborů aktualizované během živé synchronizace . Obvykle se jedná o soubory tabulky MySQL® MyISAM nebo webové servery hostující více domén, z nichž každá je nakonfigurována tak, aby se přihlašovala do samostatných souborů. Potřeba aktualizovat tyto aktivně zapsané soubory po prvním průchodu rsync kopií prodlužuje prostoje od restartu k dokončení druhého průchodu rsync procesu.
- Servery obsahující jeden nebo více velkých souborů byly během migrace aktualizovány . Příklady zahrnují databáze MySQL používající formát InnoDB, poštovní servery s velkými protokoly pošty a webové servery, které se přihlašují do jednotlivých velkých souborů. Aktualizace těchto aktivně zapsaných souborů druhým rsync po prvním průchodu rsync kopií může značně prodloužit související prostoje.
Tajemstvím zkrácení časů rsync je správa dat na vašem serveru a identifikace všech aplikací, které zapisují na disk během živé migrace.
Problém:Režie malých souborů
Přestože nezabírají mnoho místa na disku, servery hostující mnoho malých souborů nutí proces rsync, aby provedl mnoho file-open , file-copy a file-check procesy.
Například datový soubor o velikosti jednoho gigabajtu vyžaduje jednu sadu procesů otevření, kopírování a kontroly souboru. Porovnejte to s jedním gigabajtovým kusem dat rozloženým mezi 10 000 jednotlivých souborů, což vyžaduje 10 000 jednotlivých sad souborových procesů. To je mnohem větší režie systému a sítě.
Následující seznam ukazuje aplikace, které vytvářejí mnoho malých souborů a mají delší dobu přípravy na migraci:
- Webové servery poskytující mnoho malých miniatur nebo obrázkových souborů
- Ukládání serverů do mezipaměti na disku s malými soubory
- E-mailové servery s velkými archivy nesmazaných e-mailů
- Servery Ruby nebo Rails, které mají tendenci vytvářet více malých souborů relací a nemazat je
- úložiště git
- Vlastní aplikační servery, které vytvářejí, ale neodstraňují soubory relací pro každého návštěvníka
Problém s malými soubory činí rsync méně předvídatelným a trvá déle.
Jak provést migraci
Zkontrolujte své serverové aplikace podle předchozího seznamu. Pokud jsou vaše aplikace na seznamu, udělejte, co můžete, abyste před spuštěním skutečného rsync smazali nechtěné malé soubory příkaz. Pokud používáte Ruby nebo Rails, předpokládejte nejhorší a vyhledejte na komunitních fórech typická umístění souborů relace a mezipaměti a také to, jak zjistit, která z nich můžete bezpečně odstranit. Zvažte uložení dat relace v MySQL pomocí následujícího příkazu:
rake db:sessions:create
Zkrátit soubory protokolu v protokolu/ na nulu bajtů pomocí následujícího příkazu:
rake log:clear
Pokud provozujete server pro ukládání do mezipaměti, který se ukládá do mezipaměti na disk namísto do paměti RAM, identifikujte jeho adresář pro ukládání souborů a agresivně jej smažte. Zkontrolujte, zda váš systém souborů neobsahuje malé soubory relace a mezipaměti vytvořené vlastními aplikacemi. Opět s vervou prořezávejte. Pokud provádíte migraci e-mailového serveru s nainstalovaným Mail DeliveryAgentem (MDA), jako je Dovecot, požádejte uživatele e-mailu, aby nejprve vyčistili archivy e-mailů od starých e-mailů.
Problém:Neustále se měnící soubory
Soubory, které se změní mezi začátkem a koncem rsync, musíte znovu zkopírovat pomocí následného rsync pro důkladnou migraci serveru. Tento proces prodlužuje dobu dokončení migrace.
Databázové servery jsou nejčastějšími viníky, kteří aktualizují velké datové soubory mezi začátkem a koncem migrace. Tyto změny přinutí systém zkopírovat celý databázový soubor znovu v druhém procesu rsync, který můžete provést při migraci.
Některé kombinace struktury a typu databáze mají tendenci tento druh problému zhoršovat. Předpokládejme například, že máte MySQL vícetabulkovou databázi MyISAM s mnoha tabulkovými soubory aktualizovanými v rámci jednotlivých transakcí SQL. V takovém případě může být nutné během druhé operace rsync v záchranném režimu znovu zkopírovat mnoho, ne-li všechny soubory tabulek.
Vzhledem k tomu, že databázové soubory mohou být velké, jsou důsledky těchto aktualizací pro dobu migrace jasné. Je obtížné přesně předpovědět, jak dlouho může rsync migrace trvat. Koneckonců, jak můžeme předvídat, co a kolik aktualizací SQL proběhne mezi zahájením a dokončením migrace?
Jak provést migraci
Pokud vaše databáze obsahuje mnoho zastaralých dat, zvažte před migrací serveru možnost archivace těchto dat a jejich následné odstranění z aktivní databáze. MySQL vám například umožňuje archivovat data pomocí mysqldump skript, po kterém můžete smazat zastaralá data v živé databázi. Velký mysqldump výstupní soubor obsahující zastaralá data se při druhém rsync nerozšíří, protože se od prvního průchodu nezmění.
Další možností, pokud vaše aplikace zapisují během změny velikosti do mnoha souborů, je nastavit aplikaci do režimu pouze pro čtení bezprostředně před spuštěním rsync příkaz. Databáze můžete obvykle nastavit do dočasného režimu pouze pro čtení. S jinými aplikacemi se váš kilometrový výkon může lišit. Můžete také zabránit zápisu do více souborů vypnutím aplikací, ale obvykle je preferovanou možností nastavení aplikací do režimu pouze pro čtení.
Problém:Velké, neustále aktualizované soubory
Velmi velké soubory (10 GB nebo více) aktualizované během rsync představují podobné problémy s dobou formování jako menší, neustále aktualizované soubory, ale na steroidech. Pokud váš serverhostuje soubory, na které se často zapisuje, je tato část určena právě vám.
Druhý rsync potřebuje zcela znovu zkopírovat tyto velké, neustále aktualizované soubory, aby zachytil všechny aktualizace provedené po zahájení procesu migrace nebo změny velikosti. To značně prodlužuje dobu migrace kvůli velikosti této druhé kopie rsync.
Databázové servery MySQL, které používají formát datových souborů InnoDB, zapisují data do jediného souboru, který se skutečně velmi zvětšuje. Podobně se MySQL v režimu InnoDB protokoluje do jednoho velkého souboru protokolu.
Aktualizace velkých dat nebo souboru protokolu InnoDB MySQL, jako je /var/lib/mysql/ibdata1 , přinutí proces rsync znovu zkopírovat celý soubor ve druhém průchodu. Pokud jsou tyto soubory velké, může opětovné zkopírování nějakou dobu trvat, což udržuje databázi offline.
Dalším zdrojem velkých souborů jsou protokoly aplikací, včetně protokolů vytvořených poštovními servery a některými webovými servery. Apache® může vytvářet soubory protokolu, které jsou 16Gb nebo větší, takže není bezpečné předpokládat, že výchozí protokolování Apache vám pomůže vyhnout se tomuto problému s velkými soubory.
Protokoly transakcí MySQL se také mohou zvětšit, pokud jste zapnuli protokolování transakcí. Lidé to dělají jen zřídka a je ještě vzácnější, že zapnou protokolování transakcí, aniž by jim poté došlo místo na disku. Přesto je moudré na tuto možnost dávat pozor.
Jak provést migraci
Jak bylo popsáno dříve, ořezávání databází cruft může pomoci zkrátit celkový čas rsync. Před pokusem o migraci archivujte a odstraňte staré nebo zastaralé databáze.
Opět platí, že vypnutím zápisu do databáze, pokud je to možné, se zkrátí doba migrace. Vypnutí protokolování může také pomoci databázím InnoDB.
Pokud jste zapnuli protokolování transakcí MySQL a soubor protokolu transakcí je velký, vyplatí se jej před zahájením rsyncmigrace vypnout, archivovat a poté smazat na řezu.
Na poštovních serverech zkontrolujte velikost /var/log/mail.log nebo /var/log/maillog před migrací. Zvažte před migrací vypnutí poštovního serveru, zvláště pokud máte záložní poštovní server, který převezme zátěž.
Podobně zkontrolujte, jak Apache protokoluje. Pokud protokoluje všechny požadavky do jednoho souboru, zkontrolujte velikost tohoto souboru a před zahájením procesu migrace zvažte jeho archivaci a smazání nebo vypnutí Apache. Stejná rada platí pro jakoukoli jinou aplikaci, o které víte, že zapisuje do velkého souboru protokolu.
U těchto a všech dalších aplikací zkontrolujte svůj logrotate zásadu (pokud ji máte), abyste zkontrolovali, zda kontroluje velikost souborů protokolu. To vám ušetří prostoje během migrace a usnadní život s jakýmkoli serverem Linux.
Zabalte si svou brašnu
Samozřejmě je obtížné sledovat soubory vytvořené po nastavení serveru. To platí pro aplikace, které vytvářejí soubory relací. Vyplatí se najít a vyřadit tyto velké sbírky malých souborů.
Deset největších adresářů a souborů můžete identifikovat zadáním následujícího příkazu jako root :
du -a / | sort -n -r | head -n 10
Změňte posledních 10 na jakékoli jiné číslo, abyste mohli změnit počet souborů a adresářů, které vyhledávání vrátí. Tento příkaz je dobrým středním nástrojem pro identifikaci velkých adresářů malých souborů a velkých souborů. Pokud chcete hledat pouze velké soubory, vyzkoušejte tento vyhledávač velkých souborů (jako root ):
find ~/ -mount -type f -ls|sort -rnk7 |head -30|awk '{printf "%10d MB\t%s\n",($7/1024)/1024,$NF}'
Pokud chcete najít pouze velké adresáře, vyzkoušejte tento vyhledávač velkých adresářů (jako root ):
du -x --max-depth=4 ~/|sort -rn|head -n30|awk '{printf "%10d MB\t%s\n",$1/1024,$2}'
Technické podrobnosti
Předpokládejme, že váš server neodpovídá žádnému z běžných typů, které jsme zkoumali výše. V takovém případě můžete posoudit, jak by mohla vypadat doba jeho migrace, pokud zvážíte své aplikace a pochopíte, jak proces migrace (rsync) funguje.
Typickou první fází migrace je živý rsync, což je v podstatě kopie celého souborového systému serveru. Během této fáze zůstanou všechny aplikace spuštěné.
Zde se předpovídání doby migrace dostává do první nejistoty. Bez podrobných znalostí vašeho používání souborového systému vašeho serveru nemůžete přesně předpovědět, jak dlouho bude file-copy dokončení fáze rsync.
Tato nepředvídatelnost platí pro konečný adresář na souborových systémech Linux:/var/ adresář. Jmenuje se var protože velikost dat, která obsahuje, je proměnná a změny za běhu serverových aplikací.
Druhou nejistotou je, že konečná fáze migrace zahrnuje komponentu záchranného režimu (prostoje). Během této fáze proces znovu zkopíruje všechny soubory aktualizované po zahájení fáze živého rsyncfirst. Délka prostoje závisí na velikosti a počtu aktualizovaných souborů. Proces rsync opět nedokáže předem říci, kolik aktualizací aplikace jako MySQL zapisuje do datových souborů, takže je těžké předvídat trvání této konečné záchrany- režim rsync kopírovat.
Předchozí informace platí pro typický proces ruční migrace. Náš cloud mění proces změny velikosti tak, aby se server zastavil na jedinou synchronizaci, čímž se prodlouží prostoje a spolehlivost synchronizace.
Přehled
Pokud víte, jak vaše aplikace využívají místo na disku a zapisují do souborů, můžete být schopni posoudit, zda migrace bude trvat déle, než chcete, a podle toho se připravit. Přinejmenším můžete využít své nově nabyté znalosti o migraci k lepšímu plánování migrace tak, aby vyhovovala vašim požadavkům na načasování.
Pomocí karty Zpětná vazba můžete přidat komentáře nebo položit otázky. Můžete s námi také zahájit konverzaci.