[TYPO3-UG Dutch] TYPO3 zonder innodb ?

Jordan van Bergen jordanvanbergen at gmail.com
Tue Dec 20 14:35:22 CET 2011


Om iedereen alle ins- en outs te geven wat er bij mijn innodb verhaal
gebeurde na een fysieke foute stroom er uit en er op actie:

Dec 20 09:08:00 ns1 mysqld_safe: Starting mysqld daemon with databases
from /var/lib/mysql
Dec 20 09:08:00 ns1 mysqld: 111220  9:08:00 [Note] Plugin 'FEDERATED'
is disabled.
Dec 20 09:08:00 ns1 mysqld: InnoDB: Log scan progressed past the
checkpoint lsn 4 3006980536
Dec 20 09:08:00 ns1 mysqld: 111220  9:08:00  InnoDB: Database was not
shut down normally!
Dec 20 09:08:00 ns1 mysqld: InnoDB: Starting crash recovery.
Dec 20 09:08:00 ns1 mysqld: InnoDB: Reading tablespace information
from the .ibd files...
Dec 20 09:08:00 ns1 mysqld: InnoDB: Restoring possible half-written
data pages from the doublewrite
Dec 20 09:08:00 ns1 mysqld: InnoDB: buffer...
Dec 20 09:08:00 ns1 mysqld: InnoDB: Doing recovery: scanned up to log
sequence number 4 3006981206
Dec 20 09:08:01 ns1 mysqld: 111220  9:08:01  InnoDB: Starting an apply
batch of log records to the database...
Dec 20 09:08:01 ns1 mysqld: InnoDB: Progress in percents: 15 16 17 18
19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41
42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61
62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84
85 86 87 88 89 90 91 92 93 94 95 96 97 98 99
Dec 20 09:08:01 ns1 mysqld: InnoDB: Apply batch completed
Dec 20 09:08:01 ns1 mysqld: 111220  9:08:01  InnoDB: Error: the OS
said file flush did not succeed
Dec 20 09:08:01 ns1 mysqld: 111220  9:08:01  InnoDB: Operating system
error number 5 in a file operation.
Dec 20 09:08:01 ns1 mysqld: InnoDB: Error number 5 means 'Input/output
error'.
Dec 20 09:08:01 ns1 mysqld: InnoDB: Some operating system error
numbers are described at
Dec 20 09:08:01 ns1 mysqld: InnoDB:
http://dev.mysql.com/doc/refman/5.1/en/operating-system-error-codes.html
Dec 20 09:08:01 ns1 mysqld: InnoDB: File operation call: 'flush'.
Dec 20 09:08:01 ns1 mysqld: InnoDB: Cannot continue operation.
Dec 20 09:08:01 ns1 mysqld_safe: mysqld from pid file
/var/run/mysqld/mysqld.pid ended

Dus het restoren van innodb ging blijkbaar niet goed op basis van
error number 5 i/o oftewel corrupte bestanden op het file systeem
verwacht ik. 

Iemand een idee wat dit betekent:

Restoring possible half-written data pages from the doublewrite

en of dit noodzakelijk is? 

Met vriendelijke groeten,
Jordan van Bergen


On Tue, 20 Dec 2011 12:32:18 +0100, Jordan van Bergen
<jordanvanbergen at gmail.com> wrote:

>Ik snap de voordelen van innodb en begrijp dus waarom het TYPO3 CMS
>dit toegevoegd heeft gekregen. Maar er zitten ook zeer irritante
>nadelen aan innodb. Dit heeft alles met systeembeheer te maken. 
>
>Het gebeurt gelukkig niet vaak maar bij een systeem crash waarbij iets
>wordt uitgezet terwijl de machine draait kunnen mysql databases dus
>corrupt raken. Als je dan innodb hebt geldt dat je met je handen in
>het haar zit om het te herstellen omdat die TYPO3 tabellen enorm
>kunnen ontploffen door het gebruik van innodb. Zo ben ik nu bezig met
>een sys_log aan het terugzetten van meer dan 1,5 GB. Dat gaat tergend
>langzaam. 
>
>Leuk dat innodb verhaal maar vanuit systeembeheer oogpunt een drama
>bij calamiteiten. Normaal heb je buiten veel HD vreetruimte er geen
>last van maar als je iets moet restoren bij calamiteiten dan is het
>opeens niet zo fijn meer. 
>
>Zo kon ik niet eens even dit doen: 
>DROP TABLE IF EXISTS `sys_log`;
>omdat het systeem aangaf dat deze database tabel niet bestond maar
>CREATE TABLE `sys_log`
>kon ook niet omdat er al zo'n database tabel was. Je ziet dat een
>corrupt innodb mysql verhaal je helemaal gek maakt. Het is me zojuist
>gelukt om vanuit een backup alles binnen 2,5 uur weer online te
>krijgen maar ik heb daarbij wel rare fratsen moeten uithalen.
>
>Ik heb dit geprobeerd:
>
>1. via de MySQL mogelijkheden de tabellen geprobeerd te repairen
>uitkomst: mislukt
>2. dan de corrupte tabellen maar verwijderen
>uitkomt: drop table van de corrupte tabellen onmogelijk
>3. dan maar mysql stoppen en daarna de corrupte databases verwijderen
>uitkomt: dat mag
>4. mysql starten, de desbetreffende database aanmaken
>uitkomst: lege database en dus geen werkende website
>5. restore van de backup mysqldumps van een dag er voor
>uitkomst: alles weer online na meer dan 2,5 uur wachten door de enorm
>grote cache/syslog/realurl innodb tabellen. 
>
>Iemand een idee hoe en of je TYPO3 nog steeds probleemloos (laatste
>versies van TYPO3) zonder innodb kunt laten draaien of dat innodb echt
>een vereiste is om het goed te laten functioneren? 
>
>Met vriendelijke groeten,
>
>Jordan van Bergen


More information about the TYPO3-UG-Dutch mailing list