Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

AWS Database Migration Service

aws.amazon.com

Post reply on HN
Print view View original

21–30 of 67 posts

Re: AWS Database Migration Service

#21

Post by orillian »

aidos wrote: post #9
toomuchtodo wrote: post #4

Earlier quoted context omitted.

Not unless you're ready to try to create a physical host replica, and then fail over to it as a master during downtime.

Is it possible to run a read replica outside of RDS these days?

Funny this showed up on here. I just spent the last 4-5 days playing with DMS.

My company has been using AWS for a while, but management wanted a "backup" backup off Amazon "JUST IN CASE". Due to amazon blocking replication credentials for MYSQL servers we had to basically dump over scp to our off amazon server and run the update on that machine via a script. We tried a number of different options but none were reliable. All nasty stuff.

Anyway after setting up a dms.t2.medium replication instance, I was able to create a number of tasks pulling from our amazon server to our off amazon server.(You have the option to just pull a full dump, pull a full dump and continue replication or simply replicate data.) It's been running for a little under 24 hours now and has been, solid so far with the replication. I know not even a day yet, but it's looking promising. Fingers crossed!

A small bonus to doing the setup for this. I found out the hard way that there was bad schema in our database, which I spent the last couple days fixing. DMS is rather sensitive, and will fail and not restart if it encounters to many errors trying to replicate data.

Overall cost is looking like it's going to cost me about $150 a month for the replication instance, which is only marginally more than the bandwidth costs I was incurring doing full dumps to our off amazon server.

Benefits are almost instant replication and an interface that will give me almost instant feedback on failed replication tasks, all within AWS which is where we are hosting everything else at this time. I was also able to create individualized tasks for separate schema so I can watch and manage errors on a schema by schema basis which is nice.

Overall I'm happy with it, but only time will tell if it can continue to be a reliable replication option.

O.

Re: AWS Database Migration Service

#22

Post by manigandham »

swehner wrote: post #18
dantiberian wrote: post #2

The truly interesting thing to me about this product is the pricing. Competitors in this space sell software starting at ~$5,000 all the way up into 5, and I presume 6 figures. AWS is giving away their software and only charging for the hardware to run this migration software on. The catch is that you need to be migrating to AWS resources which you are paying for. I'm sure this tool will have less features than the m…

The lock-in is where the catch is right.

The whole idea of a migration service which lets you migrate to or from an AWS resource means there is no lock-in.

Re: AWS Database Migration Service

#23

Post by manigandham »

jrgoj wrote: post #15

What are my chances of a relatively successful SQL Server migration with several hundred tables and complex views to PostgreSQL using their migration tool?

I tried this, SQL Server isnt supported yet... its just not even in the dropdown options. However it is listed in the marketing and product overview text so it seems like it's coming.

EDIT: looks like it's there now. will try it out tonight then.

Re: AWS Database Migration Service

#24

Post by univerio »

znep wrote: post #10
drewpc wrote: post #5

Looks like this could be a better way to migrate between major versions of PostgreSQL on RDS than rolling your own.

If you didn't catch it, AWS now supports upgrades between so-called "major versions" (eg. 9.3 -> 9.4). https://aws.amazon.com/about-aws/whats-new/2015/11/rds-postg...

When 9.5 lands in RDS, they will inevitably take six months to roll out the major version upgrade to 9.5 feature, during which time this can be very useful.

Re: AWS Database Migration Service

#25

Post by jrgoj »

manigandham wrote: post #23
jrgoj wrote: post #15

What are my chances of a relatively successful SQL Server migration with several hundred tables and complex views to PostgreSQL using their migration tool?

I tried this, SQL Server isnt supported yet... its just not even in the dropdown options. However it is listed in the marketing and product overview text so it seems like it's coming. EDIT: looks like it's there now. will try it out tonight then.

Great! Let me know how it goes. It will be a couple of days before I can try it. Hopefully I can migrate just the schema and cherry pick some relatively static tables. We'll see.

Re: AWS Database Migration Service

#26

Post by nkozyra »

matt_wulfeck wrote: post #19
swehner wrote: post #18

Earlier quoted context omitted.

The lock-in is where the catch is right.

There's not a whole lot of lock-in using an rds instance. It's MySQL.

... with automatically managed updates, backups, monitoring, auto-scaling, auto-replication ...

The managed services are a huge part of the lock-in with AWS services, because even though they generally cost more than the competitors, they can often come out equal after accounting for those aggregate hours lost to doing those things.

Re: AWS Database Migration Service

#27

Post by rubiquity »

nkozyra wrote: post #26
matt_wulfeck wrote: post #19

Earlier quoted context omitted.

There's not a whole lot of lock-in using an rds instance. It's MySQL.

... with automatically managed updates, backups, monitoring, auto-scaling, auto-replication ... The managed services are a huge part of the lock-in with AWS services, because even though they generally cost more than the competitors, they can often come out equal after accounting for those aggregate hours lost to doing those things.

That's what you call "paying for a service." Lock-In is an entirely different matter.

Re: AWS Database Migration Service

#28

Post by acdha »

nkozyra wrote: post #26
matt_wulfeck wrote: post #19

Earlier quoted context omitted.

There's not a whole lot of lock-in using an rds instance. It's MySQL.

... with automatically managed updates, backups, monitoring, auto-scaling, auto-replication ... The managed services are a huge part of the lock-in with AWS services, because even though they generally cost more than the competitors, they can often come out equal after accounting for those aggregate hours lost to doing those things.

It's not lock-in if you don't want to leave – that's just being competitive. Real lock-in would be something like removing an export function or introducing a proprietary storage backend with incompatible semantics so anyone leaving would need to rewrite application logic.

If you want to talk lock-in, look at services like Lambda where there isn't a direct counterpart (although the model there is so simple that most users could port relatively quickly).

Re: AWS Database Migration Service

#29

Post by Johnny555 »

nkozyra wrote: post #26
matt_wulfeck wrote: post #19

Earlier quoted context omitted.

There's not a whole lot of lock-in using an rds instance. It's MySQL.

... with automatically managed updates, backups, monitoring, auto-scaling, auto-replication ... The managed services are a huge part of the lock-in with AWS services, because even though they generally cost more than the competitors, they can often come out equal after accounting for those aggregate hours lost to doing those things.

Is it really "lock-in" if you use it because it's cheaper and better for you and migrating somewhere else is as simple as a database export?

I can see something like DynamoDB being vendor lock-in since you can't just download your data into your own self-hosted DynamoDB instance, but if you're using a standard off-the-shelf RDS database (MySql, PostgreSQL, Sql/Server, etc), I don't think you can call it lock in when you're staying only because it's easier than running it yourself.

Re: AWS Database Migration Service

#30

Post by nkozyra »

rubiquity wrote: post #27
nkozyra wrote: post #26

Earlier quoted context omitted.

... with automatically managed updates, backups, monitoring, auto-scaling, auto-replication ... The managed services are a huge part of the lock-in with AWS services, because even though they generally cost more than the competitors, they can often come out equal after accounting for those aggregate hours lost to doing those things.

That's what you call "paying for a service." Lock-In is an entirely different matter.

Lock-in happens when migrating would be expensive, too. And leaving a managed service like this could introduce substantial cost.
Post reply on HN