it-swarm-eu.dev

Jak aktualizujete schéma produkční kódovací databáze / databáze, aniž byste způsobovali prostoje?

Jaké jsou některé techniky aktualizace schématu databáze/databázového schématu produkčního serveru bez způsobení jakýchkoli prostojů?

43
Olivier Lalonde

Obecně platí, že webové stránky, na kterých jsem pracoval, které měly tento druh požadavku, byly všechny za balancery zátěže, nebo měly samostatná převzetí služeb při selhání. V tomto vzorku předpokládám, že máte jeden vyrovnávač zatížení, 2 webové servery (A a B) a 2 databázové servery (M & N - obvykle jsou DB servery propojeny pomocí logshippingu - alespoň ve světě SQL Server ).

  1. Webový server A bude odpojen od vyrovnávače zatížení (veškerý příchozí provoz tedy přejde do bodu B).
  2. Doručení protokolu je zastaveno (DB Server M bude nejprve aktualizován).
  3. Aktualizujte webový server A. Nasměrujte konfiguraci na server DB Server M.
  4. Otestujte a ověřte, že aktualizace fungovala (obvykle lidé zasáhnou IP adresu přímo).
  5. Vyrovnávač zatížení nastavte tak, aby stávající relace pokračovaly na B. Nové relace přejděte na A.
  6. Počkejte na vypršení všech relací na B (může to být půl hodiny nebo více, obvykle sledujeme provoz a máme naplánovanou 1 hodinu přestávky).
  7. Aktualizace B a N.
  8. Otestujte a ověřte, zda aktualizace fungovala.
  9. Znovu nastavte odesílání protokolu a otestujte, zda funguje.
  10. Nastavte vyvažovač zatížení do běžného provozu.

Ve velmi komplikovaných webových aplikacích to, co je popsáno jako kroky 1-5, může trvat celou noc a může to být 50stránkový tabulkový procesor Excel s časy a čísly pro nouzové kontakty. V takových situacích je aktualizace poloviny systému naplánována na 18:00 až 6:00, přičemž systém zůstane k dispozici uživatelům. Zpracování aktualizace pro web DR je obvykle naplánováno na následující noc - jen doufám, že se první den nic nepřeruší.

Tam, kde je požadavek na provozuschopnost, jsou záplaty testovány nejprve v prostředí QA, což je v ideálním případě stejný hardware jako výroba. Pokud nevykazují žádné narušení, mohou být použity podle pravidelného rozvrhu, který je obvykle o víkendu.

20
Tangurena

U typických databází (například Oracle) je možné změnit schéma databáze a přitom paralelně běžet dotazy. Vyžaduje to však určité dopředné plánování.

To jsou některá omezení pro změnu, která má být použita:

  • měl by pracovat s existujícím kódem, což znamená, že kód by se měl zabývat starou i novou verzí schématu
  • nemělo by to vést k takové zátěži v DB, že by transakce křičely zastavením (dívám se na vás CREATE INDEX)
  • nemělo by to způsobit ztrátu dat (nemůžete zrušit a znovu vytvořit tabulku)

Aby bylo schéma zpětně kompatibilní, můžete obvykle přidat nebo změnit sloupec, můžete něco DROP pouze DROP, pokud jej stávající kód již nepoužívá.

Pokud váš kód nemůže tuto změnu zpracovat transparentně, změňte kód před změnou databáze.

Jednoduchá rada ohledně plánování dopředu: vždy explicitně pojmenujte názvy sloupců v požadavcích na DB (nepoužívejte SELECT * FROM). Tímto způsobem nebudete mít nové sloupce zobrazující se ve starých požadavcích.

9
Matthieu M.

Ne všechny systémy to mohou, musí být nastaveny způsobem, který je podporuje.

Například jeden z našich hlavních systémů, kterým jsem před několika lety pomohl upgradovat, by měl být k dispozici 24/7. Skládalo se z více úrovní, včetně čisté komunikační úrovně mezi off-site uživatelským rozhraním a Business Layer. Kvůli způsobu, jakým byla komunikační vrstva kódována, mohly být jakékoli budoucí změny schématu Business Layer nebo DB implementovány bez skutečného výpadku. V nejhorším případě by uživatel zaznamenal 10–30 sekundovou pauzu, jak se změny projevily.

Pokud by změny byly čistě kódovými změnami podnikové vrstvy, mohly by být zařazeny do fronty a „cyklovány“ s pouze milisekundovým zpožděním.

Mohlo by to udělat, protože:

  • Komunikační vrstva mohla uchovávat zprávy. To nám umožnilo mít skutečný výpadek na kterékoli jiné vrstvě, než je vrstva UI, aniž bychom museli snižovat UI.
  • Obchodní vrstva zpracovaná MVDB s názvem niData . Tím se uchová veškerý kód v paměti. Po kompilaci kódu můžete pomocí příkazu vynutit nový kód objektu do paměti a nahradit starý.

Další techniky zahrnují replikaci transakcí do jiného zrcadla stávajícího systému. Aplikováním aktualizace na jednu přepínáte a nahrazujete všechny transakce provedené mezi aktualizací a přepínáním. YMMV v závislosti na vašich systémech.

5
Dan McGrath

Tady je jiná perspektiva, ze světa vestavěných databázových systémů a vestavěných systémů. Vestavěné systémy zahrnují různá síťová/telekomunikační infrastrukturní zařízení a v této oblasti často hovoří o 99,999% (pět 9s) provozuschopnosti.

My (McObject) jsme dodavatelem řady produktů integrovaného databázového systému eXtremeDB, včetně eXtremeDB High Availability.

Nejprve si uvědomte, že „vložená databáze“ znamená, že databázový systém je knihovna, která je kompilována a propojena s kódem vaší aplikace; v tomto smyslu je „zabudován“ do vaší aplikace.

S vysokou dostupností eXtremeDB existuje MASTER instance vaší aplikace (což může být jeden nebo několik procesů) a jedna nebo více instancí REPLICA vaší aplikace. Když replika naváže spojení s masterem, obdrží kopii master databáze prostřednictvím procesu zvaného „počáteční synchronizace“. To lze provést, zatímco hlavní aplikace pokračuje ve své práci. Jakmile je syncrhonized, obdrží hlavní transakce prostřednictvím replikace. Proto má replika vždy aktuální data a může převzít (prostřednictvím procesu zvaného převzetí služeb při selhání) v případě selhání hlavního serveru.

Jedna funkce počáteční synchronizace se nazývá „vývoj binárního schématu“. V prosté angličtině to znamená, že proces naplnění databáze repliky přizpůsobí rozdíly mezi schématem repliky databáze a schématem hlavní databáze.

V praxi to znamená, že můžete vytvořit novější verzi aplikace (s novými/zrušenými tabulkami, novými/zrušenými/změnými poli, novými/zrušenými indexy), připojit tuto novou verzi aplikace k hlavnímu počítači a poté způsobit novější replika se stane novým hlavním (tj. vynutí převzetí služeb při selhání nové repliky, takže se stane hlavním a starý hlavní se vypne). Voila, migrovali jste svou aplikaci z verze N na N + 1, aniž byste přerušili dostupnost vašeho systému. Nyní můžete jít o upgrade starého pána a dalších replik na verzi N + 1.

1
user22538