Sziasztok!
Egy MySql problémám lenne.
Adott egy master és hozzá 3 slave. A replikáció tökéletesen megy. a masterre felkerült az egyik db-be kb 14.000.000 rekord. 1 slave tökéletesen replikált, szinte minimális laggal. A másik kettő azonban azóta folyamatosan laggol sőt ez az idő folyamatosan növekszik. A replikáció azokon is megy, csak a masterhez képest folyamatosan nő a lemaradás.
Van valkinek valami ötlete?
Annyi változás történ, hogy másnapra feldolgozta a 14.000.000 rekord változását. Illetve a többi változást most már képes úgy feldolgozni, hogy a késés ne nőjőn hanem csökkenjen.
Összefoglalva a jelenség úgy néz ki, hogy ha hirtelen nagy mennyiségű rekord keletkezik az adatbázisokban azt ez a két slave nem képes minimális laggal kezelni, csak extrém lassan képes bedolgozni a rekordokat, míg az az 1 slave szinte meg sem érzi.
- 2907 megtekintés
Hozzászólások
Egyformak a slave-ek hw es sw tekinteteben?
--
Don't Panic if you see me laughing,
that's not a bug, just a feature.
- A hozzászóláshoz be kell jelentkezni
Nem egyformák a hw-k.Az sw-k egyformák és a konfigok is. Bár RAID0-ban vannak benne hdd-k és a raidben szereplő particíók a két késő slave esetén eltérőek. Ráadásul azokon ext3 partíció van. A jól működő slave-en a RAID-ben szereplő driveok particíói bájtra egyformák és xfs a fájlrendszer.
- A hozzászóláshoz be kell jelentkezni
Akkor siman lehet csak ennyi a gond, mert hogy nem birja kovetni olyan tempoban az vagy azert van mert replikaciot nem tudja atkuldeni eleg gyorsan vagy a slave nem tudja feldolgozni eleg gyorsan.
A replika sebesseg betudhato lehet annak hogy egyenlore csak 1 szalon replikal a mysql (5.6-tol benne van a tobbszalu replika, de az meg nem stabil vagy mariadb-ben is benne van azt hiszem mar stabilban ez), az viszont ha konfig szinten ugyanazok a slave-ek akkor marad az, hogy a hw nem birja.
--
Don't Panic if you see me laughing,
that's not a bug, just a feature.
- A hozzászóláshoz be kell jelentkezni
A replica relay bin logok átjönnek. Csak az "insert to" lassú. minden más replikálása gyors! Miután az "insert to" parancsok replikálását befejezte a 14.000.000 rekord tekintetébe be is hozta a master-t.
- A hozzászóláshoz be kell jelentkezni
Nem a binaris logok masolasa tart sokaig neki, hanem annak feldolgozasa 1 szalon gyengebb hardveren. Ha nem elfogadhato ez az idonkenti lemaradas akkor vagy hw-t tuningold fel vagy nezd meg ujabb mysql verziot paralell replikacioval avagy az sql kereseket/adatbazist optimalizald, mert replika is csak azt csinalja hogy iras muveletekkel jaro query-ket lefuttatja slave-eken is.
--
Don't Panic if you see me laughing,
that's not a bug, just a feature.
- A hozzászóláshoz be kell jelentkezni
Ez rendben van, de a jól működő slave hw-e és a két másik slave hw-e alig különbözik. Amit írtam, hogy ext3 és xfs illetve a raidek eltérő particiós mérete az ami még kiválthat ekkora eltérést a replikációban. Erre látsz esélyt?
- A hozzászóláshoz be kell jelentkezni
Igen, simán, saját tapasztalatom szerint is XFS-el jókora gyorsulás érhető el, de egyszer mértem is ezt.
- A hozzászóláshoz be kell jelentkezni
köszönöm a segítséget. Kipróbáljuk ezt az irányt.
- A hozzászóláshoz be kell jelentkezni
Helló,
Nos csak hogy legyen visszajelzés, meg, hogy megköszönjem a segítséget.
Ext3-ról áttértünk ext4-re és a slave-ek lagjai kisimultak.
Köszi még 1x.
- A hozzászóláshoz be kell jelentkezni
show full processlist a slaven és látod, hogy mi tart neki sokáig.
- A hozzászóláshoz be kell jelentkezni
Muszáj a master-slave? Percona xtradb clustert használunk, ott nincs lemaradás, viszont, ha van lassabb gép, akkor az visszafogja majd a gyorsakat. Mi ezt avval védjük ki, hogy jobban terheljük a gyorsabb hw-n futó gépeket.
- A hozzászóláshoz be kell jelentkezni
Nem lehet annyira jol skalazni mint egy master-slave-t.
--
"ssh in a for loop is not a solution" – Luke Kanies, Puppet developer
- A hozzászóláshoz be kell jelentkezni