Rozdělení zátěže pomocí replikace mezi Master a Slave (MySQL/MariaDB)?

Zdravím, je možné velkou zátěž MySQL/MariaDB databáze rozložit pomocí replikace tak, že frontend se bude načítat výhradně ze Slave (jen načtení dat samozřejmě) a importy/exporty/zápis a vše ostatní půjde na Master?
Na netu hodně píšou, že je ta replikace nespolehlivá/padá...
Provozuje tak někdo něco (s jakou návštěvností) nebo to je slepá ulička?

https://mariadb.com/kb/en/galera-cluster/

pripadne ak chces nieco serioznejsie s tym ze chces ostat na mysql protokole tak https://github.com/pingcap/tidb akurat je to zlozitejsie rozbehnut lebo to ma 3 komponenty ktore treba nastavit(ulozisko TiKV, kooridonator PD a SQL vrstvu TiDb).

Pre postgres porotkol mas potom https://github.com/cockroachdb/cockroach. Vyhoda je jedna binarka ale verzia zdarma ma niektore obmedzenia ktore ti casom mozu vadit(naposledy niekto riesil problem s prihlasovanim).

Ten MariaDB cluster je vlastně multi-master replikace - tam musí být strašná režie na synchronizaci těch nodů...
Ale jinak ta replikace asi teda je jedna z možností...

na galera clusteru běží iVysilani České Televize, jeden z českých operátorů na tom rozkládá 30 000 požádavků read/write za sekundu, jinde zase máme 2TB datadir. Provozovat se to dá, ale někdy je s tím trocha učení.

U asynchronní replikace je problém monitoring, může se ti to rozpojit a nemusíš to dlouho vidět nebo omylem zapíšeš na slave a máš konflikt.

U galery to zase dobře nefunguje s stored functions nebo při hromadných updatech celé tabulky, protože row based replikace. Režie je podle množství zápisu, není obvykle problém pro čtení :). Prakticky to ale stejně používám v režimu master + slave, tj. na jeden zapiyuji jako hlavní a druhý je pro čtení, ikdyž na pozadí to je master - master, lépe se pak třeba řeší failover a hlavně galera podporuje pouze lokální locky na úrovni jedné instance, takže při multi master zápisu vzniká konflikt, který teda se dá interně řešit opakování, ale při zátěži je to zbytečně riziko, takže multimaster zápis jedu přes shardery a uvnitř nich přes round robin na balanceru.

O jakým provozu mluvíš, že uvaříš jednu instanci? Ono někdy stačí jen trochu vylepšit nastavení, konfiguraci serveru a utáhne ti to obojí.

PS: tidb je pořád při zátěži nestabilní a nepodařilo se mi ho dostat do produkčního stavu

Velká zátěž je kolik dotazů za sec? Jaký je poměr čtení a insertů/updatů? Je pro aplikaci zásadní, aby byla data vždy aktuální?

V jedne firme jsme to tak provozovali....

OK, díky za cenné informace všem, zkusím to s tou replikací a uvidím...

Dá se to, ale lze taky krásně rozházet databáze a ten Claster už nikdy nenahodíš. Claster teď používám na ElasticSearch pro logování. Stalo se mě, že se rozpadl díky menšímu výpadku disků (výměna za nové) a muselo se to stavět znovu. Naštěstí už to mám vše v Ansible a tak to už moc času nezabere. Samotné aplikační DB nejsou tak velké a využívám datové sklady. Některé dotazy na DB se dají redukovat pomocí Cache. Například COUNT může být v Redisu a nemusí vůbec zatěžovat DB. Možnosti optimalizace je hromada.

Původně odeslal tomas86 ↪

Dá se to, ale lze taky krásně rozházet databáze a ten Claster už nikdy nenahodíš. Claster teď používám na ElasticSearch pro logování. Stalo se mě, že se rozpadl díky menšímu výpadku disků (výměna za nové) a muselo se to stavět znovu. Naštěstí už to mám vše v Ansible a tak to už moc času nezabere. Samotné aplikační DB nejsou tak velké a využívám datové sklady. Některé dotazy na DB se dají redukovat pomocí Cache. Například COUNT může být v Redisu a nemusí vůbec zatěžovat DB. Možnosti optimalizace je hromada.

Mariadb a elastic se chovají ale naprosto jinak a nelze je v tomhle porovnávat, mariadb má wal, který je replikovaný s funguje jako místo pravdy a je možné se vracet libovolně v čase nebo obnovit celou db, řeší se každý insert/update zvlášť a každý je uzavřen ve své transakci a commitnut. Naproti tomu elastic search si má také nějaký translog, ale je naplňován až při flush operaci a nikoliv před commitem, elastic nemá transakce a schopnost testu integrity jako mariadb, ty databáze jsou úplně pro jiný účel.

V dritivý většině případů lze sql dotazy optimalizovat tak, že není potřeba cache a mít riziko stale záznamů. Count lze zlepšit indexama nebo si ho mohu nechat počítat přes procedury.