abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×

dnes 16:55 | Nová verze

Byla vydána verze 1.0 klienta F-Droid určeného pro instalaci aplikací do Androidu ze softwarového repozitáře F-Droid (Wikipedie), alternativy k Google Play, nabízející pouze svobodný a otevřený software. Podrobnosti v přehledu změn [Hacker News].

Ladislav Hagara | Komentářů: 5
dnes 00:55 | Nová verze

Po téměř 13 měsících vývoje od verze 0.11.0 byla vydána verze 0.12.0 hardwarově nenáročného desktopového prostředí LXQt (Lightweight Qt Desktop Environment, Wikipedie) vzniklého sloučením projektů Razor-qt a LXDE. Přehled novinek v příspěvku na blogu.

Ladislav Hagara | Komentářů: 9
včera 12:33 | Zajímavý software

Článek ne Medium představuje nejnovější stabilní verzi 2.0 svobodné decentralizované mikroblogovací platformy a sociální sítě podobné Twitteru Mastodon (Wikipedie). Detailní přehled novinek na GitHubu [Hacker News].

Ladislav Hagara | Komentářů: 0
včera 06:00 | Komunita

V Praze na půdě Elektrotechnické fakulty ČVUT dnes probíhá RT-Summit 2017 – setkání vývojářů linuxového jádra a uživatelů jeho real-time verze označované jako preempt-rt. Přednášky lze sledovat online na YouTube.

Ladislav Hagara | Komentářů: 0
20.10. 14:33 | Zajímavý projekt

Blender Animation Studio zveřejnilo první epizodu z připravovaného animovaného seriálu The Daily Dweebs o domácím mazlíčkovi jménem Dixey. Ke zhlédnutí také ve 3D s rozlišením 8K.

Ladislav Hagara | Komentářů: 0
20.10. 12:34 | Komunita

Aktualizovanou počítačovou hru Warhammer 40,000: Dawn of War III v ceně 39,99 eur běžící také na Linuxu lze o víkendu na Steamu hrát zdarma a případně ještě v pondělí koupit s 50% slevou. Do soboty 19:00 lze na Humble Bundle získat zdarma Steam klíč k počítačové hře Sid Meier's Civilization® III v ceně 4,99 eur běžící také ve Wine.

Ladislav Hagara | Komentářů: 0
20.10. 00:22 | Nasazení Linuxu

Společnost Samsung oznámila, že skrze dokovací stanici DeX a aplikaci Linux on Galaxy bude možno na Samsung Galaxy S8 a S8+ a Galaxy Note 8 provozovat Linux. Distribuce nebyly blíže upřesněny.

Phantom Alien | Komentářů: 19
19.10. 23:55 | Komunita

Společnost Purism na svém blogu oznámila, že její notebooky Librem jsou nově dodávány se zrušeným (neutralized and disabled) Intel Management Engine (ME). Aktualizací corebootu na již prodaných noteboocích lze Management Engine také zrušit. Více v podrobném článku.

Ladislav Hagara | Komentářů: 2
19.10. 21:44 | Nová verze

Organizace Apache Software Foundation (ASF) na svém blogu slaví páté výročí kancelářského balíku Apache OpenOffice jako jejího Top-Level projektu. Při této příležitosti byl vydán Apache OpenOffice 4.1.4 (AOO 4.1.4). Podrobnosti v poznámkách k vydání. Dlouhé čekání na novou verzi tak skončilo.

Ladislav Hagara | Komentářů: 7
19.10. 19:22 | Pozvánky

Již příští týden - 26. a 27. října se v Praze v hotelu Olšanka odehraje OpenWRT Summit. Na webu konference naleznete program a možnost zakoupení lístků - ty stojí 55 dolarů. Čtvrtek bude přednáškový a v pátek se budou odehrávat převážně workshopy a meetingy.

Miška | Komentářů: 1
Jak se vás potenciálně dotkne trend odstraňování analogového audio konektoru typu 3,5mm jack z „chytrých telefonů“?
 (9%)
 (0%)
 (0%)
 (1%)
 (76%)
 (13%)
