Optimalizace MariaDB na čtení nebo zápis

[hknmtt]

Ked si vezmem "CAP theorem" a chcem mat jednu MariaDB instanciu optimalizovanu na konzistenciu(zapis) a druhu instanciu zase optimalizovanu na dostupnost(citanie), su pre nu nejake specificke nastavenia ktore sa oplati riesit, ci ani nie?

[Reklama]

[RDa]

Pokud je to fakt 1 + 1 instance, tak vzdy bude existovat zelezo, ktere dane 2 zateze utahne a nemusi se nekdo mr**t s clusterem.

Cluster bych zvazoval od 1W + 8R uzlu - viz use case jako Wikipedie (tj. pokud mate penize, 8x vykon v jednom stroji jeste date.. ale vejs vam uz ani ty penize nepomuzou a problem se resi jinak).

[Pavel Stěhule]

Ked si vezmem "CAP theorem" a chcem mat jednu MariaDB instanciu optimalizovanu na konzistenciu(zapis) a druhu instanciu zase optimalizovanu na dostupnost(citanie), su pre nu nejake specificke nastavenia ktore sa oplati riesit, ci ani nie?

Pokud bys chtěl aplikovat CAP theorem na MySQL, tak jedině na nějaký replikovaný cluster. MySQL je klasická transakční relační databáze. CAP theorem má smysl na distribuované databáze, což instance MySQL není.

[Josef Marianek]

Ked si vezmem "CAP theorem" a chcem mat jednu MariaDB instanciu optimalizovanu na konzistenciu(zapis) a druhu instanciu zase optimalizovanu na dostupnost(citanie), su pre nu nejake specificke nastavenia ktore sa oplati riesit, ci ani nie?

Pokud bys chtěl aplikovat CAP theorem na MySQL, tak jedině na nějaký replikovaný cluster. MySQL je klasická transakční relační databáze. CAP theorem má smysl na distribuované databáze, což instance MySQL není.

Za me souhlas, tady je navod na ten cluster.
https://www.digitalocean.com/community/tutorials/how-to-set-up-replication-in-mysql
Neni to tak slozite.

[Filip Jirsák]

To mají být zcela nezávislé instance s různými daty, nebo ta čtecí databáze má být replikou té zapisovací? Pokud to má být replika té zapisovací, pak se do té repliky samozřejmě také musí zapisovat, akorát to nedělají klienti, ale replikují se tam data z masteru. Takže prostor pro jinou konfiguraci je velmi omezený.

[Reklama]

[Pavel Rauš]

CAP - Consistency - klienti vidí stejná data, Availability - funguje to i když přijdete o některý node, Partition-tolerance - běží to i v situaci jako je splitbrain

MariaDb dle definice splňuje C a A. Když ale uděláte cluster s asynchronní replikou ( viz ten návod co tu byl poslán ) tak z praktického hlediska o konzistenci přicházíte, protože ta replika může být opožděna. Pokud chcete i konzistenci, je potřeba nad MariaDb postavit Galera cluster a před to posadit loadbalancer, který bude požadavky rozhazovat a zároveň se postará, aby Vám neodpovídal node, pokud je z nějakého důvodu opožděný. V případě že nebudete striktně dodržovat omezení Galera clusteru, tak se Vám to celé dřív nebo později rozpadne. Z pohledu výkonu je Galera určitě náročnější na provozní zkušenost i na systémové prostředky, oproti obyčejné async replice.

Možná bych si na Vašem místě položil otázku, jestli je MariaDb správný produkt pro Vaše nasazení. Za mě - pokud je akceptovatelné přijít o konzistenci dle CAP, tak určitě najdete lehčí a rychlejší databázi, než je MariaDb. A výběrem správné databáze byste měl asi začít.


A jinak k otázce - ukládejte data do InnoDb, pokud nastavíte innodb_buffer_pool dostatečně velký, bude to rychlé pro čtení i zápis. Na zápisovém nodu zvedněte innodb_write_io_threads dle počtu jader. Na čtecím nodu naopak preferujte navýšení innodb_read_io_threads a repliku nechte běžet jen v jednom vlákně ( pokud to bude stíhat ). Když to bude mít dost systémových prostředků, zvládne to hodně. Klíčové je hodně RAM. A jestli nemáte s provozem databází zkušenosti, tak si sežeňte někoho, kdo to umí ... ušetříte spoustu času laděním, což bez zkušeností může být opravdu dlouho ... vždyť v MariaDb jsou stovky konfiguračních parametrů.