Prior to this commit the instructions in the updatetime.sql script would cause
resource_events to be deleted when PDB applied migration number 73 which
partitions the resource_events table.
This is due to the resource_events in the SLV data dump having older timestamps
than the reports. Max date of 2018-03-30 for resource_events and 2019-05-27 for
reports in the SLV 2019-05-29 dump.
If there is enough drift between the resource_events timestamp and the
producer_timestamp in reports the partitions created for resource_events are
newer than any of the timestamps for the resource_events. This will cause all
of the resource_events to be dropped during the migration.
The updated instructions in updatetime.sql now bumps the timestamps for all
resource_events to a range that falls within the partitions created during
the migration so no data is lost.
RandellP
commented
4 years ago
Prior to this commit the instructions in the updatetime.sql script would cause resource_events to be deleted when PDB applied migration number 73 which partitions the resource_events table.
This is due to the resource_events in the SLV data dump having older timestamps than the reports. Max date of 2018-03-30 for resource_events and 2019-05-27 for reports in the SLV 2019-05-29 dump.
If there is enough drift between the resource_events timestamp and the producer_timestamp in reports the partitions created for resource_events are newer than any of the timestamps for the resource_events. This will cause all of the resource_events to be dropped during the migration.
The updated instructions in updatetime.sql now bumps the timestamps for all resource_events to a range that falls within the partitions created during the migration so no data is lost.