Mitä tehdä SQL Server Log Shipping -ominaisuudella?
SQL Server Log Shipping on monipuolinen ominaisuus, jota voidaan käyttää useampaan käyttötarkoitukseen. Tämä toiminnallisuus löytyy SQL Server Enterprise-, Standard- sekä Web editioneista.
Yleisiä käyttötarkoituksia, joissa log shippingiä käytetään:
- Disaster recovery -ratkaisu
- Raportointityökuorman siirtäminen toiseen palvelimeen
- Tietokantojen migraatiot
Mitä on SQL Server Log Shipping?
Log shipping mahdollistaa tietokannan kopioinnin eri palvelinten välillä. Operaatiossa hyödynnetään transaktiolokien varmistuksia. Log shipping hoitaa automaattisesti transaktiolokin varmistukset primäärinoodilta, kopioi sekä palauttaa tietokannan varmistuksen toissijaiseen noodin (=palvelimeen).
Varmistus / palautustoimien ajastaminen hoidetaan SQL Server Agentin toimesta muutamalla jobilla, jolloin tietokanta voidaan synkronoida halutun ajankohdan mukaan (voidaan määritellä synkronoinnit tehtäväksi esim. yöaikaan). Log shipping on yksittäisen tietokannan asetus, tällöin se pitää myös konfiguroida tietokannoittain.
Toissijaisen tietokannan lukeminen on myös mahdollista log shippingillä. Palautusprosessissa voidaan määritellä tietokannan operatiivinen tila kahdella erilaisella vaihtoehdolla:
- ”standby mode” on niin sanottu lämmin valmiustila. Tällöin tietokantaa voidaan lukea toissijaiselta palvelimelta aina palautustoimien välissä.
- ”recovery mode” pitää tietokannan tilassa, jolloin tietokantaan ei voida kohdistaa erillisiä kyselyitä.
Kuinka log shipping toimii?
- Primääri-instanssin tietokannasta otetaan transaktiolokin varmistus
- Kopioidaan varmuuskopio sekundaariselle palvelimelle
- Palautetaan tietokanta sekundaariseen instanssiin
Miten tietokannat tulee varmistaa, mikäli log shipping otetaan käyttöön?
Log shipping ottaa vain yksittäisen tietokannan transaktion lokeista varmistuksia. Tällöin tulisi huolehtia, ettei mikään muu rutiininomainen ”varmistusjobi” varmistele samanaikaisesti transaktiolokeja. Mikäli tietokannasta otetaan useampia lokien varmistuksia, tällöin tietokannan palauttamiseen käytettävä lokiketju ”LSN” (Log sequence numbers) katkeaa. Tämä LSN-sarja pitää olla eheä, jotta tietokannan palauttaminen tiettyyn ajankohtaan onnistuisi. Tietokannalle pitää myös luoda log shippingin (lokivarmistusten) lisäksi päivittäiset / viikottaiset rutiininomaiset full- sekä / tai differential-varmistukset, jotta vikatilanteessa päästään palautumaan mahdollisimman tuoreeseen varmistustilanteeseen.
Log shipping voidaan pystyttää joko käyttämällä jo voimassa olevia täysvarmistuksia, tai niin että täysvarmistus otetaan pystytyksen hetkellä.
Vinkki: Muista siis pitää huoli rutiini varmistusjobeista, jottei log shipping sotke lokin palautusketjua.
Milloin Log Shipping -ominaisuutta on hyvä käyttää?
Migraatioissa Log Shipping mahdollistaa tietokannan siirtämisen palvelimelta toiselle hyvinkin pienellä käyttökatkolla, koska suurien tietokantojen varmistuksien kanssa saattaa mennä hyvinkin pitkiä aikoja, ennen kuin tietokanta saadaan siirrettyä käsipelillä (sis. varmistaminen, kopiointi sekä palautustoimet). Log shippingillä pidetään tietokanta suhteellisen ajantasaisena (tietokannan datojen menetys on lokivarmistusten välinen aika). Palvelimen siirto tehdään aina manuaalisesti (tarvitaan siis DBA-toimia). Siirron aikana otetaan vain viimeisimmät loki- sekä lokihännän varmistukset. Tämä mahdollistaa sen, että käyttökatkon pituus pysyy minimaalisena.
Log shippingiä on myös yksinkertaisempi hallita sekä konfiguroida, kuin tietokantataulujen replikointia. Replikointi vaatii myös tietokantamuutoksia tauluihin (primary key). Log shippingillä taasen riittää, että tietokannan recovery model on joko FULL tai BULK-LOGGED -tilassa.
Disaster recovery (DR) -ominaisuutena log shipping on huomattavasti yksinkertaisempi pystyttää, kuin Always On availability group, koska tämä ei tarvitse toimiakseen Windows Failover Cluster -komponentteja tai konfigurointeja. Log Shipping -ominaisuus on toiminut jo vuosia kuin se kuuluisa junan vessa. Tämän tekniikan avulla voidaan käyttää kahta tai useampaa palvelinta.
Log shippingiä voidaan myös ajatella raportointikäyttöön, esimerkiksi mikäli halutaan ohjata raportointikuorma ajettavaksi toissijaisella palvelimella, jolloin primäärillä vapautuu hieman työkuormaa muihin operatiivisiin operaatioihin. Huomiona se, että tietokantaa voidaan lukea palautustoimien välissä.
Mikäli sinulla on tarvetta SQL Server HA / DR-konsultoinnille, otathan minuun yhteyttä. 😊
Mikko Källroos
Senior DBA & Architect
DB Pro Services Oy