Mariadb ibdata1 mérete napi 90 GB-tal nő, de miért?

Adatbázis: SQL, XML DB

Sziasztok!

A táblák külön .ibd fájlokban vannak, de a /var/lib/mysql/ibdata1 fájl ennek ellenére napi 90 GB-ot nő. Mi a túrótól lehet ez?
Debian 12, innodb minden tábla, a teljes adatbázisméret 45 GB. Van pár olyan tábla, amiben gyakori a módosítás és van olyan is, amibe gyakori az írás és utána a perceken belüli törlés, de nem tudom mi indokol az adatbázis méretéhez képest kétszeres növekedést naponta. Ekkora index nincs...
ib_logfile0 mérete 100 MB.

Hogyan tudom egyáltalán megnézni, hogy mi milyen arányban van ebben a fájlban?

Előre is köszönök minden ötletet.

  • 3300 megtekintés

( Rt711 v | 2023. 08. 21., h – 23:28 )

Szerkesztve: 2023. 08. 21., h – 23:32

Változások követése, update-ek is ebben vannak követve ha jól emékszem, ezért növekszik olyan gyorsan.
A metódus az hogy csinálsz dumpot, aztán vagy helyreállítod másik gépen vagy törlöd a filet és backupból visszarántod és reméled hogy menni fog. Mondjuk azért ezt teszteld le élesbe bevetés előtt.

Ezt olvast át:
https://stackoverflow.com/questions/3456159/how-to-shrink-purge-ibdata1…

Gondolom van rendes monitoring meg minden alatta mert ezt bizony tutujgatni kell.
Holnap ránézek kikukáztam e valami emberibb megoldást, mert emlékszem hogy ebbe vagy ilyesmibe beleszaladtam már.

InnoDB-nél még érdekes hogy ha auto-increment ID van nézd meg hogy van kihagyás (1,2,3,4,5 helyett lehet 1,2,5), és ha mondjuk a schema rosszul van belőve akkor túlcsordulhat és blokkolni fog.

( petya | 2023. 08. 21., h – 23:35 )

Alapvetoen 2 dologtol lehet: a change buffertol es az undotol. Ha erdekes a napokban leirom reszletesen, hogy melyik micsoda es melyik esettel mit lehet csinalni.

Ok, en is leirhatom ezerszer, hogy google. Nem is a sztekkoverfló a barátom, kivéve, ha hirtelen lenne valamire szükségem, ami nálam minuszos.

Komolyra fordítva:

En elobb hiszek egy itteni kolleganak, mint egy -allitolag divatos szó- adatnindzsának. Egy cikk egy hozzáértőtől szerintem tízszer jobb, mint google találati lista.

Error: nmcli terminated by signal Félbeszakítás (2)

( arpi_esp v | 2023. 08. 22., k – 09:19 )

kovetem.

durva meretek... lattam mar nagy forgalmu mysql db-ket de a kozelebe se voltak ennek...

ha van egy gyáram, benne 1000 szenzor, 100msec-es mérési adatokkal, ahol a mérési adathoz elmentünk még metaadatokat is, és egy rekord kb. 200 byte, akkor ez 24 óra alatt 1000 * 10 * 200 * 60 * 60 * 24 = 1,728*10^11 byte, ami 172 gigabyte naponta. Nem olyan nagyon sok ez. Az egy dolog, hogy ebből mondjuk havonta/hetente dobunk ki adatokat aggregáció után, de nyers adat simán lehet ennyi egy nap. És ez egy kis méretű gyár csak. És akkor arról még nem is beszéltünk, hogy jó lenne elmenteni a fotószenzorok adatait is a termékéletút-követéshez, utólagos hibafelderítéshez, de az meg nem is DB.

megnézem: az egyik tesztadatbázisunk éppen 400 GB körül van, ebbe nincs is belekötve minden szenzor, meg időnként teljesen ürítjük is.

Attól még, hogy ez idősoros adatbázis, attól még a mérete ennyi lesz (amúgy SQL-lel lekérdezhető idősorra optimalizált adatbázist használunk). És hát az adatbázis is bináris fájlba ment, ami pont a rekord-alapú adattárolásra van optimalizálva. :) Szóval még mindig nem értem, miért lenne olyan túl sok napi 90 GB-nyi adat egy adatbázisban. Nem kell, hogy ez relációs adatbázis legyen feltétlenül, de attól még adatbázis.

Mik? :) Mert pont enterspájz háttérrel nem szokták érteni, hogy a web nem szólhat egy könyvnyi tárolt eljárásról, meg kutyafüléről, meg 50 millió rekordról, mert azonnal kell az eredmény. Bónuszként párhuzamosan sok lekérdezés fut, nem a pénzügy elindít egy valami, ami ha pár percig elsakkozik, akkor sincs semmi, hiszen mindenki ideje fizetve van, és szépen megvárják.

( kruska v | 2023. 08. 22., k – 09:45 )

Nincs valami olyan tranzakció esetleg, ami régóta fut? Mit mond a "show engine innodb status" ?

Hogyan tudom egyáltalán megnézni, hogy mi milyen arányban van ebben a fájlban?

Az "innochecksum /var/lib/mysql/ibdata1" megmondja, de ez csak lekapcsolt adatbázisszervernél lehetséges (amikor úgyis megszűnik a feltételezett kiváltó ok, mert a tranzakció rollbackelni fog).

Bocs, hogy beleszólok, de én egy elég csúnya deadlockot látok benne.
2023-08-22 12:54-kor futtattad a parancsot.
2023-08-22 10:36 óta van egy csúnya deadlock. Ez 2,5 óra alsó hangon.

Továbbá tele van "Record lock, heap no 2 PHYSICAL RECORD: n_fields 17; compact format; info bits 0" lockokkal. A heap-t hízlalva.

A tévedés jogát fenntartom.

Mondjuk a deadlock szerintem nem azóta áll fenn (amúgy is eltimeoutolna ennyi idő alatt), hanem akkor történt utoljára. Mindenesetre az, hogy egyáltalán történik, nem olyan jó jel.

Első látásra nem látok hosszan futó tranzakciót (4 sec a maximum), tehát önmagában nem ez lehet a gond, inkább az indított tranzakciók/lockok mennyisége, de este megnézem jobban.

Hat ize orankent tok folosleges menteni valamit ha csak nincs szabalyozas ra, hogy az egy oranal regebbi adatok nem veszhetnek el. Ez egy eleg eros RPO.

