Esta é uma questão polêmica, com certeza, já que muitos podem querer recomendar as coisas simples de imediato, como: Dividir as mesas! Divida a leitura / gravação em configurações mestre / escravo! Amp up the ram do servidor! E assim por diante .... deixe-me explicar primeiro o problema:
Eu tenho um servidor um pouco poderoso: 8GHz, 160GB de armazenamento, 8GB de RAM (16GB Flexi RAM), RAID 10, 16GB Flexi-SSD. Executando mySQL, PHP, Apache, Debian.
Meu banco de dados atual consiste em cerca de 16 tabelas, em que uma contém 1.7GB de informações, com 23 milhões de linhas (indexadas).
Eu executo um serviço que requer varreduras de dados diárias, às vezes por hora, que recebo por meio de terceiros e que produz entre 100 novas linhas por minuto até um máximo de 5000 linhas por minuto, aproximadamente (raramente). Os dados são obtidos por meio de um rastreador que os obtém de uma API e esses rastreadores são executados de forma automatizada, programada e, às vezes, ad-hoc, de modo que são pesados para o mestre.
Quando as pessoas usam o site, haverá consultas atualizadas disponíveis para mostrar seus dados de análise mais recentes, então é quando muitas pessoas estão conectadas, extremamente lentas (eu trabalhei com consultas lentas e tentei reduzir tudo com índices onde eu poderia). Eu produzo essas análises rapidamente do banco de dados (elas têm no máximo 24 horas) e podem consistir em até 5 milhões de registros somados por usuário. Eu não acho que faria sentido pré-renderizar essas consultas, já que eu teria que levar em conta todo o slicing / filtering de alguma forma nos arquivos HTML pré-renderizados ... certo? Ou as pessoas fazem isso?
Agora, às vezes, recebo avisos no meu telefone, efetuo login no servidor apenas para descobrir que o mySQL está inativo. Eu vou fazer um mysqlcheck e reparar, o que leva até 2 horas ou mais e finalmente sai com um banco de dados em funcionamento. Eu começo tudo e tudo é feliz novamente. Eu nunca descubro por que isso acontece , embora isso ocorra quando um blog escreve sobre o site e as pessoas simplesmente enlouquecem e atacam o site com inscrições. Mas nenhum log detalhado sobre onde ele caiu e caiu.
Além de limitar o processo de inscrição (linha de espera), existe alguma coisa que eu possa fazer para garantir que, aconteça o que acontecer, o MYSQL NÃO DEVE FALHAR? Posso executar uma espécie de reparo automático e otimizá-lo em uma ocorrência ao vivo por hora? Eu suponho que isso bloqueia todo o acesso às tabelas, o que seria terrível?
Estou realmente impressionado com isso. Eu divido read / write e poderia, teoricamente, dividir todos os usuários de acesso de leitura a servidores escravos em instâncias do EC2. Mas então eu tenho o problema de picos de uso subindo e descendo drasticamente e quando eu preciso de uma nova instância do EC2, ele requer que eu transfira até 2GB de dados para sincronizar o banco de dados escravo ... que nunca funciona através do log do mysql-bin se eu decidir desligar / inicializar uma instância do EC2 com uma pausa de vários dias.
Tenho conseguido me manter atualizado até saber, mas mesmo com o EC2 e outras tecnologias disponíveis, não estou no limite de minha compreensão e capacidade técnica.
Eu adoraria compartilhar TODAS as informações necessárias para torná-lo um segmento / documento útil para mais tarde. Como nem todo site é um tipo de ambiente youtube / youporn / instagram / tumblr, eu sinto que há poucas informações para o meu tipo de site (gravação / leitura alta, de 500 a 5 milhões de registros por usuário, de 3.000 a 10.000 usuários.
Obrigado a todos, pergunte e fornecerei mais informações. Eu adoraria ouvir suas melhores práticas.