tako da je za replikaciju dovoljno da se sinhronizuju podaci iz WAL fajla sa udaljenom bazom (bazama)
Asynchronous & synchronous replication
Glavna razlika asinhrone i sinhrone replikacije je u tome sto kod sinhronog modela glavni server čeka potvrdu upisa od svih slave servera:
dok kod asinhronog moda master server NE čeka potvrdu upisa od slave-a:
Sinhroni model rada je sigurniji ali je upis u bazu sporiji jer server mora da sačeka odgovor slave-a.
Asinhroni mod je brži ali uvodi kašnjenje prilikom replikacije koji mogu dovesti do gubitka podataka u slučaju otkazivanja master servera ( ali samo zadnjih par sekundi, što i nije strašno )
Najčešča primena replikacije je:Slave serveri takođe mogu da se ponašaju kao masteri svojim slave serverima i da se dalje repliciraju - to je CASCADE REPLICATION.
QUORUM COMMIT - Ukoliko imamo npr 10 slave servera možemo da kažemo master serveru da vrati COMMIT čim je 5 od 10 slave servera potvrdilo upis.
LOGICAL REPLICATION
Radi na logičkom nivou tj moguće je izabrati tabele koje se repliciraju i definisati da li će se replicirati posle inserta/update/delete operacija.
Logical replication umesto rigidne Master/Server arhitekture koristi Publish/Subscribe strukturu i vrlo je jednostavna za implementaciju.
Pri tom uopšte nije obavezno da replika bude ista kao i original jer na subscriberu možemo da odlućimo sta da radimo sa novim podatkom, trigeri mogu da budu okinuti itd.
Korisno primena je npr. server na kojem želimo da imamo agregirane podatke sa više servera
I poslastica za kraj:
HORIZONTALNO SKALIRANJE
Uz pomoć citus extenzije možemo da ubrzamo/rasteretimo server tako što ga particionišemo po bilo kom polju (npr. po company_id tj. tenant-u) na proizvoljan broj servera koji rade paralelno. Na sličan način rade više diskova u RAID 0 modu.Moguće je skalirati cpu, memory i storage i pri tome dobiti na performansama: https://www.youtube.com/watch?v=g3H4nGsJsl0