Ha ez ilyen problema es tenyleg orankent kell menteni, akkor inkabb valami low level megoldasban gondolkodnek:

* mint a diszkalrendszer pooljainak szinkronizalasa egy masikra

* incremental snapshot a diskrol

* replikalas

* valamilyen point-in-time recovery megoldas (like in cloud)

A replikáció alapból egy élő másolatot tart realtime szinkronban a mysql/mariadb történetben. Hacsak erről nem készül valamilyen mentés, akkor nem világos mitől jobb. A replikát futtató szerver értelem szerűen elsakkozhat vele, ez oké. A replikációnál a másik dolog, hogy előfordulhatnak olyan query-k, amik nem teljesen replikáció barátok, és beakad a másolati példány.

attol fugg, hogy a sql parancsokat replikalod, vagy binaris replikacio, es a valtozott rekordokat. de igen, ez megint egy olyan tema, ami a sql -ben egyszerunek tunik/eladott, de valojaban egy abszolut can of worms, mert nagyon egyszeru non-determinisztikus query-ket kesziteni, ami aztan replikacio utan mashogy fut le a secondary node-on.

de hogy ontopic legyek, mysql replikacio az un. 'binlog' -ra epul, ami feljegyzi a parsed formajat a vegrehajtott query-knek. Ezt utana vissza lehet jatszani egy backup-ra. Tehat ha te csinalsz pl. ejszaka egy full dump-ot (akar FS szintu snapshot-tal pl.), akkor a binlogot replay-elve tetszoleges idopontot vissza tudsz allitani.

A snapshottal óvatosan, mert ugyan erről már volt N+1 parázs vita, nem lehetsz benne biztos, hogy adatbázis szinten is konzisztens lesz a snapshot. Igen, értem hogy szokott sikerülni, de ettől még ezzel lehetnek bajok.

A MySQL tud egyébként bináris naplót, amiből vissza lehet mazsolázni a dolgokat, egy dumphoz képest. Ez gondolom nem véletlenül került bele. :)

Replikáció inkább folytonossági megoldás, ami technikailag egy élő másolat, hacsak nincs késleltetve a szinkron. A másik eset, hogy célszerűbb a replikált példány menteni, hogy az éles db ne halljon bele a forgalomba. Ilyenkor nem árt figyelni, hogy a replikáció tényleg folyamatos legyen, ne akadjon be.

Mindenképp óránkénti mentésre van szükség?
Ha a mentési gyakoriság sűrűbb, mint amennyi ideig 1 példány mentés lefut, akkor már maguk a mentések problémát okoznak. Egymásra futnak, lockokat generálhatnak.

Néhány tuning javaslat:
- Nem mindegy, hogy melyik lemezre készül a mentés. Ha ugyanoda, ahol maga a DB is lakik, akkor az nem jó teljesítmény szempontjából. A backup készüljön más lemezre / RAID tömbre / SAN lun-ra.
- Nem biztos, hogy megéri rögtön tömöríteni a mentést pl: gzip-pel. Eszi a CPU-t és lassítja a mentési folyamatot. A tömörítés megtörténhet később is, csökken így a mentéshez szükséges idő. Ellenben több szabad lemezterület kell.
- Ha több DB van, akkor érdemes őket külön menteni, külön időzítve. Így kevésbé okozhat lockot "A" adatbázis mentése "B" adatbázis számára.

Néhány megoldás:
- Komolyabb mentőszoftver be tud épülni a MariaDB-be és így tud konzisztens mentést csinálni. Hátránya, hogy ha hosszú a mentési folyamat (>30-40-80 perc), akkor ugyanúgy fog gondot okozni.
- Csinálsz egy replika szervert (slave, secondary) MariaDB szinten és a mentést a replikán indítod el. A replikáció legyen csak egyirányú. Továbbá a replikáció legyen szüneteltetve a mentés idejére - ha szükséges. Majd később utóléri a replika DB is az éles DB-t.
- Tranzakciós logokat mentesz akár az éles, akár a replika szerveren. MariaDB-nél ez binlog névre hallgat, ha jól emlékszem. Ezerszer gyorsabb, mint a teljes DB-t végignyálazni, inkrementálisan/differenciálisan menteni.

Igazatok van abban, hogy ez nem jó mentési stratégia ide.
Óránként 10-20 percig fut, a korábbi 1-2 perc helyett. Eredetileg egy kisebb adatbázishoz készült, egy teljesen másik rendszer alá.

Csak azokról a táblákról készített dumpot, amik változtak. A nagy és nem lényeges táblák ki voltak zárva az óránkénti mentésből.
Most pedig ahogy nézem szinte minden tábla minden órában változik. Ráadásul sok logot a webes kollégák adatbázisba tesznek, ami soha nem lesz kisebb, csak nagyobb.

Kum Gábor

Az 1-2 perc az teljesen rendben van, jól látod. Az a 10-20 perc már sok.

Azt a log táblát akkor tessék már particionálni. Mondjuk legalább havonta. Az X időnél régebbieket pedig eldobni vagy archiválni - akár egy archív adatbázisban, akár dumpban. Eszméletlen mennyiségű erőforrást lehet így megtakarítani.

A mysqldump --single-transaction kapcsoloval megy? Nezd meg az xtrabackup-ot, az binaris mentest csinal, vagy a mariadb-s verziojat ha mindenkepp a mariadb-t szeretned. Ujabb mysqlekben mar lehet korlatozni az undo space meretet, hogy ez ne tortenjen meg, viszont ha kifogysz belole, akkor a hosszu tranzakcio lesz lelove. 

Ha csak az a cel, hogy 1 oranal kevesebb adatvesztes legyen (1 ora az RPO), azt point in time recoveryvel meg binlog mentesekkel egesz konnyen ossze lehet hozni.

Mondjuk a memóriamenedzsmentet megnézhetnéd, mert nagyon szűknek tűnik a buffer pool size ekkora adatbázishoz ekkora terheléssel, ez is okozhat szűk keresztmetszetet.

Nem mondom, hogy most kell egyszerre széttúrni mindent, de azért nézd meg.

( kruska v | 2023. 08. 23., sze – 10:03 )

Inkább enterprise adatbázisokkal dolgozom, de utánanéztem pár dolognak MySQL-ben.

Nekem úgy tűnik, az alulméretezés miatt bedugul az adatbázis, az ibdata1 hízása inkább csak másodlagos tünet: a feltorlódó tranzakciók ideiglenes adatai miatt.

