Sziasztok!
Ismertek-e olyan open-source alkalmazást, amivel több "hasonló" MYSQL adatbázisból, tud keresni(lekérdezni egyszerre).
Vufind, elasticsearch irányába indultunk.
Van két MySql táblám (A,B), amiknek teljesen azonos a szerkezete, de az adataik nem.
Szeretném felcserélni ezt a két táblát úgy, hogy közben egyetlen lekérés se futhasson hibára. (Vagy még a régi, vagy már az új adatokkal kerüljön kiszolgálásra.)Megbízhatóan elég erre a következő parancs?
RENAME TABLE `A` TO `tmp`, `B` TO `A`, `tmp` TO `B`;
Vagy csak tranzakciókezeléssel megfelelő?
START TRANSACTION;
RENAME TABLE `A` TO `tmp`, `B` TO `A`, `tmp` TO `B`;
COMMIT;
Vagy ez sem 100%-os, és van rá valamilyen más, jobb megoldás?
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 EBEgy 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)
2. stage (virtuális gép, KVM)