Percona Server moved to https://jira.percona.com/projects/PS

InnoDB data file size management

Registered by George Ormond Lorch III

InnoDB currently has a very limited ability to cleanly handle an out of disk space situation. Once in an out of space state, InnoDB may sometimes sit in a simple read-only state or even be in an difficult to recover state of asserting during an attempted rollback of a transaction that failed due to an out of space error (https://bugs.launchpad.net/percona-server/+bug/1079596 see comment 25).

We propose to make this more reliable by implementing the following:
- Create a pair of new InnoDB options:
  - innodb-low-space-warn : specifies the threshold of free space available that will trigger a warning. Ex: if (space_available < innodb_low_space_warn) { emit warning }
  - inoodb-low-space-error : specifies the threshold of free space available that will trigger an error during insertions/updates. Ex: if (space_available < innodb_low_space_error && (insert || update)) { emit error; return error }

The overhead this would add is a statfs() call whenever innodb attempts to extend a data file. This should be of negligible impact as in this case we are doing a sync and holding mutexes anyway. This should be achievable by modifying fil_extend_space_to_desired_size() in fil0fil.c and/or fsp_try_extend_data_file() in fsp/fsp0fsp.c which are the main workers when InnoDB wants to extend a tablespace. The former can extend by 0 to N pages and the latter can fail to extend space_id 0.

We will also need to modify fil_extend_space_to_desired_size() and fsp_try_extend_data_file() and the calling path into them to indicate 'intention' or 'purpose' of why the extension is being made. If the extension is being done in the context of a failed transaction/rollback, or a row deletion, chances are that the rollback needs to perform a node split and thus needs more space, in this case the lid will be ignored and space allowed to be allocated. In the case of a normal transaction attempting to perform an insert/update, the innodb-low-space-error will be respected and ENOSPC returned.

Blueprint information

Status:
Not started
Approver:
None
Priority:
Low
Drafter:
George Ormond Lorch III
Direction:
Needs approval
Assignee:
George Ormond Lorch III
Definition:
Drafting
Series goal:
None
Implementation:
Unknown
Milestone target:
None

Related branches

Sprints

Whiteboard

What about purge and ibuf merge operations from the "intention"/"purpose" point of view? Can these extended tablespaces, and, if yes, how should these be treated? IMHO these should be allowed to proceed, as these are likely to result in less space used down the road. - Laurynas

That is a good point Laurynas. I obviously had not thought about that and yes, I think you are correct in that ibuf merges should be allowed to proceed through the hard limit at the risk of hitting the real ENOSPC. This does raise an interesting question though about the effectiveness of this proposal when used in conjunction of ibuf and a schema that promotes its use. In a way it allows user inserts to 'bypass' this hard limit testing since the limit tests will only be done when space actually needs to be extended. I suppose though that this may still work if the limits are still observed/enforced during ibuf page allocations/extensions when an ibuf insertion is being done but allow ibuf merge operations to pass through the limits. This is something that may take some tinkering with to get right. Another thing is that I am not really thrilled with the limit option names, please feel free to suggest alternates if you feel the same way. - George

Ohh yeah, thanks for the feedback!

Would innodb_change_buffer_max_size in 5.6 help with that? Also the admin is free to disable change buffering altogether if needed.

(?)

Work Items

This blueprint contains Public information 
Everyone can see this information.
Edit subscription

Subscribers

No subscribers.