SQL replitseerimine

SQL replitseerimises võib olla olukord, kus üks server on nn master, teine samuti master või nn slave. Esimesel serveril lubatakse binlog (binaarsed logid) ning teine server loeb (kui selleks võimalus avaneb) esimese binlogist (binaarne logi) vastavad muudatused (baasi tehtud muudatused, insertid, updated, deleted, jne), mis baasi on tehtud. SQL serveri replitseerimiseks võib olla master-master lahendus, mis tähendab, et võib nii lugeda kui kirjutada mõlemasse masinasse samaaagselt. Idee poolest vähemalt.

Kui on tegemist master-to-master replikatsiooniga siis loetakse üksteise baasi binlogist muudatusi. Unexpected shutdown ei sobi kummalegi poolele, sest kui infot ei jõuta kettale kirjutada või ei jõuta binlogist andmebaasi voolukatkestuse ajal kirjutada siis läheb baas sünkroonist välja (või kui ketas saab täis, virtuaalmasin hangub, vms). Teoreetiliselt lihtsalt teise masteri offline olek või korraks võrgust kadumine ei ole probleem – praktikas põhjustab see aeg-ajalt tuntavaid probleeme ikkagi.

Master-to-master lahenduses antakse igale automaagiliselt suurenevale ID’le erinev number (autoincremental) vastaalt seadistusele – st iga lisatud kirje saab autoincrementiga numbri. St üks server näiteks kasutab ID’sid 1,11,21,31,41 ning teine 2,12,22,32,42 – selliselt välditakse konfliktide tekkimist. Sisuliselt master-to-master on lahendus, kus mõlemale hostile öeldakse, et ta on teise hosti slave. Ning erinevaid “kirjutisi” saaks nii ID järgi eraldada. Vastav applikatsioon peab toetama ID’sid mis ei suurene järjest. Replitseerimine võib ka toimida nii, et replitseeritakse näiteks viite erinevasse baasi andmeid.

Logid võiks panna aeguma mõistliku aja jooksul (sõltuvalt kui kiiresti vahetatakse teine host) ning kui palju on kettal ruumi. Näiteks 30 päeva (võib ka suuremaks teha, sõltuvalt äri vajadustest). Samuti võiks logifailide suurus olla väiksem ning baasi kirjutamine tihedam – muidu suure muudatuse baasi kirjutamine võib tekitada korraks olukorra, kus baas on hästi aeglane (korraks). Samuti võiks kõik muudatused kohe korraga kettale kirjutada (kui jõudu on) – muidu voolukatkestusel jääb osa asju baasi ühes või teises hostis kirjutamata ning baasid lähevad syncist välja. Sama teema on relay logi’ga.

Master (a) kirjutab binlog’i, teine masin loeb binlogist ja kirjutab enda relay logi ning siis teine masin (b) võtab relay logist (binlogi koopia nimetusteises masinas) ja kirjutab baasi. Peale binlogi kirjutamist öeldakse (b) slavele, et nüüd võib hakata andmeid võtma.

Üdiselt m2m ja m2c konfiguratiooni kasutamisel peab olema väga teadlik, et mida ja kuidas teha. Samuti peaks ka teadma, et mis juhtus (kui midagi maha jookseb) ning kuidas peaks edasi toimima (näiteks, kas proovida master masin uuesti ellu äratada või taastada backupist sõltuvalt mis seisus töö seisma jäi). Üldiselt on hea m2m lahendusi monitoorida. Monitoorida nii riistvara, virtuaalmasinaid ja selle ressursse ning ka SQL baasi ennast (kas sünkroonis, jne)

Ikkagi, “turvalisem” lahendus oleks teha master to slave replitseerimine ning selle asja ja ajakohasust siis monitoorida – ja failoveri puhul siis käsitsi ringi lülitada ning enne kontrollida üle, et kas baas on up to date või peab backupist taastama. Kui on aga vaja uptime’i ja veakindlust siis tuleks mõelda SQL Clustering peale.

Lugemist:

  1. https://dev.mysql.com/doc/refman/5.7/en/replication-configuration.html
  2. https://www.vpsserver.com/community/tutorials/9/setup-a-master-to-master-replication-between-two-mariadb-servers/
  3. https://computingforgeeks.com/how-to-configure-mariadb-replication-on-ubuntu-18-04-debian-9/
  4. https://www.percona.com/blog/2011/01/12/conflict-avoidance-with-auto_increment_incremen-and-auto_increment_offset/
  5. http://dev-ops.net/page/34/?Itemid=rqxvslgr
  6. https://galeracluster.com/products/
  7. https://mysql-mmm.org ja https://mysql-mmm.org – SQL replication monitoorimiseks
  8. https://mariadb.com/kb/en/library/what-is-mariadb-galera-cluster/ – Clusterist infot – MyISAM suppordiga (InnoDB ei tööta).