【以下的问题经过翻译处理】
这是一个设置示例。
BUCKET_1 - 在本地端点上具有“DROP_AND_CREATE”表准备模式的复制任务。
BUCKET_2 - 由Lambda从BUCKET_1中的事件同步,并是迁移到Aurora RDS实例的迁移任务的源端点。
对于以下事件(以便在BUCKET_2中复制和删除对象),已为BUCKET_1定义了Lambda触发器:
s3:ObjectCreated:*
s3:ObjectRemoved:*
目标是使BUCKET_2与BUCKET_1完全同步。
最近,我们发现ObjectRemoved和ObjectCreated事件并不总是按照时间顺序排列。我找到了文件,其中记录了Lambda接收S3事件触发器的顺序是无法保证的。这会导致在创建后立即删除文件(创建和删除的顺序不正确)的情况。
我一直在研究解决方法。其中一个方法是,当事件是ObjectRemoved*时,查找对象的最后更新时间,如果在2分钟内(或某个合理的时间范围内),则不要删除。
另一个选项是创建一个类似下面的CloudWatch规则,并将其绑定到Lambda,该Lambda将检查任务的eventid是否等于'DMS-EVENT-0069',然后清理所有相关的“dbo”文件。
BUCKET_2:
{
"source": [
"aws.dms"
],
"detail-type": [
"DMS Replication State Change"
]
}
我对上述问题的担忧是,在 DMS-EVENT-0069 和数据传输开始之间是否会有足够的滞后时间以允许清空 BUCKET_2 中的所有内容。
我们将有多达 450 个任务和 300 个存储桶支持 150 个数据库的复制,因此我正在寻找最佳实践解决方案以确保 BUCKET_1 和 BUCKET_2 完美同步。这对于复制至关重要。
也许有更好的选择来确保两个桶同步?
更新:由于我们的解决方案中缺少持久性存储,我们不想保留排序器精益是针对以下解决方案(这仅在对象创建后触发 ObjectCreated* 事件并且 ObjectRemoved * 事件在对象被删除后触发)。不会有其他进程接触这些对象,只有 DMS 和 Lambda。
IN BUCKET_1 ObjectRemoved* EVENT raised during full load DROP_AND_CREATE Lambda Handler
IF BUCKET_2 has an Object with the same name
GET bucket_2_object_creation_date
IF time_span_in_minutes ( now - bucket_2_object_creation_date ) > 2
DELETE Object
ELSE
--Object was created by the same Data Migration Task instance, leave it there.