Ha van használható memóriád, mindenképp növeld meg a buffert. Kis olvasnivaló hozzá:
https://www.percona.com/search?search=innodb_buffer_pool_size

(TLDR: ha másra nem használod a DB szervert, odaadhatod neki a fizikai memória 60-70%-át, de a gyakran használt táblák mindenképpen férjenek bele, érzésre >10G kellene ekkora DB-hez, hacsak nem valami szélsőséges jellegű használat van)

( kumgabor v | 2023. 08. 23., sze – 16:11 )

Szerkesztve: 2023. 08. 23., sze – 16:17

Időközben sikerült lokalizálni a problémát némi hozzáértő segítséggel.

Van egy tábla:

syncronize_data

Column Type Comment
id bigint(20) unsigned Auto Increment  
user_id bigint(20) unsigned  
data_name varchar(255)  
data_value varchar(255)  
created_at timestamp NULL  
updated_at timestamp NULL  

Indexes

PRIMARY id
INDEX user_id

 

Ezen a táblán kb. 3000 update-et csinálnak másodpercenként, folyamatosan. Ha azt a programot, ami ezt csinálja leállítjuk, a fenti problémák megszűnnek.
Debian 11 -> 12 frissítésig ez nem okozott ilyen tüneteket, de utána igen.
(Mariadb 10.5.19 -> 10.11.3)

A fejlesztő kollégák most - logikusan - azért kérnek számon, mert eddig nem volt vele gond, frissítés után pedig lett.
Feljebb írták, hogy az óránkénti dump is rátehetett egy lapáttal a dologra, most tesztként leállítottam.

Kum Gábor

Lehet eddig is gond volt vele, csak máshogy.

Láttam már olyat, hogy volt egy specifikáció, de az implementáció rosszul volt megírva és nem rángatott meg egyéb dolgokat, amelyeket kellett volna.
A fejlesztők simán építkeztek rá, mert nekik nem kellett a rángatott cucc.

Az alaprendszer fejlesztői észrevették, hogy hohó, ez itt nem rángatja a dolgot, pedig kéne és javították a hibát és ez a Debian verzió upgradenél mindenhova települt.
A fejlesztők meg azt vették észre, hogy hopp, van itt sok deadlock, meg hogy miért vannak ezek meg azok rángatva.

Szóval simán előfordulhat nálad is ilyen, ha a MariaDB-ben valami olyat javítottak.

Ezen a táblán kb. 3000 update-et csinálnak másodpercenként, folyamatosan.

Ilyenkor a fejlesztőt a szőnyeg szélére állítani és behajlított térddel álljon ott, amíg nem ad normális magyarázatot erre a működésre. Nagyon kevés olyan élethelyzetet láttam, ahol ez a terhelési profil normális lenne.

Ha a fejlesztő szerint ez normális, nincs vele semmi gond, akkor elzavarni Szibériába követ bányászni.

Ajaj, hogy képzeled, hogy a magasságos fejelsztő urat bárki is kérdőre vonja. Mindíg elvérzik a dolog ott, hogy prezentálva van a probléma konkrétan, hogy ezt így ebben a formában vagy 4x drágább gépen (3x annyi havidíjért, lásd áram) lehet futtatni, és az sem biztos, hogy elég, vagy lesznek szivesek hegeszteni rajta. Esetleg például az 1821-ben felvett rekordokat törölni, archiválni.

Azt látom, hogy akinek többet fizetnek annak úgyis igaza lesz, és "dehát aszondta a fejlesztő" után megállnak a dolgok.

Itt nem az a lényeg, hogy kinek van igaza, mert ez időponttól, helyzettől függően változik.
Hanem, hogy ki hajlandó normális minőségben elvégezni a munkáját jó minőségben. Aki sorozatosan pocsék, ipari hulladékot ad ki a kezei közül, annak nincs helye az IT-ban. Esetleg menjen helpdeskre vagy LED figyelő operátornak, ott nagy galibát nem csinál(hat)...

Hát ezt beszéld meg fejlesztőékkel, folyamatosan keringenek ezek ideoda, és elképesztő magasságokba tudják felvinni az orrukat. Egyébként volt már olyan, akit sikerült jobb belátásra téríteni, amikor sorban látta, hogy igazam van. A megrendelői oldalon pedig sokszor hiányzik a tudás, és az elszántság, hogy végigvigyek, bevasalják a normális minőséget, és inkább fizetnek brutál pénzeket, csak ne kelljen vele foglalkozni. Egészen véletlenül előkerülnek üzemeltetési opciók a fejlesztői oldalról, hogy véééégülis meg tudják oldani, és persze a megrendelő a szerinte biztosat választja inkább. Ezzel nekem nincs is bajom, de akkor miért nem így kezdték, és fárasztottak mindenkit fölöslegesen.

Ohh, én imádok fejlesztőkkel beszélgetni. Tényleg. Érdekel a látásmódjuk, gondolkodásuk, szeretem tudni a "miérteket".

Néhány főbb sztereotip kategória, akikkel eddig találkoztam:
- "Vállalkozó fejlesztő". Örül, ha végre akad egy normális üzemeltető, akivel meg lehet beszélni a dolgokat, lehet "együtt gondolkodni". Nem ellenséget lát, hanem partnert. Általában ez az idősebb kollégákkal (50+) működik jól. Projektmunkáknál vállalkozóként is jól működik, hiszen mindenki le akarja zárni a projektet sikeresen - addig nincs pénz.
- "Néma fejlesztő". Ők általában juniorok, nem egyetemet végzettek, lehet őket formálni minden irányból. Nekik a programozás hobbi. Ha sikerül megnyílniuk, akkor mernek kérdezni a tapasztalt kollégáktól. Rá lehet döbbenteni őket, hogy mennyi mindent nem tudnak még.
- Normál senior. 30-40 körüli. Általában már családos, gyerekes. Kevés szabadideje ellenére szeret kísérletezni, POC-t gyártani. Érdeklődik új megoldások iránt. Mégse akar péniszméregetőset játszani se az üzemeltetéssel, se mással. Ügyfélképes.

