[ Orome @ 11.12.2012. 10:56 ] @
ovako, probao sam ukucati u my.cnf fajl innodb_force_recovery = 4 ; innodb_force_recovery = 5 ; innodb_force_recovery = 6.

probao sam skinuti transaction_isolation = READ_UNCOMMITTED nece da upali. inace ukljucen log-bin=backuplog sam imao na verziji 5.0 ali kada ga ukljucim na 5.5 imam nepredvidjene greske zbog kojih sam morao da stavim navedeni transaction_isolation. pustio sam check disk posle kog se nadam da ce baza da se upali.

ima li ko kakvu ideju?
[ bogdan.kecman @ 11.12.2012. 16:32 ] @
pa bez da napises za koji klinac nece da se upali mozemo samo da gledamo u pasulj ... imas error fajl pa daj sta tamo pise
[ Orome @ 12.12.2012. 06:15 ] @
znaci, kako ja vidim linija greske je :

121211 16:01:39 InnoDB: Assertion failure in thread 1836 in file fsp0fsp.c line 3559
InnoDB: Failing assertion: xdes_get_bit(descr, XDES_FREE_BIT, header_page % FSP_EXTENT_SIZE, mtr) == FALSE

a evo i err fajla

121211 16:01:30 [Note] Plugin 'FEDERATED' is disabled.
121211 16:01:30 InnoDB: The InnoDB memory heap is disabled
121211 16:01:30 InnoDB: Mutexes and rw_locks use Windows interlocked functions
121211 16:01:30 InnoDB: Compressed tables use zlib 1.2.3
121211 16:01:30 InnoDB: Initializing buffer pool, size = 1.1G
121211 16:01:30 InnoDB: Completed initialization of buffer pool
121211 16:01:30 InnoDB: Log file .\ib_logfile0 did not exist: new to be created
InnoDB: Setting log file .\ib_logfile0 size to 250 MB
InnoDB: Database physically writes the file full: wait...
InnoDB: Progress in MB: 100 200
121211 16:01:34 InnoDB: Log file .\ib_logfile1 did not exist: new to be created
InnoDB: Setting log file .\ib_logfile1 size to 250 MB
InnoDB: Database physically writes the file full: wait...
InnoDB: Progress in MB: 100 200
121211 16:01:38 InnoDB: highest supported file format is Barracuda.
InnoDB: The user has set SRV_FORCE_NO_LOG_REDO on
InnoDB: Skipping log redo
121211 16:01:39 InnoDB: Assertion failure in thread 1836 in file fsp0fsp.c line 3559
InnoDB: Failing assertion: xdes_get_bit(descr, XDES_FREE_BIT, header_page % FSP_EXTENT_SIZE, mtr) == FALSE
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: http://dev.mysql.com/doc/refma...n/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
121211 16:01:39 - mysqld got exception 0xc0000005 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.
We will try our best to scrape up some info that will hopefully help diagnose
the problem, but since we have already crashed, something is definitely wrong
and this may fail.
[ Orome @ 12.12.2012. 08:41 ] @
koja firma u beogradu ima da radi izvlacenje podataka iz ibdate koja je corrupt. ima li to? znam da ima da izvlace sa diska podatke, a radi li ko ovo?
[ bogdan.kecman @ 12.12.2012. 11:15 ] @
jesi ti siguran da je ovo 5.5 (ovo mi lici na stari 5.6 bug sa blobovima, sad sam malo u frci ne mogu da pogledam).. generalno ako ti force recovery = 6 i dalje ne dize mysql jedino je bekap ili professional data retrieval. tj, iskopiras sve fajlove prvo negde, stavis najnoviji 5.5 ako to nije najnoviji, pa probas da pustis njega sa force da se digne, ako ni to ne uspe ..

za recovery date iz ibd fajlova jedini koji to trenutno usluzno rade su momci iz perkone, ima jos par koji kao to rade ali su nesigurni i bezobrazni, pera i ekipa su do jaja skroz rade to za ok kintu i u ok vreme... slobodno se pozovi na mene (nece ti ustedeti kintu ali mozda dobijes jos brze nego normalno)

http://www.percona.com/

javi mi se na pp ako hoces da ti prosledim direkt detalje kome da se javis da to zavrsis expeditivno



[ tarla @ 12.12.2012. 18:40 ] @
Ako nije tajna, šta se desilo sa bazom ?

Nestanak struje ?