external/og-aws
1
0
Fork 0
mirror of https://github.com/nickpoida/og-aws.git synced 2025-03-09 15:40:06 +00:00
Code Issues Releases Wiki Activity

complete partial merge conflict resolution

Browse source
This commit is contained in:
Dan Hermann 2017-04-27 08:02:26 -05:00
parent c309531a76
commit 2a56c0f13a
1 changed files with 0 additions and 3 deletions
Download patch file Download diff file Expand all files Collapse all files

3
README.md
View file

@ -1155,10 +1155,7 @@ RDS Aurora
- Because Aurora is based on MySQL 5.6.10, avoiding any MySQL features from 5.7 or later will ease the transition from a MySQL-compatible database into Aurora.
- The easiest migration path to Aurora is restoring a database snapshot from MySQL 5.6. The next easiest method is restoring a dump from a MySQL-compatible database such as MariaDB. For [low-downtime migrations](http://cantrill.io/howto/aws/2016/06/06/migrating-from-mysql-to-aurora-with-almost-no-downtime.html) from other MySQL-compatible databases, you can set up an Aurora instance as a replica of your existing database. If none of those methods are options, Amazon offers a fee-based data migration service.
- You can replicate [from an Aurora cluster to MySQL or to another Aurora cluster](http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Aurora.Overview.Replication.MySQLReplication.html). This requires binary logging to be enabled and is not as performant as native Aurora replication.
<<<<<<< 949c7dbddcf37baa5dc2bddaae0e2a85389a780f
=======
- Because Aurora read replicas are the [equivalent of a multi-AZ backup](http://stackoverflow.com/a/32428651/129052) and they can be configured as zero-data-loss failover targets, there are fewer scenarios in which the creation of a multi-AZ Aurora instance is required.
>>>>>>> added tips about performance schema, global variables, and Aurora multi-AZ considerations
### RDS Aurora Gotchas and Limitations