A nehezebben kezelhető típusok:
- Ifjú titán, egyetemet éppen elvégzettek. Arcuk óriási. Juniorok, de már seniornak képzelik magukat. Üzemeltetési téren is. Könnyű őket zavarba hozni már egy közepes fajsúlyú problémával is. Ha letörik a szarvuk és alázatot gyakorolnak a munka iránt - nem a munkatársak iránt! -, akkor lehet belőlük jó szakember. Sokszor győzködni kell őket üzemeltetőként, mert az egyetemről hozottak hiányosak - finoman szólva.
- Nagyképű. A már 10+ éve az iparban dolgozó, 30-40 körüli, óriási pofával rendelkező. Beképzelt. Lusta. "Leszarom" mentalitást képviseli. Szerinte ő dolgozik egyedül a cégnél. Rossz esetben leragadt 1 programnyelvnél - pl: Delphi. Rosszabb esetben ugyanazon a projekten dolgozik 5-10 éve. Legrosszabb esetben a cégvezető/tulaj haverja, gyerekkori barátja is. Friss tudása kevés. Na, vele gyakori a konfliktus. Olykor ez eszkalálódik a cégvezető / tulajdonos / megrendelő felé is. Ha sikerül elérni, hogy a munkája minősége érdemben kihasson a fizetésére, akkor átalakulhat kooperatívvá a vele való munka. Nyomás alatt kell tartani.
"Tányérok repülése" esetén nem érdemes vele kettesben tartózkodni. :)

Mindegyikhez volt már szerencsém. Szerencsére olyan alkat vagyok, aki az emberek 99,99%-val megtalálja a közös hangot. Sok embertípushoz óriási türelem és rutin  kell. Szerintem ez is tanulható.

Szerintem nem biztos, hogy mindenkivel meg kell feltétlenül találni a közös hangot, pláne amikor a második blokkosoktól jön a "neki erre nincs ideje", "ne fárasszuk", sőt konkrétan odavágja, hogy márpedig az ő ideje nagyon drága... Az első blokkban lévőekkel valóban el lehet lenni, sőt jól együtt lehet működni. A második blokk erősen kétesélyes, és sajnos esetemben valahogy mindíg szuperpozícióban vannak a megrendelőnél. Jön a "ez így márpedig jó, oldja meg az üzemeltetés". Aha, tehát adjunk egy 3x ajánlatot a hw igényre? Mire gondolnak ilyenkor?

Ahhoz szerintem szerencse kell, hogy egy valaki elszálltat vissza lehessen hozni a földre.

Meg kell tanulni eszkalálni a helyzetet. Tudom, ez sokszor nehéz. Ennek része, hogy az állításodat bizonyítékokkal kell tudnod alátámasztani. Ha kellően magasra ér a cunami, akkor el szoktak indulni pozitív változások.

Árajánlat: Simán be kell nyögni az alternatívákat költségekkel együtt. Nem szabad szívbajosnak lenni. Aztán a megrendelő majd eldönti, hogy melyiket választja. Le kell tudni írni, hogy az üzemeltetés mire és meddig vállal felelősséget.

Olyat is láttam már, hogy az üzemeltető belenyúlt a fejlesztő kódjába. Volt is belőle kis asztalcsapkodás. Aztán amikor kiderült, hogy az üzemeltető jobban ért a fejlesztéshez, akkor meg pislogás...
Nem szabad hagyni a fejlesztőket "elszállni". Időben kell fellépni.

 Köszönöm szépen 20 éve csináljuk., vártam, hogy végülis kifut oda, hogy mennyire kell majd még fejlődni. Próbálja meg esetleg más is. Én már ezekbe a harcokba belefáradtam. Elmondjuk, eszkaláljuk, bemondjuk stb. Voltam már kénytelen belenyúlni kódba, meg sql indexelni a nagytiszteletű fejlesztő helyett, aki csak hajtogatta a marhaságait, és ez annyiban jött le a megrendelőnél, hogy oké, lehet tovább robogni, semmilyen konzekvenciát nem vont le (miután masszivan lealkudta a pénzünket, és állandóan hallgattuk, hogy jajjde drágák vagyunk, hiába irányottuk a fejlesztőhöz, hogy ez ott dől el). Nem érdekes semmi, csak 3mp-nél többet semmivel ne kelljen foglalkozni. Egyébként ki vagyok én, hogy a 3-4x-es óradíjjas fejlesztő helyett melózzak... Igen, fontos a pénz, meg egy idő után baromira visszás, hogy a sysadminba törlik a csizmát, úgy, hogy jóval erősebb a díjazásuk. Hát ez van, lehet kiégős duma, de majd ha elfogynak akik valamennyire átlátják a dolgokat, akkor majd talán kapcsolnak. Akkor majd újra 3mp-ig fontos lesz valami...

Ohh, akkor nagyjából azonos ideje vagyunk az iparban. Én ~25 éve "élvezem" az IT-t minden szépségével és gyötrelmével együtt. Azt is tudom, hogy sok mindent könnyebb mondani, mint csinálni.

Teljesen értem és megértem, amiket írsz. Kicsit a kiégés, belefásulás jeleit vélem felfedezni benne. Nálam is előfordul olykor - akkor szoktam pihenni vagy munkahelyet váltani.
Nyilván zavaró, hogy semmibe vesznek. Nyilván nem ismerem sem a munkaerőpiaci, sem egyéb lehetőségeid - Bp egy más világ ezen a téren is, mint vidék. A problémás ügyfelektől, mérgező és energiavámpír munkahelyekről szabadulni kell, ha lehetséges.
Azt is lehet csinálni, hogy 100 pezeta helyett kérsz, majd kapsz 300 pezetát és akkor legalább megfizetnek. A magasabb fizetés legalább kompenzál(hat) valamit....

miután masszivan lealkudta a pénzünket, és állandóan hallgattuk, hogy jajjde drágák vagyunk

Ilyenkor teszek rá az ügyfélnek adott árra egy 3-4x szorzót szívbaj nélkül. Egyrészt csak tipikusan előadja a hattyú halálát a megrendelő, próbál pszichikailag megtörni titeket. Jó taktika, sokszor bejön.

Pszichikailag fontos, hogy az ember ne vegyen mindent a nyakába. Fontos a "nemet mondás". Szerintem.

> kiderült, hogy az üzemeltető jobban ért a fejlesztéshez

hat ez nalunk eleg gyakori, persze ehhez az is kell hogy a vilag legidiotabb/benabb fejlesztoit bizzak meg minden projekttel, igy nem nagy kunszt...  amikor mar hetek ota szenvednek neha megszanom oket es kijavitom a bugot a kodjukban, aztan csak pislognak.

