Příspěvky

31

Sítě / Re:Pokrytí velkého RD WIFI

« kdy: 15. 01. 2018, 12:01:32 »

Jestli trvate na tech 5 GHz, tak radsi predpokladejte, ze to skrz zed vubec neleze. Treba si dejte vsude sitovou zasuvku nebo aspon husi krk, kdyby se hodil a pak muzete inteligentne laborovat s AP, az vam to bude chodit.

Ještě mě napadla druhá možnost za předpokladu, že AP (3dBi) vyzařují i směrem nahoru viz priloha. Zásuvky jsou tažený skoro všude, ale nechci mít AP někde pod gaučem nebo na komodě. Je ale dost dobře možné, že se tak stane..

32

Sítě / Re:Pokrytí velkého RD WIFI

« kdy: 15. 01. 2018, 11:12:24 »

Ještě poslední část přílohy. Nikde jsem nenašel jakou mají tyto AP Charakteristiku vyzařování signálu. APčka budou umístěné na stropě případně mohou být umístěné na stěne (z boku). Jde signát z těchto AP i směřem nahoru nebo pouze dolů 180 stupňů?

Pro upřesnění se jedná o tyto AP https://www.ubnt.com/unifi/unifi-ap-ac-lr/

33

Sítě / Pokrytí velkého RD WIFI

« kdy: 15. 01. 2018, 11:11:36 »

Dobrý den přeji,

Budeme rekonstruovat RD a rád bych se ujistil, že mnou umístěné WIFI AP budou pokrývat celý dům. Dům je asi 50 let starý stavěný z cihel. Dispozice budou zachované kromě suterénu (bude se z něj dělat byt). Pro lepší přehled posílám původní plány RD s mými poznámkami ohledně WIFI AP. Ethernetové zásuvky nejsou vyznačeny. Momentálně mi jde hlavně o tyto APčka. Máte s těmito APčky někdo reálné zkušenosti z provozu jaký mají dosah? Jejich 5Ghz část?

Děkuji za vaše podněty.

34

Server / Re:Import 2,5TB.sql souboru do DB respektive jeho rozdělení

« kdy: 02. 11. 2017, 14:39:43 »

Je to jednoduché - kdo to vymyslel,  o tom moc nepřemýšlel. Jeho úkolem byl dump, ne to pak nalévat zpět. Proč myslet dopředu, za to mě přece neplatí...

Mimochodem doporučení zálohovat mysql celým dumpem bez rozdělení na db/tabulky se i tady objevují pořád dokola.

Abych se vyhnul předešlému problému - máte někdo zkušenosti s automysqlbackup - https://www.vultr.com/docs/how-to-install-and-configure-automysqlbackup-on-ubuntu-16-04

Vypada to dobře.

35

Server / Re:Import 2,5TB.sql souboru do DB respektive jeho rozdělení

« kdy: 01. 11. 2017, 08:59:46 »

Využil jsem tohoto již hotového skriptu https://github.com/kedarvj/mysqldumpsplitter/blob/master/mysqldumpsplitter.sh

Každopádně toho kdo vymyslel dump celé DB bych nakopal. je to hrozná pakárna pracovat s tak velkým souborem i s ohledem na místo se kterým musím pracovat. Ponaučení z tohoto zni, zálohovat všechny tabulky zvlášť..

Děkuji všem zůčastněným.

36

Server / Re:Import 2,5TB.sql souboru do DB respektive jeho rozdělení

« kdy: 24. 10. 2017, 14:47:09 »

Koukám na ten htop.

Proč máš 10GB swap na stroji s 300GB RAM? Vypnul bych jej.

Proč má mysql nastaveno tak málo paměti? Máme 512GB RAM a mysql má v bufferech nastaveno 100GB (pravda nijak jsme si s tím nehráli a netestovali, ale používá je)

Kód: [Vybrat]

4065 mysql  20   0  108g 105g  17m S     3 20,9  12975:49 mysqld                                                                                                                                                                                                                                                         

20 jader = nalévání alespoň 18 jádry současně. Snadno si nastavíš parametry xargs - viz ten dump skript.

Ten stroj jsem dostal nedavno a musim ho nastavit, takze dekuju za podnety. Jinak ano mas pravdu, ze nemam uplne zkusenosti na to,a bych to dokazal efektivne spravovat, ale byl jsem do toho jak se rika hozen, takze se pokusim co nejvice veci pokazit a co mozna toho nastavit spravne.

Jeste jednou dekuju.

37

Server / Re:Import 2,5TB.sql souboru do DB respektive jeho rozdělení

