Toisinnetun tietokannan hallinta M. Kifer, A. Bernstein & P. M. Lewis: Database Systems. An Application-Oriented Approach. Complete Version. Pearson Addison Wesley, 2006; sivut 1028 1037, luvun 24 (implementing distributed transactions) kohta 24.7 (replicated databases). A. Silberschatz, H. F. Korth & S. Sudarshan: Database System Concepts. Sixth Edition. McGraw-Hill, 2010; sivut 756 759, kohta 16.9 (remote backup systems); sivut 840 844 ja 847 853, kohdan 19.5 (concurrency control in distributed databases) alakohdat 19.5.1.3 (primary copy), 19.5.1.4 (majority protocol), 19.5.1.5 (biased protocol) ja 19.5.1.6 (quorum consensus protocol), 19.5.3 (replication with weak degrees of consistency) sekä kohta 19.6 (availability); sivu 1188, luvun 28 (Oracle) alakohta 28.7.1 (replication); sivut 1220 1221, luvun 29 (IBM DB2 Universal Database) kohta 29.12 (replication, distribution, and external data); sivut 1251 1253, luvun 30 (Microsoft SQL Server) kohta 30.9 (replication). A. Silberschatz, H. F. Korth & S. Sudarshan: Database System Concepts. Fifth Edition. McGraw-Hill, 2006; sivut 711 713, kohta 17.9 (remote backup systems); sivut 848 849, 849 852 ja 854 857, kohdan 22.5 (concurrency control in distributed databases) alakohdat 22.5.1.3 (primary copy), 22.5.1.4 (majority protocol), 22.5.1.5 (biased protocol) ja 22.5.1.6 (quorum consensus protocol), 22.5.3 (replication with weak degrees of consistency) sekä kohta 22.6 (availability); sivut 1022 1023, luvun 27 (Oracle) alakohta 27.7.1 (replication); sivut 1053 1054, luvun 28 (IBM DB2 Universal Database) kohta 28.12 (replication, distribution, and external data); sivut 1082 1084, luvun 29 (Microsoft SQL Server) kohta 29.9 (replication). 121
Tietoalkioiden toisintaminen, s. 123. Toisinteiden johdonmukaisuus, s. 128. Tahdistavasti päivittävä toisintaminen, s. 130. Päätösvaltaan perustuva toisintaminen, s. 133. Tahdistamatta päivittävä toisintaminen, s. 140. Pääkopiotoisintaminen, s. 144. Ryhmätoisintaminen, s. 151. Oraclen toisintamiskäytännöt, s. 155. Julkaisuun ja tilauksiin perustuva toisintaminen, s. 161. Etävarmistusjärjestelmät, s. 166. 122
Tietoalkioiden toisintaminen Tietokannan tietoalkion toisintamisella (replication) tarkoitetaan tietoalkion kopion eli toisinteen (replica) ylläpitämistä hajautetun tietokantajärjestelmän useammassa eri pisteessä. Toisintamisen yhtenä tarkoituksena on parantaa tiedon saatavuutta (data availability) häiriötilanteissa: Jos järjestelmän jokin piste romahtaa tai jää vaille yhteyttä muihin pisteisiin verkon osittumisen vuoksi, pisteessä säilytettävän tietoalkion toisinne voi kuitenkin olla saatavilla jostakin toisesta pisteestä. Toisintaminen voi myös parantaa tiedon saatinopeutta ja sitä kautta lisätä järjestelmän transaktiosuoritustehoa (transaktioiden lukumäärää sekunnisssa) sekä vähentää vasteaikaa, koska transaktio voi operoida tietoalkion lähimpään toisinteeseen, parhaimmassa tapauksessa paikalliseen kopioon. Esimerkkinä esitetyssä verkkokauppasovelluksessa asiakkaiden tietoja sisältävän customer-taulu on ositettu vaakasuorasti kaikkiin varastopisteisiin ja lisäksi toisinnettu kokonaisuudessaan päätoimipisteeseen. Asiakkaan tavaratilauksen toimittamiseen liittyvä transaktio suoritetaan varastopisteessä käyttäen sinne sijoitettua palasta customerrelaatiosta, kun taas kuukausittaisen postituksen kaikille asiakkaille toteuttava transaktio käyttää päätoimipisteeseen toisinnettua taulua. 123
Toisintamisella on hintansa. Tallennustilaa tarvitaan enemmän. Järjestelmästä tulee monimutkaisempi toisinnetun tiedon hallinnan vuoksi. Jos kahden transaktion annetaan lukea ja mahdollisesti myös kirjoittaa saman tietoalkion eri toisinteita, kumpikin saattaa olla tietämätön toisen tekemästä luvusta tai päivityksestä, mikä voi johtaa erilaisiin eristyvyysanomalioihin ja tietokannan eheyden rikkoutumiseen. Tietoa toisintavan järjestelmän täytyy taata, että tietoalkion päivitys tavalla tai toisella ohjataan tietoalkion kaikkiin toisinteisiin ja että transaktion tietoalkioon kohdistama lukuoperaatio tyydytetään palauttamalla sopiva arvo. Verkkokauppasovelluksessa toisinnettua asiakastietoa on tarpeen päivittää vain silloin, kun kauppaan tulee uusi asiakas tai kun entisen asiakkaan tiedot (esim. osoite) muuttuvat. 124
Tietoalkio on täysin toisinnettu (totally replicated), jos siitä on toisinne jokaisessa pisteessä. Tietoalkio on osittain toisinnettu (partially replicated), jos siitä on toisinteita joissakin muttei kaikissa pisteissä. Jos tietokannan hallintajärjestelmä ei tarjoa toisintamismekanismia, sovellus voi itse toisintaa tietoalkioita. Järjestelmä on silloin tietämätön siitä, että jotkin eri pisteiden eri tietoalkioista ovatkin yhden ja saman tietoalkion toisinteita. Jos pisteen s 1 tietoalkio (x,v 1 ) ja pisteen s 2 tietoalkio (x,v 2 ) ovat saman tietoalkion toisinteita, kunkin transaktion pitää eksplisiittisesti pitää yllä eheysrajoitetta v 1 = v 2. Pisteen s 1 transaktion T 1 = BW[x,v 1,v 1 ]C, joka siis päivittää toisinnetta (x,v 1 ), täytyy eksplisiittisesti käynnistää pisteessä s 2 alitransaktio T 2 = BW[x,v 1,v 1 ]C, joka huolehtii toisen toisinteen päivittämisestä. Tietoalkion lukevan transaktion pitää eksplisiittisesti kertoa, mikä toisinne luetaan, ts. luetaanko tietoalkio pisteessä s 1 vai pisteessä s 2 toimivan alitransaktion osana. 125
Useimmat nykyisistä tunnetuista tietokannan hallintajärjestelmistä vapauttavat sovellussuunnittelijan eksplisiittisestä toisinteiden hallinnasta transaktioissa ja tarjoavat sen sijaan automaattisen toisinteiden valvonnan (replica control), jolloin toisintaminen ei näy sovellukseen. Toisinteiden valvonta tietää, missä tietoalkion kaikki toisinteet sijaitsevat. Kun transaktio pyytää saada lukea tai kirjoittaa tietoalkion, se ei määritä mitään erityistä toisinnetta. Pyynnön käsittelee toisinteiden valvonta, joka automaattisesti kääntää sen pyynnöksi operoida sopivaan toisinteeseen tai toisinteisiin ja välittää pyynnön edelleen paikalliselle samanaikaisuuden hallinnalle (jos toisinne on paikallinen) ja/tai johonkin tai joihinkin niistä etäpisteistä, joissa toisinne sijaitsee. Kun samanaikaisuuden hallinta perustuu lukitukseen, toisinteita lukitaan kuten tavanomaisia tietoalkioita kun niihin operoidaan. Samanaikaisuuden hallinta on tietämätön siitä, että tietoalkio saattaa oikeastaan olla toisinne toisessa pisteessä sijaitsevasta tietoalkiosta. 126
Toisinteiden valvonnan ja samanaikaisuuden hallinnan välinen suhde: 1. Transaktio T pyytää toisinteiden valvonnalta saada operoida tietoalkioon x. 2. Toisinteiden valvonta lähettää operointipyynnön pisteisiin s 1,...,s n (yksi tai useampi x:n toisinteiden sijaintipisteistä). 3. Kunkin pisteen s i (i = 1,...,n) samanaikaisuuden hallinta hankkii T :n s i :ssä toimivalle alitransaktiolle operoinnin oikeuttavan lukon x:ään. 4. Operaatio toteutetaan s i :ssä sijaitsevaan x:n toisinteeseen (i = 1,...,n). 127
Toisinteiden johdonmukaisuus Kaupallisen tietokannan hallintajärjestelmien toisinteiden valvonta yrittää ylläpitää toisinteiden kesken ainakin jonkinlaista keskinäistä johdonmukaisuutta (mutual consistency). Vahva keskinäinen johdonmukaisuus (strong mutual consistency) tarkoittaa, että tietoalkion kaikilla sitoutuneilla toisinteilla on aina sama arvo. Valitettavasti järjestelmän suorituskykyvaatimukset tekevät vahvan keskinäisen johdonmukaisuuden tavoitteesta epärealistisen. Niinpä useimmat toisinteiden valvonnat ylläpitävät vaatimattomampaa tavoitetta, heikkoa keskinäistä johdonmukaisuutta (weak mutual consistency): tietoalkion kaikki sitoutuneet toisinteet tulevat lopulta samanarvoisiksi, vaikka tiettynä hetkenä kahdella tai useammalla sitoutuneella toisinteella saattaakin olla eri arvot. Keskinäisen johdonmukaisuuden ylläpitämiseksi on esitetty erilaisia algoritmeja. 128
Yksinkertaisimmassa toisinteiden valvontajärjestelmässä luetaan yksi ja kirjoitetaan kaikki (read-one/write-all). Kun transaktio haluaa lukea tietoalkion, toisinteiden valvonta voi tarjota luettavaksi minkä tahansa luultavasti lähimmän toisinteen. Täysin toisinnetussa järjestelmässä lukutransaktio (so. transaktio, joka ei lainkaan kirjoita) on aina paikallinen ja siis oletettavasti hyvin nopea. Jos taas transaktio haluaa kirjoittaa tietoalkion, toisinteiden valvonnan on suoritettava algoritmi, joka lopulta aiheuttaa kaikkien toisinteiden päivityksen. Tämä on menetelmän vaikea tapaus, ja eri algoritmeilla on erilaiset ominaisuudet. Yleisesti ottaen yhden lukemiseen ja kaikkien kirjoittamiseen perustuva järjestelmä on toisintamatonta hajautettua järjestelmää tehokkaampi, jos eri tietoalkioihin kohdistuvat lukuoperaatiot ovat huomattavasti yleisempiä kuin päivitykset. (Oletamme, että lukuoperaatiot kohdistuvat etäpisteiden tietoihin.) Toisinteet voidaan päivittää tahdistetusti tai tahdistamatta. 129
Tahdistavasti päivittävä toisintaminen Tahdistavasti päivittävässä toisintamisessa (synchronous-update replication, synchronous replication) eli innokkaassa toisintamisessa (eager replication) transaktion T päivittäessä tietoalkiota x tämän kaikki toisinteet päivitetään T :n sisällä, siis osana yhtä ja samaa hajautettua transaktiota T. Jos x:stä on toisinne pisteissä s 1,...,s n, transaktiolla T on siis alitransaktio T i kaikissa näissä pisteissä ja tähän alitransaktioon sisältyy x:n päivitys. Alitransaktioiden sitoutuminen koordinoidaan kaksivaiheisella sitoutumiskäytännöllä. Menettely takaa toisinteiden vahvan keskinäisen johdonmukaisuuden. Koordinoija s 0 : Osallinen s 1 : Osallinen s 2 : T,B lokiin lock(t, x, X); T :n päivitys W[x]; T 1,s 0,T,B lokiin; T 2,s 0,T,B lokiin; lock(t 1,x,X); lock(t 2,x,X); T 1 :n päivitys W[x]; T 2 :n päivitys W[x]; 130
Toisinteiden lukinta ja operointijärjestys voidaan toteuttaa pessimistisesti tai optimistisesti. Pessimistisessä menetelmässä (josta esimerkki edellä) operoinnin kohteena olevan tietoalkion kaikki toisinteet lukitaan ennen kuin operointi voi siirtyä transaktion seuraavaan luku- tai päivitysoperaatioon. Optimistisessa menetelmässä transaktio voi edetä lukittuaan ja päivitettyään yhden toisinteen; muut toisinteet lukitaan ja päivitetään myöhemmin, mutta kuitenkin ennen transaktion sitoutumista. Kummassakin menetelmässä voi esiintyä yhdestä tietoalkiosta johtuva lukkiuma (one-item deadlock), vaikkei lukkojen korotuksia esiinny. Kaksi samaa tietoalkiota päivittävää, samanaikaisesti käynnissä olevaa transaktiota voi näet kumpikin onnistua kirjoituslukitsemaan osan tietoalkion toisinteista muttei kaikkia. 131
Innokkaassa toisintamisessa hajautettu transaktio joutuu hankkimaan paljon lukkoja, koska toisinnetun tietoalkion kaikki toisinteet on lukittava (toisinteen sijaintipisteessä toimivan alitransaktion nimiin). Tämä lisää lukkiuman vaaraa. Sitä paitsi vasteaika lisääntyy huomattavasti useiden lukkopyyntöjen vuoksi ja siksi, että transaktio ei voi sitoutua ennen kuin kaikkien toisinteiden päivityksen pysyvyys on taattu (kaksivaiheisella sitoutumisella). Näiden suorituskykyyn negatiivisesti vaikuttavien tekijöiden vuoksi innokkaan toisintamisen soveltuvuus on käytännössä rajattua. 132
Päätösvaltaan perustuva toisintaminen Tahdistettu yhden lukemiseen ja kaikkien kirjoittamiseen perustuva toisintaminen voi lisätä tiedon saatavuutta lukijoille, mutta ei auta päivittäjiä. Kaikkien kirjoittamisen vaatimuksesta seuraa, että päivitystä ei saada päätökseen, jos jonkin toisinteen sijaintipiste romahtaa. Tarkastellaan tahdistetun toisintamisen muunnelmaa, jossa minkään operaation ei tarvitse operoida tietoalkion kaikkiin toisinteisiin, niin että tietoalkio saattaa olla saatavilla, vaikka jokin sen toisinteista ei ole. Tämän tavoitteen saavuttaminen edellyttää, ettei toisinteita pidetä edes heikosti keskinäisesti johdonmukaisina. Tietoalkion kaikille toisinteille ei siis taata samaa arvoa. 133
Sovittuun päätösvaltaan (quorum consensus) perustuvassa käytännössä toisinnetun tietoalkion lukua tai kirjoitusta pyytävälle transaktiolle lukitaan ensin sovitun kokoinen osajoukko toisinteita. Tietoalkion lukuoperaatiota varten lukittavaa osajoukkoa (tai sen kokoa) kutsutaan tietoalkion lukuvallaksi (read quorum) ja kirjoitusoperaatiota varten lukittavaa osajoukkoa (tai sen kokoa) kokoa kutsutaan tietoalkion kirjoitusvallaksi (write quorum). Lukuoperaation tulos konstruoidaan lukuvaltaan kuuluvista toisinteista. Kirjoitusoperaatio toteutetaan kirjoitusvaltaan kuuluviin toisinteisiin. Jos tietoalkion lukuvaltaan kuuluu p toisinnetta ja kirjoitusvaltaan q toisinnetta, vaaditaan p + q > n ja q > n/2, missä n on tietoalkion toisinteiden kokonaislukumäärä. Tämä takaa, että minkä tahansa lukuvallan ja minkä tahansa kirjoitusvallan leikkaus on epätyhjä ja että minkä tahansa kahden kirjoitusvallan leikkaus on epätyhjä. 134
Tietoalkion x lukemista yrittävä transaktio joutuu siis odottamaan ainakin yhdessä x:n toisinteen sijoituspisteessä, jos jokin toinen transaktio on kirjoittamassa x:ää, ja x:n kirjoittamista yrittävä transaktio joutuu odottamaan ainakin yhdessä pisteessä, jos jokin toinen transaktio on lukemassa tai kirjoittamassa x:ää. Yhden lukemiseen ja kaikkien kirjoittamiseen perustuva käytäntö on itse asiassa päätösvaltaan perustuva käytäntö, jossa lukuvallan toisinteiden lukumäärä on yksi ja kirjoitusvallan n. Päätösvaltaan perustuvassa toisintamisessa on mahdollista tasapainoilla tiedon saatavuuden ja operointikustannuksen välillä. Mitä pienempi on lukuvallan koko p, sitä paremmin tietoalkio on saatavilla lukemista varten ja sitä alempi on lukuoperaation kustannus. Mitä pienempi on kirjoitusvallan koko q, sitä paremmin tietoalkio on saatavilla kirjoittamista varten ja sitä alempi on kirjoitusoperaation kustannus. Lukujen ja kirjoitusten saatavuudet ovat kuitenkin toisiinsa sidoksissa. Mitä paremmin saatavilla ja mitä tehokkaampi lukuoperaatio on, sitä vähemmän saatavilla ja tehottomampi on kirjoitusoperaatio, ja kääntäen. 135
Kun tietoalkion x kirjoitusvalta on hankittu, vain siihen kuuluvat x:n toisinteet päivitetään. Toisinteiden keskinäistä johdonmukaisuutta ei ylläpidetä, koska kaikkia x:n toisinteita ei päivitetä. Joillakin x:n toisinteista on ajantasainen arvo, toisilla ei. Koska x:n jokainen lukuvalta leikkaa jokaista kirjoitusvaltaa, jokainen lukuvalta leikkaa erikoisesti sitä kirjoitusvaltaa, johon perustuu x:n viimeisin kirjoitus. Niinpä x:n jokainen lukuvalta sisältää ainakin yhden x:n toisinteen, jolla on ajantasainen arvo. Miten toisinteiden valvonta osaa identifioida x:n ajantasaisen toisinteen? 136
Oletamme, että tietoalkion x jokaisessa toisinteessa ylläpidetään juoksevaa versionumeroa. Kun kirjoitusvaltaan kuuluvat x:n toisinteet päivitetään, kaikkien näiden toisinteiden uudeksi versionumeroksi asetetaan n + 1, missä n on kirjoitusvallan toisinteiden versionumeroiden maksimi. Kirjoitus edellyttää siis kirjoitusvallan kaikkien toisinteiden versionumeroiden lukemista. Kun kirjoitettava arvo riippuu tietoalkion entisestä arvosta, tämä entinen arvo luetaan sellaisesta toisinteesta, jossa versionumero on lukutai kirjoitusvallan suurin. Luku- ja kirjoitusvalloilta vaaditut ehdot takaavat, että luetuksi tulee aina tuorein toisinne, so. toisinne, jonka versionumero on suurin kaikista. Näin myös kirjoitus perustuu aina tuoreimpaan toisinteeseen, ja versionumeroiden sarja on kussakin toisinteessa nouseva. 137
Pessimistiseen lukitukseen ja päätösvaltaan perustuva toisintaminen toimii seuraavasti: 1. Kun pisteessä s i suorituksessa oleva transaktio T i tekee tietoalkion x luku- tai kirjoituspyynnön, pisteen s i toisinteiden valvonta lähettää pyynnön x:n luku- tai kirjoitusvallan toisinteiden sijoituspisteisiin. Jos kaikissa valtapisteissä samanaikaisuuden hallinta myöntää tarvittavan lukon x:n toisinteeseen, x:n operaatio suoritetaan ja vastaus palautetaan s i :n toisinteiden valvonnalle. Lukuoperaation tapauksessa vastaus sisältää toisinteen arvon ja versionumeron. 2. Kun pisteen s i toisinteiden valvonta on saanut vastauksen kaikilta valtapisteiltä, transaktio voi edetä. Jos kyseessä oli lukuoperaatio, s i :n toisinteiden valvonta palauttaa transaktiolle suurimmalla versionumerolla varustetun x:n toisinteen arvon. 3. Transaktio sitoutuu kaksivaiheisella sitoutumiskäytännöllä, jossa osallistujina ovat kaikki pisteet, joissa transaktiolla (tai oikeammin sen alitransaktiolla) on varattuna luku- tai kirjoituslukko. 138
Päätösvaltakäytännön suoritus voi edetä, vaikka häiriöitäkin sattuisi, niin kauan kuin toisinteiden valvonta pystyy kokoamaan operaatiota varten tarvittavan päätösvallan. Kun piste romahtaa ja aikanaan elpyy häiriöstä, joillakin sen toisinteilla saattaa olla hyvin vanha versionumero. Pisteen ei kuitenkaan ole tarpeen tehdä mitään erityisiä toimenpiteitä (tavanomaisen elvytysalgoritmin lisäksi), koska vanhentuneita toisinteita ei mikään transaktio kuitenkaan käytä ennen kuin jokin myöhempi transaktio on kirjoittanut niille uuden arvon, jolloin ne sitten ovatkin ajantasaisia. Edellä esitetyn kaltainen päätösvaltaan perustuva toisintaminen ei kuitenkaan ole saavuttanut järjestelmätoimittajien laajaa hyväksyntää, joten toteutukset ovat harvinaisia. 139
Tahdistamatta päivittävä toisintaminen Tahdistamatta päivittävässä toisintamisessa (asynchronous-update replication, asynchronous replication) eli laiskassa toisintamisessa (lazy replication) transaktion T päivittäessä tietoalkiota x toisinteiden valvonta päivittää T :n sisällä x:n joitakin muttei kaikkia toisinteita. Useimmiten vain yksi x:n toisinne päivitetään T :n sisällä. Muut toisinteet päivitetään erillisten toisinteiden ylläpitotransaktioiden toimesta vasta T :n sitouduttua. Toisinteet pidetään siis korkeintaan heikosti keskinäisesti johdonmukaisina. Toisinteiden myöhemmät päivitykset herätetään T :n sitoutumiskäytännön yhteydessä tai suoritetaan aika ajoin tiettyinä kiinnitetyinä ajankohtina. 140
Koska osa toisinteiden päivityksistä siis tapahtuu päivittävän transaktion ulkopuolella, ei tietokannan eheyttä voida taata. Esimerkki. 1. Transaktio T kirjoittaa x:n toisinteen pisteessä s 1 ja y:n toisinteen pisteessä s 2 ja sitoutuu kaksivaiheisesti (osalliset s 1 ja s 2 ). 2. Transaktio T lukee x:n toisinteen pisteestä s 3 ja y:n toisinteen pisteestä s 2 ja sitoutuu. T siis lukee x:n vanhan ja y:n tuoreen arvon, ts. mahdollisesti näkee tietokannan epäjohdonmukaisena. 3. Toisinteiden ylläpitotransaktio T päivittää x:n ja y:n kaikki toisinteet, mukaan lukien y:n toisinteen pisteessä s 3. 141
Toisintamisen yhteydessä sieppauksella (capture) tarkoitetaan prosessia, jolla toisinteiden valvonta tunnistaa toisinnetun tietoalkion päivityksen tapahtuneen. Sieppaus voidaan toteuttaa kahdella tavalla: (1) Tietokannan lokia tarkkaillaan ja toisinnettuihin tietoalkioihin kohdistuneet päivitykset merkitään muistiin. (2) Tietokantaan asennetaan herättimiä (trigger) toisinnettuihin tietoalkioihin kohdistuvien päivitysten kirjaamiseksi. Siepatut päivitykset levitetään (propagate) myöhemmin toisinteisiin. 142
Eri sovelluksilla on erilaiset vaatimukset tahdistamattomalle toisintamiselle. Joissakin tapauksissa on tarpeen pitää toisinteet mahdollisimman tahdissa, vaikkei globaalia sarjallistuvuutta taatakaan. Tavoitteena on minimoida aikaväli, jona tietoalkion yhtä toisinnetta päivitetään ja päivitys saadaan levitetyksi muihin toisinteisiin. Hajautettu sovellus, joka ylläpitää tili- tai asiakaspalvelutietoa saattaa kuulua tähän sovellusryhmään; puhutaan ryhmä-, vertais- tai moniisäntätoisintamisesta. Toisissa sovelluksissa tiukka tahdistaminen ei ole ratkaisevaa. Yrityksellä saattaa olla laaja myyntiorganisaatio kentällä, josta aika ajoin otetaan yhteys päätoimipisteeseen ja kopioidaan sen tietokannasta kohtuullisen ajantasainen näkymä. Tässä tapauksessa usein käytettävää toisintamista kutsutaan pääkopiotoisintamiseksi. Kolmas toisintamisen muoto, proseduraalinen toisintaminen, soveltuu tapauksiin, joissa hyvin suuri määrä tietoa päivitetään. 143
Pääkopiotoisintaminen Pääkopiotoisintamisessa (primary-copy replication) eli isännältä orjalle toisintamisessa (master-slave replication) tietoalkion toisinteista yksi nimetään tietoalkion pääkopioksi (primary copy) ja sen sijaintipiste pää- eli isäntäpisteeksi (primary site, master site); muita toisinteita kutsutaan oheiskopioiksi eli toissijaisiksi kopioiksi (secondary copy) ja niiden sijaintipisteitä oheis- eli orjapisteiksi (secondary site, slave site). Oheiskopioita luodaan tilaamalla (subscribe) pääkopioon tehtävät päivitykset. Transaktio voi lukea minkä tahansa toisinteen mutta päivittää vain pääkopiota. Eräässä pääkopiotoisintamisen toteutuksessa transaktion T on hankittava kirjoituslukko tietoalkion x pääkopioon halutessaan päivittää x:ää, ja T :n on myös päivitettävä pääkopio heti. Vain x:n pääkopio riittää päivittää. Vaikka x:stä olisi oheiskopio T :n suorituspisteessä, sitä ei päivitetä välittömästi. Jos siis kaksi transaktiota haluaa päivittää x:ää, toisen täytyy sitoutua ja vapauttaa x:n pääkopion kirjoituslukko ennen kuin lukko voidaan myöntää toiselle. Transaktioiden kirjoitusoperaatiot näin ollen sarjallistuvat, mutta lukuoperaatiot eivät. 144
Toisessa toteutuksessa sovellus (pääkopion kirjoituslukon saatuaan) yksinkertaisesti lähettää pääkopion sijaintipisteeseen pääkopion päivitykset myöhemmin toteutettaviksi. T :n päivitykset x:n oheiskopioihin levitetään tahdistamatta ja epäsarjallistuvasti T :n sitouduttua. Koska T ja päivitysten levitys oheiskopioihin eivät muodosta yhtä eristettyä kokonaisuutta, toisinteet päivitetään epäsarjallistuvasti. Koska lukuoperaatio voidaan tyydyttää mielivaltaisesta toisinteesta, samanaikaiset transaktiot saattavat nähdä epäjohdonmukaisen näkymän tietokannasta ja niin muodoin toimia väärin. 145
Pääkopiotoisintamisessa kaikki päivitykset kanavoidaan tietoalkioiden pääkopioiden kautta. Kun T päivittää x:ää, x:n pääkopion sijaintipiste suorittaa toisinteen ylläpitotransaktion tai -transaktioita levittääkseen T :n päivitykset T :n sitouduttua. Yksi ylläpitotransaktio voi päivittää kaikki toisinteet tai kunkin toisinteen päivittämistä varten voidaan käynnistää oma transaktio. Jos toisinteiden ylläpitotransaktiot suoritetaan kussakin pisteessä samassa järjestyksessä kuin pääkopiota päivitetään, taataan toisinteille heikko keskinäinen johdonmukaisuus. 146
Pääkopiotoisintamisen eräässä muunnelmassa pisteen s i transaktio T, joka haluaa päivittää tietoalkion x, josta on paikallinen oheiskopio, kirjoituslukitsee sekä paikallisen toisinteen että pääkopion ja päivittää molemmat osana transaktiota. Muut oheiskopiot päivitetään kuten edellä T :n sitoutumisen jälkeen. Menettelyn etuna on, että pisteessä s i toimiva sovellus voi suorittaa uusia, x:n paikallisen toisinteen lukevia transaktioita tarvitsematta odottaa T :n päivityksen leviämistä pääkopiosta takaisin s i :hin. 147
Päivitykset voidaan levittää vaihtoehtoisesti myös niin, että kunkin pisteen toisinteiden valvontajärjestelmä aika ajoin yleislähettää (broadcast) pääkopioittensa nykyarvot muihin pisteisiin. Yleislähetyksen pitäisi olla transaktiojohdonmukainen, niin että siihen sisältyy kaikki viime yleislähetyksen jälkeen sitoutuneiden transaktioiden päivittämät pääkopiot. Joissakin toteutuksissa kukin oheispiste voi esitellä näkymän pääkopioon, jolloin ainoastaan tämä näkymä lähetetään. Tämä on erityisen hyödyllistä, kun oheispiste kommunikoi pääpisteen kanssa hitaan yhteyden välityksellä, jolloin on tärkeää, että kuhunkin pisteeseen toisinnetaan vain tarpeellinen tieto. 148
Edellä esitetyt päivitysten levitysmenetelmät ovat kaikki työntöstrategioita (push strategy) siinä mielessä, että pääpiste automaattisesti työntää tietoalkion päivityksen oheispisteisiin. Työntöstrategialle vastakkaisessa vetostrategiassa (pull strategy) päivityksiä ei levitetä automaattisesti pääpisteestä oheispisteisiin, vaan kunkin oheispisteen pitää vetää tieto pääpisteestä eli eksplisiittisesti pyytää näkymänsä virkistämistä (view refresh). Vetostrategia on erityisen sopiva tapauksissa, joissa oheispiste on vain silloin tällöin kytkeytyneenä verkkoon, kuten esim. liikkuva (käsivarainen) työasema. 149
Myyntimies päivittää koneessaan säilytettävät oheiskopiot kytkeydyttyään verkkoon. Koska kaistanleveys on pieni, hän määrittelee näkymän, joka sisältää ainoastaan hänen myyntialuettaan koskevaa tietoa. Tässä sovelluksessa toisinteet saattavat olla jonkin verran (minuutteja tai tunteja) vanhoja. Lukuoperaatiot ovat vallitsevia. Kirjoitusoperaatioita esiintyy vain silloin, kun uusi sopimus allekirjoitetaan, ja uusi tieto lähetetään ensin pääpisteeseen, josta se vedetään myöhemmin oheispisteisiin. Oheispisteen näkymään vaikuttava päivitys, joka tehdään oheispisteen ollessa irti verkosta, pitää säilyttää, kunnes oheispiste jälleen kytkeytyy verkkoon. 150
Ryhmätoisintaminen Pääkopiotoisintamisessa vain tietoalkion pääkopiota voitiin päivittää. Ryhmätoisintamisessa (group replication) eli moni-isäntätoisintamisessa (multimaster replication) eli missä tahansa päivittävässä toisintamisessa (update-anywhere replication) päivitys voidaan kohdistaa mihin tahansa toisinteeseen, oletettavasti lähimpään. Jos tietokanta on täysin toisinnettu, sekä päivitys- että lukutransaktiot voidaan saada päätökseen operoimalla ainoastaan paikallisen pisteen tietoihin. Transaktion tekemät päivitykset levitetään myöhemmin muihin toisinteisiin. Levittäminen on tahdistamatonta, joten globaalia sarjallistuvuutta ei voida taata. 151
Ellei päivityksiä levitetä oikeassa järjestyksessä, menettely ei takaa heikkoakaan keskinäistä johdonmukaisuutta. Esim. Täysin toisinnetussa tietokannassa on pisteet s 1, s 2, s 3 ja s 4. Piste s 1 : Piste s 2 : Piste s 3 : Piste s 4 : päivitys T 1 : W[x]; päivitys T 4 : W[x]; T 1 :W[x]:n lähetys T 4 :W[x]:n lähetys pisteisiin s 2,s 3,s 4 ; pisteisiin s 1,s 2,s 3 ; T 4 : W[x] s 4 :stä; T 1 : W[x] s 1 :stä; T 4 : W[x] s 4 :stä; T 4 : W[x] s 4 :stä; T 1 : W[x] s 1 :stä; T 1 : W[x] s 1 :stä; Kuten tässä, päivitysten saapumisjärjestys voi vaihdella eri pisteissä. Toisinteen lopullinen arvo on viimeisen päivitysviestin sisältämä arvo, joten toisinteet eivät säily keskinäisesti johdonmukaisina. Toisintamisen terminologiassa sanotaan konfliktin sattuneen ja että toisinteiden valvontajärjestelmän pitää soveltaa jotain konfliktinratkaisustrategiaa (conflict-resolution strategy) toisinteiden konvergenssin takaamiseksi ja keskinäisen johdonmukaisuuden säilyttämiseksi. 152
Toisinteiden heikko keskinäinen johdonmukaisuus voidaan taata algoritmilla, joka liittää yksilöivän aikaleiman jokaiseen päivitykseen ja jokaiseen toisinteeseen. Päivityksen aikaleimana on ajankohta, jona päivitystä pyydettiin. Toisinteen aikaleimana on siihen viimeksi sovelletun päivityksen aikaleima. Heikko keskinäinen johdonmukaisuus voidaan taata siten, että toisinteen sijoituspiste yksinkertaisesti hylkää saapuvan päivityksen, jos sen aikaleima on toisinteen nykyistä aikaleimaa pienempi. Kunkin toisinteen arvo konvergoi lopulta suurimmalla (eli tuoreimmalla) aikaleimalla varustetun päivityksen arvoon. Päivitysten menetykset ovat kuitenkin mahdollisia: kaksi transaktiota kumpikin lukevat ja kirjoittavat saman tietoalkion eri toisinteet, mutta vain yhden tuottama tulos jää voimaan. Algoritmi ei siis ole sopiva kaikkiin sovelluksiin. 153
Joissakin sovelluksissa sopiva konfliktinratkaisustrategia on ilmeinen. Jos esimerkiksi hakemisto on toisinnettu ja samanaikaiset transaktiot lisäävät eri hakusanoja hakemistoon, hakemiston kaikkien toisinteiden lopullisen arvon pitää sisältää molemmat hakusanat. Konfliktinratkaisustrategia tiettyyn sovellukseen onkin usein mahdollista suunnitella. Yleisessä tapauksessa toisinteiden valvontajärjestelmä voi ilmoittaa käyttäjälle havaitsemastaan konfliktista ja antaa käyttäjän ratkaista se. Koska ei ole olemassa yleistä oikeellista konfliktinratkaisustrategiaa, jotkin kaupalliset järjestelmät tarjoavat useampia vaihtoehtoisia erikoistrategioita, kuten vanhin päivitys voittaa (oldest update wins), nuorin päivitys voittaa (youngest update wins), korkeimman prioriteetin pisteen päivitys voittaa (update from the highest priority site wins) ja käyttäjä antaa konfliktinratkaisumenetelmän (user provides a procedure for conflict resolution). 154
Oraclen toisintamiskäytännöt Oraclessa toisinnetun tietokannan päivitykset kohdistuvat isäntäpisteeseen (master site), josta päivitykset leviävät orjapisteisiin (slave site). Orjapisteet on yhdistetty isäntäpisteisiin tietokantalinkein. Oraclen standardiversiossa isäntäpisteitä voi olla vain yksi, mutta yritysversiossa isäntäpisteitä voi olla useita ja päivitykset voivat kohdistua mihin tahansa niistä. Toisinnettavat tietoalkiot voivat olla relaatiotietokannan tauluja, näkymiä, herättimiä, tietokantaproseduuripakkauksia, hakemistoja tai synonyymejä. Yksinkertaisimmillaan isäntäpisteen tietoa toisinnetaan orjapisteeseen luomalla orjapisteeseen transaktiojohdonmukainen tilannevedos (snapshot) jostakin isäntäpisteen taulusta tai näkymästä. Tilannevedos on transaktiojohdonmukainen (transaction-consistent), so. siinä on mukana sitoutuneiden transaktioiden päivitykset johonkin transaktioon asti sarjallistuvuusjärjestyksessä, muttei minkään myöhemmän transaktion päivityksiä. 155
Tilannevedos voi olla luku- tai päivityskelpoinen. Lukukelpoinen tilannevedos (read-only snapshot) on orjapisteessä sijaitseva, isäntäpisteen tietokannasta laskettu materiaalistettu näkymä, joka aika ajoin virkistetään (refresh) eli saatetaan ajan tasalle johdonmukaiseksi isäntäpisteen päivitysten kanssa. Päivityskelpoinen tilannevedos (updatable snapshot) luodaan samaan tapaan kuin lukukelpoinen tilannevedos, mutta tilannevedoksen sijaintipiste voi myös päivittää vedosta ja lähettää päivityksiään aika ajoin takaisin isäntäpisteeseen. 156
Esim. verkkokaupan Helsingin varastopisteen asiakaskunnan asiakastiedot sisältävä palanen päätoimipisteen taulusta customer(customer-number, name, address, location) lukukelpoisena tilannevedoksena: create snapshot customer refresh fast start with sysdate next sysdate + 7 with primary key as select from customer@hq.grocer.com where location = Helsinki ; Tilannevedoksen virkistystapana on tässä nopea (fast), ja vedos tulee virkistää viikon välein alkaen vedoksen luontipäivästä. Vedoksen luontipisteeseen järjestelmä luo taulun snap$ customer, joka on isäntäpisteen taulun customer kaavion mukainen, sekä tauluun snap$ customer määritellyn näkymän customer. 157
Tilannevedoksen virkistystapoja on kolme: täydellinen, nopea ja pakotettu virkistys. (1) Täydellisessä virkistyksessä (complete refresh) tilannevedos virkistetään laskemalla koko vedoksen määrittelevä kysely uudestaan isäntäpisteessä ja sijoittamalla kyselyn tulos vedoksen sijaintipisteeseen, jossa se korvaa vedoksen entisen sisällön. (2) Nopeassa virkistyksessä (fast refresh) vedos virkistetään vähittäin (incrementally), so. identifioimalla isäntäpisteen tauluun edellisen virkistyksen jälkeen tulleet muutokset ja soveltamalla ne vedokseen. (3) Pakotetussa virkistyksessä (force refresh) yritetään ensin nopeaa virkistystä; jos tämä ei ole mahdollista, suoritetaan täydellinen virkistys. 158
Nopea virkistys on mahdollista vain, jos isäntäpisteen tauluun on määritelty erityinen tilannevedosloki (snapshot log): create snapshot log on customer with primary key tablespace... Tilannevedoslokiin järjestelmä kirjaa (herättimen avulla) automaattisesti taulun jokaisesta päivityksestä (insert, update, delete) rivin, joka sisältää mm. päivityksen tyypin, päivitetyn attribuutin vanhan ja uuden arvon sekä päivityksen ajankohdan. 159
Oraclen moni-isäntätoisintamisessa (multimaster replication) taulu toisinnetaan useampaan isäntäpisteeseen, joissa kaikissa sitä voidaan päivittää. Toisinnuksessa isäntäpisteet esiintyvät toistensa vertaisina (peer), ja yhden isäntäpisteen toisinteeseen kohdistetut päivitykset levitetään toisiin. Päivitysten levitys voi olla tahdistettua tai tahdistamatonta. Tahdistetussa toisintamisessa päivitys levitetään kaikkiin muihin pisteisiin välittömästi saman transaktion sisällä (kaksivaiheista sitoutumista käyttäen). Tahdistamattomassa levityksessä päivityksiä lähetetään erissä päivittävän transaktion ulkopuolella sovellettaviksi muissa pisteissä. Konfliktien ratkaisuun Oracle tarjoaa joukon valmiita strategioita sekä antaa mahdollisuuden käyttäjälle kirjoittaa liiketoimintasääntöihinsä perustuvia strategioita. 160
Julkaisuun ja tilauksiin perustuva toisintaminen Microsoftin SQL-palvelimesta on peräisin julkaisuun ja tilauksiin perustuva toisintamismalli (publish-subscribe replication model). Julkaisija (publisher) on palvelin, joka asettaa tietoa muiden saataville, so. toisinnettavaksi muihin palvelimiin. Julkaisijalla voi olla yksi tai useampia julkaisuja (publication), joista kukin esittää loogisesti yhteenkuuluvan joukon tietoa ja tietokantaolioita. Julkaisun yksittäisiä oliota, kuten tauluja, tallennettuja proseduureja, käyttäjän määrittelemiä funktioita, näkymiä, materiaalistettuja näkymiä ynnä muita, kutsutaan artikkeleiksi. Lisättäessä artikkeli julkaisuun voidaan määritellä artikkelin toisinnustapa, ketkä käyttäjät voivat tilata artikkelin ja kuinka artikkelin sisältö suodatetaan taulusta vaakasuorasti (valinnalla) tai pystysuorasti (projisioimalla). 161
Tilaaja (subscriber) on palvelin, joka vastaanottaa toisinnettua tietoa julkaisijalta. Tilaajat voivat tilata vain niitä julkaisuja, joita tarvitsevat. Valituista toisinnusvaihtoehdoista riippuen tilaaja voi tyytyä joko lukukelpoiseen (read-only) toisinteeseen tai varata mahdollisuuden myös päivittää tilattuja artikkeleita, jolloin päivitykset levitetään automaattisesti artikkelin kaikkiin muihin toisinteisiin. Tilaaja voi myös julkaista uudelleen tilaamaansa tietoa. Jakelija (distributor) on palvelin, jota käytetään historia- ja virhetilatiedon tallennuspisteenä sekä etappivälitysjonona (store-andforward queue) mitoittamaan tilaajille toimitettavaa toisinnettua hyötykuormaa. 162
Tilannevedostoisintamisessa (snapshot replication) tilatun julkaisun artikkelit kopioidaan ja jaellaan vedoksen luontihetken sisältöisinä. Tilaajan tilannevedos virkistetään täydellisesti aika ajoin; vähittäistä virkistystä ei käytetä, joten myöskään mitään julkaisun muutosten jäljitystä (tilannevedoslokia tms.) ei tarvita. Päivityskelpoista tilannevedosta tilaaja voi päivittää ja levittää päivitykset takaisin julkaisijalle. Tilannevedostoisintaminen sopii parhaiten pieniin julkaisuihin ja tapauksiin, joissa päivitykset koskettavat niin suurta osaa tiedosta, että täydellinen virkistys on tehokasta. 163
Transaktionaalisessa toisintamisessa (transactional replication) julkaisija levittää julkaisun ensimmäisen tilannevedoksen tilaajille ja sen jälkeen toimittaa vähittäiset muutokset tilaajille erillisinä transaktioina tai komentoina. Julkaisun muutokset jäljitetään SQL-palvelimessa ytimessä, joka merkkaa toisinnettuja artikkeleita päivittäneet transaktiot julkaisijan tietokannan lokissa. Lokinlukija-agentiksi (log reader agent) kutsuttu prosessi lukee näin merkattujen transaktioiden kirjauksia lokista, mahdollisesti suodattaa osan niistä ja tallentaa suodattimen läpäisseet kirjaukset jakelutietokantaan, joka toimii etappivälitysperiaatteella toimivan transaktionaalisen toisintamisen pysyvänä jonona. Jakeluagentiksi (distribution agent) kutsuttu prosessi toimittaa muutokset edelleen kullekin tilaajalle. Kuten tilannevedostoisintamisessa, transaktionaalisessa toisintamisessa tilaaja voi tehdä päivityksiä, jotka joko peilataan julkaisijan tietokantaan tahdistetusti kaksivaiheisella sitoutumisella tai viedään jonoon levitettäväksi myöhemmin tahdistamatta julkaisijan tietokantaan. Transaktionaalinen toisintaminen sopii tilanteisiin, joissa on tarpeen säilyttää useiden päivitysten välitiloja. 164
Lomitustoisintamisessa (merge replication) kukin toisinne toimii täysin autonomisesti siitä riippumatta, onko toisinteen sijaintipiste verkkoon kykeytyneenä vai ei. Järjestelmä jäljittää julkaisu- ja tilauspisteiden julkaistuihin artikkeleihin tulleita päivityksiä, ja toisinnusagentti (replication agent) lomittaa päivitykset yhteen toisinteita tahdistettaessa ja takaa tiedon konvergenssin havaiten ja ratkaisten konfliktit automaattisesti. Toisinnusagentti sisältää lukuisia vaihtoehtoisia konfliktinratkaisukäytäntöjä, ja räätälöityjä ratkaisukäytäntöjä voidaan kirjoittaa mm. tallennettuja proseduureja käyttäen. Lomitustoisintamisessa ei levitetä kaikkia päivitysten välitiloja, vaan tiedon tila tahdistushetkellä. Lomitustoisintaminen sopii tilanteisiin, joissa toisinteiden pitää voida tehdä autonomisia päivityksiä ollessaan kytkettynä irti verkosta. 165
Etävarmistusjärjestelmät Etävarmistusjärjestelmä (remote backup system) on toisinnettu tietokantajärjestelmä, jonka tarkoituksena on suojata tavanomainen keskitetty tietokantajärjestelmä luonnonkatastrofeilta, kuten tulipalolta, tulvilta ja maanjäristyksiltä. Etävarmistusjärjestelmässä kaikki transaktionkäsittely tapahtuu yhdessä pisteessä, järjestelmän pääpisteessä (primary site), josta päivitykset sitten toisinnetaan etävarmistuspisteeseen (remote backup site). Toisinnus tapahtuu lähettämällä pääpisteen päivitysten lokikirjaukset etävarmistuspisteeseen ja toteuttamalla niiden perusteella päivitykset etävarmistuspisteen tietokantaan. Tällainen lokikirjausten välitykseen ja toistoon perustuva toisintaminen on huomattavasti tehokkaampaa kuin tavanomainen toisintaminen, sillä (1) kaksivaiheista sitoutumista ei lainkaan tarvita ja (2) päivitettävän tietoalkion hakupolun pituus on mahdollisimman lyhyt: lokikirjauksesta saadaan suoraan tietoalkion sisältävän sivun tunniste. 166
Etävarmistuspiste pidetään pääpisteestä fyysisesti erillään, eri paikkakunnalla, jolloin pääpisteen sijaintipaikassa tapahtuva katastrofi ei vahingoita etävarmistuspistettä. Kun pääpiste joutuu häiriötilaan, etävarmistuspiste ottaa transaktionkäsittelyn hoitaakseen. Sitä ennen etävarmistuspiste suorittaa elvytyksen käyttäen omaa (epäajantasaista) toisinnettaan tietokannasta sekä pääpisteeltä saatuja lokikirjauksia. Etävarmistuspiste suorittaa likipitäen samat elvytystoimenpiteet kuin pääpiste suorittaisi, mikäli elpyisi häiriöstä. Kun elvytys on valmis, etävarmistuspiste ryhtyy ottamaan vastaan uusia transaktioita. Jotta katastrofitilanteessa transaktionkäsittely saataisiin mahdollisimman pian uudelleen käyntiin, on etävarmistuspisteen jatkuvasti sovellettava pääpisteeltä saamiaan lokikirjauksia omaan toisinteeseensa tietokannasta ja otettava myös tarkistuspisteitä riittävän usein. 167
Jotta sitoutuneen transaktion päivitykset jäisivät pysyviksi pääpisteen katastrofista huolimatta, transaktiota ei saisi julistaa sitoutuneeksi ennen kuin sen lokikirjaukset ovat ehtineet etävarmistuspisteeseen. Tämä taas hidastaa transaktion sitoutumista. Eräät järjestelmät sallivatkin alempiasteisen pysyvyyden. Pysyvyysasteet (degrees of durability) luokitellaan seuraavasti: (1) Epävarma (one-safe): transaktio sitoutuu heti kun sen sitoutumistietue on viety pääpisteen lokilevylle. (2) Varma (two-safe): transaktio sitoutuu vasta kun sen sen sitoutumistietue on viety pääpisteen lokilevylle ja lisäksi, mikäli etävarmistuspiste on aktiivisena, myös sen lokilevylle. (3) Hyvin varma (two-very-safe): transaktio sitoutuu vasta kun sen sitoutumiskirjaus on viety sekä pääpisteen että etävarmistuspisteen lokilevylle. 168