persze visszatero elem a "de az en laptopomon mukodik, nezzek meg, szoval a tarhely/szerver a szar", aztan kiderul hogy a C:\melok\ugyfelneve\lofasz.php-t includeolja valahol, igy ilyen path-al, vagy valami hasonlo okorseg...

meg amikor a fejleszto 10 rekorddal teszteli a cuccot, a szreveren meg beimportalnak 5milliot es fejreall az egesz, mert pl. indexet nem rakott a tablakra, vagy ugy gondolta jo otlet a kliensen js-bol az egesz tablat beolvasni egy tombbe, mind a 2GB-ot...

a securityt meg hagyjuk is... ha nem a sajat szememmel latom nem hiszem el: http GET-ben az url-ben ment a bankkartyaszam... ja azert le volt base64-elve, ez volt a "titkositas".

vagy egy egyedi webshopnal a szamlak url-je domain/szamlak/00016543.pdf  ahol a szam a szamla sorszama. termeszetesen a szamot novelve/csokkentve a tobbi ugyfel szamlai lathatok, mindenfele auth nelkul. a fejleszto meg ertetlenkedett, de hat neki kell egy auth nelkuli url a pdf-re amit kikuld a mail-be.

vagy a regisztacios email ellenorzo link amiben csak az email cim van benne (kb. domain/emailverify.php?cim=joska@mail.com)

es a legszornyubb hogy a fejlesztok nem is ertik mi ezekkel a baj...

Ha az on-call -t mintkét csapat viszi az "én 5kor befejeztem és a többi a ti bajotok" hozzáállású emberek elkezdenek gondolkodni milyen rendszert álmodnak meg.

Nálunk kötelező a negyedéves security training, van fejlesztőknek és üzemeltetőknek is. Külön security csapat átnézi a projekt tervet, és a diagramokat így a fenti problémákkal megtűzdelt projekt már ott elhasal és amig a design document -ben benne nincs hogyan van x probléma kezelve, addig le van állítva a dolog. Persze van aki immunis a tanulásra, és eszméletlen energiába kerül ezeknek az embereknek a terelése.

Automatizálva van a: compliance reporting, security scanner. Ha release-t adsz ki akkor be kell vonni a managert. Ezektől éves bónusz függ, szóval ezt illik jól csinálni.

Prod-ba csak úgy nem lehet telepíteni, kell legyen vagy build pipeline ami multi-environment vagy ha ez olyan emergency eset akkor a manager hagyja jóvá a release-t.
Ha ez kieséssel jár és ügyfeleket érint, hát az nem jó, nagyon nem.

"Én gépemen" nem játszik mert konténer tag és build van amire hivatkozni lehet, vagy egyéb módja a release-nek.

Ez az egész nem egy ember munkája, hanem csapatmunka és céges filozófia kérdése. Ha nincs meg az akarat, erőforrás sem lesz biztosítva, és semmi jó nem sül ki belőle. Egyedül nem fogod tudni megváltani a világot.

Néha nehezemre esik elhinni vannak emberek akiket nem érdekel a saját szakmája, pedig van ilyen.

Az egy másik szint... Egyébként aki magolásból, meg ilyen skillekből jó volt, az ezeken átmegy, hiszen a vizsgára készülünk lesz ami lesz, aztán majd vagy javul a kódja vagy nem.

Szóval ha a fejlesztés közepével, tetejével találkozol, ott azért az általános helyzet jobb szerencsére.

Valójában nem a szakmája nem érdekli, hanem valszin messze túlmutat a tapasztalatán, vagy esetleg képességein a történet. A megrendelői oldal is képes csodákra, mert egy kisebb vállalkozás az nemnagyon szokott (nem tud...) érdemi IT elvárásokat támasztani. Kód működik, rendelés jön, vagy folyamat lefut, bódottá van. Nemrégen egy elvileg progmat körüli ember PHP kódjában bukkantam olyanra, hogy fogtam a fejemet, és ez egy méret SQL injection volt. Ott bukott ki, hogy jajjhát az X dolog nemmegy, biztosan van valami a szerverrel. Hát igen volt, nyilván végigtolja a robot az összes url-ben áttolt változót, és talált is hibát, aztán pörgette az sql-t boldogan. Nem MySQL-ről, hanem azért komolyabb történetről volt szó. Megadtam a javíŧási tippet (igen erős változó ellenőrzés, mert az isset() az nemaz), és hogy ezen felbuzdulva mindent át kéne nézniük. Megköszönték, és majd nézik, de azóta hozzám nem jutott el egyéb. Megnézni nem merem. :)

(A mod rewrite-os vagy hasonló védelmek nem ördögtől valóak, de attól nem lesz valójában biztonságos a dolog, hanem egy valamire bekerült egy duct tape.)

Ez a PHP kód gondolom valami projekt keretében készült. Van ott architect, project manager? Tippem szerint nincs...

Az IT kicsit olyan, mint az építészet. A megrendelő mindkét esetben nem akar / tud belemenni a szakmai részletekbe. Épületeknél ő leragad az elrendezésen, tájoláson, ablakok helyén és számán, esetleg a burkolatok anyagminőségén, színén. De nem kell értenie az alapozáshoz, a betonozáshoz, statikához, a szabványokhoz, hőhidak elkerüléséhez stb. Egy jó kivitelező nem csak "ki vitelezi" a befektető pénzét...
Építészetnél megvannak a szerepkörök, hogy ki miért felel (elvileg). Számon is lehet kérni őket.
IT-ben ez miért nem jellemző? Miért hagyja / hagyjuk / hagyják, hogy IT szemetet gyártsanak? A kérdés részben költői....

Amikor sokadszor a sokadik cégnek, vezetőnek mondod el, hogy N probléma van, nem fogja 10e forintból megoldani stb, és közben csak lenézően mosolyog, akkor hovamitminek. Sajnos azért hiszi el, hogy 10e forintból megoldja, mert valaki hirtelen felindulásból bemondta neki, hogy akkor az annyi, sőt valamit gyorsan csinált is szivességből, és hirtelen megszűnt a probléma (fél hónapra kb.). Meg azt is, hogy háromperces dolgok vannak igazából, minden csak három perc. Ahol rendes a hozzáállás, oda baromi nehéz bekerülni, kb. születni kell, vagy szerencse kell hozzá.

