Příspěvky

1

Hardware / Re:GSM domovní zvonek – klasické zvonění + volání na telefon

« kdy: 28. 04. 2025, 14:04:45 »

Pokud to tam má vydržet třeba 10 let, určitě bych se vyhnul GSM-only řešením. GSM nemá budoucnost, jak už tu napsal skopda.

Přesně tak.  2G se bude během několik let vypínat. Takže by to muselo být zařízení co volá přes VoLTE, nebo přes LTE + SIP.   Pokud to má dosah wifi, nebo tam lze zavést ethernet, je to lepší řešit přes něj. A tedy SIP. Protože to bude fungovat i za 10 let.

2

Hardware / Re:GSM domovní zvonek – klasické zvonění + volání na telefon

« kdy: 28. 04. 2025, 14:02:12 »

Technologie 2N by to měla splňovat. A funguje na SIPu. Volat lze na jedno číslo, ne všechny na jednou nebo na všechny postupně za sebou.

Některé 2N či jiné SIP dveřníky umí volat i více čísel současně. Zároveň jedno z volaných zařízení může být ip adresa  Jen je to docela drahé. Ale je to spolehlivé.

3

Server / Re:Nevýhody InnoDB oproti MyISAM v MariaDB

« kdy: 25. 04. 2025, 14:36:44 »

15 tis. hovorů za sekundu je nic. Disky WD mají pět let záruky a tohle zvládnou bez problémů.

Tak tohle je chvástání.
15 tisíc hovorů za vteřinu by mohlo být až půl miliardy hovorů za den. Tedy třeba 1 TB komprimavných dat denně a to nepočítám overhead s updatováním indexů a podobně, což bude více než dvojnásobek.
Tolik hovorů nedá ani celá česká republika všichni mobilní i jiní operátoři dohromady.
Jeden hovor není jeden řádek v tabulce. Ale minimálně pět, nejspíše více, sleduje se celá cesta hovoru a jednotlivé SIP pakety. Je pak možné určit, kde nastal problém.
Aby to ale bylo možné, je třeba mít vyladěné nastavení InnoDB a souborového systému.

Souhlas, clovek ktery resi 15tis hovoru za sekundu je profesional ktery se nebude chodit radit do anonymniho fora…klasicky troll, spravuje databazi pro megakorporat ale jde pro radu sem…

Ale já jsem nikde nepsal, že mám 15 tisíc hovorů za vteřinu.  Ale že to zvládne innoDB s vhodným nastavení podle toho co píší zde. https://www.voipmonitor.org/doc/Scaling#SSDs  jeden stroj s innoDB tabulkou zvládne tohle množství hovorů zaznamenávat. Což je provoz celého státu většího než česká Repulbika. Ale ne s defaultním nastavením ale speciálním nastavením innoDB a souborového systému.  Defaultní nastavení je totiž velmi pomalé (řádově desetkrát pomalejší než default u MyISAM).
Na co upozorňuji, že ač má toto nastavení přímo obrovský vliv na výkon, jeho dokumentace je velmi slabá. Především co to udělá s integritou dat není nikde moc dokumentováno.


Jinými slovy. S dobrým nastavením to zvládne jediný výkonnější počítač (a druhý záložní). Když se to udělá špatně, mohl by si velký mobilní operátor např. ve velké Británii také postavit kvůli tomu celé nové datacentrum. A místo jednoho člověka, by to mohlo spravovat celé nové oddělení.  Rozdíl mezi špatným a dobrým fungování je v IT propastný.

4

Server / Re:Nevýhody InnoDB oproti MyISAM v MariaDB

« kdy: 22. 04. 2025, 13:12:19 »

Nevím, jen jak jsem psal, prostě 10x změna v WA je divoká, pokud se skutečně změnila jen platforma (ten základ OpenZFS je víceméně stejný pro oba systémy, byť tam samozřejmě jsou trochu jiné I/O schedulery na blokové vrstvě).
Spíš bych tipoval, že tam těch změn je víc - Linux -> FreeBSD, možná verze MariaDB (tam je to taky občas divočina, mění se občas zásadní defaulty mezi desetinovými verzemi, pokud to není explicitně uvedené), taky to ZFS mohlo být trochu jinak nastavené atp.
Nicméně jestli jsem to pochopil správně, tak to stejně teď zkouší celé na FreeBSD a k tomuhle by se musel vracet.

