c_parser shows tables, but no data is output to file

[George Francis]

I've issued the c_parser command:

"./c_parser -4f pages-ibdata1/FIL_PAGE_INDEX/0000000000000001.page -t dictionary/SYS_TABLES.sql > dumps/default/SYS_TABLES 2> dumps/default/SYS_TABLES.sql"

in the output I can see the tables I want to recover:

000000000500 810000012D0110 SYS_TABLES "bugs/attach\_data" 13 2 1 0 0 "" 0
000000186569 0C00000966103D SYS_TABLES "bugs/attachments" 322 11 1 0 0 "" 0
0000000009A6 6D00000965055B SYS_TABLES "bugs/audit\_log" 144 7 1 0 0 "" 0
000000000516 97000001700110 SYS_TABLES "bugs/bug\_group\_map" 15 2 1 0 0 "" 0
0000000009B2 75000008E00256 SYS_TABLES "bugs/bug\_see\_also" 145 4 1 0 0 "" 0
...

but after the command finishes, the dumps/default/ directory remains empty and doesn't contain any SYS_TABLES data.

Is there something else I should be doing?  I've made sure the dumps subdirectories are writable 

[Aleksandr Kuzminsky]

Hi George,

I think it's a formatting typo. There should be ">" instead of ">"

So, the command should be 

./c_parser -4f pages-ibdata1/FIL_PAGE_INDEX/0000000000000001.page -t dictionary/SYS_TABLES.sql > dumps/default/SYS_TABLES 2>&1 dumps/default/SYS_TABLES.sql

[George Francis]

thank you.  

I think that second ampersand (&) also needs to go, so should the command be:

./c_parser -4f pages-ibdata1/FIL_PAGE_INDEX/0000000000000001.page -t dictionary/SYS_TABLES.sql > dumps/default/SYS_TABLES 2>1 dumps/default/SYS_TABLES.sql

I am following the guide here: https://twindb.com/how-to-recover-innodb-dictionary/

after the above command I now have a dumps/default/SYS_TABLES file showing all the eligible tablenames, but I still don't have a dumps/default/SYS_TABLES.sql file

is there another typo in the command?

[Aleksandr Kuzminsky]

Sorry, I gave you a wrong command again. 

It should be this one:

./c_parser -4f pages-ibdata1/FIL_PAGE_INDEX/0000000000000001.page -t dictionary/SYS_TABLES.sql > dumps/default/SYS_TABLES 2> dumps/default/SYS_TABLES.sql

which means, stdout is redirected to dumps/default/SYS_TABLES, stderr is redirected to dumps/default/SYS_TABLES.sql

[George Francis]

OMG - I got to the end of the instructions and it says

"Stay tuned to learn what to do with them and how to recover sakila.actor"

I am half way through recovering my data!  Please do you have the info on what the final steps are?

[Aleksandr Kuzminsky]

Depending on your case you may want to check either of these

https://twindb.com/recover-after-drop-table-innodb_file_per_table-is-on/
https://twindb.com/recover-after-drop-table-innodb_file_per_table-is-off/
https://twindb.com/recover-corrupt-mysql-database/

[George Francis]

Thanks again for the pointer..  I'm so close now - I'm just having trouble with the command:

# ./c_parser -6f pages-ibdata1/FIL_PAGE_INDEX/0000000000000919.page -t out.sql

Could not open file out.sql

load_table(): No such file or directory

i've created out.sql and made it writable - any ideas?

[Aleksandr Kuzminsky]

What do you have in out.sql?

[George Francis]

At first the file didn't exist.

Then I tried creating it with 'touch' (empty file)

[Aleksandr Kuzminsky]

That file must contain a CREATE TABLE statement of a table you try to recover.
c_parser reads the table structure from it.

[George Francis]

it works ;) . thank you so much!!

[George Francis]

Hmmm, after I do LOAD DATA LOCAL INFILE, by table only has 64 of the 2000+ recovered records, and some of the text fields have ASCII junk characters in them.. 

I took the table definition straight from a mysql dump of the original DB.. it included the encoding (UTF-8)

Any other suggestions?

[Aleksandr Kuzminsky]

George,

This is an iterative process of tuning filters to refine recovery result. I can't tell what would help unless I can see some sample data.

See "Filters" paragraph on https://twindb.com/recover-corrupt-mysql-database/ for some examples.

[George Francis]

OK, I've added a filter to my defn as follows:

CREATE TABLE `longdescs` (
  `comment_id` mediumint(9) NOT NULL AUTO_INCREMENT,
  `bug_id` mediumint(9) NOT NULL,
      /*!FILTER
     int_min_val: 1
     int_max_val: 3000 */,
  `who` mediumint(9) NOT NULL,
...

but I get the following error:

# ./c_parser -6f pages-ibdata1/FIL_PAGE_INDEX/0000000000000960.page -t /root/tables/longdescs-def.sql > /root/tables/longdescs-data.sql
Line 5: syntax error at 'int_min_val'
 4:       /*!FILTER
 5:      int_min_val: 1
Failed to parse table structure

[Aleksandr Kuzminsky]

A filter must be a comment in the end of a field definition. Thus it should come before the comma.
It should be  (note a missing comma after the "NOT NULL")

CREATE TABLE `longdescs` (
  `comment_id` mediumint(9) NOT NULL AUTO_INCREMENT,
  `bug_id` mediumint(9) NOT NULL

      /*!FILTER
     int_min_val: 1
     int_max_val: 3000 */,
  `who` mediumint(9) NOT NULL,
...

I would also recommend to set a filter on comment_id. Being auto_incremented it's very likely values can't be less than 1. Usually you also know how many records could you expect - hence the max possible value. It's ok to give the max value some room. For instance, if you know max comment_id should be around 100, "int_max_val: 1000" will give a good result.

[George Francis]

thanks again.  With the hint added, the data file output doesn't contain any rows of data, just a lot of comments of the following form:

-- Page id: 4168, Format: COMPACT, Records list: Valid, Expected records: (25 25)
-- Page id: 4168, Found records: 0, Lost records: YES, Leaf page: YES
-- Page id: 4171, Format: COMPACT, Records list: Valid, Expected records: (92 92)
-- Page id: 4171, Found records: 0, Lost records: YES, Leaf page: YES
...

any ideas about that?

[Aleksandr Kuzminsky]

Looks like InnoDB pages are more or less fine, the tool could access all records in the page by their pointers (Note Records list: Valid).

But it seems like the filters ignored the records because the values didn't satisfy the limits.

That could happen if you work with a wrong index_id? How did you determine what index_id to scan?

Also, you may want to check debug output with the -V option of c_parser, maybe it'll give a hint what's wrong.

Aleksandr Kuzminsky

TwinDB LLC

https://twindb.com/

Mobile: +1 (844) 533-0409 ext 101

Skype: aleksandr.kuzminsky

Calendar: https://secure.scheduleonce.com/akuzminsky

--
You received this message because you are subscribed to the Google Groups "TwinDB" group.
To unsubscribe from this group and stop receiving emails from it, send an email to twindb+unsubscribe@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/twindb/be5230c3-7254-4ff5-88ea-f413a5c372fb%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.