A nincs pénz dologgal meg ne jöjjenek, mert havonta többet költ cégesautóra az illető, mint az egész éves IT büdzsé. Ami nem IT büdzsé, hanem egy ilyen zavaró tényezők, akik amúgy is állandóan fárasztják. Az első orbitális fejreállásig valszin, mert utána vagy magához tér, vagy megszűnik a cég.

Erre is nehéz 1-2 mondatban válaszolni, de megpróbálok. Elnézést, ha valahol keverem a Pgsql-lel. És elnézést a hosszért.
Klasszikus szerverhosztingról (IaaS) írok. PaaS, SaaS kicsit másabb.

Először is vegyük ketté: A.) béna szolgáltató, B.) profi szolgáltató
A.) Simán rápakol több ügyfelet ugyanarra a DB szerverre. Akár Mariadb, akár Postgresql, akár MSSQL, akár DB2 stb. Próbál a DB adta lehetőségeken belül limiteket beállítani. Például: connection/sec, query/hour, update/hour stb. De ezek kb. annyit érnek, mint halottnak a csók. Közös lónak túrós a háta. Mindig.
Amit még megtehetnek, hogy tényleg dedikált DB szervert raknak a feladathoz. Megfelelő mennyiségű cpu, ram területtel. Továbbá a lemezrendszer is nagy teljesítményű (akár full SSD SAN) és jól elosztott.
Mit jelent a jól elosztott? Több tablespace van, a data, index, log, temp mind külön lemeztömbre / LUN-ra / RAID tömbre / SAN storage-ra kerül. Azaz a DB fájlai más helyen tárolódnak. Egy intenzív Temp használat nem nyírja ki a többi tablespace-t, nem okoz I/O várakozást. Ezt még lehet cizellálni akár ügyfelenként is, de akkor már átlépünk a B.) verzióra.
Pár link a témában, amit most találtam:
- http://underpop.online.fr/m/mysql/manual/mysql-server-administration-us…
- https://mariadb.com/kb/en/server-system-variables/
Ha hiba / teljesítmény probléma van, akkor általában az ügyfelek elkezdenek panaszkodni. Aztán a szolgáltató meg nyomozhat, hogy vajon kinek a DB-je nyírja a rendszert. A szolgáltató részéről proaktivitás minimális.

B.) Ügyfelenként van külön DB szerver. Ügyfél által igényelt beállításokkal és paraméterekkel. Nem okoz gondot, ha egyik ügyfél OLAP, másik OLTP, harmadik DW (data warehouse) módon használja a DB-ket. Szépen hozzá lehet igazítani a használati profilok alapján. Erősen szabályozott a QoS cpu, ram, disk szinten is.
Ügyfelen belül is lehet másik DB szervert beállítani, ha a beállítások, költségek, teljesítmény igények indokolják. Elvileg egyik ügyfél / DB sem zavarhatja a másikat - nem okoz gondot, ha egyik pörgeti a lemezeket. A lemezrendszer jól elosztott és jól konfigurált. Természetesen ez a megoldás jóval drágább, mint az A.) verzió. PaaS, SaaS esetén csak ez játszik.

Klasszikus szerver upgrade - nagyon erősen zanzásítva:
Egy normális helyen van legalább dev, test, prod környezet - persze lehet mellette UAT, stage, preprod is más-más célra. Külön szerverekkel / vm-ekkel / konténerekkel. Az upgrade része, hogy az ember elolvassa az upgrade notice-t, guide-okat, elolvassa a changelogot. Ennek figyelembe vételével kockázatelemzést végez (hol bukhat el a frissítés). Van rollback planje
Majd először a dev környezetet frissíti. Elemzi a frissítés során keletkezett logokat, elemzi a monitoring rendszerből jövő adatokat, megvárja a fejlesztők visszajelzését a frissítésről.
Ha minden oké és az esetleges hibák elhárultak, akkor felkészíti a test környezetet is a frissítésre. Végigmegy ott is a lépéséken. Felírja az esetleges problémákat, megoldja - akár közösen a fejlesztőkkel. Próbál jóslást végezni, hogy a prod rendszerben mi borulhat meg, minek a teljesítménye változhat.
Majd ha minden oké a test rendszerben és felülről is rábólintanak, akkor jöhet a prod rendszer frissítése. Ha jók a folyamatok a cégnél, van CI/CD, van monitorozás, akkor - elvileg - nem szabadna a prod rendszerben nem várt hibával találkozni. Olyan simán kell mennie a frissítésnek, mint a sicc.

Lehet itt behozni devopsot, agile-t, attól még a folyamat érdemben nem változik. A legkisebb kockázatú rendszert frissítjük először, majd megyünk tovább a nagyobb kockázatúak felé. Csak akkor lépünk tovább, ha minden problémának tudjuk az okát és meg is oldottuk őket. Dokumentálunk, ahol csak lehetséges. Nem húzzuk az upgrade folyamatot hónapokig. Ideális esetben egy ilyen upgrade-nek 1-3 hét alatt le kell futnia - multinál / nehéz ügyfeleknél lehet ez hónapok kérdése is. Csak az meg szart se ér.

Hogy hogyan kell jó dev, test rendszereket építeni, mikor lesz használható, arról meg könyvet lehetne írni. Szerintem. :)

Aurora clustert használok MySQL engine-el.

Attól függően hogy v1 vagy v2 Aurora-t használsz minimális karbantartást igényel. v2 Aurora serverless automatikusan skáláz v1 pedig jelenti ha baja van.

Ezekkel a paraméterekkel + állandó monitoring sikerült gatyába rázni hogy elbírja a prod terhelést, eltartott mire megtaláltuk a megfelelő instance type-ot is:
https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQ…
És persze CloudWatch monitoring ami össze van lőve Grafana-val szóval lehet nézegetni hogy mikor melyik paramétert kell tuningolni ha kell.
Ha sok az adat, a schema nincs rendben vagy a kliensek nem cachelnek akkor azt nagyon drága ám normálisan fenntartani, felhő nem old meg mindent.

Legtöbb dolog terraform és a schema lambda-val kerül betöltésre.
Upgrade tesztelve van több környezetben is mielőtt élesbe megy (van 3, de igazából ez több mert a dev olyan hogy bárki beránthatja magának és újrakezdheti az egészet x verzióból).
Napi backup 30 napra visszamenőleg.
Upgrade előtt backup mindig.
Van change management.

