Each connection carries the load of per-connection buffers as set by these parameters
Changing the number of connections increases the amount of memory each connection can demand to this : (join_buffer_size+sort_buffer_size+read_buffer_size
+read_rnd buffer_size) X max_connections
I have written about these before
ANALYSIS
Amazon has to set the number of connections based on each model's right to demand a certain amount of memory and connections
MODEL max_connections innodb_buffer_pool_size
--------- --------------- -----------------------
t1.micro 34 326107136 ( 311M)
m1-small 125 1179648000 ( 1125M, 1.097G)
m1-large 623 5882511360 ( 5610M, 5.479G)
m1-xlarge 1263 11922309120 (11370M, 11.103G)
m2-xlarge 1441 13605273600 (12975M, 12.671G)
m2-2xlarge 2900 27367833600 (26100M, 25.488G)
m2-4xlarge 5816 54892953600 (52350M, 51.123G)
I wrote about this as well : When should I think about upgrading our RDS MySQL instance based on memory usage?
This allows Amazon to do the following:
- Charge you for each memory model based on seamless MySQL usage
- Fairly Apportion Resources for MySQL RDS per region
- Shoot yourself in the foot for tampering with per-connection settings
RECOMMENDATION
Perhaps you should try useing Amazon EC2 where you have no restrictions on access to my.cnf
Upgrading an instance in RDS means RDS will be physically migrating the database to a new instance, likely on a different physical host, so downtime would not be avoidable. Migrating to provisioned IOPS would likely mean your data would be migrated to a new EBS volume (and the server might be migrated to a new instance as well with this change, depending on whether, internally, machines capable of accessing EBS volumes with provisioned IOPS are physically segregated from machines that aren't, so that they can be on a different class of network hardware) so downtime would again be inevitable.
There appears to be a way to avoid this disruption: a Multi-AZ deployment, which creates an invisible and inaccessible (to you) replica in another availability zone within the region.
In the case of system upgrades like OS patching or DB Instance scaling, these operations are applied first on the standby, prior to the automatic failover. As a result, your availability impact is limited only to the time required for automatic failover to complete.
— http://aws.amazon.com/rds/multi-az/
That should provide a quick and seamless migration path, though I have not had occasion to test this capability. "Modify" in the console appears to allow you to convert an instance to Multi-AZ. Presumably, this would result in brief I/O freeze as the instance is cloned, so I of course would recommend testing all of this functionality before trying it.
Alternately, RDS supports an internal mechanism that should allow you to emulate the "add slave; promote to master; switch clients" operation, and this also should allow you to achieve a near-zero-downtime conversion:
- Create an actual RDS read replica of your database with the desired instance class
- Wait for the replica to come online and be synched with the master
- Modify the replica's configuration to add Provisioned IOPS
- Wait for the replica to come online and be synched with the master
- Verify that both systems have identical data using 3rd party tools
- Disconnect your application from the old master
- Verify matching binlog coordinates on master and replica to assure that all application writes have replicated
- Split the systems with "Promote Read Replica" on the new replica in RDS
- Connect your application to the new master
http://aws.amazon.com/about-aws/whats-new/2012/10/11/amazon-rds-mysql-rr-promotion/
Best Answer
Look for Amazon instructions. With RDS, the instructions are roughly: