Acu ceva vreme am instalat la niste oameni niste multe servere de MSSQL pentru niste chestii de logistica.
Anul asta au zis oamenii ca bai, e important sa nu pierdem datele pe care le avem pe servere si hai sa facem un backup offsite.
Backup-ul offsite n-a fost sa fie ca latenta si TCP e picky cu latenta cand vrei sa transferi single-connection fisiere mari si eram intr-o situatie din aia in care dura mai mult de-o zi sa transfer un fisier de backup (mind you, gigabit in ambele parti, da TCP…). “Stiintific” treaba asta se cheama “long fat pipe problem” si necesita un pic de inginerie sa mearga cum trebuie, da’ in cazul de fata n’aveam ce inginerie sa fac ca tehnologia era la impuse.
Long story short, zic hai ca am solutia: facem replicare intre servere de MSSQL si o sa fie aproape realtime datele, eventual o sa se mai piarda cateva tranzactii, da’ nu e un capat de lume.
Si ma apuc eu si instalez un SQL server in alta parte si da-i sa fac replicare. Ma gandeam eu ca e la MySQL undeva faci un master/slave, restaurezi un backup pe ala remote si dupa aia trimiti binlog-urile pe al doilea sa le face replay si aia e. Simplu.
Well… not really, ca Microsoft fiind Microsoft au zis ca de ce sa fie simplu cand poate sa fie complicat si nu poti face replicare asa simplu. Ca de exemplu daca ai tabele fara primary key nu le poti include in replicare. Procedurile stocate nu se replica, because reasons…
Multa muie lor pe tema asta ca mi-au scos peri albi.
Zic bine, facem transaction log shipping care “replica” tot. O sa fie baza de date remote un pic in urma, da’ a zis lumea ca poate trai si daca se pierd 30min de date.
Acum, astia cu logistica sunt mai speciali… cam ca niste autisti de speciali, si ei nu cred in versiuni prea noi de software si asa am ajuns eu sa am si MSSQL 2014 si 2016, ca fiecare producator are versiunea lui de baza de date “suportata”.
Mno, acu aveam servere din astea diferite, zic hai ca pun MSSQL 2017 in locatia remote si stochez acolo toate bazele de date ca fiecare baza de date un Compatibility Level care e in functie de versiunea de SQL Server, gen 2014, 2016 si 2017.
Instalez eu serverul vietii, dau sa setez transcation log shipping: nu se poate prietene ca trebuie upgradata versiunea de baza de date pe serverul remote si ghinion ca tu ai o versiune mai veche. Morti si raniti si muie alora de-au programat mizeria asta.
Se pare ca desi poti bifa acolo Compatibility Level, intern MSSQL mai modifica un pic baza de date ca sa fie compatibila cu noul engine de SQL, da’ la suprafata se comporta ca ala vechi…
Alte ore pierdute aiurea, da-le-as muie la imbecilii pulii. Pai orice esti backward compatible ori nu esti.
Zic bine, hai ca pun un 2014 remote sa se impace cu 2014 local. Pun serverul pulii, setez acolo replicarea, face primul backup mare de pe sursa, il copiaza super repede pe destinatie si imi da prin gura: n-ai destul loc pe C:\ ca sa restaurez baza de date pe destinatie. Mi-au scapat instant multe mui inspre Microsoft pe tema asta…
Asta desi din setup era configurat sa tina bazele de date pe alt disk cu suficient de mult spatiu. Dar nu, el vrea musai pe C:\ pentru ca ma gandesc eu ca acolo are setat “Instance Root Directory” si simte nevoia s-o puna acolo desi ar trebui s-o puna in alta parte.
Varianta complicata a fost sa fac eu un backup full la o baza de date, s-o copiez in 3 ore in partea ailata si s-o restaurez unde trebuie si abia dupa aia sa setez transaction log shipping pe sursa si sa-i zic la sursa ca deja exista baza de date in partea ailalta.
Asta era azinoapte. Dupa un pic de investigatii descoperii ca de fapt nu merge log shipping.
Banuiesc ca e din cauza ca pana s-a copiat baza de date si s-a restaurat a trecut prea mult timp pe sursa si logurile pe care le genereaza nu au logica pe destinatie ca’s la prea mare distanta in timp.
Back to the drawing board. Sa moara in chinuri aia de la MS care in loc sa faca un setup simplu, l-au complicat pana i-au scos mucii pe cur. Unfuckingbelieveable…
(Cateva zile mai tarziu…)
Dupa un pic de desenat am descoperit cum pot sa-l fac sa restaureze baza de date unde trebuie. La Restore are niste optiuni semi-ascunse in care ii zici unde sa restaureze baza de date si unde sa restaureze logurile. La asta cu restauratul evident ca nu e simplu: baza da date pe sursa se cheama ABC si are doua fisiere mari si late: ABC.MDF si ABC_LOG.LDF (baza de date propriuzisa si logurile). Eh, cand le faci restore in alta parte, poti sa schimbi numele bazei de date – asa cum am facut eu, ca poate vrei s-o prefixezi cu ceva. Catch-ul e ca numele de pe disk al fisierelor nu se schimba in noul prefix, gen baza sa fie LS-ABC si fisierele sa se cheme LS-ABC.MDF si LS-ABC_LOG.LDF… Pai ce erau prosti sa-l schimbe? Nu, pe disc ramane la fel. Si daca ai doua servere din medii diferite de productie si cu acelasi nume de baza de date si vrei sa faci log shipping de pe ambele pe un singur server… ghici ce… la a doua restuare o sa-ti dea eroare ca deja exista baza de date si ca bla bla e folosita. Si trebuie sa faci alte directoare pentru baza si pentru loguri ca sa poti face log shipping si pentru al doilea server…
Problema de dinainte era din cauza ca aveam alte job-uri de log backup si MSSQL asta nu e asa inteligent sa nu amestece oalele, si se facea backup la loguri din 2 in 5 si evident ca unele loguri era salvate undeva si alte altundeva si pula continuitate in loguri si n-avea ala la ce sa faca restore.
Fixat asta, dat backup/restore si log shipping si pare sa mearga. Trebuie sa stau cu geana pe el sa vad ca nu sughita, sa dau un reboot pe ici pe colo sa vad cum face cand se mai pierde sursa sau destinatia un pic.
Sa-i chis in freza pe astia de la Microsoft si mai ales pe aia de scriu la MSSQL ca au gandit diverse chestii din puta gandirii…