Celkem 204 hlasů
 Komentářů: 8, poslední dnes 23:02
    Rozcestník

    Replikace databáze MySQL

    7. 11. 2012 | David Watzke | Návody | 7726×

    V tomto článku si popíšeme master-slave replikaci databáze MySQL – co to vlastně je, jak to probíhá, jaké jsou výhody a nevýhody a jak něco takového nakonfigurovat.

    Obsah

    Co to je master-slave replikace?

    link

    Jde o způsob jakým udržovat stejný obsah databáze na více DB serverech naráz, přestože se SQL příkazy provádějí pouze na jednom ze serverů.

    Replikace probíhá tak, že hlavní DB server (master) si ukládá tzv. transakční logy (informace o tom, jaké příkazy provádí), které pak (zpravidla po síti) pomocí replikačního protokolu postupně zasílá vedlejšímu DB serveru (slave – těchto může být i více) a tento pak vykonává stejné příkazy jako master.

    Slave může být provozován na pomalejším hardware než master a potom je možné (pravděpodobné), že bude minimálně ve špičkách docházet ke zpoždění – replikace nebude probíhat v reálném čase a slave dožene mastera až v klidnějším období, kdy se databáze nemění tak rychle. To je jeden z důvodů proč jsou potřeba transakční logy – jinak by master tyto informace mohl posílat slavům ihned. Další důvod je ten, že replikace nemusí probíhat pořád a lze ji přerušit a navázat kdykoliv, pokud máme transakční logy z časového období od přerušení replikace až po současnost a známe aktuální pozici v logu, od které musíme replikaci navázat.

    K čemu je to dobré?

    link

    Replikační slave lze využít pro účely zálohování databáze, a to zejména v případě, kdy je hlavní DB server příliš vytížený nebo je na něm velká databáze, kterou si nemůžeme dovolit zálohovat pomocí mysqldump – zamklo by to tabulky na nepřijatelně dlouhou dobu. V takovém případě lze dump spustit na některém ze slave serverů a jediné k čemu může dojít je, že se zpozdí replikace.

    Dále, pokud vypadne master DB server, může jej slave okamžitě zastoupit. Ovšem může dojít k tomu, že ve slave DB budou chybět některé poslední změny.

    Pokud nám nezáleží na replikačním zpoždění, tedy smíříme-li se s tím, že změny se na slave serverech projeví se zpožděním, tak lze replikaci využít i pro load-balancing, ale je potřeba mít na paměti, že slave DB servery lze v takové konfiguraci používat pouze pro čtení, protože zápis (do replikované tabulky) by způsobil nekonzistenci s masterem a replikace by se dříve či později rozpadla. Je-li toto omezení nepřijatelné, pak je potřeba využít multi-master replikace, kterou se v tomto článku zabývat nebudu.

    Konfigurace asynchronní master-slave replikace

    link

    Master server je potřeba nastavit tak, aby ukládal transakční (binární) logy. Toto jsou soubory na souborovém systému, ve kterých jsou uloženy informace o změnách v DB, které byly provedeny. Samozřejmě se zaznamenávají pouze příkazy, které mění data (INSERT, UPDATE, ...). Do hlavního konfiguračního souboru my.cnf přidáme:

    server-id        = 1
    log_bin          = /var/log/mysql/mysql-bin.log
    max_binlog_size  = 100M
    expire_logs_days = 10
    binlog_format    = MIXED
    

    Volba server-id je ID serveru – slave servery budou pokračovat v číslování od 2 dále. Pomocí log_bin určíme, kam se mají transakční logy ukládat, dále max_binlog_size stanoví jak velké soubory mají vznikat (kdyby se měl soubor zvětšit nad tuto hodnotu, vytvoří se další), pak nastavíme kolik dnů zpátky chceme mít logy k dispozici (expire_logs_days) a nakonec binlog_format určuje formát binárních logů*. Je potřeba zkontrolovat volbu bind-address – pokud DB server naslouchá pouze na lokálním síťovém rozhraní, nedostane se k ní vzdálený slave.

    O formátech binárních logů a jejich výhodách a nevýhodách by se dal napsat samostatný článek. Zde pouze zmíním, že máte tři základní možnosti: 1) STATEMENT, kdy se do logů budou ukládat přímo SQL příkazy, 2) ROW, kdy se budou ukládat přímo změněné řádky anebo jako v ukázce 3) MIXED – to nejlepší z obou světů, kdy se používá standardně STATEMENT a kde to není bezpečné, tam ROW.

    Dále je (na master serveru) potřeba vytvořit uživatele s právem replikace, tedy pod správcovským účtem v MySQL spustit:

    mysql> GRANT REPLICATION SLAVE ON *.* TO 'replslave'@'adresa_slave' IDENTIFIED BY 'slozite_heslo';
    

    Slave server je potřeba nastavit tak, aby replikoval.

    server-id             = 2
    relay-log             = relay-bin
    relay-log-index       = relay-bin.index
    relay-log-space-limit = 5G
    

    Volby relay-log* určují nastavení logů obsahujících data z transakčních logů od master serveru (názvy souborů, jejichž umístění je relativní k datadiru a maximální velikost relay logu).

    Když máme toto připravené, je potřeba zkopírovat adresář s daty MySQL (datadir – obvykle /var/lib/mysql), ale musíme si předem uložit pozici v binárním logu, abychom replikaci mohli od tohoto bodu na slave serveru navázat. Na master DB serveru tedy spustíme:

    mysql> FLUSH TABLES WITH READ LOCK;   -- zamkne celou databázi
    mysql> SHOW MASTER STATUS;            -- tento výstup je potřeba si uložit
    +------------------+----------+--------------+------------------+
    | File             | Position | Binlog_Do_DB | Binlog_Ignore_DB |
    +------------------+----------+--------------+------------------+
    | mysql-bin.045325 | 47975493 |              |                  |
    +------------------+----------+--------------+------------------+
    

    A klienta MySQL nebudeme zavírat (jinak by se zámek zrušil) – zejména pokud toto provádíme vzdáleně přes SSH, je vhodné použít nástroj screen. Nyní zkopírujeme celý datadir na slave server (vypneme slave DB a můžeme kopírovat rovnou na správné místo) a ihned poté můžeme klienta na master serveru ukončit, čímž se databáze opět odemkne.

    master # rsync -av --progress --delete /var/lib/mysql/ slave:/var/lib/mysql/
    

    Alternativou tohoto kopírování za běhu je vytvoření dumpu pomocí mysqldump, ale opět nesmíme zapomenout na to, že budeme potřebovat znát pozici v binárním logu v době dumpu.

    Nyní, poté co jsme překopírovali datadir na slave, je vše připraveno pro to, abychom replikaci spustili na slave serveru. Spustíme zde tedy DB server a v MySQL spustíme pod správcovským účtem následující:

    mysql> CHANGE MASTER TO MASTER_HOST='adresa_master',
            MASTER_PORT=3306, MASTER_USER='replslave',MASTER_PASSWORD='slozite_heslo',
            MASTER_LOG_FILE='mysql-bin.045325', MASTER_LOG_POS=47975493; -- všimněte si, že jsem použil údaje z výše vypsaného MASTER STATUS
    mysql> START SLAVE;
    mysql> SHOW SLAVE STATUS \G
    

    Ve výpisu posledního příkazu musí být toto:

    Slave_IO_Running:  Yes
    Slave_SQL_Running: Yes
    

    Pokud I/O či SQL vlákno neběží, tak došlo k chybě, která bude vysvětlená ve sloupci Last_Error.

    Proces (od kopírování datadiru z master serveru) můžeme opakovat kdykoliv dojde k nezotavitelné chybě na slave serveru nebo když chceme přidat další slave server.

    Další možnosti

    link

    Předvedl jsem nejjednodušší variantu, kdy se replikuje celá databáze, ale lze docílit i toho, aby se replikovaly pouze vybrané databáze či tabulky a dokonce se i každá z nich může replikovat na jiný slave server. Toho lze docílit tak, že na slave serveru v my.cnf nastavíme:

    replicate-wild-do-table = nazev_databaze.%

    Použité „žolíkové“ (wildcard) znaky fungují stejně jako v SQL výrazu LIKE a například abc%.def% by vybralo ze všech databází začínajících na „abc“ tabulky s názvy začínajícími na „def“.

    Když dojde při replikaci na slave k chybě, která se vám nezdá kritická a chcete ji přeskočit, lze toho docílit pomocí:

    mysql> SET GLOBAL SQL_SLAVE_SKIP_COUNTER=1; START SLAVE;

    Proměnná SQL_SLAVE_SKIP_COUNTER určuje počet chyb, které se mají jednorázově přeskočit.

    Je ovšem možné nastavit přeskakování určitých chyb pokaždé. Například chyba „duplicate entry“ (při vkládání stejného řádku podruhé) má kód 1062 (pro všechny kódy chyb viz dokumentaci) a přeskakování tohoto typu chyb lze nastavit tak, že na slave přidáme do my.cnf následující:

    slave-skip-errors = 1062

    Přejeme-li si přeskakovat více druhů chyb, pak kódy oddělujeme čárkou.

    Přeskakování chyb ale nenastavujte, pokud k tomu nemáte dobrý důvod anebo pokud dobře nerozumíte tomu, proč k chybám dochází. Snadno tak může dojít k nekonzistenci dat, kdy na slave serveru budete mít něco jiného, než má master.

           

    Hodnocení: 100 %

            špatnédobré        

    Nástroje: Tisk bez diskuse

    Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

    Komentáře

    Vložit další komentář

    7.11.2012 11:01 razor | skóre: 32
    Rozbalit Rozbalit vše Re: Replikace databáze MySQL
    IMHO chybí zmínka o tom, že výše popsaná replikace je tzv. asynchroní a že od verzi 5.5 je k dispozici i tzv. semisynchroní replikace.
    David Watzke avatar 7.11.2012 11:44 David Watzke | skóre: 74 | blog: Blog... | Praha
    Rozbalit Rozbalit vše Re: Replikace databáze MySQL
    Díky za připomínku, upravil jsem podle toho nadpis "Konfigurace".
    “Being honest may not get you a lot of friends but it’ll always get you the right ones” ―John Lennon
    7.11.2012 13:24 Pavel Francírek | skóre: 6
    Rozbalit Rozbalit vše Re: Replikace databáze MySQL
    Dále jsem nenašel zmínku o statement vs. row replikaci (ta je třeba u clusteru default). A jejich chování se v některých případech radikálně liší (operace nad celými tabulkami atp.).
    Luboš Doležel (Doli) avatar 7.11.2012 15:01 Luboš Doležel (Doli) | skóre: 98 | blog: Doliho blog | Kladensko
    Rozbalit Rozbalit vše Re: Replikace databáze MySQL
    Vždyť to tam je...
    7.11.2012 14:02 lh
    Rozbalit Rozbalit vše Re: Replikace databáze MySQL
    8.11.2012 00:05 Kvakor
    Rozbalit Rozbalit vše Re: Replikace databáze MySQL
    K toimu load balancingu - u většiny webů je poměr čtení/zápis velké číslo, některé CMS klidně udělají okolo sta selectů jen na zobrazení jedíné stránky, ale zápis se vyskytuje jen pří změně dat (úprava obsahu, diskuze a spol), tedy pokud si web nedělá svojí interní statistiku.

    Z toho důvodu je výhodné směrovat veškerá čtení z databáze přes load balancer na slave servery, zatímco na master server půjdou pouze zápisy. Pokud se tato funkcionalita vloží do nějaké databázové mezivrstvy, tak může všecho probíhat z pohledu programátora naprosto transparentně (tedy pokud nejsou požadavky na sobě vzájemně závislé).

    Navíc může master server fungovat jako failover během komunikaci s databází - mezivstrva nemusí čekan na to, než balancer vybere jiný server, protože ví, že master běží (a pokud neběží, tak je nejspíš jednoduší ukázat uživatel nejakého veselého obluďáka s přetrženým kabelem a hlášením o poruše - uživatel se na pár sekund potěší veselým obrázkem a než dá reload, je zvolen nový master a vše zas funguje normálně).
    frEon avatar 8.11.2012 13:38 frEon | skóre: 40 | Praha
    Rozbalit Rozbalit vše Re: Replikace databáze MySQL
    Tohle imho funguje hezky tak dlouho, dokud nemas ty servery hodne vytizeny. Pak se ti muze stat, ze neco do master db ulozis, pocitas s tim, ze to tam je, sahnes si na nektery slave a ouha, ono to tam jeste neni.
    Talking about music is like dancing to architecture.
    8.11.2012 17:35 diverman
    Rozbalit Rozbalit vše Re: Replikace databáze MySQL
    některé CMS klidně udělají okolo sta selectů jen na zobrazení jedíné stránky
    Tak to je hodne spatne, pokud se provadi nasledujici pseudokod:
    for row in (SELECT foo FROM Foo):
       SELECT bar FROM Bar WHERE foo = row[0]
    
    Jinymi slovy, kdyz pocet dotazu na stranku je primo umerny poctu vypisovanych polozek. Spatny framework/CMS/programator.
    11.11.2012 01:23 trekker.dk | skóre: 71
    Rozbalit Rozbalit vše Re: Replikace databáze MySQL
    některé CMS klidně udělají okolo sta selectů jen na zobrazení jedíné stránky
    Dokonce jsem viděl i několikrát zopakovaný stejný select (při vyřizování jednoho požadavku)
    Quando omni flunkus moritati
    8.11.2012 13:56 martin
    Rozbalit Rozbalit vše Re: Replikace databáze MySQL
    V clanku nikde neni zminka o zabezpeceni. Musim komunikaci master<--->slave tunelovat (ssh, stunnel), nebo uz je sama o sobe sifrovana a bez starosti ji muzu pustit do Internetu pres pul sveta?
    David Watzke avatar 8.11.2012 14:47 David Watzke | skóre: 74 | blog: Blog... | Praha
    Rozbalit Rozbalit vše Re: Replikace databáze MySQL
    Šifrované to není, dokud šifrování nepovolíš (či nepřikážeš), stejně jako všechna ostatní komunikace s MySQL. Více v tomto článku.
    “Being honest may not get you a lot of friends but it’ll always get you the right ones” ―John Lennon
    8.11.2012 19:42 lacik
    Rozbalit Rozbalit vše Re: Replikace databáze MySQL

    Budu to muset řešit výhledově, v blízké budoucnosti dostanu na starost webový projekt, ale protože nejsem programátor, neodpustím si dotaz: je možné řešit replikaci k předem stanovenému okamžiku třeba jednou za den nebo týden, nebo příkazem? A pokud k tomu replikace není vhodná, jakým jiným způsobem řešit můj problém?

    Oč mi jde: mám databázi, která obsahuje odkaz na XML soubor s textem, někdy dost rozsáhlým. Program v php pak skládá web stránku ze záznamů v databázi a z onoho XML souboru přes XSLT. Pokud se přidává záznam do projektu, pak se musí vytvořit záznam v databázi, zeditovat k němu příslušný nově vzniklý soubor XML a upravit či doplnit v daších XML souborech odkazy. Teprve poté, po delší práci, jsou synchronní jak položky v databázi, tak i soubory XML, a chtěl bych to dávkově zpracovat (čili během jednoho okamžiku skriptem odeslat nové a změněné XML soubory na server a replikovat databázi). Právo na insert/update/delete a na editaci XML mají pouze admini v admin verzi db, návštěvníci webu mají pouze select do serverové verze db schovaný v php.

    Předem díky za navedení na použitelné a funkční řešení.

    Jakub Lucký avatar 8.11.2012 21:21 Jakub Lucký | skóre: 40 | Praha
    Rozbalit Rozbalit vše Re: Replikace databáze MySQL
    To nehledáte replikaci, ale nějaký deployment systém... Ale líp vám neporadím, s tím nepracuju...
    If you understand, things are just as they are; if you do not understand, things are just as they are. (Zen P.) Blogísek
    8.11.2012 23:37 RapMan | skóre: 14 | blog: RapMan
    Rozbalit Rozbalit vše Re: Replikace databáze MySQL
    Diky za clanek, videl jsem hodne master - slave replikaci, i master-master.

    Co vsak neni nikde dobre zdokumentovane je to, kdyz se master rozbije, provoz presunu na slave, jak pak nejlepe spravit master a opet na nej presunout provoz, aby doslo k co nejmensimu vypadku.
    9.11.2012 08:41 http://blog.hostname.sk
    Rozbalit Rozbalit vše Re: Replikace databáze MySQL
    Mozno hladate mysql-proxy. Aplikacia sa potom nepripaja priamo do DB, ale na proxy. Presmerovanie sa potom vykona zmenou v nastaveniach mysql-proxy
    11.11.2012 11:12 Ondra
    Rozbalit Rozbalit vše Re: Replikace databáze MySQL
    Z asi 2leté zkušenosti doporučím naučit se 2 věci. Většinou se replikace zasekne na nějaké chybě. Jedna možnost je tu zmíněnou operaci přeskočit: STOP SLAVE; SET GLOBAL SQL_SLAVE_SKIP_COUNTER=1; START SLAVE; Další možností je v konfiguraci nastavit, aby tyto události nevyvolávaly chybové stavy (teď z hlavy přesně nevím jak se ten parametr jmenuje).

    Druhá možnost je použít mysqldbcompare, které vyhodí rozdíly mezi master a slave databází a vypíše i SQL příkazy, které se mají spustit, aby bylo vše stejné. Funguje to OK.
    12.11.2012 01:32 RapMan | skóre: 14 | blog: RapMan
    Rozbalit Rozbalit vše Re: Replikace databáze MySQL
    skip counter je jasny, ale automaticky bych to neriskoval. Prenos dat z logu bezi, i kdyz SQL thread vykazuje chybu, ale chapu, kdyz nekdo ze slave potrebuje ihned ziskavat aktualni data, ze si to lajzne....
    12.11.2012 17:24 Pev | skóre: 28
    Rozbalit Rozbalit vše Re: Replikace databáze MySQL
    Možná by se Vám na to hodil flipper.
    9.11.2012 10:40 Program
    Rozbalit Rozbalit vše Takhle radši ne
    Nelíbí se mi rsync živé db. Pokud proběhne nejdřív překopírování datových souborů a až pak logů, vyleze z toho více či méně nekonzistetní databáze. FLUSH TABLES WITH READ LOCK to nezachrání, protože nezamnkne interní procesy v DB.

    Opravte mě, jestli se mýlím, ale tohle opravdu NEDOPORUČUJI UDĚLAT. Když už tak využít LVM snapshot, pak je to OK.
    9.11.2012 13:40 lh
    Rozbalit Rozbalit vše Re: Takhle radši ne
    Ake interne procesy v MySQL? Kde by som nasiel viacej info?
    9.11.2012 18:49 Program
    Rozbalit Rozbalit vše Re: Takhle radši ne
    Chce to znát trochu detaily MySQL, viz http://dev.mysql.com/doc/refman/5.5/en/. Nic méně nemyslím, že je dnes perspektivní nějak hodně zkoumat mysql, pokud člověk není nucený ho spravovat.

    Nic méně, abych líp odpověděl:

    1) Ukládání upravených stránek na disk -> Stránky jsou uloženy v trans. logách, takže když MySQL najednou celé spadne, tak je to ok, ale když db kopírujete za živa, tak se Vám data mění pod rukama. (Viz dirty pages v doc.)

    2) Change buffer (odložený update sekundárních indexů) -> Dle dokumentace update probíhá při načtení dané stránky do buffer poolu, nikde ale není psáno, že musí čekat libovolně dlouho a nemůže si ji načíst sám (viz change buffering).

    3) Undo buffer -> Pokud rdbm nestíhala odstraňovat data z undo bufferu, může to provést zrovna teď. To se týká celé správy MVCC architektury, která se dělá na pozadí.

    Ničemu z toho read lock nezabrání, navíc pokud db má pár desítek GB, tak se bude kopírovat docela dlouho a celou dobu bude nepoužitelná. To už je lepší ji rovnou vypnout a kopírovat "za studena".
    10.11.2012 02:21 rajo | skóre: 4 | Bratislava
    Rozbalit Rozbalit vše Re: Takhle radši ne
    V dokumentacii sa pise:

    FLUSH TABLES WITH READ LOCK

    Closes all open tables and locks all tables for all databases with a global read lock. This is a very convenient way to get backups if you have a file system such as Veritas or ZFS that can take snapshots in time. Use UNLOCK TABLES to release the lock.

    Cize podla mna globalny read lock zarucuje, ze vsetky zmeny su zapisane v tabulkovych suboroch na disku a nie niekde v pamati alebo transakcnom logu. Ak by to tak nebolo, tak by takyto command bol uplne zbytocny a neexistovala by cesta, ako MySQL odbackupovat bez dlhej odstavky (ok, slo by to replikovanim na slave, ktory by sa mohol zastavit na potrebnu dobu zalohovania).

    Ze sa v dokumentaci spomina snapshot FS je fajn, ale nie je nutne ho pouzit. Ak mam dostatok casu, kludne mozem data skopirovat rsyncom alebo aj cez F5 v mc.:-) Kym nevytukam "UNLOCK TABLES", tak ziaden zapis na disk neprebehne a vsetky vlakna mysql co chcu zapisovat na disk cakaju na uvolnenie global read lock.

    A par ludi adminovat MySQL servery musi, inac by firmy nemohli predavat sluzby webhostingu. :-)
    10.11.2012 13:10 Program
    Rozbalit Rozbalit vše Re: Takhle radši ne
    To jste bohužel pochopil špatně. Ten postup je: FLUSH TABLES WITH READ LOCK; udělat FS/LVM snapshot; UNLOCK TABLES;

    Možná by ten flush ani nebylo nutné dělat, ale byla by větší pravděpodobnost poškození DB.

    O tom, že nemáte pravdu se přesvědšíte snadno. Stačí se podívat na SHOW ENGINE INNODB STATUS\G. V sekci BUFFER POOL AND MEMORY. Ideálně si to pustit v linuxovém watchi. Uvidíte, že "dirty pages" se budou postupně házet na disk.
    10.11.2012 13:15 Jan33
    Rozbalit Rozbalit vše Re: Replikace databáze MySQL - kompletni redo log
    Diky za článek. Jako lehký úvod to je dobré. Jen mi hlavou vrta proč je nutné nejdřív zastavit master. Nešlo by jej donutit k vytvoření kompletního redo logu? Tedy aby se slave synchronizoval s prázdnou (myšleno s prázdnými tabulkami) databází? Přece když mi slave zdechne nebo potrebuji připojit další nebudu zastavovat mastra? Nebo to vážně nejde udělat bez zastavení a dumpu?
    David Watzke avatar 10.11.2012 14:03 David Watzke | skóre: 74 | blog: Blog... | Praha
    Rozbalit Rozbalit vše Re: Replikace databáze MySQL - kompletni redo log
    No, v praxi se často používá LVM snapshotů. Uděláš na masterovi FLUSH TABLES WITH READ LOCK, až proběhne (často jen pár sekund), tak vytvoříš snapshot (to je téměř okamžitě) a pak to můžeš zase odemknout. Pak připojíš snapshot, odkopíruješ data, odpojíš ho a zrušíš.

    Kompletní redo log vytvořit podle mě nemůžeš z principu fungování replikace - jak on má zpětně vědět, jaké příkazy byly provedeny? :-) A k získání příkazů pro vytvoření dané databáze (včetně obsahu, volitelně) slouží právě dump.
    “Being honest may not get you a lot of friends but it’ll always get you the right ones” ―John Lennon
    10.11.2012 16:58 Jan33
    Rozbalit Rozbalit vše Re: Replikace databáze MySQL - kompletni redo log
    Asi si to predtavuju jako Hurvínek válku. Nevím ale proč by do toho "inicializačního" redo logu nemohla db vysypat aktuální obsah tabulek. Kouzlo je v tom, že by se tak stalo automaticky, bez nutnosti zamykat celou databázi a zjišťovat nějaká čísla příkazů.

    LVM to pravda zrychluje, když ho tedy máš, ale stejně mi prijde , že je v tom příliš (zbytečné) lidské práce a ryziko selhání je velké. Stačí se uklepnou v čísle a při jdeš o část dat a ani na to nemusíš (hned) přijít.
    10.11.2012 20:51 Program
    Rozbalit Rozbalit vše Re: Replikace databáze MySQL - kompletni redo log
    Teoretických monžostí rozumného inicializačního syncu je víc. Problém je v tom, že to nikdo u InnoDB neudělal a vzhledem ke stavu celého projektu pravděpodobně v tomto století neudělá. Je hodně "jednoduchých" věcí, které prostě nikdo zatím neudělal.
    David Watzke avatar 11.11.2012 12:08 David Watzke | skóre: 74 | blog: Blog... | Praha
    Rozbalit Rozbalit vše Re: Replikace databáze MySQL - kompletni redo log
    Když si na to napíšeš skript, tak v tom lidská práce není žádná ;-) (Vyzkoušeno.)
    “Being honest may not get you a lot of friends but it’ll always get you the right ones” ―John Lennon
    12.11.2012 17:26 Pev | skóre: 28
    Rozbalit Rozbalit vše Re: Replikace databáze MySQL
    Docela hezké video na youtube k tomuto tématu (začíná to replikacemi a ukazuje dalí nástroje): MySQL High Availability Solutions with Lenz Grimmer.

    Založit nové vláknoNahoru

    ISSN 1214-1267   www.czech-server.cz
    © 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.