XF 2.0 xf_css_cache database table corrupted after a L7 DDOS attack

Jean-Baptiste

Well-known member
Hello,

I have just received a L7 DDOS attack on my servers.
The attack have been filtered, but I can't start the MySQL server anymore due to the following error :

Code:
InnoDB: Error: the size of single-table tablespace file ./realityg_db/xf_css_cache.ibd
InnoDB: is only 0 8192, should be at least 65536!InnoDB: Restoring possible half-written data pages from the doublewrite
InnoDB: buffer...
InnoDB: Doing recovery: scanned up to log sequence number 1788798863614
180519 18:31:38  InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percents: 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
InnoDB: Apply batch completed
180519 18:31:38  InnoDB: Error: table 'realityg_db/xf_css_cache'
InnoDB: in InnoDB data dictionary has tablespace id 36290004,
InnoDB: but tablespace with that id or name does not exist. Have
InnoDB: you deleted or moved .ibd files?
InnoDB: This may also be a table created with CREATE TEMPORARY TABLE
InnoDB: whose .ibd and .frm files MySQL automatically removed, but the
InnoDB: table still exists in the InnoDB internal data dictionary.
InnoDB: Please refer to
InnoDB: http://dev.mysql.com/doc/refman/5.5/en/innodb-troubleshooting-datadict.html
InnoDB: for how to resolve the issue.

Any ideas on how to fix this ?

It's related to eh xf_css_cache table.

Best regards
 
@Fabien fyi, you should be able to-do a truncate table xf_css_cache as this is a drop & recreate.

Also, this implies your MySQL instance and webserver (likely apache in pre-fork mode) are on the same box. A fixed size php worker pool and a webserver which doesn't use fork is generally recommended to avoid this sort of data corruption due to an out-of-memory issue.
 
@Fabien fyi, you should be able to-do a truncate table xf_css_cache as this is a drop & recreate.

Also, this implies your MySQL instance and webserver (likely apache in pre-fork mode) are on the same box. A fixed size php worker pool and a webserver which doesn't use fork is generally recommended to avoid this sort of data corruption due to an out-of-memory issue.

Hello Xon,

Thanks for your reply.

What do you mean by fixed size php worker and a webserver which doesn't use fork ? Do you know how can I do that with LiteSpeed ?

Best regards
 
Top Bottom