Adatbázis: SQL, XML DB

Keresek egy olyan, lehetőleg minél egyszerűbb SQL adatbáziskezelőt, aminek stabil a master-master replikációja.
Eddig mysql-ben használtam csak replikációt, ott is csak master-slave típusút, de annyira megbízhatatlan, hogy erre nem mernék fontosabb adatokat bízni. Olyan rendszert keresek, ami a fájlrendszer vagy hardver hibák esetén történő leállások után is képes újra szinkronba kerülni, anélkül, hogy a másik master rendszernek le kellene állnia - akár csak egy teljes dump erejéig is.Az SQL képességek tekintetében nincsenek nagy igényeim, csak egyszerű sql műveleteket kell végrehajtani, tehát mellőzném az oracle farmok kialakítását, bár ezek bizonyosan elég megbízhatóak lennének.
Jelenleg csak a pgsql-re tudok alternatívaként gondolni, de ezzel gyakorlatilag semmilyen tapasztalatom nincs, csak a legendák, hogy mennyivel jobb mint a mysql.
Mivel csak konfigurációs adatokat fog tárolni az adatbázis, az jó lenne, ha minél gyorsabban lenne képes lefuttatni egy-egy SELECT-et. Ennek ellenére a cdb-t és egyéb nem SQL adatbázisokat kerülném, a konfigurálhatóság egyszerűsítése miatt.

Sziasztok!

Tudna segíteni valaki egy nagy tárhely szolgáltató support válaszának az értelmezésében?

Ezt a választ kaptam, hogy egy adott lekérdezésre (ami php-ban történt) miért bannolta az ip-met a szerverük:

"A szerver biztonságos üzemeltetése miatt szűrjük az olyan jellegű kéréseket ahol böngészőn keresztül próbálnak meg SQL parancsokat lefuttatni."

Sok dolgot láttam már, de sok évnyi fejlesztéssel a hátam mögött ezt nem sikerült értelmeznem. Mit takarhat a böngészőn keresztül futtatott sql parancs?

Köszi előre is!!!

Sziasztok!

Csináltam egy pure-ftpd szervert, ami Postgres-ből autentikál.
De most kiderült, hogy egy már meglévő táblából kell autentikálnia, abban viszont SHA512-ben vannak tárolva a jelszavak.
A pure-ftpd konfig fájljában nincs utalás, hogy tudná ezt a titkosítást és eddig a google sem segített.
Valaki csinált már ilyet?

Köszönöm!

Szeretném, ha több sor megmaradna a .sqlite_history fájlban. Van valahol lehetőség ezt megnövelni (vagy esetleg korlátlannak beállítani)?

Találtam egy hibát az SQLite3-ban. Illetve éppen az a (némiképp filozófiai) kérdés, hogy hibáról van-e szó, vagy egyszerűen ez a működése.

Mielőtt továbbmennénk, leszögezem, hogy nem vagyok érdekelt a kérdésben. Nincsenek SQLite3-ra alapozott alkalmazásaim. Az SQLite csak annyiban érdekel, hogy interfészeket írok különböző adatbázisokhoz: Oracle, Postgres, MySQL, DB2 mellett az SQLite-hoz is. Az SQLite lehetőségeit letapogató programjaim egyikével akadtam a jelenségre. Vettem magamnak a fáradságot egy bug report elkészítésére, megírtam a jelenséget demonstráló programot Rubyban (azért Rubyban, hogy mindenki könnyen tanulmányozhassa) és beküldtem az SQLite3 users mailing listre.

A kérdéses Ruby program:

http://comfirm.hu/pub/sqlite3-regression.rb

Érdekelnének a vélemények.

Várhatóan meg fognak jelenni olyan posztok, amikben tanácsokat kapok, hogyan tudom elkerülni azt a jelenséget, amit demonstrálni akarok. Ezért itt leírok néhány lehetőséget, amit érdemes kipróbálni. Egy részüket leírtam a ruby script alján levő kommentekben is:

1) Ha nincs bekapcsolva a WAL mód (write ahead log, 6. sor kikommentezve), a jelenség megmarad, tehát nem függ a WAL-tól.

2) Ha nincs létrehozva a "proba_nev" index (28. sor kikommentezve), a jelenség megszűnik.

