Missing table partition

[tanguyvda]

---

BUG REPORT INFORMATION

Centreon Web version: 2.8.17

Centreon Engine version: 1.8.1

Centreon Broker version: 3.0.11

OS: centos 6.8

Additional environment details (AWS, VirtualBox, physical, etc.):
vmware virtual machine

Steps to reproduce the issue:

1. mysql > alter table data_bin drop partition pyyyymmdd #select a partition that is not the latest
2. make sure that the partition is dropped in administratin -> server status
3. run the centreon-partitioning cron and notice that your partition is not created back

Describe the results you received:

partition is missing

Describe the results you expected:

I expect the cron to, not only create the missing partitions based on the latest one but to create every missing partition. It mustn't create missing partitions that are in the past (it could have some side effects with the data that is in next partition instead of the previously missing one. Perhaps, Maybe, I don't know)
Additional information you think important (e.g. issue happens only occasionally):

obviously you're not supposed to drop your partitions, but in some very specific cases (that haven't been yet determinated) you can have your cron that is failing to create the partition. You somewhere have the information that the latest partition is this one but it is not created. So when the cron is running the next day, it doesn't see that the partition is not created and does not try the create it. Resulting in a missing partition.

[lpinsivy]

@tanguyvda it is impossible to create partition with an "LESS THAN" value older than the last available in the partitions of the table.

Case 1: if the destroyed partition contained data, it is lost
Case 2: if it is a prepared partition for the future, the values will be stored into the next partition due to "LESS THAN" value of the next one.

[lpinsivy]

Or, if the dropped partition is in the future, may be delete all partition after the dropped partition and recreate all...

[tanguyvda]

yes that is the solution we used. But perhaps we shouldn't let our users do that on their own