Page History

We are in the process of understanding this process in greater detail. Initial trials suggest that this sequence, as recommended by AWS, does not work. We have found that the snapshot will not proceed until the MySQL session holding the locks releases the locks or exits (which releases the locks).

Be aware that your database may have MyISAM tables in the internal schemas MySQL uses for operations. We are not sure what to do with those. It may be the case that trying to flush-and-lock them Initial trials suggest that flushing-and-locking those tables along with your own tables will block the snapshot from proceeding while flushing-and-locking just your own MyISAM tables will allow snapshotting to proceed as normal.

beginning (or at least completing). Snapshot creation times seem nominal if only your own MyISAM tables are flushed-and-locked, leaving out the internal MyISAM tables.

Read Replicas

• Making snapshots from Read Replicas may also be in the solution mix. However, be aware that creating a new read replica is based on a snapshot, so getting a good snapshot with stable/valid MyISAM table also may be problematic. 
• RDS documentation warns to be sure to monitor the ReplicaLag metric if you have read replicas setup for MySQL RDS DBs containing MyISAM tables. In particular it warns that if the ReplicaLag metric returns -1, then replication may be having problems because of MyISAM tables.
  • From AWS: "Using a non-transactional storage engine such as MyISAM. Replication is only supported for the InnoDB storage engine."
  • However, AWS might really mean that "Reliable replication is only supported for the InnoDB storage engine." Empirical tests show that data in MyISAM tables is replicated though we haven't tested the reliability of that.