3) Ha a select bármilyen módon rendezve van, azaz írunk egy _akármilyen_ plusz order by klózt az 54. sorba, a jelenség megszűnik.

4) Ha teljesen kihagyjuk az 56. sorban levő update-et, a jelenség megszűnik.

5) Ha úgy módosítjuk, az 56. sorban levő update-et, hogy ne módosítsa a "megnevezes" mezőt, a jelenség megszűnik.

6) Ha az sqlite3 könyvtár mostani változatai helyett a 3.7.9 verzióval futtatjuk a programot, a jelenség megszűnik.

Még biztos lehetnek további ötletek is. Nem érdekelnek az olyan megjegyzések, hogy a design pattern jó vagy rossz. Ezek legális SQL utasítások, amiket az adatbázisnak így vagy úgy végre kell hajtania. A kérdés az, hogy amit az SQLite3 csinál, az hiba-e. Az bizonyos hogy _regresszió_ (vagyis magyar szóval _eltérés_), hiszen látjuk, hogy a 3.7.9 még másképp működik, mint a későbbiek.

Nem tudja véletlenül valaki, hogy az alábbi karakterkészlet vajon milyen lehet?

á  é  í  ó  ö  ő  ú  ü  ű  Á  É  Í  Ó  Ö  Ő  Ú  Ü  Ű
A0 82 A1 A2 94 8B A3 81 FB B5 90 D6 E0 99 8A E9 9A EB

Egy DBF fájlt kellene generálnom, és a program által kiadott minta DBF-ben így vannak kódolva az ékezetes betűk.

Egy futó másik témához hasonlóan nekem is ez a problémám én viszont nem akarom ott tárolni a fájlokat. :)

Adott egy katalógus szerű rendszer, ami valójában csak kényszerűségből katalógus, valójában egy kutatási célszoftver (kódexeket kutat). Az oldalaknak a fizikai manifesztációja háromféle. Első az eredeti kép, a második egy PDF amiben x méretre butítva ülnek a képek, a harmadik pedig osm tileokra bontott formátumban sok kicsi csempe. Ezek a képek kezdetben fontosak, aztán ahogy feltérképezik a rajtuk található információt egyre kevéssé érdekesek. Ez így 4-5 TB adat a filerendszeren, amíg a belőlük kinyert adatok nem több mint 70 mb (jelenleg) relációs adatbázisban.
Tegnap volt egy meetingem ahol eléggé vágta a pofákat az illető, mikor kiderült, hogy a képek nincsenek adatbázisban tárolva a kutatási eredményekkel együtt. Eddig eléggé ódzkodtam a gondolattól, és nem is látom indokoltnak, hogy a 70 mb-os adatbázisból csináljak egy 5 TB-os, nehez(ebb)en backuppolható, nehezen mozgatható relációs adatbázist, csak azért, hogy a forrásanyag mindenáron együtt legyen a metaadatokkal és a feldolgozás végtermékével. A relációs adatbázis egy adatbázis, a fájlrendszer pedig fájlrendszer. Külön-külön mindkettő lehet annyira fontos (és az is), hogy a maga területén a mentés, snapshotolás működjön megfelelő sebességgel, ami csorbulhat ha összekeverem a kettőt.
Az adatok "összekapcsolását" akár az adatbázis fejlesztésével is meg lehetne oldani és akkor még mindig nem binárist tárolok adatbázisban (pl eredeti képek hashelése és azok visszaellenőrzés sérülés/elveszés esetére).
A kérdésem az, hogy ezt hogyan oldják meg? Lehet, hogy csak én gondolom túl ezt a bináris adattárolást relációs adatbázisban?

Sziasztok!

Egy sokkal erősebb gép közel 2x annyi idő alatt végzi el a MongoDB importálást, mint a jóval gyengébb és nem tudunk rájönni, hogy miért.

A teszteléshez ezt használtuk: https://github.com/jsteemann/BulkInsertBenchmark
Lokálisan futtatva: `php run.php`

Ami a stage szerveren 261,1 mp alatt lefut az a production-on csak 466,0 mp.
Vagy ami 9,2 alatt az 14,1 alatt.

