Kako migrirati bazu podataka na linuxu bez prekida rada

Zašto migrirati bazu podataka bez prekida i šta to podrazumeva

Kada planiraš migraciju baze podataka na Linux server — bilo zbog zamene hardvera, nadogradnje distribucije, prelaska na novi storage ili promene DBMS verzije — cilj ti je da korisnici i aplikacije nastave da rade bez prekida. Migracija bez prekida znači očuvanje konzistentnosti podataka, minimalan uticaj na performanse i neprimetna promena konekcija za aplikacije. Ako ne pripremiš sve kako treba, može doći do zastoja, gubitka podataka ili potrebe za hitnim vraćanjem na staro stanje.

Ključni benefiti migracije bez prekida

Ne prekidaš proizvodne procese i poslovne tokove.
Smanjuješ rizik od ljudskih grešaka tokom kritičnih satnica.
Možeš postepeno testirati i validirati novu okolinu bez hitnih rollback procedura.

Pripremni koraci koje moraš obaviti pre migracije

Bez dobrog planiranja, nijedna migracija neće biti bezbolna. Fokusiraj se na inventar, kompatibilnost i test okruženje. Evo šta treba da uradiš pre nego što kreneš sa tehničkom implementacijom:

Napravi potpuni inventar: verzija DBMS-a, veličina baze, broj tabela, tipovi indeksa, složene transakcije i dugotrajne upite.
Proveri kompatibilnost: SQL dijalekti i funkcije između trenutne i ciljne verzije (npr. MySQL/MariaDB, PostgreSQL). Obrati pažnju na promene u ponašanju transakcija, tipove podataka i rezervisane reči.
Izračunaj performanse i I/O zahteve: da li novi server/ssd ima dovoljnu propusnost i IOPS za tvoje radno opterećenje?
Proveri privilegije korisnika: da li su role i pristupi identični u novom okruženju?
Plan za backup i rollback: sinhroni snapshot, log shipping ili kompletan dump — moraš znati kako brzo vratiti stanje ako nešto krene po zlu.
Postavi testno okruženje: reprodukuj produkciju, pokreni stres testove i simuliraj prekid mreže/čvora.

Izbor strategije: replikacija i proxy sloj za bezprekidnu migraciju

Za migraciju bez prekida obično se oslanjaš na replikaciju podataka i proxy koji upravlja konekcijama. Neke opšte strategije:

Fizička (streaming) replikacija: idealna za PostgreSQL ili binlog replikaciju u MySQL — sinhronizuje podatke na nivou fajla/bloka i omogućava prebacivanje bez gubitaka.
Logička replikacija: korisna kada menjaš verziju DBMS-a ili želiš selektivnu migraciju tabela.
Proxy sloj (HAProxy, ProxySQL, PgBouncer): omogućava preusmeravanje konekcija sa stare instance na novu bez izmene aplikacionog koda.
Alati za online schema changes: gh-ost, pt-online-schema-change ili pg_repack — menjaju strukturu tabele bez blokiranja upisa.

U sledećem delu pokazaću ti konkretne korake za postavljanje replikacije i konfiguraciju proxya na Linuxu, sa primerima naredbi i testovima koje treba da izvršiš pre finalnog preseka.

Postavljanje replikacije: primeri za PostgreSQL i MySQL

Ovde su koncizni, provereni koraci za postavljanje replikacije koja će ti omogućiti bezprekidnu migraciju. Ne zaboravi da izvršiš ove komande u test okruženju pre produkcije.

PostgreSQL (streaming replication, primer za PG 12+)

Na primaru: omogući WAL i pošalji parametre u postgresql.conf:
wal_level = replica, max_wal_senders = 5, wal_log_hints = on. Restartuj postgres: sudo systemctl restart postgresql.
Kreiraj korisnika za replikaciju: CREATE ROLE replicator REPLICATION LOGIN ENCRYPTED PASSWORD 'sifra';
Napraviti bazu kopiju na standby koristeći pg_basebackup:
pg_basebackup -h primar_ip -D /var/lib/postgresql/12/main -U replicator -P --wal-method=stream.
Na standby ubaci fajl standby.signal i u postgresql.conf postavi primary_conninfo='host=primar_ip user=replicator password=sifra', pa startuj servis.
Proveri replikaciju na primaru: SELECT pid, state, sync_state, application_name FROM pg_stat_replication; i na standby: SELECT pg_is_in_recovery(), now()-pg_last_xact_replay_timestamp() AS lag;.

MySQL (binlog replikacija, ROW format)

Na primaru u my.cnf: server-id=1, log_bin=mysql-bin, binlog_format=ROW. Restartuj mysqld.
Kreiraj replikacionog korisnika: CREATE USER 'repl'@'%' IDENTIFIED BY 'sifra'; GRANT REPLICATION SLAVE ON . TO 'repl'@'%'; FLUSH PRIVILEGES;
Napravite snapshot sa master informacijom: mysqldump --single-transaction --master-data=2 --all-databases > dump.sql ili koristi filesystem snapshot.
Na repliki importuj dump, zatim pokreni: CHANGE MASTER TO MASTER_HOST='primar_ip', MASTER_USER='repl', MASTER_PASSWORD='sifra', MASTER_LOG_FILE='mysql-bin.000001', MASTER_LOG_POS=123; (vrednosti preuzmi iz SHOW MASTER STATUS na primaru). Pokreni START SLAVE;
Proveri status: SHOW SLAVE STATUSG i obrati pažnju na Seconds_Behind_Master i eventualne greške.

Konfiguracija proxy sloja i finalni testovi pre preseka

Proxy sloj ti omogućava da promeniš gde aplikacija piše/čita bez izmene koda. Evo praktičnih koraka i testova pre samog preseka.

