Newbe Dev Stack

Answer : Short answer - you shouldn't worry about FreeableMemory unless it is became really low (about 100-200 Mb) or significant swapping occur (see RDS SwapUsage metric). FreeableMemory is not a MySQL metric, but OS metric. It is hard to give precise definition, but you can treat it as memory which OS will be able to allocate to anyone who request it (in your case it likely will be MySQL). MySQL have a set of settings which are restricting it's overall memory usage to some cap(you can use something like this to actually calculate it). It's unlikely that your instance will ever hit this limit, due to the fact that in general you never reach max number of connections, but this is still possible. Now going back to "decline" in FreeableMemory metric. For the MySQL most of the memory consume by InnoDB buffer pool (see here for details). RDS instances in there config by default have size for this buffer set to 75% of hosts physical memory - which in your case i...

Answer : Solution 1: AWS RDS max_connections limit variable is based on Instance type, so you can upgrade your RDS or make more replica. The RDS types with max_connections limit: t2.micro 66 t2.small 150 m3.medium 296 t2.medium 312 m3.large 609 t2.large 648 m4.large 648 m3.xlarge 1237 r3.large 1258 m4.xlarge 1320 m2.xlarge 1412 m3.2xlarge 2492 r3.xlarge 2540 Referring by max_connections at AWS RDS MySQL Instance Sizes in 2015 Update 2017-07 The current RDS MySQL max_connections setting is default by {DBInstanceClassMemory/12582880} , if you use t2.micro with 512MB RAM, the max_connections could be (512*1024*1024)/12582880 ~= 40, and so on. Each Web server could have many connections to RDS, which depends on your SQL requests from Web server. Solution 2: You can change the max_connections value by either updating the default parameter policy or create a new one - I'd suggest going with the latter. Go to RDS Parameter Groups Create a new ...

Answer : Backup window doesn't specifically ask for the time when to start take backup but instead ask for time period in which aws can trigger backup. So basically it's asking for backup window time . That's why it has 2 fields 1. StartTime: When can the process of backup be started. 2. Duration : time window in which process must start to take backup. E.G if I set start time: 5:30 and duration: 30mints Backup can start at anytime between 5:30 to 6:00 . from Working With Backups documentaion Below is the answer for "what if the backup did not fit into a backup window?" If the backup requires more time than allotted to the backup window, the backup continues after the window ends, until it finishes. Below is the answer for "If backup may not fit into the backup window, why do we need a backup window?" The backup window can't overlap with the weekly maintenance window for the DB instance.

Answer : The technical differences are summarised nicely in this SlideShare - http://www.slideshare.net/AmazonWebServices/amazon-aurora-amazons-new-relational-database-engine It's really quite a different architecture/implementation under the covers from standard MySQL, and one that is fundamentally closed. Amazon are being coy about the extent to which the front end is a MySQL derivative or a complete rewrite that is protocol-compatible - see http://www.theregister.co.uk/2014/11/26/inside_aurora_how_disruptive_is_amazons_mysql_clone/?page=2 - but it looks likely it's at least a major fork with lots of new code. It will have different bugs from the main MySQL releases, which users will be reliant on Amazon to fix. A distributed transactional database backend is a complex thing to write, and while Amazon have some of the best engineers in the world for this sort of system, it's still quite new. It relies on a completely new Amazon-specific multi-tenanted storage bac...