Timeline for Between optimizing a 1-billion rows table and dump-restoring it, which would be faster?
Current License: CC BY-SA 3.0
6 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Feb 6, 2016 at 21:44 | comment | added | Rick James | (I added some more.) | |
| Feb 6, 2016 at 21:43 | history | edited | Rick James | CC BY-SA 3.0 |
more
|
| Feb 6, 2016 at 20:44 | comment | added | Gautam Somani | The better way which I do is that I start optimizing with the smallest table is the free disk space is 5 Gb more than the size of the smallest table, and then I go next with the next bigger table, this ensures that as space keeps recovering, So when the remaining disk space is size of smallest table + 5 to 10 Gb extra, that's my trigger point to start this activity. | |
| Feb 6, 2016 at 20:44 | comment | added | Gautam Somani | Dump takes time, no doubt. I don't want to know methods of doing this, there are many, I just want to know that between restoration process and optimize why is optimize better? We never take dumps to recover space, unless there are use cases. Problem with creating new table is that there should be enough space left on the disk. Partitions are automatically archived and dropped after a certain number of days. Each table has its own IBD file. | |
| Feb 6, 2016 at 18:30 | history | edited | Rick James | CC BY-SA 3.0 |
typo + another caveat + more on dump+relaod
|
| Feb 6, 2016 at 18:10 | history | answered | Rick James | CC BY-SA 3.0 |