Üzemeltetési oldalról logikusnak tűnik nekem egy olyan megoldás konkrétan erre az esetre, hogy egy bizonyos méretig engedem növelni ezt a fájlt, utána pedig dobja el a tranzakciót a szerver, és jelenjen meg alkalmazásoldalon a probléma, mert így még fejlesztés közben kiderülhetnek ilyenek.
Nyilván azt is át kell néznem, hogy hogyan tudnám az amúgy izmos szerverhez méretezni a MariaDB beállításait.

Kum Gábor

Látom van egy user_id index külön. Ennyi update-nél nem lesz nyerő, és ha esetleg selectnálni valaki a táblából, akkor pláne bajok lesznek. A query cache-t mindenképp kapcsold ki, mert itt gyanúsan fölösleges, és a querycache update-tel megy az idő.

A másik dolog, ahogy már említették, az a schema. Gyanítom, hogy a bigint kissé meredek a userid-nek, az unsigned meg marhaság. Esetleg az id-nél kellhet bigint, de az usigned ott sem nyerő. Az INT típus 32 bitig jó, ami unsined módon 4,2 milliárd, nekem gyanús, hogy nincs ennyi user id. :) Még valszin a MEDIUMINT sincs meg. Doksi: https://dev.mysql.com/doc/refman/8.0/en/integer-types.html  - sok rekordnál, sok update-nél nagyon nem mind1, hogy mennyire sok byte-nyi adatot kell variálni.

A user_id index mennyi indokolt? Egy user_id-vel több data-value páros előfordulhat?

A mariadb update valszin kihozott valamilyen eddig lappangó problémát, mert a 3000 update, az 3000 update. Az is egy opció, hogy valami kikerült a mariadb-ből, vagy számotokra hátrányosan változott épp.

Ha dump fut, az lock tables-s csinál.

Ha INT-re változtatja az ID-t fogadok megdöglik az egész rendszer heteken belül. Az InnoDB sajátja hogy nem folyamatos az ID,a failed updatek is számítanak így sarkított példával lehet 100 usered, mégis 5000 lesz az utolsó ID-je. Tapasztalatból beszélek, kb három hónapja kellett ilyen problémát oldanom.

"Esetleg az id-nél kellhet bigint, de az usigned ott sem nyerő." - nem véletlenül írtam, láttam már ilyen csodát én is. Természetesen a magasságos fejlesztő urak azonnal nekünk támadtak, hogy megint "sz*r" a szerver, mert mégegy insert sem megy. Ehhez képest nem sikerült mellékelniük egy hibaüzenetet, és oda volt vágva (kimás mint a fejlesztők részéről) az unsigned int az elsődleges kulcsos auto increment mezőhöz. Finoman gratuláltunk, és ha már ilyen kellemesen kezdték a kommunikációt, akkor néhányan még cc-be kerültek.

Az a kérdés, hogy mennyire új rekordok jönnek, mert azon csodálkoznék, hogy ha a user_value-data-trióval 4 milliárd rekordot update-el, illetve új rekord jönne létre. Ha igen, akkor valszin a koncepció a hibás. Nagyon szoktak szeretni, mikor benyögöm, hogy van olyan, hogy tervezési hiba. :) Nyilván valóan le vagyok sajnálva, hiszen a szuperfejlesztők mindenképp mindent is jobban tudnak.

Az auto increment elvileg egész jól szokott működni, és ha annyi sok hibás inserted van, akkor ott más bajok vannak.

A user_id index mennyi indokolt? Egy user_id-vel több data-value páros előfordulhat?

Szerintem csak ugy van ertelme. Imho itt arra gondolt a kolto, hogy minden usernek van egy dictionary strukturaja. Ha tippelnem kene, kizarolag a user_id szerint van query, minden mas ~ertelmetlen.

latom, meg senki se irta, de: auto_increment artatlan szuzlanykanak tunik, de irtozatos hiba a gyakorlatban. meg nem lattam olyan adatbazist, ahol ne lett volna komplett wiki article cimezve a problemakrol, hatranyokrol, gondokrol. pl. fel perc google ez az oldal: https://dev.mysql.com/doc/refman/8.0/en/innodb-auto-increment-handling…

btw ezert utalom a sql-t. egyszerunek alcazott, gyakorlatban tobb benne a kivetel, mint a szabaly, tomor magyarsaggal faszerdo.

bizony az auto increment mogott egy unique index van ami sok insertnel nagyon koltseges tud lenni es konnyen deadlockhoz vezet.

altalaban siman helyettesitheto egy timestamp-el, az is nagyjabol unique es monoton novekvo, es persze nem erdemes moge indexet tenni.

zászló, zászló, szív

( dotnetlinux | 2023. 08. 23., sze – 20:02 )

UserId indexet UserId+dataName-re raknam latatlanban, se 3k/sec akkor is terhelne.

Lehetne csak idonkent update-elni a sorokat (feltetelezem hogy egy sort tobbszor update-el), kieses eseten par mp-nyi sync ujra lefutna, de hatha idempotens a tuloldal. 

( x-daemon | 2023. 08. 25., p – 15:42 )

Szerkesztve: 2023. 08. 25., p – 15:43

nem tudom mennyire kell uptodate-nek lennie ebben a tablaban az updatelt adatoknak, illetve hogy tobbszor is updatelve vannak-e ugyanazok a rekordok, ez felhasznalas kerdese.

csinaltam mar olyat, hogy egy masik szerveren csinaltam az update-et, es 5 percenkent egy replace into-val, querynkent max 1000 rekorddal updateltem a modosult adatokkal a vegleges tablat. igy ami a 3k/sec-bol tobbszor is updatelne a vegleges tablat, az csak 1x updateli, illetve valamelyest csokkenti a terhelest, ha 1 queryben 1000 rekord van.

neked aztan fura humorod van...

( kumgabor v | 2023. 09. 06., sze – 11:11 )

Köszönöm mindenkinek a segítséget.

A fejlesztők megfogadták a javaslataimat, amik a következők voltak:

  • Ahelyett, hogy másodpercenként több ezer update-et csinálnának egy-egy táblán, ellenőrizzék, hogy amit frissíteni szeretnének, annak az értéke nem ugyanaz-e, mint amire módosítani szeretnék. Bár a tranzakciók száma ezzel minimálisan nő, de a sok update helyett sok select és kevés update lesz.
  • Egy ilyen konkrét tábla volt, amit ezentúl a RAM-ban tárolunk, mert a tartalmát a programjuk vissza tudja állítani újraindításkor. Emiatt a mentése sem szükséges.
  • Az 1 GB-nál nagyobb táblák mentése ritkább lesz, nem óránkénti. Az előző mentés óta változott táblák dump-os mentése marad, ha felmerül megrendelői oldalról az igény, akkor ezen változtathatunk később. A kisebb tábláknál, ahol kötelezettség az óránkénti mentés, ez nem jelent problémát
  • Töröljük a felesleges adatokat a táblákból, az adatbázis nem log, még ha egyes táblák nevébe bele is írták, hogy az valaminek a logja.

