697fa3c000
Previously, we archived deleted rows in batches of max_rows parents + their child rows in a single database transaction. Doing it that way limited how high a value of max_rows could be specified by the caller because of the size of the database transaction it could generate. For example, in a large scale deployment with hundreds of thousands of deleted rows and constant server creation and deletion activity, a value of max_rows=1000 might exceed the database's configured maximum packet size or timeout due to a database deadlock, forcing the operator to use a much lower max_rows value like 100 or 50. And when the operator has e.g. 500,000 deleted instances rows (and millions of deleted rows total) they are trying to archive, being forced to use a max_rows value several orders of magnitude lower than the number of rows they need to archive was a poor user experience. This changes the logic to archive one parent row and its foreign key related child rows one at a time in a single database transaction while limiting the total number of rows per table as soon as it reaches >= max_rows. Doing this will allow operators to choose more predictable values for max_rows and get more progress per invocation of archive_deleted_rows. Closes-Bug: #2024258 Change-Id: I2209bf1b3320901cf603ec39163cf923b25b0359
22 lines
1.0 KiB
YAML
22 lines
1.0 KiB
YAML
---
|
|
fixes:
|
|
- |
|
|
`Bug #2024258`_: Fixes an issue with performance degradation archiving
|
|
databases with large numbers of foreign key related records.
|
|
|
|
Previously, deleted rows were archived in batches of max_rows parents +
|
|
their child rows in a single database transaction. It limited how high
|
|
a value of max_rows could be specified by the user because of the size of
|
|
the database transaction it could generate. Symptoms of the behavior were
|
|
exceeding the maximum configured packet size of the database or timing out
|
|
due to a deadlock.
|
|
|
|
The behavior has been changed to archive batches of complete parent +
|
|
child rows trees while limiting each batch when it has reached >= max_rows
|
|
records. This allows the size of the database transaction to be controlled
|
|
by the user and enables more rows to be archived per invocation of
|
|
``nova-manage db archive_deleted_rows`` when there are a large number of
|
|
foreign key related records.
|
|
|
|
.. _Bug #2024258: https://bugs.launchpad.net/nova/+bug/2024258
|