În 9.4, a apărut o replicare logică. Deci, de la 9.4 la 9.5 va fi posibil să se actualizeze foarte ieftin (cel puțin așa ar trebui să fie). Actualmente actualizarea versiunii majore a PostgreSQL este o durere. În forma cea mai obișnuită se arată astfel:
- Este necesar să stingeți complet masterul și să trageți pg_upgrade.
- Scoateți cu noua versiune numai de comandant.
- Faceți o copie de rezervă completă cu ajutorul expertului actualizat.
- Redenumiți toate replicile din noua copie de rezervă.
Avem baze într-o unitate de terabytes, fiecare shard din care constă din trei mașini - un maestru și două replici. O parte semnificativă a solicitărilor de lectură duce la replici. Și există baze în care știm cum să supraviețim morții unei singure remarci. Ie dacă ambele replici mor, un maestru nu va scoate toată sarcina de scriere și citire. Și să faci o copie de rezervă completă în câteva terabytes și să o folosești la cel puțin o replică pe noapte nu este cea mai ușoară sarcină.
Ray de speranță
Când am fost pe cale să fie actualizate în noaptea de sâmbătă spre duminică și să sufere, Bruce Momjian a trimis un patch la documentația care vă permite să efectuați și actualiza toate replicile fără perenalivki din copia de rezervă. Plastura este aplicată în cele din urmă comandantului, adică documentația pentru 9.5 are deja pașii necesari.
Singurul dezavantaj al acestei soluții este faptul că, la momentul actualizării, toate mașinile de tip cluster ar trebui să fie stinse (adică baza de date nu este disponibilă chiar și pentru citire). Nu ne-a plăcut nici această restricție, pentru că am decis să facem ceva diferit.
punerea în aplicare
Din moment ce avem câteva zeci de baze, nu am vrut să actualizăm mâinile pe fiecare dintre ele, pentru că am scris un script simplu pentru asta. În același timp, scenariul este foarte prost - în caz de orice problemă, acesta cade imediat și este necesar să-l terminăm cu mâini suplimentare.
Din moment ce scenariul este strâns legat de infrastructura noastră, public doar câteva fragmente din ea, reflectând esența. Secvența generală este destul de simplă (am pus pachetele pe toate mașinile 9.4, actualizăm asistentul, rsync pe fiecare replică, scoatem masterul):
Această secvență prelungește durata de viață numai în citire (expertul poate fi eliminat după actualizarea primei replici), dar elimină complet necesitatea reconfigurării replicilor din copii de rezervă.
Actualizați asistentul
Actualizați expertul, probabil cea mai intensă etapă:
La început pg_upgrade -check se face și dacă există probleme, atunci totul se întoarce la loc. Acesta este singurul loc în care se întâmplă acest lucru. În toate celelalte cazuri, scriptul scade.
Apoi trage fișierele noastre de configurare și master este închis de un paravan de protecție replici, deoarece (surpriza!) O replica cu 9.3 poate trage pentru a schimba master la 9.4. Nimic bun nu este adevărat, nu se va termina.
Important este faptul că din momentul în care pgbouncerul se oprește pe comandant, toată încărcătura este turnată în replici, adică clusterul se degradează numai la citire.
Actualizarea replicilor
Actualizarea replicilor are loc secvențial:
În funcția însăși, în general, nimic nu se face cu excepția rsyns:
Ultimul pas creează recuperarea corectă. Pentru a roti replica la masterul corect.
După ce prima replică este actualizată, ea este deschisă pentru încărcare, iar în acest moment cea de-a doua este închisă și actualizată. Aceasta este cea mai grea etapă de renovare, deoarece comandantul este închis, replica cu 9.3 închisă și singura mașină care servește sarcina - replica cu 9.4, care nu are nici un statistici (din păcate, nu pg_upgrade tolera Statistică).
După actualizarea tuturor replicilor, expertul se deschide pentru încărcare.
În acest moment, toate cele trei mașini sunt disponibile pentru întreținerea încărcăturii. Dansul, bucuria.
Am actualizat câteva zeci de fragmente de la 9.3.6 la 9.4.1, cu citirea fiecăruia mai puțin de trei minute. Cioburi pe o pereche a urcat efecte speciale, script-ul și a scăzut deoarece a fost necesar să se actualizeze mâinile lor, ci o secvență clară a măsurilor și acțiunilor mâinile au venit în jos pentru a face același lucru, ceea ce este scris în scenariu. Timpul, cu toate acestea, acest lucru, desigur, a durat mai mult, aproximativ 7 minute pe shard.
Iar dulcelui, voi spune că am făcut deja un gest rar. un patch cu soluția pe care Tom Lane a hackat în 38 de minute (!) de la crearea raportului de eroare. Acest lucru este foarte cool.
Articole similare
Trimiteți-le prietenilor: