malo sam se loše izrazio, ne bih znao da odradim ni unutar istog DC sa više DB servera, da se razumemo, opet isti problem, i ako sam napisao da je pokriven scenario :)

Tolika nedostupnost datacentra na mesečnom nivou je nedopustiva. Neke privatne moje servere koje držim u kući su samo zbog struje na godišnjem nivou nedostupni oko 1h. Usput da napomenem agregat još nisam popravio.
Tako da možda razmišljaš u smeru neka optika kod kuće + server + dobar ups + agregat ( plus rezervni server). Trebalo bi da je to puzdanije i mnogo jeftinije nego plaćanje hostinga u 3 data centra. U privatnoj režiji bi imao dostupnost 99,9%

Tolika nedostupnost datacentra na mesečnom nivou je nedopustiva. Neke privatne moje servere koje držim u kući su samo zbog struje na godišnjem nivou nedostupni oko 1h. Usput da napomenem agregat još nisam popravio.
Tako da možda razmišljaš u smeru neka optika kod kuće + server + dobar ups + agregat ( plus rezervni server). Trebalo bi da je to puzdanije i mnogo jeftinije nego plaćanje hostinga u 3 data centra. U privatnoj režiji bi imao dostupnost 99,9%

Ja mislim da ti nemas dovoljno iskustva sa ovime - i da imas nekoliko problema u tome sta si zamislio:

- Ne postoji nijedan razlog zasto bi server X bio primarni. Imas tri servera. Mozes da imas Galera replikaciju i da su sva tri ravnopravni, ili mozes da imas plivajuci sistem gde je jedan master, dva su slave, a ti imas npr. proxy koji preusmerava upite tamo gde treba. Bolje resenje bi se odredilo na osnovu dimenzionisanja podataka.
- Ideja da imas cron job koji kopira podatke unaokolo je jako, jako losa. Imas HA, replicated file sisteme tipa GlusterFS ili Ceph (opet, odlucuje se na osnovu ulazenja u aplikaciju malo bolje) - koji bi ti sve odradili automatski.
- Pretpostavka da imas "pouzdan intranet" je losa. Treba da imas sve kriptovano izmedju svih servera.

Konacno, ovo sto ti trazis se zove "dignemo sve na AWS, jedan region, tri AZ-a".

Mislim da si se zaglibio mnogo duboko - dublje nego sto si u stanju da isplivas i da ti treba da angazujete nekog konsultanta da vam pomogne da to napravite. Apsolutno je moguce to izvesti i u tri fizicka DC-a, ako vam je to iz nekog razloga neophodno (tipa baza sa Galera replikacijom, GlusterFS preko tri DC-a), mada da li je, ako mozete da koristite CloudFlare - a mozete i samo da lepo uzmete AWS.

Problem je, izvini sto ti tako kazem, sto si ti krenuo sa onime sto znas i onda "zamisljas" kako da izvedes to - bez da budes svestan da postoje namenska resenja za problem koji imas.

Tačno je da nemam dovoljno iskustva, te sam zato i pitao, ali bi te začudilo koliko brzo učim i kapiram i kakva sve čuda sam uspeo da realizujem u svojoj karijeri, posebno na malom budžetu i sa ograničenim vremenskim okvirima :) #MojLičniSalesPitch

Problem koji imam sa dostupnošću će se realizovati i u cloud-u dokle god je cloud rešenje na niskom nivou (tipa VPS). AWS bi tu mogao da pomogne samo zato što nude namenski database as a service, i naravno čuveni S3, pa ću to razmotriti kao rešenje, jer nije problem refaktorisati aplikaciju da koristi DBaaS umesto hostovane MySQL instance.

Razmotriću moguća rešenja u tom pravcu.

Sta je prednost AWS:

Imas "Region". U okviru njega imas bar 3 "Availability Zone-a". Svaki AZ je jedan datacentar. Time si odma resio zahteve.

RDS je DBaaS, koji mozes da imas u sva 3 AZ-a. Dobijes jedan URI kojim gadjas "writer". Ako neka instanca ispadne, AWS ti prebaci taj URI da gadja trenutni writer. Ti ne mislis o tome. Nema nista da refaktorises, bukvalno je isto - samo promenis na sta se kacis.

EFS je, u sustini NFS. Imas file system, koji se replicira u sva 3 AZ-a, mount-ujes kao NFS, radi na svim instancama. Nema nista da menjas ni tu aplikaciju.

