1 Antwort
- Neueste
- Die meisten Stimmen
- Die meisten Kommentare
0
Hello Aman!
T3.medium is a pretty small instance, depending on the size of your MYSQL database, this may not be enough to handle the load. Without knowing all details in your world, I would recommend either 1) sizing up the replication instance or 2) giving DMS serverless (https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Serverless.html) a try.
One other approach, if you're using Aurora MYSQL RDS, you could look into the relatively new zero-ETL option (https://aws.amazon.com/rds/aurora/zero-etl/)
beantwortet vor 2 Monaten
Relevanter Inhalt
AWS OFFICIALAktualisiert vor 2 Jahren- AWS OFFICIALAktualisiert vor 2 Jahren
- AWS OFFICIALAktualisiert vor einem Jahr
- AWS OFFICIALAktualisiert vor 3 Jahren
Thanks for your answer. So suppose I have 2 tables where approximately daily inserts and updates is 2Lac and other 2 tables have inserts apporximately 30Lac . There can be time where these are bulk inserts and in future this number might grow more . So to handle this scale of work load what should be idle instance size so that DMS task does not fail being slow is fine .
FYI : I have created different types of task like extra small , small , medium , large and extra large. I am worries about large and extra large breaking the other three are running fine .
Also the small and medium ones are in one replication instance of size t3.medium and other two large ones are in other t3.medium instance .
I'm not able to provide an exact answer with this info, but can share some additional details. DMS is reading from the binlog in mysql (https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Task.CDC.html), so I'm less worried about this new job "breaking" the exisiting jobs. You have some pretty sizeable daily inserts/updates you're looking to use DMS for, especially if they are coming through in bulk. I'd recommend trying out some of the R type instances (https://docs.aws.amazon.com/dms/latest/userguide/CHAP_ReplicationInstance.Types.html) instead of the t types you've been trying to date. I also think serverless may be a better option, particularly if you're doing bulk CDC off this database.