Fórum Root.cz
Hlavní témata => Server => Téma založeno: bratr vítr 10. 02. 2015, 10:49:41
-
Prosím zkušenější o názor...
Přecházím na Postfix, asi 10 emailových účtů, do každého cca 15 emailů denně. Schránky uživatelů budou zálohovány (zrcadleny) rsyncem na jiný server.
Rozhodnout se pro mailbox či maildir/ ? A příp. co byste doporučili použít za filesystem, EXT4 či XFS ?
Děkuji.
-
Rozhodne maildir - urcite je lepsi mit jeden mail v jednom souboru. Uz z duvodu zalohovani, archivace apod.
-
Rozhodne maildir - urcite je lepsi mit jeden mail v jednom souboru. Uz z duvodu zalohovani, archivace apod.
A modří už vědí, že úplně nej, nej, nej je .pst soubor ...
-
Rozhodne maildir - urcite je lepsi mit jeden mail v jednom souboru. Uz z duvodu zalohovani, archivace apod.
maildir = vela malych suborox
mailbox = jeden velky subor
tu su zhrnute vyhody nevyhody
http://www.linuxmail.info/mbox-maildir-mail-storage-formats/
-
A z ceho na nej prechazis, jestli se muzu zeptat?
Postfix je super a asi nejlepsi MTA, ale z uzivatelskeho hlediska zijeme uz kapku v jine dobe a resit maildir vs. mailbox je navrat o sto let zpet. Reseni je neco ve stylu Zimbra nebo SOGo.
-
Reseni je neco ve stylu Zimbra nebo SOGo.
Kristepane....
http://wiki.zimbra.com/wiki/Zimbra_MTA
The Zimbra MTA server includes the following programs:
• Postfix MTA, for mail routing, mail relay, and attachment blocking
Debile. ::) >:(
-
A z ceho na nej prechazis, jestli se muzu zeptat?
Postfix je super a asi nejlepsi MTA, ale z uzivatelskeho hlediska zijeme uz kapku v jine dobe a resit maildir vs. mailbox je navrat o sto let zpet. Reseni je neco ve stylu Zimbra nebo SOGo.
samozřejmě maildir, o tom není řeči
řešit maildir/box vs zimbra je trochu jako mluvit o hruškách a argonu, btw. ta zimbra má pod sebou ten postfix, jestli se nepletu
-
Smarja ja vim, ze Zimbra pouziva postfix - jde o to, ze nemusim resit jak a co si kam uklada a pouzivam jeji nastroje na zalohovani... Je to asi jako zalohovat MySQL kopirovanim souboru s tabulkama z masteru misto master-slave-mysqldump.
Druha vec je ta z pohledu uzivatele, ale tu tady nema cenu resit, protoze tady si evidentne vsichni ctou maily muttem, pripadne rovnou tcpdumpem.
-
Co má co dělat uživatelský klient připojený například přes IMAP se serverovou stranou? Nějak se nechytám.
Druha vec je ta z pohledu uzivatele, ale tu tady nema cenu resit, protoze tady si evidentne vsichni ctou maily muttem, pripadne rovnou tcpdumpem.
-
Co má co dělat uživatelský klient připojený například přes IMAP se serverovou stranou? Nějak se nechytám.
Nic, přece... seš sto let za vopicema a starší než hnědý uhlí. Použij Iksčejndž s obrovským binárním blobem woe, páč to je woe moderní. A když se to posere tak už z toho ty maily woe nikdo nedostane.
Tyhle mlamoje kopat s rozběhem do glutea maxima. >:( >:( >:(
-
Co má co dělat uživatelský klient připojený například přes IMAP se serverovou stranou? Nějak se nechytám.
Celkem nic no. Jenom ze postfix na to fakt nestaci. Budes muset nainstalovat autentizacni server, adresar, IMAP server, antivir, antispam, nejake DKIM aj. filtry, webmail, atd. abys dosahnul cca toho, co je dneska standard. Nemluve o kalendari, distribucnich listech, atd.
Nic, přece... seš sto let za vopicema a starší než hnědý uhlí. Použij Iksčejndž s obrovským binárním blobem woe, páč to je woe moderní. A když se to posere tak už z toho ty maily woe nikdo nedostane.
Tyhle mlamoje kopat s rozběhem do glutea maxima. >:( >:( >:(
Tovizejo. Zimbra ma vsechny maily ulozene v /opt/zimbra/store v obyc textovem msg formatu, takze je z ni snad dokazes dostat i Ty.
-
Tovizejo. Zimbra ma vsechny maily ulozene v /opt/zimbra/store v obyc textovem msg formatu, takze je z ni snad dokazes dostat i Ty.
To rozhodně není možné. Tady náš nadějný mlamoj psal, že "resit maildir je navrat o sto let zpet" a že řešením je Zimbra. A hlavně woe je výhoda že "nemusim resit jak a co si kam uklada" - páč to je woe zbytečný, co si nenaklikám v GUI tak nemám, to je woe správný mažerský entrprajs řešení woe!
Jinak pro zopakování:
asi 10 emailových účtů, do každého cca 15 emailů denně. Schránky uživatelů budou zálohovány (zrcadleny) rsyncem na jiný server.
-
Tovizejo. Zimbra ma vsechny maily ulozene v /opt/zimbra/store v obyc textovem msg formatu, takze je z ni snad dokazes dostat i Ty.
To rozhodně není možné. Tady náš nadějný mlamoj psal, že "resit maildir je navrat o sto let zpet" a že řešením je Zimbra. A hlavně woe je výhoda že "nemusim resit jak a co si kam uklada" - páč to je woe zbytečný, co si nenaklikám v GUI tak nemám, to je woe správný mažerský entrprajs řešení woe!
Jinak pro zopakování:
asi 10 emailových účtů, do každého cca 15 emailů denně. Schránky uživatelů budou zálohovány (zrcadleny) rsyncem na jiný server.
Asi uplne nechapes nebo blbe ctes. Nadejny mamloj psal "resit maildir vs. mailbox". A ja neresim, kam si to Zimbra uklada, jenom to vim.
Pokud to nejsou jenom systemove schranky a budou s tim pracovat realni uzivatele, tak co se ficur tyce, pocet uzivatelu v podstate nehraje roli.
Jinak kdyz porad zminujes ten Exchange, tak jeho masova rozsirenost je dana presne timhle uvazovanim - smatlat postfix + dovecot + neco dalsiho prece staci. A to nemluvim o tom, ze Zimbra presne tohle udelala - vzala open source komponenty a dotahla to smatlani do funkcniho celku.
-
MailDir protože pak se s tim líp racuje.
Jo a nenech si radit a nebo se otrávit od hulvátských pubertáků co svojí hloupost dohání výkřiky jako woe ... .
-
Asi uplne nechapes nebo blbe ctes. A ja neresim, kam si to Zimbra uklada, jenom to vim.
Ano, neřešíš, protože "detaily" jako jaký filesystém se hodí pro ukládání spousty malých souborů nebo co se líp zálohuje tím či oním, to je přece pod rozlišovací schopnosti entrprajs mlamoje. Tam tam nahodí jakýsi grůpvér, z posledních sil tam něco nakliká ("konfigurace") no a pak to funguje jako blackbox, o kterém přece není potřeba nic vědět, vždyť takové blbosti moh někdo řešit snad před sto lety.
-
a k druhé části mého dotazu... jaký filesystem byste doporučovali ?
předpokládám, že v mém případě to je jedno, nicméně jaký je váš názor na volbu ?
-
400 000 mailů, 200G, mám na ext4, 10k disky. Měl jsem to i na 7.2k disku a bylo to ok. Tomu extu prostě věřím nejvíc.
-
Je to asi jako zalohovat MySQL kopirovanim souboru s tabulkama z masteru misto master-slave-mysqldump.
Jo jasně. A potom zjistíte, že ten dump je nekonzistentní, protože replikace se uráčila replikovat by the mysql way a ne s ohledem na konzistenci dat a budete víte kde. Pokud už někdo musí používat tuhle .... věc, tak je lepší to občas vypnout a odzálohovat ty soubory (nebo alespoň zabránit přístupu klientům a udělat pořádný dump, který ta db za běhu taky neumí).
-
Jo jasně. A potom zjistíte, že ten dump je nekonzistentní, protože replikace se uráčila replikovat by the mysql way a ne s ohledem na konzistenci dat a budete víte kde. Pokud už někdo musí používat tuhle .... věc, tak je lepší to občas vypnout a odzálohovat ty soubory (nebo alespoň zabránit přístupu klientům a udělat pořádný dump, který ta db za běhu taky neumí).
No to podle me akorat znamena, ze mas blbe nastaveny binlog-format, nemas zadnej monitoring logu (hlasky "Statement may not be safe to log in statement format") a downtime Ti nedela problem. Nevychvaluju MySQL, ale neprijde mi to jako jeho chyba.
-
a k druhé části mého dotazu... jaký filesystem byste doporučovali ?
předpokládám, že v mém případě to je jedno, nicméně jaký je váš názor na volbu ?
Ext3/4, XFS, BTRFS. Prostě si vyber to, co znáš, co umíš otestovat / opravit a s čím máš zkušeností. U této minimální zátěže je to fakt jedno, takže neřešit. U větší zátěže je možné všechny fs nastavit s ohledem na počty souborů a vybrat v testu ten nejlepší.
-
No to podle me akorat znamena, ze mas blbe nastaveny binlog-format, nemas zadnej monitoring logu (hlasky "Statement may not be safe to log in statement format") a downtime Ti nedela problem. Nevychvaluju MySQL, ale neprijde mi to jako jeho chyba.
Ano, to že to JÁ mám blbě nastavené už jsem slyšel. Víte, problém je jinde. U MySQL všichni berou jako normální, že se o tu mysql musíte starat, neustále kontrolovat konzistenci, neustále něco řešit a když to neděláte, je to VÁŠ
-
No to podle me akorat znamena, ze mas blbe nastaveny binlog-format, nemas zadnej monitoring logu (hlasky "Statement may not be safe to log in statement format") a downtime Ti nedela problem. Nevychvaluju MySQL, ale neprijde mi to jako jeho chyba.
Ano, to že to JÁ mám blbě nastavené už jsem slyšel. Víte, problém je jinde. U MySQL všichni berou jako normální, že se o tu mysql musíte starat, neustále kontrolovat konzistenci, neustále něco řešit a když to neděláte, je to VÁŠ problém.
Ne, ten software se o ty data má postarat sám, od toho je. A má k tomu úplně všechno, co k tomu potřebuje. Viz následující příklad:
* mysqldump blokuje aplikace (protože zámky)
* Na to někdo vymyslí geniální řešení: tak to replikuj a dumpuj slave
* Super, tak se to replikuje a dumpuje slave, slave se rozbije a reakce je: tvoje chyba měl jsi kontrolovat konzistenci.
JAK? Tím že zastavím klienty na masteru a udělám dump? :-D
Takže abych se vyhnul downtime při zálohování, tak udělám downtime při kontrole replikace. Jako fakt super řešení by the mysql way... A přesně těchto pastí je to plné a lidem okolo to vůbec nevadí. Takže sorry, ale této věci svoje data fakt nedám. ;-)
-
Zalohy se daji delat jednoduse pomoci snapshotu fs, nebo pripadne pomoci http://www.percona.com/doc/percona-xtrabackup/2.1/innobackupex/innobackupex_script.html
-
Smarja ja vim, ze Zimbra pouziva postfix - jde o to, ze nemusim resit jak a co si kam uklada a pouzivam jeji nastroje na zalohovani... Je to asi jako zalohovat MySQL kopirovanim souboru s tabulkama z masteru misto master-slave-mysqldump.
Druha vec je ta z pohledu uzivatele, ale tu tady nema cenu resit, protoze tady si evidentne vsichni ctou maily muttem, pripadne rovnou tcpdumpem.
Tovizejo, ja si taky koupim kamion. Sice jezdim skoro furt jen sam, ale moh by se hodit, zejo ...
Ano, neřešíš, protože "detaily" jako jaký filesystém se hodí pro ukládání spousty malých souborů nebo co se líp zálohuje tím či oním, to je přece pod rozlišovací schopnosti entrprajs mlamoje. Tam tam nahodí jakýsi grůpvér, z posledních sil tam něco nakliká ("konfigurace") no a pak to funguje jako blackbox, o kterém přece není potřeba nic vědět, vždyť takové blbosti moh někdo řešit snad před sto lety.
entrprajs mamloj si woe predevsim necha ty vecy udelat ne klyc neee? Proste woe vikesuju mego, paac ten co mi to nabid me pozval na golf/sqash/... a dal mi k tomu pekny barevny obrazky vismatejch rodinek, takze to prece musi workovat fpohode.
a k druhé části mého dotazu... jaký filesystem byste doporučovali ?
předpokládám, že v mém případě to je jedno, nicméně jaký je váš názor na volbu ?
Mno, vzhledem k tomu co pises, bych dal prednost proverenosti, protoze vykon rozhodne kritickej nebude. takze ext. Mam na stejnym nejakych 45 000 mailu a zadnej problem neni.
No to podle me akorat znamena, ze mas blbe nastaveny binlog-format, nemas zadnej monitoring logu (hlasky "Statement may not be safe to log in statement format") a downtime Ti nedela problem. Nevychvaluju MySQL, ale neprijde mi to jako jeho chyba.
mysql a problem s downtime? lol ... to je asi tak stejny, jako kdybys resil HA na windows.
Zalohy se daji delat jednoduse pomoci snapshotu fs, nebo pripadne pomoci http://www.percona.com/doc/percona-xtrabackup/2.1/innobackupex/innobackupex_script.html
loooool a nekonzistentni data v databazi ti neva, vid?
-
Proste woe vikesuju mego, paac ten co mi to nabid me pozval na golf/sqash/... a dal mi k tomu pekny barevny obrazky vismatejch rodinek, takze to prece musi workovat fpohode.
Jop! Woe tady bych to potřeboval přivařit nebo snejtovat, co myslíš že bude lepší? Takový píčoviny řešili před sto lety, seš úplně zavostalej, místo nejtů za deset korun si kup si CNC za deset mega a vyrob si to celý znova! ;D ::)
-
Zalohy se daji delat jednoduse pomoci snapshotu fs, nebo pripadne pomoci http://www.percona.com/doc/percona-xtrabackup/2.1/innobackupex/innobackupex_script.html
loooool a nekonzistentni data v databazi ti neva, vid?
Tak jestli pouzivas myisam tak si muzes pred dumpem zamknout tabulky pro zapis. :P
-
Zalohy se daji delat jednoduse pomoci snapshotu fs, nebo pripadne pomoci http://www.percona.com/doc/percona-xtrabackup/2.1/innobackupex/innobackupex_script.html
loooool a nekonzistentni data v databazi ti neva, vid?
Tak jestli pouzivas myisam tak si muzes pred dumpem zamknout tabulky pro zapis. :P
Dumpem => Snapshotem
-
Zalohy se daji delat jednoduse pomoci snapshotu fs, nebo pripadne pomoci http://www.percona.com/doc/percona-xtrabackup/2.1/innobackupex/innobackupex_script.html
loooool a nekonzistentni data v databazi ti neva, vid?
Tak jestli pouzivas myisam tak si muzes pred dumpem zamknout tabulky pro zapis. :P
Koukam ze ses vazne odpornik ... tvle je uplne jedno jakej model pouzivas, snap fs bude vzdy nekonzistentni. A zamceni pro zapis je ti howno platny. Musis flushnout data na disk. V pripade transakcnich veci musis dokoncit probihajici transakce. K tomu se sice muzes pokusit mysql ruzne dokopat, ale "od prirody" to nijak negarantuje => pro jakykoli nasazeni kde na datech sejde je naprosto nepouzitelna.
-
Zalohy se daji delat jednoduse pomoci snapshotu fs, nebo pripadne pomoci http://www.percona.com/doc/percona-xtrabackup/2.1/innobackupex/innobackupex_script.html
loooool a nekonzistentni data v databazi ti neva, vid?
Tak jestli pouzivas myisam tak si muzes pred dumpem zamknout tabulky pro zapis. :P
Koukam ze ses vazne odpornik ... tvle je uplne jedno jakej model pouzivas, snap fs bude vzdy nekonzistentni. A zamceni pro zapis je ti howno platny. Musis flushnout data na disk. V pripade transakcnich veci musis dokoncit probihajici transakce. K tomu se sice muzes pokusit mysql ruzne dokopat, ale "od prirody" to nijak negarantuje => pro jakykoli nasazeni kde na datech sejde je naprosto nepouzitelna.
Abych to zkratil.
Myisam - je nutne pouzit flush tables with read lock; set global read_only = on; a pote provest snapshot.
Innodb - staci provest snapshot a pri obnoveni pri startu mysql pockat az provede co potrebuje podle logu.
Nechapu v cem vidis problem a kde muze vznikat nejaka nekonzistence dat, snapshot fs je z principu to same jako vypadek napajeni.
-
Koukam ze ses vazne odpornik ... tvle je uplne jedno jakej model pouzivas, snap fs bude vzdy nekonzistentni. A zamceni pro zapis je ti howno platny. Musis flushnout data na disk. V pripade transakcnich veci musis dokoncit probihajici transakce. K tomu se sice muzes pokusit mysql ruzne dokopat, ale "od prirody" to nijak negarantuje => pro jakykoli nasazeni kde na datech sejde je naprosto nepouzitelna.
ACID. Clovek ma zalohu suborov tak, ako by ich videl, keby v tom momente vypadol prud (to sa tiez nestihne flushnut alebo dokoncit transakcie).
Z toho by sa slusna databaza s transakciami mala spamatat bez nejakych nekonzistencii.
-
ACID. Clovek ma zalohu suborov tak, ako by ich videl, keby v tom momente vypadol prud (to sa tiez nestihne flushnut alebo dokoncit transakcie).
Z toho by sa slusna databaza s transakciami mala spamatat bez nejakych nekonzistencii.
Až na to, že MySQL není ACID. Pokud nějaká databáze používá výhradně InnoDB, tak se možná dá uvažovat o tom, že tato konkrétní db v rámci serveru acid splňuje, ale MySQL jako celek ne. Už jen proto, že nelze vypnout MYISAM, která je na (nejen) systémové věci prostě povinná.
-
Abych to zkratil.
Myisam - je nutne pouzit flush tables with read lock; set global read_only = on; a pote provest snapshot.
Innodb - staci provest snapshot a pri obnoveni pri startu mysql pockat az provede co potrebuje podle logu.
Nechapu v cem vidis problem a kde muze vznikat nejaka nekonzistence dat, snapshot fs je z principu to same jako vypadek napajeni.
Abych to zkratil, netusis o cem plkas.
Koukam ze ses vazne odpornik ... tvle je uplne jedno jakej model pouzivas, snap fs bude vzdy nekonzistentni. A zamceni pro zapis je ti howno platny. Musis flushnout data na disk. V pripade transakcnich veci musis dokoncit probihajici transakce. K tomu se sice muzes pokusit mysql ruzne dokopat, ale "od prirody" to nijak negarantuje => pro jakykoli nasazeni kde na datech sejde je naprosto nepouzitelna.
ACID. Clovek ma zalohu suborov tak, ako by ich videl, keby v tom momente vypadol prud (to sa tiez nestihne flushnut alebo dokoncit transakcie).
Z toho by sa slusna databaza s transakciami mala spamatat bez nejakych nekonzistencii.
Clovek kupodivu zalohuje proto, aby ta data mel, ne proto, aby se spolehal na to, ze se to "nejak" vzpamatuje. Proto se zalohuji konzistetni data v konzistentnim stavu. A proto je na to treba databaze, ktera takovy stav umi zajistit. A zajistuje se to tak, ze databaze ma api (nebo integrovany nastroj), kde se rekne, ze chci zalohovat, databaze se postara o dokonceni transakci, pozastavi zapis do dat, udela se snap dat a pak se zapis znova povoli. A mimo jine se i proto davaji transakcni logy na jiny disk nez jsou data. Protoze ta databaze z hlediska uzivatele stale bezi (i pro zapis), jen se zapisuje docasne pouze do transakcniho logu.
Mluvit v pripade databaze o stavu "jako kdyz vypnes elektriku" muze leda pomatenec. Proto se kupodivu porizuji UPS, aby takovy stav nenastal. A dela se to proto, ze takovy stav rozhodne konzistetni data nezaruci, a zadna databaze na svete nezaruci to, ze se po podobnem vypnuti da jeste s daty pracovat. To ze to vetsinou "nejak funguje" neznamena vubec nic.
Az budes mit data ktery ti nekdo ohodnoti na desitky/stovky mega, tak si popovidame.
-
zadna databaze na svete nezaruci to, ze se po podobnem vypnuti da jeste s daty pracovat.
Zaručí to všechny které mají D z toho ACID a platí to pro data transakcí které dosáhly stavu commited.
-
A proto je na to treba databaze, ktera takovy stav umi zajistit. A zajistuje se to tak, ze databaze ma api (nebo integrovany nastroj), kde se rekne, ze chci zalohovat, databaze se postara o dokonceni transakci, pozastavi zapis do dat, udela se snap dat a pak se zapis znova povoli. A mimo jine se i proto davaji transakcni logy na jiny disk nez jsou data. Protoze ta databaze z hlediska uzivatele stale bezi (i pro zapis), jen se zapisuje docasne pouze do transakcniho logu.
Existuji i jine databaze nez MySQL. Ty opravdove, velke (ale i ruzne alternativni male). U tech bezi zaloha na pozadi na transakcich nezavisle. Zadny zapis dat se napozastavi ani nepovoli. Dokonce to muze zalohovat inkrementalne. A presto jsou ty zalohy konzistentni a dokonce umoznuji PITR (Point-in-time-recovery).
MySQL je tu uz s nami 15 let a porad je to takovej mladej frikulinskej cupr projekt. Takze mu vsichni radi odpusti ze jeste poradne nemaji vyreseny zalohovani anebo ze nedodrzuji zadnou normu SQL.
PS: sorry za flame, ale zkuste se podivat kolik je dneska na trhu databazi a porovnejte to s tim co umi MySQL.
-
zadna databaze na svete nezaruci to, ze se po podobnem vypnuti da jeste s daty pracovat.
Zaručí to všechny které mají D z toho ACID a platí to pro data transakcí které dosáhly stavu commited.
Nezaruci, nemuze. Databaze vubec netusi, jestli ta data uz na disku skutecne jsou. A tusit nemuze. Zapis na disk resi OS, a ani ten v realu nevi, zda data uz sou zapsana, nebo zda jsou v nejake cache. Prave proto se vsechny tyhle veci pripojujou na UPSky, a diskovy systemy maji zcela bezne jeste vlastni baterie - prave pro cache radice/disku.
Navic krome konzistence databazovy existuje jeste konzistence datova. Databaze muze byt perfektne konzistentni a nepozkozena, a presto jsou data v ni naprosto khownu.
-
Nezaruci, nemuze. Databaze vubec netusi, jestli ta data uz na disku skutecne jsou. A tusit nemuze. Zapis na disk resi OS, a ani ten v realu nevi, zda data uz sou zapsana, nebo zda jsou v nejake cache.
fsync()
A ano, dalo sa to vypnut a niekto si potom pochvaloval nasobne zrychlenia. Az do prveho vypadku prudu.
Prave proto se vsechny tyhle veci pripojujou na UPSky, a diskovy systemy maji zcela bezne jeste vlastni baterie - prave pro cache radice/disku.
A UPSka nikdy nezlyha...
Navic krome konzistence databazovy existuje jeste konzistence datova. Databaze muze byt perfektne konzistentni a nepozkozena, a presto jsou data v ni naprosto khownu.
Napriklad? Nie je to vec programatora? (Tak mu treba, ked nepouziva transakcie)
-
Navic krome konzistence databazovy existuje jeste konzistence datova. Databaze muze byt perfektne konzistentni a nepozkozena, a presto jsou data v ni naprosto khownu.
Kdyz programator nepouziva transakce, tak tim bude trpet i zaloha pomoci dumpu.
-
Nezaruci, nemuze. Databaze vubec netusi, jestli ta data uz na disku skutecne jsou. A tusit nemuze. Zapis na disk resi OS, a ani ten v realu nevi, zda data uz sou zapsana, nebo zda jsou v nejake cache. Prave proto se vsechny tyhle veci pripojujou na UPSky, a diskovy systemy maji zcela bezne jeste vlastni baterie - prave pro cache radice/disku.
Boha jeho >:(
Samozřejmě, že zaručí. DB klient pošle commit, db udělá zápisy co potřebuje a vydá směrem k fs příkaz fsync, fs pošle data na disk a vydá směrem k disku příkaz flush, disk zapíše potvrdí zápis, os potvrdí fsync a db potvrdí commit. (Zjednodušeně řečeno.)
Cache řadiče držená zvláštní baterkou s předchozím schématem má společného jen tolik, že se data neukládájí přímo na disk (což je samozřejmně pomalé), ale do paměťi řadiče a ten to až potom asynchronně zapíše na disk. Baterku to má proto, aby když vypadne proud a disky přestanou komunikovat, tak si ta data podrží v paměti a při další power on je zapíšou na ty disky.
Problém nastává v případech, kdy nějaký krok selže, tedy pokud disk potvrdí zapsání dat dřív, než je skutečně zapíše. Nebo kdy DB potvrdí klientovi commit dřív, než dostane odpověď od OS apod. Pokud ale ty jednotlivé vrstvy pracují jak mají, je vše ok a v případě výpadku napájení se nic nestane. UPSky slouží spíše ke korektnímu vypnutí služeb a korektnímu ohlášení okolním systémům, že se jde vypnout.
-
Korektní dump innodb tabulek za běhu (samozřejmě se netýká myisam a memory tabulek) lze pomocí mysqldump --single-transaction.
-
Nezaruci, nemuze. Databaze vubec netusi, jestli ta data uz na disku skutecne jsou. A tusit nemuze. Zapis na disk resi OS, a ani ten v realu nevi, zda data uz sou zapsana, nebo zda jsou v nejake cache. Prave proto se vsechny tyhle veci pripojujou na UPSky, a diskovy systemy maji zcela bezne jeste vlastni baterie - prave pro cache radice/disku.
Na normálním PC/serveru jsou data po ukončení transakce buď fyzicky na plotně disku nebo v zápisové cache RAID zálohované baterkou a spolehnutí na to je, nevím kde je zase problém.
-
OK, du vysvetlit zakaznikum, ze ty statisice za UPSky sou vlastne vyhozeny prachy ... pisou to na rootu, tak to musi bejt pravda...
A co teprve ty miliony za licence na (konzitentni) zalohovani ...
-
UPS vyhozené prachy nejsou, jsou záležitosti které UPS potřebují.
Konzitentní zálohování je co přesně ?
-
OK, du vysvetlit zakaznikum, ze ty statisice za UPSky sou vlastne vyhozeny prachy ... pisou to na rootu, tak to musi bejt pravda...
A co teprve ty miliony za licence na (konzitentni) zalohovani ...
Statisíce a miliony nejsou zárukou ničeho. Viděl jsem projekty 60x předražené a prachy vyhozené na věci, které byly naprosto k ničemu a nakonec vlastně nepoužité. A viděl jsem, jak dotyčný se ani vteřinu nezamyslel a chystal se vypláznout dalšího čtvrt mega za další nesmysl, který šel řešit jen jiným uspořádáním již existujícího systému. V podstatě by to šlo jen do kapsy dodavateli, za nic.
-
A proč by se měl zamýšlet, když ty prachy nejsou jeho?