Motivado na construção de uma solução de backups para os meus ambientes de MySQL me defrontei com alguns questionamentos importante sobre que linha seguir. Quando falamos de backups de banco de dados invariavelmente caímos na discussão de qual melhor forma de proteger nosso ambiente, com backups lógicos ou físicos.
Segundo a Oracle um backup lógico, o dump, não pode ser considerado um backup por si só, mas sim um complemento de backup. O backup lógico normalmente é utilizado para situações onde uma restauração de somente algumas linhas, por exemplo é necessária. Algumas outras questões como migrações entre versões ou diferentes plataformas o dump pode ser o único recurso.
Já o backup físico, o "verdadeiro backup" particularmente no MySQL parece ter uma performance surpreendente, principalmente levando em conta o fato do tempo de restore (o dump deixa muito a desejar). Apesar dessa performance atrativa venho enfrentando alguns problemas, aparentemente o utilitário (em perl) responsável por executar o backup físico no MySQL, mysqlhotcopy, é restrito aos storage engines myisam e archive, o que acaba rementendo a um fator negativo dessa independencia que o MySQL tem em seus gerenciadores de tabela.
Aparantemente se você tiver necessidades de performance principalmente no seu procedimento de backup terá de combinar utilitários prontos como o mysqldump e o mysqlhotcopy (existem ferramentas pagas) ou desenvolver seu próprio utilitário.
Em relação a necessidades de performance tenho um banco de dados que possui um tamanho relativamente consideravel de índices, o que me fez recorrer da opção --noindices. Reduzindo 30% praticamente o tamanho de backup e consequentemente no tempo, o que me pareceu uma ótima opção, mas está resultando em uma certa dor de cabeça para reconstruir esses índices utilizando o myisamchk -r.
Procurando por respostas sobre como corrigir esse problema encontrei um workshop sobre segurança e backup em MySQL que acredito que seja de muito bom uso para quem está iniciando nessas áreas de adminsitração no mysql:
http://www.archive.org/details/mysql_backup_security
http://szeged2008.drupalcon.org/files/mysqlBackupSecurity-DrupalCon-2008-08-28.pdf
Aproveitei a oportunidade e enviei um e-mail para o palestrante para ver se consigo alguma luz.
Bom proveito da palestra.
Segundo a Oracle um backup lógico, o dump, não pode ser considerado um backup por si só, mas sim um complemento de backup. O backup lógico normalmente é utilizado para situações onde uma restauração de somente algumas linhas, por exemplo é necessária. Algumas outras questões como migrações entre versões ou diferentes plataformas o dump pode ser o único recurso.
Já o backup físico, o "verdadeiro backup" particularmente no MySQL parece ter uma performance surpreendente, principalmente levando em conta o fato do tempo de restore (o dump deixa muito a desejar). Apesar dessa performance atrativa venho enfrentando alguns problemas, aparentemente o utilitário (em perl) responsável por executar o backup físico no MySQL, mysqlhotcopy, é restrito aos storage engines myisam e archive, o que acaba rementendo a um fator negativo dessa independencia que o MySQL tem em seus gerenciadores de tabela.
Aparantemente se você tiver necessidades de performance principalmente no seu procedimento de backup terá de combinar utilitários prontos como o mysqldump e o mysqlhotcopy (existem ferramentas pagas) ou desenvolver seu próprio utilitário.
Em relação a necessidades de performance tenho um banco de dados que possui um tamanho relativamente consideravel de índices, o que me fez recorrer da opção --noindices. Reduzindo 30% praticamente o tamanho de backup e consequentemente no tempo, o que me pareceu uma ótima opção, mas está resultando em uma certa dor de cabeça para reconstruir esses índices utilizando o myisamchk -r.
Procurando por respostas sobre como corrigir esse problema encontrei um workshop sobre segurança e backup em MySQL que acredito que seja de muito bom uso para quem está iniciando nessas áreas de adminsitração no mysql:
http://www.archive.org/details/mysql_backup_security
http://szeged2008.drupalcon.org/files/mysqlBackupSecurity-DrupalCon-2008-08-28.pdf
Aproveitei a oportunidade e enviei um e-mail para o palestrante para ver se consigo alguma luz.
Bom proveito da palestra.
Nenhum comentário:
Postar um comentário