maria-discuss team mailing list archive

Thread
Date

Re: ALTER TABLE ENIGNE=InnoDB performance

To: "maria-discuss@xxxxxxxxxxxxxxxxxxx" <maria-discuss@xxxxxxxxxxxxxxxxxxx>
From: Conor Murphy <conor_mark_murphy@xxxxxxxxxxx>
Date: Wed, 17 Jan 2018 17:55:04 +0000
Accept-language: en-IE, en-US
In-reply-to: <CAJuX1hyYqbwHbZeAGLYYkQPH-j+6VzyXgD8vqBT8=iEjTb93Mw@mail.gmail.com>
Spamdiagnosticmetadata: NSPM
Spamdiagnosticoutput: 1:99
Thread-index: AQHTiUnDTNCM7ZXTT0C9HmJMuXDwu6NujAkAgAJZJCKABucdgIAAIFexgAAppYCAAE+fZw==
Thread-topic: [Maria-discuss] ALTER TABLE ENIGNE=InnoDB performance

Hi Marko,


I don't think that's an option

- It would interfere with the normal operations on the master, currently we use a "FLUSH TABLES WITH READ LOCK" with an LVM snapshot to get a consistent copy of the database while the system is up and running. Changing the PARTITIONs to TABLEs would mean having to stop the running system.

- I haven't checked this in a while (> a year), but the last time we looked at swapping a TABLE back to a PARTITION, it took hours, I think it's because it validates that the rows in the TABLE belong in the PARTITION according to the partitioning scheme. MySQL has the "WITHOUT VALIDATION" option to overcome this


Regards,

Conor

Follow ups

Re: ALTER TABLE ENIGNE=InnoDB performance
From: Justin Swanhart, 2018-01-17

References

ALTER TABLE ENIGNE=InnoDB performance
From: Conor Murphy, 2018-01-09
Re: ALTER TABLE ENIGNE=InnoDB performance
From: Marko Mäkelä, 2018-01-11
Re: ALTER TABLE ENIGNE=InnoDB performance
From: Conor Murphy, 2018-01-12
Re: ALTER TABLE ENIGNE=InnoDB performance
From: Marko Mäkelä, 2018-01-17
Re: ALTER TABLE ENIGNE=InnoDB performance
From: Conor Murphy, 2018-01-17
Re: ALTER TABLE ENIGNE=InnoDB performance
From: Marko Mäkelä, 2018-01-17