« kdy: 24. 10. 2017, 14:32:37 »

Jednak to importuješ celé v jednom vlákně (takže celkový výkon stroje téměř nevyužiješ), jednak před importem určitě nevypínáš kontroly na cizí klíče a unique checks, zkusil bych i vypnutí čekání na flush

set global innodb_flush_log_at_trx_commit=2

Takže stávající dump rozsekat na tabulky (vždy je to v pořadí create database, create table, inserty do table) a ty nalévat paralelně. + samozřejmě rychlé pole či SSD, ale to u tak velkého dumpu předpokládám.

A jak jsem psal, opravit zálohovací skript, aby nedělal takovéto obludy. Navíc se to snázeji pak zálohuje/deduplikuje, protože se řada tabulek (tj. souborů) mezi intervalem záloh určitě nemění.

Děkuju

38

Server / Re:Import 2,5TB.sql souboru do DB respektive jeho rozdělení

« kdy: 24. 10. 2017, 14:28:03 »

Děkuju všem za rady. Jakmile se proberu řešením. Dám vědět. Je mi jasné, že je lepší zálohovat jednotlivé tabulky či schémata.

Mně hlavně zaráží ten výkon, jak píšete, na to bych doporučoval se podívat. Tam čuju nějaký problém.

S výkonem ze strany HW by problém být neměl. Spíš kde může být chyba, že SW nedokáže využít HW..

39

Server / Re:Import 2,5TB.sql souboru do DB respektive jeho rozdělení

« kdy: 24. 10. 2017, 14:13:16 »

Děkuju všem za rady. Jakmile se proberu řešením. Dám vědět. Je mi jasné, že je lepší zálohovat jednotlivé tabulky či schémata.

40

Server / Re:Import 2,5TB.sql souboru do DB respektive jeho rozdělení

« kdy: 24. 10. 2017, 13:35:39 »

Jaký textový editor dokáže otevřít 1,5 TB a vyzobnout z toho 30 GB?

Máte pravdu, neupřesnil jsem.
Zejména mě zaráží "problém" naimportovat pár tera. To bych řešil jako první.
Na extrakci jednocho schématu či jedné databáze z dumpu jsou příklady na googlu, lze to poměrně snadno nascriptovat.
Hledejte například: extract single database from mysql dump

Ano nasel jsem dobry skript, ktery toto umi. Problem je v tom, ze ze souboru napred vytahne schema a pak je musim nasledne importovat coz je v ramci tak velkeho objemu dat casove narocne.

41

Server / Re:Import 2,5TB.sql souboru do DB respektive jeho rozdělení

« kdy: 24. 10. 2017, 13:33:24 »

Jako nejlepší řešení mi nakonec vždy přišlo rozsekání velkého souboru na jednotlivé create a insert části. Jednak je lze v případě nutnosti/chyby opakovaně spustit, jednak lze některé části paralelizovat (rozhodně create a inserty číselníků) a nechat si největší sousta nakonec .. I tam lze pak příliš velký insert jen jednoduše rozdělit na části, které se zpracují v relativně rychlejším sledu. Nemíval jsem žádné problémy, když jsem si inserty rozsekal po cca max 200 MB souborech.. větší už obvykle "drhly"..

Jsem v linuxu zacatecnik, takze si dost dobre nedokazu predstavit jak bych takovy soubor pomoci prikazu mohl rozsekat. Asi teoreticky chapu, ze bych si mel najit radky kde zacina a konci konkretni schema s inserty a pak je postupne zkouset, ale jak na to?

42

Server / Import 2,5TB.sql souboru do DB respektive jeho rozdělení

« kdy: 24. 10. 2017, 10:22:31 »

Dobrý den,

Bohužel jsem dostal do rukou archive(záloha MySQL databáze), který má cca 800GB a po jeho rozbalení má hrubý soubor 2,5TB. V souboru je jedna velká databáze rozdělená na několik (cca 30) schémat.

V prvé řadě jsem zkusil naivně spustit celý import dat do DB*, ale i přesto, že server disponuje velkým výpočetním výkonem import jsem vypočítal na cca 3 týdny. Takto dlouhou dobu nemohu čekat. Potřeboval bych ze zdrojového souboru "vyzobat" jednotlivé schémata a pouštět (importovat) tyto data podle priority.

Máte někdo představu jak by se tato věc dala řešit?

Informace:
OS Serveru: Ubuntu 16.04LTS
SW DB: MySQL 5.7 ComunityServer

*mysql -u username -p database_name < backup_name.sql

Děkuji za všechny reakce!