Přesně tak. Problém se ZFS jsem vyřešil přechodem na FreeBSD. Takže to dál již nezkoumám i když se k problému možné někdy vrátím, protože Linux používám dál pro méně zapisující databáze a jiné kontejnery.
Na FreeBSD mi ZFS funguje stejně jako ostatním.   ZFS je v pohodě použitelné i pro hodně zapisující databázi a při dobrém nastavením nemusí být Write Aplification vůbec žádná.

Nyní řeším jen optimální nastavení voleb InnoDB pro dobrý výkon tak, aby to nebylo nebezpečné pro integritu dat. Protože defaultlní nastavení způsobuje cca desetinásobně horší výkon u zápisů oproti defaultnímu nastavení MyISAM.  Kromě importu existujících dat to měřím také rychlostí jakou zastavená a znovu spuštěná replika dovede dohánět master.

Jestli tohle zničí disk jsem nezkoumal, pravděpodobně ne, ale preventivně chci zápisy minimalizovat kvůli lepšímu výkonu a menšímu opotřebení disku, což znamená menší pravděpodobnost poruch. Zbytečně nepřetěžovat stroj je vždy dobrá prevence problémů a mimo jiné to šetří třeba elektřinu. Zapsat třeba jen 5% toho co by měl disk vydržet (100 TB) za dobu osmi dost možná pomůže k tomu, že jej nikdy měnit nebudu muset.

5

Server / Re:Nevýhody InnoDB oproti MyISAM v MariaDB

« kdy: 22. 04. 2025, 12:54:38 »

Mě se to také nezdá. Proto o tom píši. To zničení těch disků není žádná teorie, ale skutečnost po roce provozu. Kdy díky ZFS a té amplifikaci to ve smartu disku hlásilo vypotřebovanou životnost i když disky stále fungovaly.

