Adatbázis: SQL, XML DB

Sziasztok!

Hozzám került egy MySQL adatbázis amit rendbe kéne raknom. Nem dump, hanem a /var/lib/mysql-ből egy teljes könyvtár. Próbáltam megetetni egy MySQL 5.5-el, de nem működik. Az adatbázist látszólag megtalálja, de a neve elé tesz egy #mysql50# prefixet. Ez állítólag azt jelenti, hogy ez egy 5.0-ás adatbázis.
Összeolvastam mindenfélét. Úgy tűnik, hogy előbb 5.1-re kell alakítani, majd mehet 5.5-re.
Vagyis fel kéne tennem pl. virtualboxba valami régebbi Linuxot 5.0-ás MySQL-el, aztán upgradelni 5.1-re.

A kérdés az, hogy miként tudom ezt megtenni a lehető legkevesebb macerával? Elsőre Fedora 17-18 környékét nézegettem, de mysql-server-ből nem találok 5.0-ás csomagot.

Vagy ha van más megoldás az is érdekel.

Kösz:
-----
miles

Hello mindenki,

a segítségeteket szeretném kérni a következő megoldására: különböző felhasználók rendelkezésre állásának az időtábláját kellene eltárolnom MySQL-ben. Az a helyzet, hogy 63 darab igen / nem mező van, amin nem tudok egyszerűsíteni. A felületen ixelhetőek a külöböző időablakok egy táblázat formájában. A tábla felső fejlécében a Hétfő, Kedd, Szerda, Csütörtök, Péntek, Szombat és Vasárnap oszlopnevek szerepelnek, a táblázat bal leírásában pedig 06-08, 08-10 .. 20-22, 22-24 óráig a mezők. Ez 7×9 = 63 pipálható mezőt jelent (24 órától hajnal 06-ig nincs bejelölhető ablak). Ennek az esetnek a tárolását kellene megoldanom adatbázisban.

Eddig egy ötlet merült fel, mégpedig, hogy létrehozok minden naphoz egy táblát, amelyekben lesz 10 darab oszlop: userID, elsoAblak, masodikAblak .. kilencedikAblak. Azt gondolom, hogy ennél azért van szofisztikáltabb megoldás is, de én még nem jöttem rá.

Segítségeteket előre is köszönöm!

Sziasztok,

Adott egy mysql szerver, verzioja 5.1.37. A szerveren van kb. 1300 adatbázis, az összes adatbázisban pedig 1.400.000 tábla.
A szerver hirtelen lelassult, így egy tuningot szeretnék csinálni rajta, de sajnos nem tudom futnak le a mysqltuner és a tuning-primer.sh tool-ok sem, egyszerűen kifagynak. A szerveren vannak MyIsam es InnoDB táblák is. A szerver konfigurációja 4CPU, 4GB RAM. Van valakinek ötlete, hogy mit csináljak? Köszönöm előre is.

Itt a config amit használok:
[mysqld]
#GENERAL
user = mysql
default-storage-engine = InnoDB
pid-file = /var/run/mysqld/mysqld.pid
socket = /var/run/mysqld/mysqld.sock

#DATA STORAGE
port = 3306
basedir = /usr
datadir = /var/lib/mysql
tmpdir = /tmp

#MyISAM
key_buffer = 500M
myisam-recover = FORCE,BACKUP

#SAFETY
max_allowed_packet = 16M
max-connect-errors = 1000000

# BINARY LOGGING #
log-bin = /var/lib/mysql/mysql-bin
expire-logs-days = 14
sync-binlog = 1

# CACHES AND LIMITS #
tmp-table-size = 320M
max-heap-table-size = 320M
query-cache-type = 0
query-cache-size = 0
max-connections = 150
thread-cache-size = 50
open-files-limit = 65535
table-definition-cache = 4096
table-open-cache = 10240

# INNODB #
innodb-flush-method = O_DIRECT
innodb-log-files-in-group = 2
#innodb-log-file-size = 128M
innodb-flush-log-at-trx-commit = 1
innodb-file-per-table = 1
innodb-buffer-pool-size = 2G

# LOGGING #
log-error = /var/lib/mysql/mysql-error.log
log-queries-not-using-indexes = 0
slow-query-log = 1
slow-query-log-file = /var/log/mysql_slow
long-query-time =2

Adott a következő MySQL tábla az alábbi adatokkal: http://pastebin.com/V0bujAhD

Hogyan keressük meg azokat a sorokat, amelyek nem jó helyen vannak, ha az ID értékek szigorúan egymás után következnek úgy, hogy a hozzájuk rendelt dátum is egymás után kell következzen?

HINT:
A fenti példában a 343 és 352 nincsenek a helyükön, (2014-01-17 helyett 2014-01-16-on vannak), de előfordulhatnak egyéb anomáliák is.

Külső segédszkriptekkel meg tudom keresni, viszont van-e esetleg erre tiszta mysql megoldás?

Megoldás:

SELECT DISTINCT
t1.*
FROM
ttt t1 INNER JOIN ttt t2
ON t1.id>t2.id
WHERE
t1.datum<t2.datum

A Pastebines adatok sajnos nem frissek, abban nincs hiba. :)

Mivel eredendően síkhülye vagyok az sqlhez, de szükséges néha ezt-azt lekérni, segítséget szeretnék kérni. Van általam írt select, ami működik, visszadja a szükséges táblát. E táblában szeretném megszámoltatni, hogy az egyik sorban hányféle adat található. Gondolom a count(distinct adat) -t kellene használnom, de eddig nem sikerült belecsempésznem úgy, hogy szintaktikailag (is) jó legyen.

