Merge lp:~alikrubin75/undrop-for-innodb/undrop-for-innodb into lp:undrop-for-innodb
Proposed by
Alexander Rubin
Status: | Needs review |
---|---|
Proposed branch: | lp:~alikrubin75/undrop-for-innodb/undrop-for-innodb |
Merge into: | lp:undrop-for-innodb |
Diff against target: |
378 lines (+362/-1) 2 files modified
c_parser.c (+1/-1) recover.sh (+361/-0) |
To merge this branch: | bzr merge lp:~alikrubin75/undrop-for-innodb/undrop-for-innodb |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Aleksandr Kuzminsky | Needs Fixing | ||
Review via email:
|
Description of the change
I would suggest adding my script recover.sh to the main branch after fixing https:/
To post a comment you must log in.
Unmerged revisions
- 18. By root <root@mysql-recovery>
-
New version of recover.sh, merged to v.23
- 17. By EC2 Default User <ec2-user@ip-10-164-164-213>
-
Merged from trunk, added test_mysql_
connection to recover.sh - 16. By EC2 Default User <ec2-user@ip-10-164-164-213>
-
Added recover.sh - simple script to recover the tables.
Modified c_parser.c for fixing https://bugs.launchpad .net/undrop- for-innodb/ +bug/1339356 and https:/ /bugs.launchpad .net/undrop- for-innodb/ +bug/1339358
See inline.
In principle, it's possible a deleted record is still a member of the records list in a page. If so, then the record will be recovered.
Sometimes InnoDB excludes deleted records form the list. I don't know what it depends on, just have seen that before.
So, if check_page() returns OK and the deleted record isn't part of the list it will be silently ignored. If check_page() returns Not OK then c_parser will produce junk records which can be filtered out with c_parser filters. This is better than silently ignoring the deleted records.