[TYPO3-UG Dutch] TYPO3 zonder innodb ?
Jordan van Bergen
jordanvanbergen at gmail.com
Tue Dec 20 15:20:52 CET 2011
Ik doe het in het vervolg in ieder geval zo:
1. Op de backup server de database terugzetten
2. Dan alle innodb tabellen droppen en opnieuw aanmaken
3. Dan een nieuwe mysqldump op de backupserver maken
4. Deze naar de productie server overhalen en restoren
Dat scheelt me hoop ik bij een volgende calamiteit veel tijd en daar
is het mij net om te doen ;-)
Ad 2. Ik doe het zo (dit wel voor iedere versie op juistheid
controleren en anders een juiste versie maken):
/* Opschonen innodb tabellen door ze te verwijderen en opnieuw aan te
maken voor v4.5.6 */
/* Table structure for table `cache_hash` */
DROP TABLE IF EXISTS `cache_hash`;
CREATE TABLE `cache_hash` (
`id` INT(11) UNSIGNED NOT NULL AUTO_INCREMENT,
`hash` VARCHAR(32) NOT NULL DEFAULT '',
`content` MEDIUMBLOB,
`tstamp` INT(11) UNSIGNED NOT NULL DEFAULT '0',
`ident` VARCHAR(32) NOT NULL DEFAULT '',
PRIMARY KEY (`id`),
KEY `hash` (`hash`)
) ENGINE=INNODB AUTO_INCREMENT=2154 DEFAULT CHARSET=utf8;
/*Table structure for table `cache_imagesizes` */
DROP TABLE IF EXISTS `cache_imagesizes`;
CREATE TABLE `cache_imagesizes` (
`md5hash` VARCHAR(32) NOT NULL DEFAULT '',
`md5filename` VARCHAR(32) NOT NULL DEFAULT '',
`tstamp` INT(11) NOT NULL DEFAULT '0',
`filename` VARCHAR(255) NOT NULL DEFAULT '',
`imagewidth` MEDIUMINT(11) UNSIGNED NOT NULL DEFAULT '0',
`imageheight` MEDIUMINT(11) UNSIGNED NOT NULL DEFAULT '0',
PRIMARY KEY (`md5filename`)
) ENGINE=INNODB DEFAULT CHARSET=utf8;
/*Table structure for table `cache_md5params` */
DROP TABLE IF EXISTS `cache_md5params`;
CREATE TABLE `cache_md5params` (
`md5hash` VARCHAR(20) NOT NULL DEFAULT '',
`tstamp` INT(11) NOT NULL DEFAULT '0',
`type` TINYINT(3) NOT NULL DEFAULT '0',
`params` TEXT,
PRIMARY KEY (`md5hash`)
) ENGINE=INNODB DEFAULT CHARSET=utf8;
/*Table structure for table `cache_pages` */
DROP TABLE IF EXISTS `cache_pages`;
CREATE TABLE `cache_pages` (
`id` INT(11) UNSIGNED NOT NULL AUTO_INCREMENT,
`hash` VARCHAR(32) NOT NULL DEFAULT '',
`page_id` INT(11) UNSIGNED NOT NULL DEFAULT '0',
`reg1` INT(11) UNSIGNED NOT NULL DEFAULT '0',
`HTML` MEDIUMBLOB,
`temp_content` INT(1) NOT NULL DEFAULT '0',
`tstamp` INT(11) UNSIGNED NOT NULL DEFAULT '0',
`expires` INT(10) UNSIGNED NOT NULL DEFAULT '0',
`cache_data` MEDIUMBLOB,
PRIMARY KEY (`id`),
KEY `page_id` (`page_id`),
KEY `sel` (`hash`,`page_id`)
) ENGINE=INNODB AUTO_INCREMENT=160 DEFAULT CHARSET=utf8;
/*Table structure for table `cache_pagesection` */
DROP TABLE IF EXISTS `cache_pagesection`;
CREATE TABLE `cache_pagesection` (
`page_id` INT(11) UNSIGNED NOT NULL DEFAULT '0',
`mpvar_hash` INT(11) UNSIGNED NOT NULL DEFAULT '0',
`content` BLOB,
`tstamp` INT(11) UNSIGNED NOT NULL DEFAULT '0',
PRIMARY KEY (`page_id`,`mpvar_hash`)
) ENGINE=INNODB DEFAULT CHARSET=utf8;
/*Table structure for table `cache_treelist` */
DROP TABLE IF EXISTS `cache_treelist`;
CREATE TABLE `cache_treelist` (
`md5hash` CHAR(32) NOT NULL DEFAULT '',
`pid` INT(11) NOT NULL DEFAULT '0',
`treelist` TEXT,
`tstamp` INT(11) NOT NULL DEFAULT '0',
`expires` INT(11) UNSIGNED NOT NULL DEFAULT '0',
PRIMARY KEY (`md5hash`)
) ENGINE=INNODB DEFAULT CHARSET=utf8;
/*Table structure for table `cache_typo3temp_log` */
DROP TABLE IF EXISTS `cache_typo3temp_log`;
CREATE TABLE `cache_typo3temp_log` (
`md5hash` VARCHAR(32) NOT NULL DEFAULT '',
`tstamp` INT(11) NOT NULL DEFAULT '0',
`filename` VARCHAR(255) NOT NULL DEFAULT '',
`orig_filename` VARCHAR(255) NOT NULL DEFAULT '',
PRIMARY KEY (`md5hash`)
) ENGINE=INNODB DEFAULT CHARSET=utf8;
/*Table structure for table `cachingframework_cache_hash` */
DROP TABLE IF EXISTS `cachingframework_cache_hash`;
CREATE TABLE `cachingframework_cache_hash` (
`id` INT(11) UNSIGNED NOT NULL AUTO_INCREMENT,
`identifier` VARCHAR(128) NOT NULL DEFAULT '',
`crdate` INT(11) UNSIGNED NOT NULL DEFAULT '0',
`content` MEDIUMBLOB,
`lifetime` INT(11) UNSIGNED NOT NULL DEFAULT '0',
PRIMARY KEY (`id`),
KEY `cache_id` (`identifier`)
) ENGINE=INNODB DEFAULT CHARSET=utf8;
/*Table structure for table `cachingframework_cache_hash_tags` */
DROP TABLE IF EXISTS `cachingframework_cache_hash_tags`;
CREATE TABLE `cachingframework_cache_hash_tags` (
`id` INT(11) UNSIGNED NOT NULL AUTO_INCREMENT,
`identifier` VARCHAR(128) NOT NULL DEFAULT '',
`tag` VARCHAR(128) NOT NULL DEFAULT '',
PRIMARY KEY (`id`),
KEY `cache_id` (`identifier`),
KEY `cache_tag` (`tag`)
) ENGINE=INNODB DEFAULT CHARSET=utf8;
/*Table structure for table `cachingframework_cache_pages` */
DROP TABLE IF EXISTS `cachingframework_cache_pages`;
CREATE TABLE `cachingframework_cache_pages` (
`id` INT(11) UNSIGNED NOT NULL AUTO_INCREMENT,
`identifier` VARCHAR(128) NOT NULL DEFAULT '',
`crdate` INT(11) UNSIGNED NOT NULL DEFAULT '0',
`content` MEDIUMBLOB,
`lifetime` INT(11) UNSIGNED NOT NULL DEFAULT '0',
PRIMARY KEY (`id`),
KEY `cache_id` (`identifier`)
) ENGINE=INNODB DEFAULT CHARSET=utf8;
/*Table structure for table `cachingframework_cache_pages_tags` */
DROP TABLE IF EXISTS `cachingframework_cache_pages_tags`;
CREATE TABLE `cachingframework_cache_pages_tags` (
`id` INT(11) UNSIGNED NOT NULL AUTO_INCREMENT,
`identifier` VARCHAR(128) NOT NULL DEFAULT '',
`tag` VARCHAR(128) NOT NULL DEFAULT '',
PRIMARY KEY (`id`),
KEY `cache_id` (`identifier`),
KEY `cache_tag` (`tag`)
) ENGINE=INNODB DEFAULT CHARSET=utf8;
/*Table structure for table `cachingframework_cache_pagesection` */
DROP TABLE IF EXISTS `cachingframework_cache_pagesection`;
CREATE TABLE `cachingframework_cache_pagesection` (
`id` INT(11) UNSIGNED NOT NULL AUTO_INCREMENT,
`identifier` VARCHAR(128) NOT NULL DEFAULT '',
`crdate` INT(11) UNSIGNED NOT NULL DEFAULT '0',
`content` MEDIUMBLOB,
`lifetime` INT(11) UNSIGNED NOT NULL DEFAULT '0',
PRIMARY KEY (`id`),
KEY `cache_id` (`identifier`)
) ENGINE=INNODB DEFAULT CHARSET=utf8;
/*Table structure for table `cachingframework_cache_pagesection_tags`
*/
DROP TABLE IF EXISTS `cachingframework_cache_pagesection_tags`;
CREATE TABLE `cachingframework_cache_pagesection_tags` (
`id` INT(11) UNSIGNED NOT NULL AUTO_INCREMENT,
`identifier` VARCHAR(128) NOT NULL DEFAULT '',
`tag` VARCHAR(128) NOT NULL DEFAULT '',
PRIMARY KEY (`id`),
KEY `cache_id` (`identifier`),
KEY `cache_tag` (`tag`)
) ENGINE=INNODB DEFAULT CHARSET=utf8;
/*Table structure for table `fe_session_data` */
DROP TABLE IF EXISTS `fe_session_data`;
CREATE TABLE `fe_session_data` (
`hash` VARCHAR(32) NOT NULL DEFAULT '',
`content` MEDIUMBLOB,
`tstamp` INT(11) UNSIGNED NOT NULL DEFAULT '0',
PRIMARY KEY (`hash`),
KEY `tstamp` (`tstamp`)
) ENGINE=INNODB DEFAULT CHARSET=utf8;
/*Table structure for table `fe_sessions` */
DROP TABLE IF EXISTS `fe_sessions`;
CREATE TABLE `fe_sessions` (
`ses_id` VARCHAR(32) NOT NULL DEFAULT '',
`ses_name` VARCHAR(32) NOT NULL DEFAULT '',
`ses_iplock` VARCHAR(39) NOT NULL DEFAULT '',
`ses_hashlock` INT(11) NOT NULL DEFAULT '0',
`ses_userid` INT(11) UNSIGNED NOT NULL DEFAULT '0',
`ses_tstamp` INT(11) UNSIGNED NOT NULL DEFAULT '0',
`ses_data` BLOB,
`ses_permanent` TINYINT(1) UNSIGNED NOT NULL DEFAULT '0',
PRIMARY KEY (`ses_id`,`ses_name`)
) ENGINE=INNODB DEFAULT CHARSET=utf8;
/*Table structure for table `sys_history` */
DROP TABLE IF EXISTS `sys_history`;
CREATE TABLE `sys_history` (
`uid` INT(11) UNSIGNED NOT NULL AUTO_INCREMENT,
`sys_log_uid` INT(11) NOT NULL DEFAULT '0',
`history_data` MEDIUMTEXT,
`fieldlist` TEXT,
`recuid` INT(11) NOT NULL DEFAULT '0',
`tablename` VARCHAR(255) NOT NULL DEFAULT '',
`tstamp` INT(11) NOT NULL DEFAULT '0',
`history_files` MEDIUMTEXT,
`snapshot` TINYINT(4) NOT NULL DEFAULT '0',
PRIMARY KEY (`uid`),
KEY `recordident_1` (`tablename`,`recuid`),
KEY `recordident_2` (`tablename`,`tstamp`),
KEY `sys_log_uid` (`sys_log_uid`)
) ENGINE=INNODB AUTO_INCREMENT=317 DEFAULT CHARSET=utf8;
/*Table structure for table `sys_log` */
DROP TABLE IF EXISTS `sys_log`;
CREATE TABLE `sys_log` (
`uid` INT(11) UNSIGNED NOT NULL AUTO_INCREMENT,
`userid` INT(11) UNSIGNED NOT NULL DEFAULT '0',
`action` TINYINT(4) UNSIGNED NOT NULL DEFAULT '0',
`recuid` INT(11) UNSIGNED NOT NULL DEFAULT '0',
`tablename` VARCHAR(255) NOT NULL DEFAULT '',
`recpid` INT(11) NOT NULL DEFAULT '0',
`error` TINYINT(4) UNSIGNED NOT NULL DEFAULT '0',
`details` TEXT NOT NULL,
`tstamp` INT(11) UNSIGNED NOT NULL DEFAULT '0',
`type` TINYINT(3) UNSIGNED NOT NULL DEFAULT '0',
`details_nr` TINYINT(3) UNSIGNED NOT NULL DEFAULT '0',
`IP` VARCHAR(39) NOT NULL DEFAULT '',
`log_data` VARCHAR(255) NOT NULL DEFAULT '',
`event_pid` INT(11) NOT NULL DEFAULT '-1',
`workspace` INT(11) NOT NULL DEFAULT '0',
`NEWid` VARCHAR(20) NOT NULL DEFAULT '',
PRIMARY KEY (`uid`),
KEY `event` (`userid`,`event_pid`),
KEY `recuidIdx` (`recuid`,`uid`)
) ENGINE=INNODB AUTO_INCREMENT=4705 DEFAULT CHARSET=utf8;
/*Table structure for table `tt_news_cache` */
DROP TABLE IF EXISTS `tt_news_cache`;
CREATE TABLE `tt_news_cache` (
`id` INT(11) UNSIGNED NOT NULL AUTO_INCREMENT,
`identifier` VARCHAR(32) NOT NULL DEFAULT '',
`content` TEXT NOT NULL,
`crdate` INT(11) NOT NULL DEFAULT '0',
`lifetime` INT(11) NOT NULL DEFAULT '0',
PRIMARY KEY (`id`),
KEY `cache_id` (`identifier`)
) ENGINE=INNODB DEFAULT CHARSET=utf8;
/*Table structure for table `tt_news_cache_tags` */
DROP TABLE IF EXISTS `tt_news_cache_tags`;
CREATE TABLE `tt_news_cache_tags` (
`id` INT(11) UNSIGNED NOT NULL AUTO_INCREMENT,
`identifier` VARCHAR(128) NOT NULL DEFAULT '',
`tag` VARCHAR(128) NOT NULL DEFAULT '',
PRIMARY KEY (`id`),
KEY `cache_id` (`identifier`),
KEY `cache_tag` (`tag`)
) ENGINE=INNODB DEFAULT CHARSET=utf8;
/*Table structure for table `tx_realurl_chashcache` */
DROP TABLE IF EXISTS `tx_realurl_chashcache`;
CREATE TABLE `tx_realurl_chashcache` (
`spurl_hash` CHAR(32) NOT NULL DEFAULT '',
`chash_string` VARCHAR(32) NOT NULL DEFAULT '',
`spurl_string` TEXT,
PRIMARY KEY (`spurl_hash`),
KEY `chash_string` (`chash_string`)
) ENGINE=INNODB DEFAULT CHARSET=utf8;
/*Table structure for table `tx_realurl_pathcache` */
DROP TABLE IF EXISTS `tx_realurl_pathcache`;
CREATE TABLE `tx_realurl_pathcache` (
`cache_id` INT(11) NOT NULL AUTO_INCREMENT,
`page_id` INT(11) NOT NULL DEFAULT '0',
`language_id` INT(11) NOT NULL DEFAULT '0',
`rootpage_id` INT(11) NOT NULL DEFAULT '0',
`mpvar` TINYTEXT NOT NULL,
`pagepath` TEXT NOT NULL,
`expire` INT(11) NOT NULL DEFAULT '0',
PRIMARY KEY (`cache_id`),
KEY `pathq1` (`rootpage_id`,`pagepath`(32),`expire`),
KEY `pathq2` (`page_id`,`language_id`,`rootpage_id`,`expire`),
KEY `expire` (`expire`)
) ENGINE=INNODB AUTO_INCREMENT=534 DEFAULT CHARSET=utf8;
/*Table structure for table `tx_realurl_urldecodecache` */
DROP TABLE IF EXISTS `tx_realurl_urldecodecache`;
CREATE TABLE `tx_realurl_urldecodecache` (
`url_hash` CHAR(32) NOT NULL DEFAULT '',
`spurl` TINYTEXT NOT NULL,
`content` BLOB NOT NULL,
`page_id` INT(11) NOT NULL DEFAULT '0',
`rootpage_id` INT(11) NOT NULL DEFAULT '0',
`tstamp` INT(11) NOT NULL DEFAULT '0',
PRIMARY KEY (`url_hash`),
KEY `page_id` (`page_id`)
) ENGINE=INNODB DEFAULT CHARSET=utf8;
/*Table structure for table `tx_realurl_urlencodecache` */
DROP TABLE IF EXISTS `tx_realurl_urlencodecache`;
CREATE TABLE `tx_realurl_urlencodecache` (
`url_hash` CHAR(32) NOT NULL DEFAULT '',
`origparams` TINYTEXT NOT NULL,
`internalExtras` TINYTEXT NOT NULL,
`content` TEXT NOT NULL,
`page_id` INT(11) NOT NULL DEFAULT '0',
`tstamp` INT(11) NOT NULL DEFAULT '0',
PRIMARY KEY (`url_hash`),
KEY `page_id` (`page_id`)
) ENGINE=INNODB DEFAULT CHARSET=utf8;
Eens kijken of ik dit onthoud voor een volgende calamiteit en of het
me dan inderdaad veel tijd gaat schelen ;-)
Met vriendelijke groeten,
Jordan van Bergen
On Tue, 20 Dec 2011 15:05:41 +0100, Jordan van Bergen
<jordanvanbergen at gmail.com> wrote:
>Hoi Bas,
>
>Ik heb niet echt weinig diskruimte. 60+% over maar ik ben meer iemand
>die een snelle restore wil kunnen uithalen. Ik heb veel liever bij
>calamiteiten een restore procedure die je binnen 30 minuten weer 100%
>online hebt met je websites dan een vette performance omdat het hier
>toch maar kleine websites betreft met bladiebla informatie.
>
>Doordat je al snel 10 GB aan HD ruimte voor het innodb verhaal
>hebt/krijgt geldt:
>
>1. dataverkeer neemt toe wat je uiteindelijk geld kan kosten
>2. vanaf een backupserver de boel weer over plaatsen naar de ter
>herbouwen live server kost je door de vele GB's meer tijd dan wanneer
>je alleen MyISAM tabellen zou hebben. Gelukkig gaan mijn servers niet
>vak plat maar ik merk dat in de tijd van alleen MyISAM ik echt binnen
>30 min. een server terug online had en nu met de hoeveelheid data in
>innodb tabellen dit vele malen langer duurt. Pomp eerst maar eens 10+
>GB naar een andere server voordat je het uberhaupt kunt restoren.
>3. wat andere minder belangrijke zaken.
>
>Dus performance is leuk maar een snelle calamiteiten oplossing is
>volgens mij veel belangrijker. Liever 1 uur offline door een server
>fout dan 5 uur offline. Het is me nu in 2 jaar tijd 4x over komen of
>zo en dat zullen meer en meer mensen gaan ervaren als ze met een
>virtuele VPS omgeving zullen gaan werken verwacht ik. Die zijn net
>iets minder betrouwbaar dan fysieke schijven ;-) LOL. Als je dan tegen
>zo'n calamiteit oploopt zie je opeens het voordeel van een 100 MB
>backup in plaats van een 10 GB backup voor dezelfde website ;-)
>
>Ze vinden mij wel vaker een rare maar ik kijk vaak anders tegen zaken
>aan ;-) In een kleine organisatie moet je anders te werk gaan dan in
>een grote organisatie en dan komt alles op snelheid en flexibiliteit
>neer. Ik wil geen dag bezig zijn met herstellen van een simpele
>website ;-) LOL. Zo kent iedereen de beweegredenen van mij waarom ik
>in geval van calamiteiten niet echt happy ben met de innodb oplossing
>die voor het overige natuurlijk een prima oplossing is als het
>allemaal 100% draait en blijft draaien. Vooral dat blijven kun je
>blijkbaar nooit op vertrouwen. Dat is mij vandaag ook weer eens
>duidelijk geworden ondanks dat ik het binnen 3 uur weer up-and-running
>had.
>
>Met vriendelijke groeten,
>Jordan van Bergen
>
>On Tue, 20 Dec 2011 14:48:55 +0100, "Bas v.d. Wiel"
><bas at kompasmedia.nl> wrote:
>
>>Hoi Jordan,
>>Dat loopt inderdaad in de gigabytes, maar dat gegeven beschouw ik niet
>>als het probleem hier. MySQL heeft die ruimte stomweg nodig en claimt
>>die daarom zonder deze ooit weer vrij te geven aan het OS. Truncate je
>>echter tabellen, dan wordt intern binnen die InnoDB-files wel degelijk
>>ruimte hergebruikt voordat er verdere groei van het bestand plaatsvindt.
>>Door bestanden te laten krimpen en weer groeien, werk je
>>schijffragmentatie in de hand. Het is een ontwerpbeslissing achter
>>InnoDB om dat nadrukkelijk niet te doen omwille van performance. Een
>>keuze waar ik het overigens zeer mee eens ben zolang je datadir niet op
>>SSD staat. Door zelf alsnog met het handmatig droppen en opnieuw
>>aanmaken deze fragmentatie aan te brengen, ben je m.i. niet verstandig
>>bezig. Mijn voorzichtige conclusie: je hebt blijkbaar te weinig disk
>>voor de omvang van de sites die je draait.
>>
>>Groeten,
>>Bas
>>
>>On 12/20/2011 02:32 PM, Jordan van Bergen wrote:
>>> Hoi Bas,
>>>
>>> Dank voor je tips maar ik kan wel over dit zeggen:
>>>
>>>> Vlak voordat je gaat backuppen de cache- en andere tijdelijke tabellen
>>>> legen (TRUNCATE TABLE). Dat scheelt aanzienlijk.
>>> Dat scheelt dus helaas in HD ruimte helemaal niets omdat de .ibd
>>> bestanden van innodb NOOIT shrinken. Ze blijven altijd wat ze waren en
>>> zullen dus alleen maar groter worden indien noodzakelijk. Het enige
>>> wat je kunt doen is er voor te zorgen dat je innodb_pertable = 1 hebt
>>> (of zoiets) en dan een table DROPPEN en opnieuw aanmaken. Dan heb je
>>> HD ruimte gewonnen en heb je echt weer een lege cache of syslog tabel
>>> bijvoorbeeld. Voordat ik innodb_pertable = 1 had liep de overall
>>> innodb file wel op tot 10 GB voor een simpele website.
>>>
>>> Je opmerking dat de restore veel sneller zal gaan geldt wellicht wel
>>> ondanks de hoeveelheid HD ruimte. Dus dat is toch wel een slimme om
>>> door te voeren lijkt me. Eens kijken dat ik dit in ieder geval ga
>>> verwerken in onze shell scripts. En dan regel ik zelf wel 1x per
>>> kwartaal een drop table en het weer aanmaken om HD ruimte terug te
>>> winnen.
>>>
>>> Ik denk echter niet dat jij dus innodb_pertable = 1 aan hebt staan of
>>> wel? Hoe groot zijn jouw onderstaande bestanden?
>>>
>>> -rw-rw---- 1 mysql mysql 27262976 Dec 20 05:09 ibdata1
>>> -rw-rw---- 1 mysql mysql 5242880 Dec 20 09:08 ib_logfile0
>>> -rw-rw---- 1 mysql mysql 5242880 Dec 20 09:08 ib_logfile1
>>>
>>> bestanden? Zonder innodb_pertable liep dit bij mij op bij 3 TYPO3
>>> websites naar 10+ GB binnen een maandje of 2.
>>>
>>> Met vriendelijke groeten,
>>>
>>> Jordan van Bergen
>>>
>>>
>>> On Tue, 20 Dec 2011 13:50:50 +0100, "Bas v.d. Wiel"
>>> <bas at kompasmedia.nl> wrote:
>>>
>>>> Hoi Jordan,
>>>>
>>>> Vlak voordat je gaat backuppen de cache- en andere tijdelijke tabellen
>>>> legen (TRUNCATE TABLE). Dat scheelt aanzienlijk. Ik zou sys_log niet
>>>> helemaal leeggooien maar elke dag/week alles ouder dan plm 3 maanden
>>>> deleten is niet zo'n gek plan denk ik. Als je daarna de DB dumpt, bevat
>>>> 'ie voornamelijk je feitelijke data en hooguit een paar cache-records
>>>> van de pagina's die tussen het truncaten en dumpen zijn bezocht. Gaat
>>>> veel sneller in de restore.
>>>>
>>>> Zonder deze voorzorg duurde het restoren van een grote website bij mij
>>>> ruim een uur. Daarna nog slechts een kwartiertje.
>>>>
>>>> Groeten,
>>>> Bas
>>>>
>>>> On 12/20/2011 12:52 PM, Jordan van Bergen wrote:
>>>>> Hoi Jigal,
>>>>>
>>>>> Dank voor je reactie. Een paar reacties:
>>>>>
>>>>>> Je zou tijd kunnen investeren in het juist leren inrichten van een MySQL
>>>>>> omgeving met InnoDB (boeken als High Performance MySQL geven veel
>>>>>> informatie; dan leer je ook om InnoDB file per table in te stellen,
>>>>>> etc.)
>>>>> Dat gebruik ik al. innodb_pertable = 1 of zoiets. Dat is al erg handig
>>>>> maar ook ONHANDIG blijkt nu. Want er hoeft maar 1 tabel corrupt te
>>>>> zijn met zo'n .ibd bestand en mysql start niet meer. Ik had zojuist
>>>>> binnen de MySQL omgeving alleen bij TYPO3 problemen met
>>>>> cache/syslog/etc. waarbij innodb was gebruikt. Dus iets van 3 database
>>>>> x 12 innodb corrupte bestanden waardoor MySQL gewoonweg niet meer
>>>>> wilde starten.
>>>>>
>>>>>> en het juist inrichten van je database backups (zonder log, cache,
>>>>>> temp, etc. tabellen).
>>>>> Dat is wel een interessante. Heb je een suggestie hoe dit te doen? Ik
>>>>> doe een mysqldump per database en dus niets per tabel. Wellicht
>>>>> interessant om te weten hoe je een backup per tabel doet en als je
>>>>> zo'n tabel met innodb overslaat moet het na een restore toch wel weer
>>>>> aangemaakt worden?
>>>>>
>>>>>> Alternatief is om een Oracle consultant in te huren om de boel in te
>>>>>> richten en een fatsoenlijke backup/restore strategie op te zetten. Kost
>>>>>> je eenmalig geld, maar je hoeft er geen tijd in te steken.
>>>>> Hihi. Bij een stichting een Oracle consultant inhuren ;-) LOL. Daar is
>>>>> geen geld voor ;-) De tijd is het probleem niet om het zelf terug te
>>>>> zetten maar eerder de tijd wat het kost om zo'n hele database met GB's
>>>>> terug te zetten. Dus hoe de backup te maken en te restoren lukt me wel
>>>>> maar meer het gigantische aantal GB's is het probleem terwijl het een
>>>>> website van niets is. Zonder die innodb tabellen is het in 10 sec.
>>>>> teruggezet. Met de innodb tabellen> 2 uur.
>>>>>
>>>>> Met vriendelijke groeten,
>>>>> Jordan van Bergen
>>>>>
>>>>>
>>>>> On Tue, 20 Dec 2011 12:43:45 +0100, Jigal van Hemert<jigal at xs4all.nl>
>>>>> wrote:
>>>>>
>>>>>> Hoi,
>>>>>>
>>>>>> On 20-12-2011 12:32, Jordan van Bergen 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.
>>>>>> (...)
>>>>>>> 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?
>>>>>> Het kan "werken" zolang performance niet interessant is (de table locks
>>>>>> vliegen je om de oren).
>>>>>>
>>>>>> Je zou tijd kunnen investeren in het juist leren inrichten van een MySQL
>>>>>> omgeving met InnoDB (boeken als High Performance MySQL geven veel
>>>>>> informatie; dan leer je ook om InnoDB file per table in te stellen,
>>>>>> etc.) en het juist inrichten van je database backups (zonder log, cache,
>>>>>> temp, etc. tabellen).
>>>>>>
>>>>>> Alternatief is om een Oracle consultant in te huren om de boel in te
>>>>>> richten en een fatsoenlijke backup/restore strategie op te zetten. Kost
>>>>>> je eenmalig geld, maar je hoeft er geen tijd in te steken.
>>>>> _______________________________________________
>>>>> TYPO3-UG-Dutch mailing list
>>>>> TYPO3-UG-Dutch at lists.typo3.org
>>>>> http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-ug-dutch
>>> _______________________________________________
>>> TYPO3-UG-Dutch mailing list
>>> TYPO3-UG-Dutch at lists.typo3.org
>>> http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-ug-dutch
More information about the TYPO3-UG-Dutch
mailing list