A máš správné zarovnání? A rozumně velký recordsize (viz např. https://www.percona.com/blog/mysql-zfs-performance-update/ ) ? Innodb na ZFS provozuji (optimalizované dle onoho popisu) a nepozoruji nadměrné ošoupání NVMe.

S recordsize jsem experimentoval, ale má to minimální vliv.  Protože když s větším recordsize zase funguje lépe komprese (to jsem si vyzkoušel i ve freeBSD), tedy rozdíl není násobný. Špatné zarovnání by to být mohlo, ale to by mělo zvýšit zápis předpokládám maximálně dvojnásobně. Všechno to doporučované ladění má jen relativně malý vliv.
Na FreeBSD mi to vychází stejně jako ostatním, výkon je to srovnatelné s ext4 podle toho jak dobře se to vyladí.
Jestli někdy přijdu na to čím to bylo, podělím se.

6

Server / Re:Nevýhody InnoDB oproti MyISAM v MariaDB

« kdy: 22. 04. 2025, 11:16:49 »

U toho write amplification, o kterém často píšete, se mi to upřímně moc nezdá.
Resp. může se to samozřejmě vymknout z kloubů v nějakých specifických situacích (kdy máte např. nějaké šílené zarovnání a dělá vám to hromadu zbytečných RMW cyklů, nebo máte např. zvol, který jede všechno přes ZIL, nad ním ještě další FS, zapnete žurnálování na všech vrstvách atp.).
Ale zaráží mě, že jste se za tu dobu nedobrali, kde k tomu dochází. Při správné konfiguraci není úplně realistické, že by OpenZFS na Linuxu mělo samo o sobě desetinásobnou WA a jen přechod mezi systémy to magicky vyřešil.

I ten tweak, co jste zmiňoval ve vlákně o FreeBSD, že je to už v pohodě, když jste prodloužil zfs_txg_timeout, mi přijde v téhle aplikaci trochu haluz (hlavně proto, že MySQL posílá sync(), který tu transakci uzavírá mnohem častěji).
Abyste to nějak rozumně porovnal, musíte zapsat opravdu identická data. Ideálně nějaký připravený test, nebo třeba i sysbench pro MySQL. Jestliže vám tam jednou vycházela odhadovaná WA menší než jedna, tak to znamená jen, že pokud je na datasetu zapnutá komprese, tak to s těmi konkrétními daty mělo lepší poměr.

Další věc je, že byste to měl opravdu počítat exaktně (fyzicky zapsaná data / logicky zapsaná data). Což nezjistíte jen iostatem. Logicky zapsaná data z databáze s innodb se dají zjistit přes globální status (SHOW GLOBAL STATUS LIKE '%WRITTEN%', tam jsou čítače od spuštění.
Další místo, kde se to dá dohledat, kolik se zapsalo z aplikací, jsou statistiky pro jednotlivé datasety. V Linuxu je to v  /proc/spl/kstat/zfs na FreeBSD se to vypíše přes: sysctl kstat.zfs.zroot.dataset

Mám na to takový skript.., co to vyfiltruje (první parametr je dataset, např. zpool/mysql ).
Vyjede vám akumulovaný počet zapsaných bajtů (nwritten), I/O operací, kolik šlo přes ZIL atp.

Kód: [Vybrat]

#!/bin/sh

dataset=$1
zpool=${dataset%%/*}
objset=$(zfs list -H -o name,objsetid \
        | awk -v ds="$dataset" '$1 == ds { printf("objset-0x%x", $2) }')
sysctl kstat.zfs.${zpool}.dataset.${objset}
Akumul. počet bajtů zapsaných do zařízení se na FreeBSD nejsnáz zjistí přes iostat -Ix.
Když mu dáte parametr -I a neuvedete periodu, tak vám dá akumulované hodnoty od startu systému. Parametr -x dá každé zařízení na svůj řádek. Zápisy jsou v pátém sloupci kw/i (pozor na jednotky, je to v kB).

Tzn. je potřeba spočítat rozdíly (deltu) za dobu, co to měříte. A pak to mezi sebou podělit, abyste dostal WA u ZFS.
Jde to analogicky i u jiných filesystému a aplikací, ale tam už se musí typicky zapojit nějaký tracing, kdy budete odchytávat syscally pro zápis a sčítat hodnoty. Na FreeBSD přes DTrace, na Linuxu třeba přes bpftrace, perf atp.

Ještě krátce k tomu hardware, ta terabajtová SSDčka, co máte, mají zhruba 1DWPD. Tzn. reálný problém by měl nastat, pokud zapíšete vyšší stovky GB denně (samozřejmě včetně WA na úrovni databáze i FS), aby to začal být problém. Upřímně si nedovedu moc představit, kolik záznamů musíte denně zalogovat, ale asi bych úplně nečekal, že v tomhle bude problém i při použití "normální" databáze s transakcemi, replikací atp. pokud se to rozumně nastaví.

Díky moc za konkrétní rady. Budou se hodit. Určitě zápisy prověřím až bude vše finálně vyladěno na FreeBSD. Na Linuxu mi ZFS s hlavní databází nyní neběží, předělali jsme to na ext4, tedy budu moci tu WA ověřit příležitostně.

7

Server / Re:Nevýhody InnoDB oproti MyISAM v MariaDB

« kdy: 22. 04. 2025, 11:13:05 »

15 tis. hovorů za sekundu je nic. Disky WD mají pět let záruky a tohle zvládnou bez problémů.

Tak tohle je chvástání.
15 tisíc hovorů za vteřinu by mohlo být až půl miliardy hovorů za den. Tedy třeba 1 TB komprimavných dat denně a to nepočítám overhead s updatováním indexů a podobně, což bude více než dvojnásobek.
Tolik hovorů nedá ani celá česká republika všichni mobilní i jiní operátoři dohromady.
Jeden hovor není jeden řádek v tabulce. Ale minimálně pět, nejspíše více, sleduje se celá cesta hovoru a jednotlivé SIP pakety. Je pak možné určit, kde nastal problém.
Aby to ale bylo možné, je třeba mít vyladěné nastavení InnoDB a souborového systému.

8

Server / Re:Nevýhody InnoDB oproti MyISAM v MariaDB

« kdy: 22. 04. 2025, 10:14:59 »

U mne všechny disky (kromě několika Samsung 3TB) selhaly až po záruce. A vše v záruce vždy obchod vyměnil do jednoho měsíce od reklamace.

Mě zatím neodešel žádný SSD disk nasazený na serveru. Magnetické čas od času odejdou.
Přetěžovat disk kvůli neoptimálnímu nastavení, aby měl co dělat, že se dožije pěti let nebo konce záruky, ale rozhodně není dobrá strategie. Pro spolehlivost provozu je lepší neřešit výměnu disku ani v záruce ani po ní. Nasazení 24/7 jakoukoli manipulaci hrozně komplikuje.  Proto hledat opravdu optimální nastavení se vyplatí už kvůli tomu, že se sníží pravděpodobnost selhání disků. A platí to samozřejmě i na magnetické disky, protože zbytečné zatížením jim také nesvědčí.

Snažit se redukovat zbytečné zápisy, i kdyby to měl disk teoreticky vydržet, je dobrá strategie.

9

Server / Re:Nevýhody InnoDB oproti MyISAM v MariaDB

« kdy: 22. 04. 2025, 09:55:38 »

U toho write amplification, o kterém často píšete, se mi to upřímně moc nezdá.

Mě také ne. Rozdíl mezi Linux a FreeBSD určitě není 10x a rozdíl mezi mít DB na XFS nebo na ZFS také neudělá dalších 10x a přechod MyISAM na InnoDB také neudělá 10x. Dohromady tedy 1000x write amplification.

Tazatel se asi moc dívá na nějaké zcela nezajímavé statistiky. U mne všechny disky (kromě několika Samsung 3TB) selhaly až po záruce. A vše v záruce vždy obchod vyměnil do jednoho měsíce od reklamace.

Mě se to také nezdá. Proto o tom píši. To zničení těch disků není žádná teorie, ale skutečnost po roce provozu. Kdy díky ZFS a té amplifikaci to ve smartu disku hlásilo vypotřebovanou životnost i když disky stále fungovaly. Neběžela tam hlavní databáze, ale její repliky. Vyřešil jsem to převod na ext4.
Na ext4 byl počet zápisů naprosto zanedbatelný. Počet zápisů na ext4 byl menší než desetinásobný. Ale beru v úvahu, že ZFS má  přirozeně více zápisů než ext4, protože je to copy on write např. s méně efektivními updaty, což je v databázích velmi běžná operace. Indexy se updatují věčně. Rozdíl byl ale více jak desetinásobný proti tomu co bych považoval ještě za přirozené, normální a snesitelné a to ještě s nějakou rezervou.  Ten rozdíl mezi ext4 a ZFS ale byl mnohem větší než desetinásobný.

Je ale pravda, že pokud někdo nemá opravdu hodně zapisující databází, amplifikace se vůbec nevšimne, neb rezerva životnosti disku je tam dostatečná. Věřím že právě proto jsem snad jediný, kdo ten problém pozoroval.

10

Server / Re:Nevýhody InnoDB oproti MyISAM v MariaDB

« kdy: 21. 04. 2025, 23:27:13 »

Reaguji na to co napsal Tomáš Crhonek.

Pod pojmem SSD Samsung pro mi to najde jen tohle https://www.alza.cz/samsung-990-pro-1tb-d7516911.htm
Což není ani serverový disk.  Já používám tohle https://www.alza.cz/wd-red-sn700-nvme-1tb-d6998050.htm
Kapacita 1TB, životnost 2000TBW.  Tedy disk lze cca 2000 krát přepsat. Dříve to byly disky s kapacitou 512 GB s životností cca 600 TBW. Všechny disky vydržely to co měli v popisu.


Oni jsou to ale dva různé problémy.  Jeden problém byl v tom, že ZFS mělo v mém případě více jak desetinásobnou write applification oproti tomu, jakou by mělo mít dle všech pouček a návodů.
To jsem nyní vyřešil přechodem z Linuxu na FreeBSD. Tam to na stejném hardware a při stejném zatížení prostě nedělá. Přechod na FreeBSD má i další podstatné výhody, např. že mi přijde že ve FreeBSD je vše jednodušší a lépe zdokumentované, tedy nemám už potřebu příliš zkoumat, kdy přesně a proč se to násobné zapisování v Linuxu vyskytuje.

Druhý problém na který jsem narazil a který z prvním souvisí jen okrajově a o kterém je tohle vlákno je ten, že při defaultním nastavení innoDB  jsou zápisy více jak 10 krát pomalejší než než u defaultního nastavení MyISAM.
Výsledek je, že když importuji CSV soubor do nové databáze se 264 milióny záznamy, tak na to místo dvou hodin potřebuji celý víkend. Rozdíl je možné srovnat vhodným nastavením innoDB. Změna nastavení nespočívá ve vypínání sync!

Pokud by zkombinoval ZFS write amplification a neoptimální nastavení databáze, zničí to v mém provozu pravděpodobně i ty nejlepší disky a poběží to pomaleji, než kdyby databáze jela na deset let starém hardware. Řešit to lepším hardware je nesmysl.

MySQL/MariaDB neumožňuje vypnout sync, píše se, že tato možnost je jen pro testování. To bych mohl vypnout jen nastavením ZFS, aby ZFS sync jen předstíralo. Což ale není nutné i když u repliky databáze by to nijak nevadilo, ta se dá za pár minut nahodit znovu z posledního snapshotu.

Ostatní změny nastavení InnoDB konzistenci dat tak zásadně neohrožují. Např. z toho, že se provádí automatický comit po každém jednotlivém přidání záznamu, žádná výhoda neplyne, jen je vše mnohonásobně pomalejší. 

Např. zde je návod jak nastavit InnoDB pro monitoring hovorů. Nastavení je docela brutální, ale brutálně to také zvýší propustnost a sníží zápisy na disk. S tímto nastavením to zvládá ukládat více jak  15 000 hovorů za vteřinu (CPS =calls per second). A to každý hovor vyžaduje více záznamů!
https://www.voipmonitor.org/doc/Scaling#SSDs
Ze zkušenosti vím, že pravděpodobnost, že budou data po výpadku elektřiny nebo pádu kernelu poškozena i při tomto nastavení, není velká.
Jaký přesně mají vliv jednotlivé parametry, i když je to věc naprosto zásadní, zůstává nedokumentováno.

Budu nucen si to nějak vyzkoušet např. vypínáním elektřiny nějakému klonu a zvolit vhodný kompromis.
V případě poškození dat je vždy možné se vrátit v čase 5 minut a začít od posledního snapshotu, což není žádná katastrofa. Navíc zápisy v mezičase budou uchovány na klonech, tedy je možné je doplnit později.


Kdykoli čtu srovnání MyIsam a InnoDB, vždy se píše o výhodách InnoDB, ale to že je v InnoDB defaultně cca 10 krát pomalejší pro zápis, v podstatě vždy zapomene propagátor zmínit. Porovnávám výkon v defaultní konfiguraci. InnoDB je možné zrychlit na úroveň MyISAM, ale důsledky pro bezpečnost dat nejsou řádně dokumentovány. To je pro mne dost překvapivé, když jedním z hlavních výhod InnoDB má být lepší bezpečnost dat a fakt, že se tabulky opraví sami, rychle a plně automaticky.

11

Server / Re:Nevýhody InnoDB oproti MyISAM v MariaDB

« kdy: 18. 04. 2025, 19:49:10 »

Pokud bych nechtěl opouštět mariaDB/Mysql, tak lze použít MyRocks místo innoDB. Chlubí se že má až 10 krát menší zápisy, je optimalizovaná na SSD, měla by umět partitioning a data obsahují několikanásobně méně místa na disku díky efektivní kompresi. Jak je to ale odolné proti výpadkům elektřiny jsem nenašel.
Jedinou zmínku co jsem našel byla.

MyRocks (MariaDB only)   Designed for write-heavy workloads, MyRocks is optimized for crash resilience but might not be suitable for all use cases.

Jestli má MyRocks a Aria stejné nedokumentované nedostatky jako MyIsam co se týče paralelního čtení a zápisů se nelze nikde dočíst.

12

Server / Re:Nevýhody InnoDB oproti MyISAM v MariaDB

« kdy: 17. 04. 2025, 23:42:03 »

Jo a postgresa instaluj z postgresql.org, anzto tuto verzi podporuji originalni timescale baliky
V distre h byva postgres i timescale, ale jenom v pure OSS variante, ktera je orezana a neumi komprimaci. Potrebujes community versi, to je mezistupen mezi pure OSS a komercni variantou

Používám teď FreeBSD, ti na to mají automatizovanou kompilaci/balíček https://www.freshports.org/databases/timescaledb/
Je to ta verze s podporou komprimace? Předpokládám, že by to mohla být ta comunitty (TSL) protože freebsd nemá takové problémy s licencemi.  Mají tam napsáno licence Apache TSL. No mělo by se to poznat minimálně podle toho odkud a jaké zdrojáky to stahuje.

13

Server / Re:Nevýhody InnoDB oproti MyISAM v MariaDB

« kdy: 17. 04. 2025, 23:09:48 »

Mám ZFS, takže některé ochranné prvky, které dělá innoDB jsou zbytečné, protože jsou dělány na úrovni souborového systému.

ZFS je dost pomalý filesystém - a při velké zátěži jsou s ním s databázemi problémy.

To by mohl být jeden z důvodů, proč pozoruji při přechodu na innoDB takové zpomalení zápisů.
Pod Linuxem ZFS nebylo použitelné ani s innoDB, vznikala tam write aplifikace a kromě špatného výkonu to ničilo disky. Tedy používal jsem ext4. Byl jsem pak překvapen, že na FreeBSD se stejným hardware najednou problémy nebyly. A ZFS fungovalo s MyIsam dobře.

MyISAM neřeší konzistenci - zápisy končí ve filesystémové cache - a v případě havárie můžete příjít o data z filesystémové cache - což vzhledem k primitivnímu formátu nemusí být problém - můžete mít ale nakopnutý index, a to už problém být může.

Potvrzuje to je pravda. Ale index menší tabulky lze celkem snadno a rychle jednou za 5 let případně opravit. Stejně tak oprava tabulky jednou za 5 let je relativně rychlá. Větší tabulka se skládá s partition. Mohu to rozbít a opravit jen tu poškozenou, což je také rychlé. Navíc také tu poškozenou mohu přejmenovat a nahradit ji  novou prázdnou.
Celý systém tak v době opravy může běžet bez problémů.

InnoDB má mnohem složitější formát a pokud by došlo ke ztrátě konzistence, tak to není jen o ztrátě pár záznamů.

Myslím že máte pravdu. Když se InnoDB pokazí je to horší a často je lepší začít obnovou ze zálohy.

ZFS vám pomůže jen v tom, že si můžete udělat snapshot a vrátit se k nějakému snapshotu.
Pokud by se ale rozbila konzistence v MySQL, tak je vám ZFS na dvě věci. InnoDB má na rozdíl od MyISAM vlastní write cache - o kterou v případě havárie můžete přijít, a tak musíte mít konzistentní transakční logy. Pokud byste je neměl, tak to, že přijdete o pár záznamů je to nejmenší - můžete mít nakopnutý index, což rozbije vyhledávání - unikátní index nemusí být unikátní, atd atd. MyISAM je do jisté míry "inmemory db", takže některé operace mohou být velice rychlé. Má velice primitivní formát - který je relativně odolný vůči chybám. InnoDB funguje už úplně jinak, a případné chyby konzistence v InnoDB mají mnohem horší dopad.

Ano souhlasím.   Řešením by mohlo být na hlavní databázi nepoužívat ZFS, aby se snížila režie zápisů. Nebo  prostě zvolit vhodný kompromis nastavení. Ale jak přesně jej vybrat?  Také by mohla být možnost,  na hlavní databázi zůstat na MyIsam a pro jakékoli náročnější čtení používat jen neblokující repliky s innoDB, které ale nebudou odolné vůči havárii. Ale může jich být více a jdou relativně snadno znovu nahodit, když se data poškodí. Např. se vrátím k poslednímu snapshotu před havárií a během pár vteřin replika všechno dožene do aktuálního stavu.

14

Server / Re:Nevýhody InnoDB oproti MyISAM v MariaDB

« kdy: 17. 04. 2025, 22:42:02 »

A já nemusel databázi startovat z několik minut starého snapshotu nad ZFS, protože z dat hlavní databáze se stala neopravitelná fašírka.

Nechci býti kverulant, ale to, co s daným nastavením bude na tom ZFS snapshotu patrně bude neopravitelná fašírka taky, jen o 10 minut starší.

Připojuji se k předřečníkovi - fakt tušíte, co děláte?

Snapshot je velmi rychlá operace. Na tak krátkou dobu si mohu dovolit zamknout všechny tabulky a flushnout všechno na disk. Po tu velmi krátkou dobu by měly být blokovány další zápisy, ale nikoli čtení. Tedy pokud to innoDB podporuje. Pak snapshot nebude rozbitý.  S MyISam s tím problém nebyl.

15

Server / Re:Nevýhody InnoDB oproti MyISAM v MariaDB

« kdy: 17. 04. 2025, 22:34:04 »

tak, pokud data nepošleš na disk, těžko ti pomůže zfs .

Např. na ZFS mohu vypnout double write, protože zfs je copy on write a tak se nemůže stát, že něco se zapíše jen napůl.
Také mohu vypnout checksumy.

Kde ty dokumentace vůbec hledáš? Vždyť za ty roky má innodb popsané snad všechny varianty.
Pokud chceš, aby ti zápis neblokoval čtení, tak hledej věci jako dirty ready (READ UNCOMMITTED v innodb).

Mě je ale úplně jedno co mi vrátí select. Tedy jestliže nejnovější zápisy v poslední vteřině vynechá nebo nikoli, nebo je vynechá jen někdy. Důležité je jen to, aby to běželo rychle a efektivně a čtení se zápisy neblokovalo navzájem. Tedy nevím kterou variantu si mám vybrat.

Z tvých experimentů a nastavení mám špatný pocit, vypadá to, že prostě nevíš co děláš. Např. innodb_doublewrite=0 je skvělé, ale v takovém případě musíš na zfs nastavit innodb_log_write_ahead_size na ideálně dvojnásobek page_size, aby nedošlo k částečnému zápisu.

Na tohle jsem nikde nenarazil.  Pokud to někdo nastavuje tak na 16K, ale přitom nenastavuje page_size.

Nastavit innodb_buffer_pool_size na 40G je šílenost.

Na více místech radí, že to má být 70-80% paměti co je k dispozici. Stroj má 64 GB.

Že různí lidé na internetu radí různé věci na mne dělá dojem, že je to opravdu špatně dokumentované.

Podotýkám, že na replice vůbec nejde o bezpečnost dat, protože je to už kopie. A repliku mohu kdykoli obnovit z jiné repliky, co běží na jiném stroji.
Na hlavní databázi, až s ní přejdu také na innoDB, by byla dobrá vlastnost, aby to výpadek elektřiny/pád systému přežilo a po nastartování to mohlo ihned pokračovat. Možná ztráta dat za několik vteřin před pádem není vůbec podstatná.  Navíc se dá obnovit z replik a kdyby se nějaký záznam náhodou neobnovil, tak se celkem nic neděje.