A select valami ilyesmi:

select u.mezo1, u.mezo2, s.mezo4, k.mezo2 from base1 u join base2 k on u.mezo1=k.mezo2 join base3 s on s.mezo3=k.mezo3 where "feltétel hegyek" :)

A mezo1-t szeretném megszámolni, hogy mennyi féle adat van benne. Szóval valami olyasmi kellene (totál hibás sql szintaxissal), hogy

select count(distinct mezo1) from a fenti select által visszaadott eredmény. Össze kellene fűzni a selecteket valahogyan. Próbálkoztam a select .... in -formával, de ott is elrontok valamit.

Előre is köszi.

Szisztok!

Egy kis segítséget szeretnék. Win server alól Ubuntu alá vinném át az adatbázist restore/backup megvolt.
/data könyvtárban a fájl létrehozva, rwx jogok beállítva, tulaj/csoport firebird/firebird. Win7 alól mégsem látja.
Már egy hete szenvedek, de semmi.Tudna valaki segíteni?

Előre is köszönöm!

Szeretnénk egy mysql klaszter elé proxyt tenni, mik a tapasztalatok? Használ valaki Amoeba-t? Read és Write szeparálásra (is) kellene...

Üdv,

Történt, hogy töröltem pár node-t Drupal 6-ban. Ezt szeretném visszaállitani, van is db mentésem, csak azt nem tudom, hogy pontosan mit is kellene visszaállitanom.

Az egész DB-t nyilván nem fogom felülcsapni, mert van már bent új adat.

Amit tudok a törölt adatokról:
A "uid", amin közzé lettek téve.

Hol tudnám ezt kulturáltan megoldani, hogy a node és a hozzá való commentek is visszakerüljenek a helyükre?

Egy 3 -szintu hash-elt (xx/xx/xx) konyvtarban van tobb millio par kB ... MB meretu file. Mivel ennek a mentese nem egyszeru (a file-ok sokasaga miatt), arra gondoltam, hogy jobb lenne / lehetne, ha ez a csomo file valamilyen joval kevesebb szamu (pl. 256 db) binaris file-ban lenne (pl. zip, tar, etc).

Persze nem eleg csak siman egy tar file-ba tenni a sok file-t, olyan szerkezet kell, amibol gyorsan elo tudom venni / kiolvasni a keresett file-t, ill. azt is meg kell oldani, hogy tobb processz is irhassa ezeket a file-okat, ill. torolni is tudni kell a belehelyezett file-okat.

Mit javasoltok erre a celra? Lattam egy megoldast, ami 4096 zip file-t nyit meg, es abba pakolja a file-okat, de hatha van ennel elegansabb es hatekonyabb megoldas.

hali,

épp egy tárolási problémával küszködök, és kéne némi tapasztalati vélemény.

az van, hogy van 50E+ user, nekik pedig vannak kapcsolataik egymással -- kivel leveleztek, ki nézett meg kit, ki kedvel kicsodát, stb. ez kb. 3-4M kapcsolati rekord.

mivel igen aggresszíven cache-elek (hogy ne kelljen átnézni állandóan ezeket a kapcsolati rekordokat), így az van, hogy tároláskor és cache-újraépítéskor kell csak a backendhez nyúlnom, ami jelenleg megosztva file (userenként 4 file) és mysql tábla (kapcsolatonként (típusok szerint is) 1 rekord).

mivel nemrég clusteresedtünk, ezért a file backend nfs-re került, de az nagyon omladozik a terhelés alatt (mivel leginkább írási műveletek történnek), így átmenetileg visszakoznom kellett a terheléselosztásos php módszertől. innentől eléggé egyértelmű, hogy a file backendet meg kell szüntetnem, és át kell raknom valamilyen db alapra. a mongot gondoltam kipróbálni erre, főleg, mert memóriában tudja tárolni az igazán aktív rekordokat.

a nagy gondom az, hogy melyik tárolási forma lenne a célszerű.

ha user/kapcsolattípus alapján 1-1 rekordot tárolnék (mint a klasszikus sql alapon), akkor legalább 3-4 millió rekordról lenne szó, ahol minimum 3 indexet kéne fenntartanom (user1 id, user2 id, típus) a hatékony lekéréshez -- ez viszont a cache-elés miatt nem tűnik annyira fontosnak.

a másik variáció az, hogy userenként 1 rekordot tartok fent, amin belül mondjuk json-ba kódolva a jelenlegi fájlok (illetve sql-ben tárolt adatok) tartalma kerül. ez kb. 50E+ rekordot jelent. így csak egy indexet kellene fenntartanom, a user ID-t. így persze vesztem azt, hogy szabadon csináljak lekéréseket a db-ben, de mint az a fentiekből látható, ez most sem lenne megoldható, és nincs is rá szükség. viszont így egy-egy entry viszonylag nagyobb méretű lehet, és kell némi logikát alkalmaznom a betöltéskor/mentéskor, plusz saját logikával kell átnéznem és módosítanom a "file" tartalmát.

per pillanat hajlok az utóbbi felé, mert attól tartok, az előbbinél a rekordok száma miatt az indexek nagyon sok operatív memóriát falnának fel, és eléggé fontos lenne, hogy minél több minden férjen be a ramba.

ti melyiket választanátok?