HAProxy za MySQL/Postgres (brza zamena targeta)

Instaliraj: sudo apt install haproxy. U haproxy.cfg koristi TCP mode za DB sa backendima za primar i repliku. Primer osnovnog backend-a za MySQL:
```
backend mysql_rw
  mode tcp
  balance leastconn
  server db_primary 10.0.0.1:3306 check
  server db_replica 10.0.0.2:3306 check backup
```
Za prebacivanje: promovisi repliku na primarnu (npr. pg_ctl promote ili za MySQL STOP SLAVE; RESET SLAVE ALL; pa osiguraj binlog), ažuriraj haproxy backend da ukloniš staru primarnu ili promeniš backup u aktivan i reloaduj: sudo systemctl reload haproxy.

PgBouncer / ProxySQL

Za Postgres, PgBouncer ti omogućava brzo “drain” postojećih konekcija i preusmeravanje novih. Koristi PAUSE i RELOAD komande za kontrolu pool-a.
Za MySQL, ProxySQL ti daje finu kontrolu writer/read hostgroup. Promena writing hostgroup na runtime je instantno primenljiva i reverzibilna.

Obavezni testovi pre preseka

Monitoruj replikacioni lag 10–30 minuta; cilj: stabilan near-zero lag.
Izvrši smoke test suite aplikacije preko proxyja — zapisi + čitanja, transakcije, long-running upiti.
Proveri integritet podataka: za MySQL koristi pt-table-checksum; za PostgreSQL pokreni kontrolne selekte i uporedi rezultate sa primarom.
Simuliraj rollback: imaj spremnu proceduru za vraćanje proxy-a na staru instancu i testiraj je jednom na testnom saobraćaju.

Nakon ovih koraka i uspešnih testova, bićeš spreman za finalni presek — naredni deo opisuje tačan redosled operacija u minuti preseka i backup-rollback proceduru.

Finalni presečni koraci i rollback procedura

U nastavku su konkretni koraci koje izvršavaš u minuti preseka i jasna, praktikabilna rollback procedura ako nešto pođe po zlu. Radi u timovima: jedan tim radi na bazi, drugi na proxy-ju, treći prati aplikaciju i komunikaciju sa korisnicima.

Najavi kraće održavanje i prebaci aplikaciju u režim samo-čitanja ili postavi feature-flag za zabranu novih pisanja.
Pojačano monitorovanje: aktiviraj alert-e i zabeleži trenutne metrike replikacije i brojeve konekcija.
Sačekaj da replikacija dostigne near-zero lag (potvrdi na standby/replici).
Promoviši repliku u primarnu (npr. pg_ctl promote za PostgreSQL ili odgovarajuća procedura za MySQL).
Ažuriraj proxy konfiguraciju ili hostgroup tako da novi primarni preuzme writer ulogu; reload/config apply na proxy-ju bez drop-a konekcija kad je moguće.
Drain-uj stare konekcije na starom primarnom; po potrebi graceful shutdown procesa baze ili samo ukloni iz load-balancera.
Pokreni smoke testove — zapisi, čitanja i ključne transakcije putem produkcionog puta.
Ako su testovi uspešni, ukloni režim samo-čitanja i obavesti timove; napravi novi snapshot/backup za novu topologiju.

Rollback (ako se pojave kritične greške):

Odmah preusmeri proxy natrag na staru primarnu (ako je još integritetan) kako bi vratili stanje pisanja — to obično vraća servis najbrže.
Ako stari primarni nije konzistentan, demotuj trenutno promovisanu instancu i restore-uj iz poslednjeg stabilnog snapshot-a ili binlog-a; pratite dokumentovanu proceduru restore-a i replay-a binlog/WAL-a.
Obavesti timove i korisnike, ostavi sistem u režimu samo-čitanja dok se ne potvrdi integritet i konzistentnost podataka.
Analiziraj root-cause, izvrši korekcije i ponovo probaj migraciju u planiranom prozoru nakon testova.

Završna razmatranja

Bezprekidna migracija baze zahteva disciplinu u pripremi, jasne procedure za presečenje i testirane rollback puteve. Drži konfiguracije i skripte verzionisanim, automatizuj proveru konzistentnosti i redovno vežbaj ceo proces u test okruženju. Za dodatne detalje o Postgres streaming replikaciji pogledaj PostgreSQL streaming replication docs.

Frequently Asked Questions

Koliko dugo traje presek (cutover) pri pravilno postavljenoj replikaciji?

Uz ispravno podešen proxy i near-zero replikacioni lag, presek obično traje sekunde do par minuta (vreme potrebno za promovisanje replike i refresh proxy konfiguracije). Ključno je da su testovi i dry-runovi izvršeni pre produkcionog preseka kako bi se eliminisali neočekivani koraci.

Da li mogu da izvedem migraciju bez ikakvog rizika od gubitka podataka?

Potpuni izostanak rizika zahteva synchronous replikaciju ili potvrđene mehanizme log-piranje (npr. binlog/WAL) plus trenutnu sinhronizaciju pre preseka. U praksi je cilj minimalan rizik: osiguraj da je replika catch-up, koristi alatke za verifikaciju integriteta i napravi finalni backup pre preseka.

Šta raditi sa long-lived konekcijama i transakcijama koje sprečavaju brzi cutover?

Koristi poolere (PgBouncer, ProxySQL) da pause-uješ ili drain-uješ nove konekcije, obavesti timove da zatvore long-running transakcije pre preseka i, ako je potrebno, forsiraj rollback pojedinačnih transakcija u kontrolisanom testu. U krajnjem slučaju, planiraj duži maintenance window i komuniciraj uticaj unapred.