MariaDB verzió szívás [Megoldva]

Azért kicsit gyanús, hogy a default nyelvi beállítás a svéd (latin1_swedish)

Miért, jósokról elnevezni az okés?

a beszolasod alapjan az uzemelteto macik is eleg lustak lettek...
ha az van a dokumentacioban, h X verziorol Y-ra a hivatalos menet, akkor ugy kell csinalni, nem lelustazni a fejlesztot :) ha mar menet kozben elmaradtak a security/bugfix update-ek :)

Inkonzisztens mentéshez: valamikor, 20 éve voltam Oracle tanfolyamon, akkor kb. azt tanították, hogy alter database begin backup,  mentés, alter database end backup, és úgy emlékszem ilyenkor én még újra lementettem a redo(?) logokat. Szóval ~húsz éve volt, nyilván megkoptak az emlékek, de a trükk annyi volt, hogy a motor írta a redo(?) log fájlba is a deltákat, aztán helyreállításkor persze sérült volt a DB, de egy recover database, és kikalapálta a redo logokból (vagy valami hasonlóból).

Plusz ilyenkor már lehetett tranzakciószinten is tekergetni, hogy na, akkor eddig és ne tovább.

Nálam mysqldump megy, mert picik az adatbázisok, és binlog mentés, szóval amikor elkattan valami, akkor betöltöm a dumpot és a binlogból oda tekerek, ahová kell.

Máshol, más körülmények, elvárások mellett valószínűleg más megoldás kell/a jobb.

> mivel a DB ki kell bírjon egy nem várt leállást és úgy ír a fájlrendszerre, hogy abból el tudjon indulni, ezért ez szokott működni, csak az adatok lehetnek kuszák.

Nem, ez nem elvárható működés. Az, hogy "szokott működni" az nem azt jelenti, hogy ez mindig, minden esetben működni is fog. Nem, a DB-nek nem kell kibírnia egy nem várt leállást, mert ezért létezik a (konzisztens) backup intézménye. Sehol nincs leírva a MySQL doksiban tudtommal, hogy ez egy valid mentési stratégia lenne, és egyébként én ezt 20 év alatt többször láttam már nem működni mint igen. És pontosan azért nem szabad erre backupként tekinteni, mert "az adatok lehetnek kuszák" - azaz nem bízhatsz abban, hogy ami az adatbázisban volt a mentés pillanatában, az 1:1 mindenben helyreállítható, sőt, abban sem, hogy a mentés adott esetben elindítható adatbázis szervert eredményez.

Mondjuk egy felelős adatbázisgazdában fel sem merül, hogy élő DB alól FS szinten mentsen mindent, és ezt backupnak hívja.

PostgreSQL esetén amúgy általában WAL-t mentünk - van is erre külön szoftver több is -, nem pedig fájlrendszert. Illetve a PostgreSQL-nek van saját bináris mentési formátuma is. De egyébként a legbiztonságosabb talán tényleg az SQL dump mentése mindkét adatbázis esetében, elsősorban az OP által is felvetett probléma miatt: a szöveges SQL dumpok a legtöbb esetben verziófüggetlenül helyreállíthatóak, és minimális funkcionalitás vesztés történik. Ha valamit hosszú távon meg kell őrizni helyreállítható módon, nagyjából ez az egyetlen garantáltan működő megoldás.

És nincs olyan, hogy "nincs idő se I/O" a mentésre, akkor a rendszergazdát ki kell csapni a picsába, mert alkalmatlan a munkáját elvégezni, és mehet mellé az infrastruktúra architekt is, ha ez két ember volt a cégben. A mentésnek BAU üzemeltetési folyamatnak kell lenni, és nulladik időpillanattól tervezni kell vele erőforrásigényben és időben is. Ritka az, hogy egy cég ebbe amúgy beleállna, mert azt már az üzleti emberek is kezdik felfogni, hogy a backup kritikus a cég működőképességének fenntartásához - ha nem, akkor pedig az üzemeltető feladata ezt elmagyarázni.

MySQL esetében erre - is - jó a Master-Slave replikáció, hogy a slave korlátlanul terhelhető a mentéssel (backip után pedig majd utoléri a mastert), PostgreSQL esetében pedig a pg_dump egyébként alig terheli a szervert, és mocsok gyors is (gyakorlatilag annak az eszköznek az I/O sebessége a limitáló, ahova a dumpot teszi); mindazonáltal pont azért szoktak WAL-t menteni Postgres esetén, mert az gyakorlatilag fájlmásolás, meg sem kell állítani a db-t hozzá semmilyen szinten, és a WAL fájlok mindig konzisztensek. 

csak az adatok lehetnek kuszák.

Ezt adott esetben azért illene tisztázni, hogy milyen kuszaság lehet :-)

Gyanítom, hogy 2. alatt úgy érted, hogy technikailag fájlrendszer pillanatkép ("technikailag" rész 1. és 3. pont nélkül), de ez közel sem ugyanaz, mintha elkezdenéd lemásolni a mappát valahova futás közben: mire végig ér, addigra az adatbázis "eleje" köszönő viszonyban sincs a "végével", például redo logok is kiforogtak. (kolléga winscp-vel másolt...)