From 2a56c0f13a19d378e38288670b2498038b38b847 Mon Sep 17 00:00:00 2001 From: Dan Hermann Date: Thu, 27 Apr 2017 08:02:26 -0500 Subject: [PATCH] complete partial merge conflict resolution --- README.md | 3 --- 1 file changed, 3 deletions(-) diff --git a/README.md b/README.md index cf9d533..b6a4efa 100644 --- a/README.md +++ b/README.md @@ -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