ELB prati dostupnost aplikativnih servera kroz health check. Ako umre izbaci ga, ti dobijes notifikaciju ako je podesis. Mozes i autoscale da se radi. Opet nista ne menjas. Automatski podrzava 3 AZ-a.

I da - imas i S3, naravno.

-----------

Alternative:

- Veza male latencije izmedju sva tri DC-a
- GlusterFS cluster, 3 servera (moze virtuelna) u 3 DC-a. Onda radis mount na aplikativne servere.
- Percona MySQL sa Galera replikacijom, 3 servera u 3 DC-a, plus bar jedan slave za backup.
- Aplikativni serveri po jedan i svaki DC. Health check.
- CloudFlare kao LB je odlicno resenje za ovo.

----------

Sta je prednost/mana: Za odrzavanje ove alternative ti treba, realno, dva coveka. Ako uzmes konsulatnte placaces, realno, bar 40-60h mesecno posla na odrzavanje. Da se sve pregleda, prati, digne neki monitoring, rade update-i - ima puno posla. Sustina: to nije malo novca.

AWS ti je sve dostupno odma, da ti neko naplati odrzavanje za jedan RDS, jedan EFS, jedan ELB, S3 i par aplikativnih servera, realno, uzece ti 15-20h mesecno, maksimalno.

---------

Konacno, licno: Nisam hteo da impliciram nista lose oko tebe. Jednostavno, nemas iskustva. Sajt ti kaze da si developer. Ne mislim da ne mozes da naucis - zato i pisem, da bi pomogao, samo mislim da ne treba da krenes sa time "kako ja da napravim da MySQL radi.... X". Kreni sa "treba mi resenje za MySQL server i File System u 3 Data Centra. Kad pitas "kako da uradim ovo" ljudi ti kazu to - a to ne znaci da je to dobro resenje. Ja se trudim da ti predlozim bolje resenje - ne ono sto si trazio, vec ono sto ti treba. :)

Slobodno pitaj sve sto zelis, ja cu probati da odgovorim sta mogu. Meni nije tesko da ti napisem kako bi ja to resio, posto sam to vec radio, samo probam da izbegnem sistem gde ti ids sa svojim "resenjem" koje, opet ne tvojom krivicom, je zasnovano na onome sto si sam smislio - bez da znas sta postoji. Boldovao sam ti ovde kljucne reci za istraziti. :) Problem nije da li ovo znas da uradis - verujem da ces se snaci. Problem koji ja ocekujem je da, ako ovo sto pravis (sta god to bilo) bude imalo vece koriscenje, onda ces trebati da ga optimizujes - i tu mozes imati problema.

Zasto ne prilagodis (ako ti razvijas) aplikaciju da moze da radi kao kontejner?
Za stack koji koristis ne vidim da bi bilo problema.

I onda kod cloud operatera (GCP, Azure, AWS, Linode itn)
1. uzmes kao infrastrukturu resurse i sam postavis kubernetes cluster i unutra svoje aplikacije. Tada koliko znam ti cloud podrska "samo" napravi LB rute do tvog cluster-a. Tada si ti admin kubernetes cluster-a
2. direktno u kubernetes cluster od cloud-a postavis svoje aplikacije. Tada cloud tim od provajdera upravlja kubernetes cluster-om i oni ti dodeljuju resurse (disk cpu) za tvoje aplikacije na osnovu tvojih zahteva odnosno koliko si spreman da platis.

Vidi sta ti se vise isplati.
Prednost ovih izbora gore je da vrlo lako u zavisnosti od prometa na sajtu resurse dodajes (npr horizontalno povecavas broj instanci web aplikacije - frontenda)

U svakom slucaju imas reltivno ozbiljne zahteve za aplikaciju i to vise nije hobi projekat. Iako to nisi napisao, vise pisem generalno.
Tako da i cena je odgovarajuca potrebama. Pretpostavljam da od te aplikacije nesto zaradjues odnosno u skladu sa tim odlucujes koliko si spreman da potrosis na infrastrukturu.

Da, pretpostavka je da moras poznavati kubernetes (ili unajmiti DevOps). Nije nesto preterano komplikovano ali ipak trazi vreme da se posvetis.

_{[Ovu poruku je menjao djordjeno dana 26.10.2022. u 14:04 GMT+1]}

Čemu toliko komplikovanje kad postoji replikacija:

https://dev.mysql.com/doc/refman/8.0/en/group-replication.html