abh1sar commented on code in PR #13019: URL: https://github.com/apache/cloudstack/pull/13019#discussion_r3231616204
########## engine/schema/src/main/java/com/cloud/upgrade/dao/Upgrade42030to42040.java: ########## @@ -0,0 +1,58 @@ +// Licensed to the Apache Software Foundation (ASF) under one Review Comment: Hi @winterhazel, this can happen if someone is using two management servers behind a load balancer, and the times on the servers are skewed by a few seconds. T1. VM.START done by M1 (local time 00:00:00) T2+1s. VM.STOP done by M2 (local time 23:59:59) T3+2s. VM.START done by M2 (local time 00:00:00) The usage_events table will have entries: | id | type | account_id | created | resource_id | name | |----------|--------------------------|------------|----------------------|-------------|--------------| | 100 | VM.START | 2 | 2026-05-13 00:00:00 | 100 | vm1 | | 101 | VM.STOP | 2 | 2026-05-12 23:59:59 | 100 | vm1 | | 102 | VM.START | 2 | 2026-05-13 00:00:00 | 100 | vm1 | The events have come at the right sequence in the DB, but due to time skew the rows 100 and 102 are duplicates. The constraint on the helper table causes these events to never get processed and usage server retries processing these events everyday. This has been seen in production multiple times. If we allow duplicate helper records (by removing the constraint), it doesn't have any side-effects. The usage is processed correctly for the VM start and stop events. In createVMHelperEvent() 100 inserts a record (R1) in the usage_vm_instance table with startDate as 00:00:00 101 sets the endDate on the above record (R1) as 23:59:59 102 inserts another record (R2) in usage_vm_instance table with startDate as 00:00:00 Then in VMInstanceUsageParser() R1 is ignored as endDate is less startDate R2 is processed correctly Other helper tables apart from usage_vm_instance and usage_volume don't have any duplicate key constraint, so I though this was the right way to go about it. Let me know your thoughts. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
