Jakou DB nasadit: MariaDB nebo Percona?

[thcom]

ahoj profici, mam ty jednoduchou aplikace v delphi a MySQL select update insert obcas delete, zadna ducharina
rad bych si na druhy server nainstaloval zalozni DB a zkusim zprovoznit replikace, staci mastar slave, dogooglil jsem ze na cistem MySQL je to peklo, mam se dat cestou percona nebo mariaDB,

diky moc za rady

[Reklama]

[Boo]

PostgreSQL bude vhodnejsi, tam je master slave primo v zakladu od nepameti.

[dustin]

Mysql a mariadb se v replikaci liší způsobem generování transakčních ID do binárního logu. MariaDB to má IMO lépe, přišla s tím později a vyvarovala se chyb mysql.

Doporučuji mít všechny tabulky v innodb (což by již dnes měla být samozřejmost), databázi za běhu přenést pomocí innobackupex (najdi si tutoriály na googlu, není to nic složitého). Pak je rozchození replikace jednoduché, protože kopie již přímo obsahuje ID poslední transakce, kterou replikaci nastartuješ.

Vykopíruješ data dir pomocí innobackupex, přeneseš na slave, nastartuješ, nastavíš replikační master a spustíš slave. Pokud jsi to nikdy nedělal, chvíli si s tím pohraješ, než se to naučíš. Pak už to běží spolehlivě. Je potřeba nechat na masteru dostatečně dlouhý binlog (v konfigu je počet dnů expire-logs-days), abys v případě problému se slavem měl dostatek času na jeho opětovné spuštění a nepřenesené logy se ti mezitím na masteru neodmazaly.

Replikace samozřejmě row-based, nebo kombinovanou (ale stejně se použije row-based).

Jinak replikace běží spolehlivě, používáme řadu let. Je ale dobré to něčím monitorovat (skript, nagios atd.), abys případný problém chytil včas a nenechal si utéct logy na masteru. Doporučuji slave nastartovat read-only, abys do něj nedopatřením nezapsal. Pak by se ti to rozjelo a musel bys jej obnovovat zase přes dump innobackupex (naštěstí je přitom master v plném provozu).

[n]

S Postgre bych byl opatrny.
 Pokud jsou to male data a par klicu na tabulkach, tak asi nebude problem, ale postgre ma, nebo minimalne mela dost neefektivni replikaci(a vubec zapisy dat, z duvodu "divneho" systemu fyzickeho ulozeni na disk). S vice sekundarnimi klici, pripadne vetsimi daty, ta replikace dost zabiji sit a i bezne lokalni zapisy zerou dost IO.

[stehule]

S Postgre bych byl opatrny.
 Pokud jsou to male data a par klicu na tabulkach, tak asi nebude problem, ale postgre ma, nebo minimalne mela dost neefektivni replikaci(a vubec zapisy dat, z duvodu "divneho" systemu fyzickeho ulozeni na disk). S vice sekundarnimi klici, pripadne vetsimi daty, ta replikace dost zabiji sit a i bezne lokalni zapisy zerou dost IO.

Postgres má vestavěnou fyzickou replikaci, která je náročnější na přenos, ale vždy zachovává konzistenci o jednoduše se nerozpadne. Výkonostně jsem ji viděl nasazenou na intenzivním zápisu desítek gb dat a cca 5000..11k transakcí za sec. Což je hodně atypická aplikace na čr.

Ten divný zapis na disk používá i innodb. Rozdílná je implementace indexů. U mysql je optimalizovaný přístup na primární klíč, ostatní jsou pomalejší. U postgresu není rozdíl mezi primárním a jiným indexem. Postgres rychleji čte data z dalších indexů, MySql rychleji updajtuje. Rozdíly se poznají na aplikaci typu Uber. Tady na čr to asi nebude vůbec poznat.

[Reklama]

[n]

S Postgre bych byl opatrny.
 Pokud jsou to male data a par klicu na tabulkach, tak asi nebude problem, ale postgre ma, nebo minimalne mela dost neefektivni replikaci(a vubec zapisy dat, z duvodu "divneho" systemu fyzickeho ulozeni na disk). S vice sekundarnimi klici, pripadne vetsimi daty, ta replikace dost zabiji sit a i bezne lokalni zapisy zerou dost IO.

Postgres má vestavěnou fyzickou replikaci, která je náročnější na přenos, ale vždy zachovává konzistenci o jednoduše se nerozpadne. Výkonostně jsem ji viděl nasazenou na intenzivním zápisu desítek gb dat a cca 5000..11k transakcí za sec. Což je hodně atypická aplikace na čr.

Ten divný zapis na disk používá i innodb. Rozdílná je implementace indexů. U mysql je optimalizovaný přístup na primární klíč, ostatní jsou pomalejší. U postgresu není rozdíl mezi primárním a jiným indexem. Postgres rychleji čte data z dalších indexů, MySql rychleji updajtuje. Rozdíly se poznají na aplikaci typu Uber. Tady na čr to asi nebude vůbec poznat.

To se vam nerospadne ani u mysql. To co jste videl nic neznamena, neznamena, ze to nevytizi napr GB sit.
Postgre prenasi v podstate pro kazdy klic na radku cely radek znova. A protoze nepodporuje poradne MVCC, tak v pripade updatu mate na slavech zamknute i cteci transakce. Ja nerikam, ze na vetsinu veci nestaci, jen rikam at si date bacha, ze vytizite jak IO, tak sit vice nez u mysql. A jinak i v CR najdete mista, kde s tim budete mit VELKY problem ;-)

[Pavel Stěhule]

S Postgre bych byl opatrny.
 Pokud jsou to male data a par klicu na tabulkach, tak asi nebude problem, ale postgre ma, nebo minimalne mela dost neefektivni replikaci(a vubec zapisy dat, z duvodu "divneho" systemu fyzickeho ulozeni na disk). S vice sekundarnimi klici, pripadne vetsimi daty, ta replikace dost zabiji sit a i bezne lokalni zapisy zerou dost IO.

Postgres má vestavěnou fyzickou replikaci, která je náročnější na přenos, ale vždy zachovává konzistenci o jednoduše se nerozpadne. Výkonostně jsem ji viděl nasazenou na intenzivním zápisu desítek gb dat a cca 5000..11k transakcí za sec. Což je hodně atypická aplikace na čr.

Ten divný zapis na disk používá i innodb. Rozdílná je implementace indexů. U mysql je optimalizovaný přístup na primární klíč, ostatní jsou pomalejší. U postgresu není rozdíl mezi primárním a jiným indexem. Postgres rychleji čte data z dalších indexů, MySql rychleji updajtuje. Rozdíly se poznají na aplikaci typu Uber. Tady na čr to asi nebude vůbec poznat.

To se vam nerospadne ani u mysql. To co jste videl nic neznamena, neznamena, ze to nevytizi napr GB sit.
Postgre prenasi v podstate pro kazdy klic na radku cely radek znova. A protoze nepodporuje poradne MVCC, tak v pripade updatu mate na slavech zamknute i cteci transakce. Ja nerikam, ze na vetsinu veci nestaci, jen rikam at si date bacha, ze vytizite jak IO, tak sit vice nez u mysql. A jinak i v CR najdete mista, kde s tim budete mit VELKY problem ;-)

UPDATE na masteru Vám nezamkne čtecí transakce na slave - může dojít ke kolizi, a transakce na slave bude stornovaná - aby se Vám to nestalo, tak lze na slave nastavit hot_standby_feedback.