Atualize o MySQL para 5.5 no Lucid, atualize o servidor para Precise ou mude para o Percona?

1

Olhando para a atualização do mysql em nosso servidor de desenvolvimento para o qual o 10.04 está executando, ele está preso no MySQL 5.1, já que parece que não há suporte do apt-get para atualizar para 5.5 exceto por determinados PPAs de terceiros.

Então, estou procurando qual rota seguir e o que outras pessoas fizeram:

a. Siga um guia casal com idade de um ano para instalar manualmente o MySQL 5.5 e, em seguida, investir tempo contínuo para baixar manualmente e instalar atualizações de segurança a cada mês ou dois?

b. Atualize 10.04 para 12.04, e da experiência de outros povos eu trabalho com passar vários dias resolvendo as falhas dessa grande atualização, então eu terei acesso ao mysql 5.5 e fácil de instalar o apt-get de futuras atualizações de segurança?

c. Mudar do MySQL para o Percona Server 5.5 e obter todos os benefícios dessa versão do MySQL, além de atualizações fáceis do apt-get com o PPA?

d. Algo mais?

    
por xref 05.06.2012 / 21:28

1 resposta

2

Essa deve ser uma pergunta que você deve fazer à sua equipe. Decidimos atualizar o Ubuntu, mas tendemos a nos ater ao mesmo sistema operacional, uma vez que o escolhemos, e apenas uma vez mudamos do Fedora para o Ubuntu quando o Ubuntu foi útil (foi quando o 6.06 foi lançado).

Todos os nossos servidores que estão em uso com dados para nossos clientes são atualizados para 12.04 assim que sentimos que valeu a pena. Temos 3 servidores idênticos sincronizados (ou seja, replicação de dados do MySQL, sincronizando nosso software), em que 2 são configurados como fallbacks automáticos se o principal cair fora.

A segunda máquina de reversão foi colocada off-line e informamos os clientes de que estaríamos rodando em uma máquina de reserva pelas próximas 12 horas como uma ação de manutenção regular. Atualizou para 12.04, atualizou nosso software e testou o sistema por um bom tempo. A atualização para 12.04 foi impecável pelo caminho.

Nós então fizemos o play catch up, transformamos na máquina principal e fizemos as mesmas ações para a 2ª e 3ª máquina. Tempo de inatividade zero. Poderíamos ter tido problemas se os sistemas principal e de fallback fossem descartados, mas se isso acontecer 999 de um total de 1000 vezes, é apenas uma máquina (e o inferno se soltará).

Em suma ...

Então B seria minha opção. É um método comprovado, portanto, menos arriscado que a opção A. A opção C pode ser uma opção, mas alternar o sistema operacional pode ser mais um incômodo (para nós, envolveria dias de servidor, semanas de verificação se tudo funciona da maneira que queremos). / p>     

por Rinzwind 05.06.2012 / 21:55