AWS documentdb documentation change
Summary
Significant content restructuring: Removed detailed migration methodology sections and replaced with simplified overview linking to external guides. Removed technical details about migration tools, discovery process, planning requirements, and testing procedures. Added quick start guide and migration runbook references.
Security assessment
The changes are organizational/structural improvements to documentation flow rather than security-related updates. No vulnerabilities or security controls are mentioned. Removed content about TLS/SSL usage and security group configuration was part of general technical detail removal, not a security-specific change.
Diff
diff --git a/documentdb/latest/developerguide/docdb-migration.md b/documentdb/latest/developerguide/docdb-migration.md index eebd2061a..5cdc3f0b6 100644 --- a//documentdb/latest/developerguide/docdb-migration.md +++ b//documentdb/latest/developerguide/docdb-migration.md @@ -5,2 +4,0 @@ -Migration toolsDiscoveryPlanning: Amazon DocumentDB cluster requirementsMigration approachesMigration sourcesMigration connectivityTestingPerformance testingFailover testingAdditional resources - @@ -9,358 +7 @@ Migration toolsDiscoveryPlanning: Amazon DocumentDB cluster requirementsMigratio -Amazon DocumentDB (with MongoDB compatibility) is a fully managed database service that is compatible with the MongoDB API. You can migrate your data to Amazon DocumentDB from MongoDB databases running on premises or on Amazon Elastic Compute Cloud (Amazon EC2) using the process detailed in this section. - -###### Topics - - * Migration tools - - * Discovery - - * Planning: Amazon DocumentDB cluster requirements - - * Migration approaches - - * Migration sources - - * Migration connectivity - - * Testing - - * Performance testing - - * Failover testing - - * Additional resources - - * [Migration playbook: MongoDB to Amazon DocumentDB](./migration-playbook.html) - - - - -## Migration tools - -To migrate to Amazon DocumentDB, the two primary tools that most customers use are the [AWS Database Migration Service (AWS DMS)](https://aws.amazon.com/dms/) and command line utilities like `mongodump` and `mongorestore`. As a best practice, and for either of these options, we recommend that you first create indexes in Amazon DocumentDB before beginning your migration as it can reduce the overall time and increase the speed of the migration. To do this, you can use the [Amazon DocumentDB Index Tool](https://github.com/awslabs/amazon-documentdb-tools). - -### AWS Database Migration Service - -AWS Database Migration Service (AWS DMS) is a cloud service that makes it easy to migrate relational databases and non-relational databases to Amazon DocumentDB. You can use AWS DMS to migrate your data to Amazon DocumentDB from databases hosted on-premises or on EC2. With AWS DMS, you can perform one-time migrations, or you can replicate ongoing changes to keep sources and targets in sync. - -For more information on using AWS DMS to migrate to Amazon DocumentDB, please see: - - * [ Using MongoDB as a Source for AWS DMS](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Source.MongoDB.html) - - * [ Using Amazon DocumentDB as a Target for AWS Database Migration Service](https://docs.aws.amazon.com/dms/latest/userguide/target.docdb.html) - - * [ Walkthrough: Migrating from MongoDB to Amazon DocumentDB](https://docs.aws.amazon.com/dms/latest/userguide/target.docdb.tutorial.html) - - - - -### Command line utilities - -Common utilities for migrating data to and from Amazon DocumentDB include `mongodump`, `mongorestore`, `mongoexport`, and `mongoimport`. Typically, `mongodump` and `mongorestore` are the most efficient utilities as they dump and restore data from your databases in a binary format. This is generally the best option and yields a smaller data size compared to logical exports. `mongoexport` and `mongoimport` are useful if you want to export and import data in a logical format like JSON or CSV as the data is human readable but is generally slower than the `mongodump`/`mongorestore` and yields a larger data size. - -The Migration approaches section below will discuss when it is best to use AWS DMS and command line utilities based on your use case and requirements. - -## Discovery - -For each of your MongoDB deployments, you should identify and record two sets of data: _Architecture Details_ and _Operational Characteristics_. This information will help you choose the appropriate migration approach and cluster sizing. - -###### Architecture Details - - * **Name** - -Choose a unique name for tracking this deployment. - - * **Version** - -Record the version of MongoDB that your deployment is running. To find the version, connect to a replica set member with the mongo shell and run the `db.version()` operation. - - * **Type** - -Record whether your deployment is a standalone mongo instance, a replica set, or a sharded cluster. - - * **Members** - -Record the hostnames, addresses, and ports of each cluster, replica set, or standalone member. - -For a clustered deployment, you can find shard members by connecting to a mongo host with the mongo shell and running the `sh.status()` operation. - -For a replica set, you can obtain the members by connecting to a replica set member with the mongo shell and running the `rs.status()` operation. - - * **Oplog sizes** - -For replica sets or sharded clusters, record the size of the oplog for each replica set member. To find a member’s oplog size, connect to the replica set member with the mongo shell and run the `ps.printReplicationInfo()` operation. - - * **Replica set member priorities** - -For replica sets or sharded clusters, record the priority for each replica set member. To find the replica set member priorities, connect to a replica set member with the mongo shell and run the `rs.conf()` operation. The priority is shown as the value of the `priority` key. - - * **TLS/SSL usage** - -Record whether Transport Layer Security (TLS)/Secure Sockets Layer (SSL) is used on each node for encryption in transit. - - - - -###### Operational Characteristics - - * **Database statistics** - -For each collection, record the following information: - - * Name - - * Data size - - * Collection count - -To find the database statistics, connect to your database with the mongo shell and run the command `db.runCommand({dbstats: 1})`. - - * **Collection statistics** - -For each collection, record the following information: - - * Namespace - - * Data size - - * Index count - - * Whether the collection is capped - - * **Index statistics** - -For each collection, record the following index information: - - * Namespace - - * ID - - * Size - - * Keys - - * TTL - - * Sparse - - * Background - -To find the index information, connect to your database with the mongo shell and run the command `db.collection.getIndexes()`. - - * **Opcounters** - -This information helps you understand your current MongoDB workload patterns (read-heavy, write-heavy, or balanced). It also provides guidance on your initial Amazon DocumentDB instance selection. - -The following are the key pieces of information to collect over the monitoring period (in counts/sec): - - * Queries - - * Inserts - - * Updates - - * Deletes - -You can obtain this information by graphing the output of the `db.serverStatus()` command over time. You can also use the _mongostat_ tool to obtain instantaneous values for these statistics. However, with this option you run the risk of planning your migration on usage periods other than your peak load. - - * **Network statistics** - -This information helps you understand your current MongoDB workload patterns (read-heavy, write-heavy, or balanced). It also provides guidance on your initial Amazon DocumentDB instance selection. - -The following are the key pieces of information to collect over the monitoring period (in counts/sec): - - * Connections - - * Network bytes in - - * Network bytes out - -You can get this information by graphing the output of the `db.serverStatus()` command over time. You can also use the _mongostat_ tool to obtain instantaneous values for these statistics. However, with this option you run the risk of planning your migration on usage periods other than your peak load. - - - - -## Planning: Amazon DocumentDB cluster requirements - -Successful migration requires that you carefully consider both your Amazon DocumentDB cluster’s configuration and how applications will access your cluster. Consider each of the following dimensions when determining your cluster requirements: - - * **Availability** - -Amazon DocumentDB provides high availability through the deployment of replica instances, which can be promoted to a primary instance in a process known as _failover_. By deploying replica instances to different Availability Zones, you can achieve higher levels of availability. - -The following table provides guidelines for Amazon DocumentDB deployment configurations to meet specific availability goals. - -Availability Goal | Total Instances | Replicas | Availability Zones ----|---|---|--- -99% | 1 | 0 | 1 -99.9% | 2 | 1 | 2 -99.99% | 3 | 2 | 3 - -Overall system reliability must consider all components, not just the database. For best practices and recommendations for meeting overall system reliability needs, see the [AWS Well-Architected Reliability Pillar Whitepaper](https://d1.awsstatic.com/whitepapers/architecture/AWS-Reliability-Pillar.pdf). -