A lekért MongoDB configból látszik, hogy a production szerveren a storageEngine {persistent} true-ra van állítva.
Azonban ha ezt módosítani akartuk az /etc/mongod.conf-ban (tudom YAML, tab nem lehet),
akkor 2-es kóddal elszáll a mongod main process, ami "The specified options are in error or are incompatible with other options."

Próbáltuk a loggolást teljesen kikapcsolni meg a diagnosztikai adatok gyűjtését, de az sem hozott eredményt.
Próbáltuk azt is, hogy mmapv1 helyett wiredTiger -re állítjuk a tárolást, de nem segített.

A production gép nem csinál ezen kívűl szinte semmit, mert nincs még publikálva az oldal.
Ha valakinek van bármi ötlete, hogy mit és hogyan próbáljunk ki, akkor kérjük írja meg.

A két gép configja:

1. production (fizikai gép)

• CPU 48 mag, bővebben: http://pastebin.com/74SbJnAp
• RAM 64GB
• Disk HDD
• RAID LSI Logic / Symbios Logic MegaRAID SAS 2108 [Liberator] (rev 05), bővebben: http://pastebin.com/9vYAg7jL
• Ubuntu 14.04.5 LTS
• Linux 4.4.0-57-generic
• Mongo version 3.2.11 mmapv1
• Mongo config etc http://pastebin.com/nB1zNwZS
• Mongo config dump http://pastebin.com/2hDCbrD9

2. stage (virtuális gép, KVM)

• CPU 2 mag, bővebben: http://pastebin.com/74DPCQ20
• RAM 4 GB
• DISK HDD
• Ubuntu 14.04.3 LTS
• Linux 3.19.0-78-generic
• Mongo version 3.2.1 mmapv1
• Mongo config etc http://pastebin.com/YdwTRP2h
• Mongo config dump http://pastebin.com/v1mP29Pr

Helo,

kivancsi vagyok, ki mit gondol.
Adott egy bare metal szerver 16G RAM-mal, rajta egy Postgres instance. Altalaban a memoria kozel teljesen foglalt, de a free es a vmstat alapjan kb. 14.5 GB page cache, kb. 1 G pedig hasznalatban van. vm.overcommit_memory = 0 (heuristic).

Namost, az OOM killer egyszercsak lelott par Postgres processzt, mert szerinte nem volt elegendo szabad memoria.

Kerdes: miert nem takaritja ki a mmap-elt fajlokat a kernel ahelyett, hogy leolne az egyik processzt?

Egyebkent:

- az OOM killer akkor utott be, amikor egy uj (egyebkent kis memoriaigenyu) processz elindult a gepen (ClamAV)
- a memoriafragmentacio jelentos (256K folotti chunk-okbol kb. egyaltalan nem volt szabadon).

Sziasztok,

Ubuntu Szerveren futott alapbol (telepitesnel ki lehetett valasztani) egy MySQL szerver amit Webmin-en keresztul el is lehetett erni.
Nem hasznaltam idaig semmire, csak volt. Most azonban szerettem volna :)

sudo mysql_secure_installation

beallitasa utan mar nem sikerult elerni igy arra jutottam hogy hasznalom eszetlenul a google-t es torlom valahogy a beallitast --> Mysql meghalt mert sem Webmin-en keresztul nem tudok hozza ferni sem terminalbol.

sudo cp /etc/mysql/mysql.conf.d/mysqld.cnf /etc/mysql/my.cnf

parancs eseten meg azt kapom hogy nincs ilyen konyvtar sem.

Probaltam

Torolni es telepiteni de semmi hatas :

sudo apt install mysql-server mysql-client  / sudo apt remove mysql-server mysql-client

Forras ahonnan lestem az okossagot (okossag csak faszul hasznaltam valoszinuleg:) ) : https://askubuntu.com/questions/172514/how-do-i-uninstall-mysql

sudo apt-get purge mysql-server mysql-client mysql-common mysql-server-core-5.5 mysql-client-core-5.5
sudo rm -rf /etc/mysql /var/lib/mysql
sudo apt-get autoremove
sudo apt-get autoclean

Innen kiszedtem a

mysql-common

-t mert akkor torolte volna a kodit is tobbek kozott (ami nem hasznalja a servert igy nem ertem miert akarja torolni?) De nem szeretnem azt is ujra beallitani

Mit csinaljak?:)
Koszonom