Amit csinálok ezután:

  • Éjszakai rendszerleállítás, dump ki, dump be, ezzel visszaállítva az ibdata1 fájl normális méretét
  • Egy szkript figyelni fogja a /var/lib/mysql mappa méretét, és ha elkezd nagyon nőni, még időben tudok lépni. Most ez nem jött össze, későn vettem észre
  • A dumpok készítésénél ezentúl mérni fogom az időt, tehát ha "váratlanul" lesz nagy egy olyan tábla, ami eddig üzemszerűen nem volt nagy, akkor ehhez tudjuk igazítani a mentéseket.

További érdekességek:

  • Örömmel vettem, hogy a fejlesztő kollégák nem tolták rám a dolgot azzal, hogy "oldjam meg, ahogy akarom". Együttműködőek voltak és vették az időt, hogy foglalkozzanak a módosításokkal. A cégvezetés sem szükséges rosszként tekint az üzemeltetésre.
  • Megdöbbentő, hogy az innodb-nél tényleg csak ez a kidump-bedump megoldás képes arra, hogy eltüntesse ezt a több száz gigabyte-os szemétdombot.
  • Hiába terveznek meg valamit az alkalmazásfejlesztők, ha utána teljesen másra kell használni egy rendszert, mint amire alapvetően tervezték. Alkalmas rá, csak az eredetileg tervezett 1-2 MB-os táblák több GB-osra nőnek, újratervezésre vagy átalakításra pedig nincs idő, maximum így, ha már baj van üzemeltetési oldalon.

Tehát összességében pozitív vége lett a dolognak.
Köszönöm mindenkinek a segítséget, bebizonyosodott, hogy nem csak politizálni járnak a felhasználók a HUP-ra! :-)

Kum Gábor

Ahelyett, hogy másodpercenként több ezer update-et csinálnának egy-egy táblán, ellenőrizzék, hogy amit frissíteni szeretnének, annak az értéke nem ugyanaz-e, mint amire módosítani szeretnék. Bár a tranzakciók száma ezzel minimálisan nő, de a sok update helyett sok select és kevés update lesz.

Itt tudna menni az egyik fajtája az optimistic lock módszernek: `UPDATE table SET x=2 WHERE id=1 AND x != 2;`, amivel nem növekszik végrehajtott tranzakciók száma és csak akkor fut le az update, ha az x értéke nem '2'.

https://iotguru.cloud

Megdöbbentő, hogy az innodb-nél tényleg csak ez a kidump-bedump megoldás képes arra, hogy eltüntesse ezt a több száz gigabyte-os szemétdombot.

Közben eszembe jutott, hogy mintha lenne erre megoldás, mert pár éve belefutottam ilyenbe: https://dev.mysql.com/doc/refman/8.0/en/optimize-table.html

OPTIMIZE TABLE reorganizes the physical storage of table data and associated index data, to reduce storage space and improve I/O efficiency when accessing the table. The exact changes made to each table depend on the storage engine used by that table.

https://iotguru.cloud

Egy ilyen konkrét tábla volt, amit ezentúl a RAM-ban tárolunk, mert a tartalmát a programjuk vissza tudja állítani újraindításkor. Emiatt a mentése sem szükséges.

Nem tudom pontosan milyen adat szerkezetet használtok, de az volt az első megérzésem, hogy ez leírja hellyel-közzel egy REDIS működését.

Ami még eszembe jutott, hogy nem lenne-e jobb nekik egy MongoDB a MySQL (MariaDB) helyett olyan adatok tárolására, amire később mégis szükség lehet? Ami átmenetileg kell csak az mehetne REDIS-be.

A redis nem egy veszedelmes történet, egészen apt-get install jellegű, igaz RAM kell neki valamennyi. Ha a keretrendszer, CMS eleve támogatja, akkor relatív könnyen megugorható, akkor több oldalról segít az RDBMS-nek. A "csak egy tábla" az egy dolog, de ha óriási, vagy óriási forgalmú, pláne ha mindkettő, akkor azért egy igen jó elképzelés.

pedig nagyon ugy nez ki hogy a szoftverarchitectura nemmegfelelo. RDBMS tabla a cache/session alapu dolgokra? RDBMS-ben uzengetnek egymasnak processek? Mindre van jobb megoldas. Ott vannak a cache-k meg a queue managerek.

A baj ot van, hoby te abban gondokkodsz egy tablat kell kivaltani valamelyikukkel, mikozben nem egy tablarol van szo, hanem folyamatokrol, processekrol, business logic-rol. Hol van a szoftverarchitect ilyenkor?

( hyperborg | 2023. 09. 06., sze – 11:37 )

  • Ahelyett, hogy másodpercenként több ezer update-et csinálnának egy-egy táblán, ellenőrizzék, hogy amit frissíteni szeretnének, annak az értéke nem ugyanaz-e, mint amire módosítani szeretnék. Bár a tranzakciók száma ezzel minimálisan nő, de a sok update helyett sok select és ke

Itt nem lehetne valami stored procedure-t használni a szerver oldalon? Szóval a fejlesztő továbbra is updatel, viszont a DB nézi meg, hogy mi az értéke a dolognak és csak akkor frissít ha kell. Így azért spórolnál sok átviteli költséget, illetve mák esetén az adott adat még a cache-ben is lehet, így nem kell(?) diszkhez nyúlnia a DB-nek az ellenőrzéshez. 

MariaDB alapból így csinálja:

MariaDB [teszt]> update teszt set egyik=11, masik=22 where id=3;
Query OK, 1 row affected (0.007 sec)
Rows matched: 1  Changed: 1  Warnings: 0

MariaDB [teszt]> update teszt set egyik=11, masik=22 where id=3;
Query OK, 0 rows affected (0.000 sec)
Rows matched: 1  Changed: 0  Warnings: 0

Első update változtatott, a második már nem változtatott semmit, mert nem kellett.