Nível de dados (Amazon Aurora e Amazon) ElastiCache

Com a WordPress instalação armazenada em um sistema de arquivos de rede distribuído, escalável e compartilhado e os ativos estáticos sendo servidos pelo Amazon S3, você pode focar sua atenção no componente de estado restante: o banco de dados. Assim como no nível de armazenamento, o banco de dados não deve depender de um único servidor, portanto, não pode ser hospedado em um dos servidores web. Em vez disso, hospede o WordPress banco de dados no Amazon Aurora.

O Amazon Aurora é um banco de dados relacional SQL compatível com o My SQL e o Postgre, criado para a nuvem, que combina o desempenho e a disponibilidade de bancos de dados comerciais avançados com a simplicidade e a economia de bancos de dados de código aberto. O Aurora My SQL aumenta o SQL desempenho e a disponibilidade do My integrando totalmente o mecanismo de banco de dados a um sistema de armazenamento distribuído específico, com o respaldo de. SSD Ele é tolerante a falhas e se recupera automaticamente, replica seis cópias de seus dados em três zonas de disponibilidade, foi projetado para oferecer mais de 99,99% de disponibilidade e faz backup contínuo de seus dados no Amazon S3. O Amazon Aurora foi projetado para detectar falhas no banco de dados e reiniciá-lo automaticamente sem necessidade de recuperação de pane nem de recriar o cache do banco de dados.

O Amazon Aurora fornece vários tipos de instâncias para se adequar a diferentes perfis de aplicativos, incluindo instâncias com capacidade de intermitência e otimizadas para memória. Para melhorar o desempenho do seu banco de dados, você pode selecionar um tipo de instância grande para fornecer mais CPU recursos de memória.

O Amazon Aurora processa o failover automaticamente entre a instância primária e as réplicas do Aurora para que seus aplicativos possam retomar as operações de banco de dados o mais rápido possível e sem intervenção administrativa manual. O failover normalmente leva menos de 30 segundos.

Depois de criar pelo menos uma réplica do Aurora, conecte-se à sua instância primária usando o endpoint do cluster para permitir que seu aplicativo faça o failover automático caso a instância primária falhe. Você pode criar até quinze réplicas de leitura de baixa latência em três zonas de disponibilidade.

À medida que seu banco de dados é dimensionado, o cache do banco de dados também precisará ser escalado. Conforme discutido anteriormente na seção Cache de banco de dados, ElastiCache tem recursos para escalar o cache em vários nós em um ElastiCache cluster e em várias zonas de disponibilidade em uma região para melhorar a disponibilidade. Ao escalar seu ElastiCache cluster, certifique-se de configurar seu plug-in de cache para se conectar usando o endpoint de configuração para que ele WordPress possa usar novos nós de cluster à medida que são adicionados e parar de usar nós de cluster antigos à medida que são removidos. Você também deve configurar seus servidores web para usar o ElastiCacheCluster Client PHP e atualizá-lo AMI para armazenar essa alteração.