Dotaz: Záloha / replikace databází na jeden server

[Tomas3]

Zdravím Vás, měl bych dotaz ohledně záloh / replikací. Rád bych ze 3 serverů (hlavních), replikoval data (kvůli záloze) na jeden fyzický server. Jak lze toho docílit, když využívám MariaDB v.10? 3 servery mají odlišné databáze a tudíž nejsou totožné. Kdybych měl data online na tom "záložním" serveru, bylo by to super, protože při výpadku některých serverů bych pak mohl rychle přenastavit přístup do "záložní" databáze.

Děkuji Tomáš

Odpovědi

[pavele]

Na záložním serveru vytvořit KVM virtuály s databázemi a ty potom replikovat master-slave.

[Tomas3]

To by asi nebylo to pravé, ne? Servery mám na páteři a ten záložní na 200 Mbit lince :( Tam by docházelo asi k velkému přenosu dat. Říkal jsem si, že bych přes rsync zálohoval data a nějakým způsobem pak řešil tu replikaci databáze.

[trekker.dk]

Ono by to nemuselo být to pravé, ani kdyby ty servery ležely vedle sebe - ten zálohovací server by nemusel stíhat (dělal by součet práce těch tří serverů, co se zápisů týče.) Nicméně pokud chcete online zálohu, abyste se do ní mohl přepnout v případě, že hlavní server vypadne, tak vám nic jiného než master-slave replikace nezbude

[Tomas3]

No, já mám představu, že bych tím rsyncem dělal zálohy dat a třeba přes mariadb replikaci. No, jen jsem se nikde nedozvěděl a nevím jestli to jde, replikovat z třech serverů na jeden server. Lze to udělat nebo je na to nějaký fígl? Děkuji

[trekker.dk]

nevím jestli to jde, replikovat z třech serverů na jeden server.

Není důvod, aby to nešlo, ale všechno je přednastavené tak, že je na jednom serveru jenom jedna MariaDB. Takže ty další dvě instance budete muset hodně přenastavit, aby používaly jiné konfigurační soubory, jiné adresáře pro data atd. A nebo na tom serveru vytvořit tři virtuály a kopírovat to na ně

[OldFrog {Ondra Nemecek}]

Jak velké jsou ty databáze? Replika není záloha ve smyslu ochrany proti nechtěnému smazání nebo aplikačnímu poškození dat. V řadě případů je rozumné začít normální zálohou - archivací. Na to stačí dump a rsync, rdiff-backup apod. Teprve pokud tento postup odůvodněně nevyhovuje, má cenu hledat jiné řešení. Je možné ale udělat repliku a zálohovat pak tu repliku, což může omezit přenos dat, zvýšit četnost záloh apod. - ovšem vše v závislosti na charakteru dat, poměru čtení vs. zápis a dalším.

[Tomas3]

Celkem mohou mít databáze cca. 10GB. Je pravdou, že bych chtěl dělat zálohy, ale ty dělám přes mysql_backup, ty bych mohl pak posílat na ten druhý server, ale aktuální data by se také hodila a k tomu by ta replikace byla asi v pořádku. Napadá mě teď jen, aby se mi do záloh nedostal ransomware, ale to asi pomocí rsyncu nevyřeším, že? To se budu muset asi podívat na ochranu Centos proti ransomware.

[Ondrej]

My to delame tak, ze dumpneme databazi do souboru a ten sbirame bacula daemonem a ukladame. Neni to okamzite obnoveni, ale je to stav db k dane pulnoci.

[Tomas3]

Děkuji, já to mám zatím takto, ale přes scp. O Bacule jsem slyšel a nedávno četl, jen mi přijde ta konfigurace dosti složitá :(

[OldFrog {Ondra Nemecek}]

Záleží, jaký je provoz na těch db, jaké zatížení a zda přavažují zápisy či čtení a jak hodně se ta data mění. Pak záleží, jaké máte požadavky na četnost záloh, jak rychle chcete data obnovit ze zálohy či jak rychle přepnout na repliku. Podle toho vybírejte řešení.

Například pokud jsou data líná (moc se nemění), z databáze se hlavně čte ale je poměrně velká na dostatečně rychlou obnovu z sql dumpu (co je "dostatečně rychlá" si stanovujete sám), můžete udělat slave repliku, na kterou můžete v případě potřeby přepnout a současně můžete tuto repliku na záložním serveru lokálně dumpovat a ukládat do read-only archivu. Tím získáte i určitou odolnost proti ransomware - stále budete mít možnost plné obnovy k určitému času ze sql dumpu. Oproti dumpování na produkčního serveru a přenosu na záložní server ušetříte výkon produkčního serveru a dále ušetříte přenos dat. Opačná situace naproti tomu nastane, pokud se data mění intenzivně a nepřetžitě, pak by naopak přenosy vzrostly a replikováním můžete záložní server uvařit. Současně nemusí v takovém případě vyhovovat ani četnost záloh - budete chtít body obnovy co nejčastější.

To je jen příklad toho, jak je potřeba uvažovat a jak protichůdná požadavky mohou vzniknout v různých situacích.

Takže bych začal tím, že bych zjistil jaký je v té databázi provoz a jaké jsou požadavky na řešení. Pak se dá radit dále, protože možností je více.

[Josef Kufner]

Jeden server může spravovat několik databází, takže si na zálohovacím serveru vytvoříš ty tři databáze a nastavíš tři master–slave replikace.

[Tomas3]

Jeden server samozřejmě může spravovat několik databází, ale možná myslíš instance, ne? Nebo mariadb umí replikovat jen vybrané databáze a posílat je na slave? Já myslel, že bych musel udělat několik instancí a to například pod portem 3306,3307,3308,... a ty pak replikovat na ten slave.

[Josef Kufner]

S instancemi to půjde také, ale žiju v domnění, že to jde nastavit i pro jednotlivé databáze (ale je možné, že ne).

[Dušan]

MariaDB od neviem akej verzie podporuje multi server replikáciu, ALE

Treba si uvedomiť, že vždy replikuješ konkrétnu databázu a nie databázový stroj ako taký, TEDA

na MASTER stroji dáš do my.cnf toto

server_id = 1
gtid_domain_id = 1
report_host = master1.domain.tld
log_bin = /var/lib/mysql/binary.log
relay_log = /var/lib/mysql/relay.log
expire_logs_days = 7

binlog_do_db = databaza_x
binlog_do_db = databaza_y
binlog_do_db = databaza_z

replicate_do_db = false

a vytvoríš používateľa

GRANT REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO `replication`@`ip.tvojho.slave.servera` IDENTIFIED BY PASSWORD 'xyz';

samozrejme, pre ďalšie serveri náležite upravíš id-čka, ktoré musia byť jedinečné a ostatné riadky

na SLAVE stroji dáš do my.cnf toto

server_id = 1000
gtid_domain_id = 1000
report_host = slave.domain.tld
log_bin = /var/lib/mysql/binary.log
relay_log = /var/lib/mysql/relay.log
expire_logs_days = 7
binlog_do_db = false

# master1.domain.tld
replicate_do_db = databaza_x
replicate_do_db = databaza_y
replicate_do_db = databaza_z

ďalej si treba uvedomiť, že pri vytvorení novej replikácie, respektíve pri jej "rozpadnutí" musíš vždy najprv ručne dumpnuť konkretnú databázu, nahrať ju na slave a až tak zapnúť replikáciu, spravil som si preto následujúce skripty

na mastri spustíš toto a riadok čo ti dá na konci spolu vložíš do scriptu na slave do premennej status="", samozrejme skopíruješ aj ten sql dump čo ti vytvorí

#!/bin/bash

host="127.0.0.1"
user="root"
pass="abc"

dump="`mysql --host=${host} --user=${user} --password=${pass} --skip-column-names --vertical --execute="show master status;" | tail -n2 | head -n1 | sed "s|,| |g"`"

halt="`mysql --host=${host} --user=${user} --password=${pass} --skip-column-names --execute="flush tables with read lock; select sleep(86400);" > /dev/null 2>&1 &`"
sleep 5
lock="`mysql --host=${host} --user=${user} --password=${pass} --skip-column-names --execute="show processlist;" | grep -i "select sleep(86400)" | awk '{print $1}'`"

mysqldump --host=${host} --user=${user} --password=${pass} --lock-all-tables --hex-blob --events --routines --triggers --result-file=$(hostname).sql --log-error=$(hostname).sqr --databases ${dump}

zero="`mysql --host=${host} --user=${user} --password=${pass} --skip-column-names --vertical --execute="reset master;"`"
data="`mysql --host=${host} --user=${user} --password=${pass} --skip-column-names --vertical --execute="show master status;" | tail -n4 | head -n3 | xargs`"
kill="`mysql --host=${host} --user=${user} --password=${pass} --skip-column-names --vertical --execute="kill ${lock};"`"

echo "${data}"

slave

#!/bin/bash

status=""

master_host="master1.domain.tld"
master_user="replication"
master_pass="xyz"

slave_host="127.0.0.1"
slave_user="root"
slave_pass="123"

mysql --host=${slave_host} --user=${slave_user} --password=${slave_pass} --execute="stop slave '${master_host}';" > /dev/null 2>&1
mysql --host=${slave_host} --user=${slave_user} --password=${slave_pass} --execute="reset slave '${master_host}' all;" > /dev/null 2>&1

for db in $(echo "${status}" | cut -d " " -f 3 | sed "s|,| |g"); do
  echo "Dropping database \"${db}\""
  mysqladmin --host=${slave_host} --user=${slave_user} --password=${slave_pass} --force drop ${db}
  echo
done

pv ${master_host}.sql | mysql --host=${slave_host} --user=${slave_user} --password=${slave_pass}
if [[ $? -ne 0 ]]; then
  exit 1
fi

mysql --host=${slave_host} --user=${slave_user} --password=${slave_pass} --execute="change master '${master_host}' to master_host='$(resolveip -s ${master_host})', master_user='${master_user}', master_password='${master_pass}', master_log_file='$(echo "${status}" | cut -d " " -f 1)', master_log_pos=$(echo "${status}" | cut -d " " -f 2); start slave '${master_host}';"
if [[ $? -ne 0 ]]; then
  exit 1
fi

Ďalej malé upozornenie, keď máš nejaké pohľady, procedúri, funkcie, tak je vhodné aj na slave vytvoriť používateľov s rovnakými oprávneniami ako na mastri, ktoré používaju

Kebyže niečo nechápaš, pýtaj sa

[dustin]

https://mariadb.com/kb/en/multi-source-replication/#typical-use-cases

Pro úvodní zkopírování různých databází z různých serverů do jednoho slave lze použít mariabackup https://mariadb.com/kb/en/partial-backup-and-restore-with-mariabackup/, jen nalití není u partial backup zdaleka tak jednoduché, jako u full backup https://mariadb.com/kb/en/partial-backup-and-restore-with-mariabackup/#restoring-the-backup. Ale samozřejmě to lze celé naskriptovat.

[majales]

Mariabackup je vlastně původní xtrabackup, jedná se o fyzickou zálohu db souborů + replay logu. Výhodou je oproti dumpu mnohem větší rychlost zálohy ( dá se pomocí pipe odesílat na vzdálený stroj a rovnou komprimovat) , ale hlavně oproti dumpu je mnohem větší rychlost obnovy všech db ( zvláště při databázích o velikosti desítek GB a větších) . Obnova je v podstatě rozbalení a nalití všech db souborů nazpět ( přepsání původních db souborů) a přehrání binlogu logu tak aby se obnovená záloha dostala do konzistentního stavu. Například vytvoření slave pomocí xtrabackup/maribackup je mnohem rychlejší, protože se jen kopírují soubory. Kromě full backupu lze řešit i přírůstky jak píše dustin. Lze takto zálohovat i ze slave, a nezatěžovat backupem master.

[dustin]

Jasně, hlavně lze kopii vytvářet bez shození masteru a navíc tam rovnou strčí transakční ID, tudíž je nastartování replikačního slejva/jeho obnovení po vytikání binlogů daleko jednodušší (jinak je to pěkná pakárna).

Možnost zálohovat (a hlavně obnovovat) jen vybrané databáze je velice užitečná, pro multimaster s různými DB víceméně nezbytná.

Samozřejmě to vyžaduje file per table, ale to už je snad dnes standard. Obří soubory ibdata jsou peklo.

[MP]

Pletete tu nekolik veci.

Chcete zalohu? Zaridte si transakcni zalohu (ma to mariadb vubec?)

Chcete zalozni server pro prepnuti provozu? Zaridte si HA cluster.

Zaloha != replikace.

[j]

To mas jednoduchy, chces zalohovat? Zahod mysql (a vsechny jeji forky). Tahle vec zalohovat neumi nikdy neumela a podle vseho nikdy umet nebude*.

A jak to funguje u tech databazi ktery to umej? Velmi jednoduse. Vytvoris konzistentni snap, a ten preneses na zalozni disk. Tzn nemusis provozovat picovyny jako replikace, ktery ti stejne nebudou fungovat, protoze jak tu zaznelo, ten server by musel zvladat zatizeni vsech zdroju dohromady (a zdaleka nejen to).

Kdyz potrebujes zprovoznit zalohu, tak to obnasi jen to, ze ji nad tema datama na tom zaloznim disku pustis. A nebo ta data samozrejme proste nakopirujes zpet.

*Tim netvrdim, ze to pro spoustu ucelu neni zcela vyhovujici reseni. Ale jakmile se zacne resit zalohovani za chodu nebo jakakoli bezpecnost provozu ...

[dustin]

A co jiného tedy dělá ten mariabackup (xtrabackup)? Znáš to vůbec?

Replikace samozřejmě není záloha, to tu nikdo neříkal. Mít stále aktuální slave je velice užitečné, používáme každý den spoustu let.

[j]

Dela to presne to, co vzdycky ... odsype to random data kamsi na disk. Tudis ty vubec jak fungujou databaze? A jak vypada konzitentni backup?

... ALTER TABLE ... jo, to je backupovac jak noha ... lol ...

[dustin]

Ta random data jsou úplně kompletní a funkční struktura souborů/adresářů, vytvořené za plného běhu původní databáze (žádný downtime), ze kterých můžeš celou instanci kdykoliv nastartovat. Také se to přesně tak dělá.

Diskuse ale byla o obnovení jen jedné konkrétní databáze (jedné z mnoha běžících na dané instanci), což je logicky mnohem složitější. Na druhou stranu zavolat na tabulkách discard tablespace, nakopírovat jeden nebo dva soubory a zase jej načíst přes import tablespace není nic složitého. Ve všech DB jim musíš říci, že jejich obsah obnovuješ.

Já bych to ale přes partial backup nedělal a klonoval celou instanci, to je standardní postup.

Hádat se s tebou nebudu, protože s mariadb nemáš žádné zkušenosti a diskuse je tudíž o ničem.

[j]

Kristova noho ... takze netusis co je to zaloha a konzistence je pro tebe sprosty slovo.

Soubory si muzes tak leda ve svete databazi strcit doprdele. Skutecna zloha musi byt transakcne konzistentni. A ne ze tam mam pulku dat ktery se zrovna zapisovaly a tu druhou ne. A PRESNE to dostanes pri "zalohovani" mysql.

Jinak receno, vis o tom lautr hovno!

"nakopírovat jeden nebo dva soubory a zase jej načíst přes import tablespace není nic složitého"

Tohle muze napsat leda totalne negramotny hovado!

--- Jdete s tou gugli capthou dopice

[majales]

Ale já už jsem psal, jestli jste si nevšimnul, že se kopírují soubory a k nim transakční log, aby záloha byla konzistentní. Při obnově je pak obnovena původní struktura souborů z doby zálohy a k nim se z transakčního logu přehraje vše se se událo v době zálohy do přesně definovaného log position, který je po po záloze v jednom ze souborů. Pak je to to konzistentní.

[Filip Jirsák]

Prázdný sud nejvíc duní.

Co se podle vás stane s databází, když vypadne napájení serveru? Co podle vás dělá s databází Mariabackup?

[majales]

Bavíme se vůbec o stejné věci? Zdá se mi že asi ne.

[dustin]

Myslím, že úplně o té samé.

[Filip Jirsák]

My se bavíme o stejné věci, jéčko píše o svém vlastním světě, kde mu vůbec nic nefunguje a všichni ostatní kromě něj jsou debilové a idioti, jenom on všemu rozumí nejlépe. Ale to je u něj normální.

[OldFrog {Ondra Nemecek}]

Nerad ruším vespolek, ale tady je popsané jak to funguje https://www.percona.com/doc/percona-xtrabackup/2.4/how_xtrabackup_works.html

IMHO to pro řadu případů bude postačovat, pokud budou k dispozici i plné offline zálohy. A ro náročnější použití se stejně použije asi jiná db než Mysql.

[Pavel 'TIGER' Růžička]

Já se zeptám jinak, nestačili by místo virtualizace na to kontejnery? Ptám se proto, protože sám moc zkušeností s kontejnery nemám.

[dustin]

Více instancí mysql není moc složité (stačí my.cnf a startup skript s cestou k němu), máme na vytvoření nové instance skript a provozujeme spoustu instancí vedle sebe. Osvědčilo se mi pro každou instanci extra uživatele pro klienta, kde lze nastavit porty a není to potřeba pořád dokola zadávat jako parametr klienta, navíc má pak každý klient k instanci svou vlastní historii, to se hodí. Nebo nějaké aliasy pro jednotlivé klienty, taky cesta.

Ale samozřejmě lxc kontejner je jednodušší na instalaci, leč musí se jeho OS aktualizovat a zabere víc místa na disku.

[Pavel 'TIGER' Růžička]

Jasně, ale u těch více instancí se jedná o tutéž verzi, ne? Nebo lze provozovat i rozličné verze? Z tazatelova dotazu jsem pochopil, že to nemá sjednocené, což by byl ideální stav, ale nejspíše k němu v nejbližší době nedojde. Jestli kontejnery dobře chápu, tak pak v nich může mít i různé verze všeho možného a nemělo by to být tak náročné na hardware jako virtualizace. Nebo mi něco uniká?

[OldFrog {Ondra Nemecek}]

Vedle sebe můžete provozovat různé verze mysql i bez kontejneru, pokud je lze v daném prostředí spustit (verze knihoven apod.). V kontejneru si k tomu přidáte i ty knihovny anebo v plné virtualizaci (třeba kvm s qemu) i jádro, takže pak můžete provozovat i historické verze. Mezi prvními dvěma variantami není velký rozdíl ve výkonnosti, v plné virtualizaci padne něco z výkonu na režii. Kontejner či plná virtualizace mají výhodu v oddělení od hostitelského OS, z čehož vyplývá přehlednější správa a případně lepší možnosti zabezpečení.

[Pavel 'TIGER' Růžička]

Jasně, díky za rozepsání, myslel jsem si, že tak nějak to bude. Vše má něco pro a proti.

[dustin]

Z dotazu mi nepřišlo, že by měl/potřeboval různé verze mariadb, zmiňuje jen, že má verzi 10.

Samozřejmě máme jednu instalaci mariadb, spouští se jen různé instance na různých portech, s jinými cestami k datům, logům a socketům. Ve vzorovém konfig adresáři má my.cnf na příslušných místech značky, které klonovací skript při vykopírování do /etc/mysql-cloneX nahradí za údaje pro daný klon. Kopie startup skriptu (ještě to běží na sysv) pak jen změní cestu ke konfigu. Jednoduché a funguje OK.