Migrating to Amazon RDS with Database Migration Service

Editor's Notes

1. Start with some audience interaction… How many of you have been to the AWS Database Migration website? Has anyone tried using DMS yet? Databases are special! Crown jewels of the business! They’re also the most common cause for lost sleep and IT escalations. So, its natural that people want to know,
2. There are other ways of migrating too. Often the native option is the best option. They come with drawbacks though: downtime and the inability to move between engines
3. - Pre DMS, costly, license-intensive replication software to move data - Were not simple to setup or use required expert resources - Long downtimes the other option - Customers who wanted to switch engines had to deal with differences in datatypes, table syntax, sp’s, functions, triggers
4. Responsive to customers Migrations easier and less intrusive Migrate will low downtime to any RDS engine type   Post migration, customers asked for ongoing sync Sync between on prem and also between engines This mobility addresses one of the big requests: The ability to migrate off of commercial, license-intensive database engines, onto cloud-native, non-commercial engines.
5. So it was with all these factors in mind that we developed the database migration service. We designed it to be simple - you can get started in less than ten minutes. We designed it to enable near-zero-downtime migration. And we designed it to be a kind of replication Swiss army knife. To replicate data between on-premises systems, RDS, EC2, and across database engine type
6. So it was with all these factors in mind that we developed the database migration service. We designed it to be simple - you can get started in less than ten minutes. We designed it to enable near-zero-downtime migration. And we designed it to be a kind of replication Swiss army knife. To replicate data between on-premises systems, RDS, EC2, and across database engine type
7. So it was with all these factors in mind that we developed the database migration service. We designed it to be simple - you can get started in less than ten minutes. We designed it to enable near-zero-downtime migration. And we designed it to be a kind of replication Swiss army knife. To replicate data between on-premises systems, RDS, EC2, and across database engine type
8. So it was with all these factors in mind that we developed the database migration service. We designed it to be simple - you can get started in less than ten minutes. We designed it to enable near-zero-downtime migration. And we designed it to be a kind of replication Swiss army knife. To replicate data between on-premises systems, RDS, EC2, and across database engine type
9. So it was with all these factors in mind that we developed the database migration service. We designed it to be simple - you can get started in less than ten minutes. We designed it to enable near-zero-downtime migration. And we designed it to be a kind of replication Swiss army knife. To replicate data between on-premises systems, RDS, EC2, and across database engine type
10. So it was with all these factors in mind that we developed the database migration service. We designed it to be simple - you can get started in less than ten minutes. We designed it to enable near-zero-downtime migration. And we designed it to be a kind of replication Swiss army knife. To replicate data between on-premises systems, RDS, EC2, and across database engine type
11. The database migration process works like this. first start with the SCT.
12. - Embedded SQL conversion - Cloud native code optimization
13. Creates tables at target database Sets up metadata required at target Populates data from source Each process loads one entire table Can use multiple processes Can be paused When restarted will continue from where it was stopped Will reload any tables that were currently in progress
14. Oracle supplemental logging MySQL row-level bin logging SQL Server bulk logged/full recovery Postgres WAL No agent Uses recovery log Native change data capture API
15. Let’s explore how it is that DMS can enable near zero downtime migration. The customer starts by launching a DMS instance in their AWS account. (click) Then the customer provides database connection information to connect out to their on-premises database, and in to their AWS database. (click) Next the customer will select which tables, schemas or databases they want to migrate, (click) and DMS will load the data, and keep it in sync on an ongoing basis. (click) Finally, at the time of the customer’s choosing, they can simply change the application to point to the new AWS database, instead of their old on-premises database. (click)
16. When you either migrate or replicate, you can choose the Multi-AZ option. This option provides DMS in a high availability mode–in case the primary DMS server fails, the secondary one kicks in.
17. So by now it should be pretty obvious that data can move from A to B, and many have used DMS to do just that. Some customers have been pretty ingenious with DMS and have fanned in, or consolidated systems. DMS will put data where you ask it to, so if you want to merge data from a number of legacy systems into a single repository, DMS can help with this. And remember, DMS can just as easily move data between like databases and unlike databases, so you can take information from a number of different platforms and consolidate it in a single, cloud database.
18. In addition to “fanning-in” or consolidating, we’ve had a customer who has taken their database and “fanned-out” different portions to different targets. For example, from their ERP system they replicate they customer list out to the CRM system and also take some of the general ledger transactions and funnel them over to a BI system. We’ve also had a customer who, for legacy reasons, used a single database for three different applications. With DMS you can split this information out to different databases. One could be PostgreSQL, one SQL Server, and one Aurora
19. Some organisations have many years of historical data, and for those that are willing to make the leap, filtering can be done during a migration so that only newer information is kept. Filtering can be done on any field in the source database–not just dates.
20. Just in case it wasn’t abundantly clear–DMS can move your data from pretty much anywhere to pretty much anywhere. Sort of like a courier company for the cloud
21. Mention why no older engines as sources
22. Where can you learn more? (CLICK) The User Guide and download option are available from the DMS section of the AWS Console (CLICK) Yeah, there’s the Download button. Click it and you’ll see something like this. (CLICK) Information on installation and use (CLICK) The Schema Conversion Tool has its own forum to ask questions and get help