Cerca de dois anos atrás, fui encarregado de avaliar o Amazon RDS para MySQL. Eu escrevi algumas postagens no DBA StackExchange sobre minhas descobertas e observações:
-
Jul 25, 2012
: Datacenters Percona de escala: configuração e replicação -
Aug 02, 2012
: Banco de dados local vs Amazon RDS -
Sep 21, 2012
: O MySQL 5.5 fica sem memória, descarta todas as conexões ao criar muitos bancos de dados
Em suma, existem três opções que você não pode alterar
- max_connections (por modelo de servidor )
- innodb_buffer_pool_size (por modelo de servidor)
-
innodb_log_file_size (todos os modelos de servidor,
128M
)
Aqui está o gráfico que fiz dizendo esses limites por modelo de servidor
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)
Quanto à sua pergunta atual, t1.micro
tem 34 como configuração de max_connections . Se você não pode superar 32, isso é bastante compreensível. O Amazon AWS deve ser capaz de se conectar e monitorar as coisas da Instância RDS como um < usuário strong> SUPER . Não ser capaz de ir além de 32 é razoável para uma instância de t1.micro
. Em vista disso, você não terá escolha a não ser confiar no esquema de gerenciamento administrado pela Amazon para distribuir max_connections e outras opções entre todas as Instâncias do MySQL na Nuvem AWS.