mysql no debian stretch

Question

O Debian Stretch provavelmente será lançado no meio deste ano.

O mysql-server-5.x não estará mais disponível e é substituído por mariadb-server-10.1 . Eu não sinto que estou pronto para o grande passo e mudando para o MariaDB, eu prefiro ficar com o mysql 5.6 ou - melhor ainda - 5.7. o que você recomendaria - usando 5.7 do repositório instável do debian? indo com os pacotes fornecidos pelo oracle ? algumas outras opções?

obrigado!

    

Answer 1

A menos que você esteja usando recursos específicos de 5.6 +, então o mariadb é, para todos os efeitos, totalmente compatível.

Ou, como o artigo da wikipedia sobre mariadb é :

MariaDB version numbers follow the MySQL's numbering scheme up to version 5.5. Thus, MariaDB 5.5 offers all of the MySQL 5.5 features

Tenha em mente também que o principal desenvolvedor do mariadb é o Monty - autor original do mysql.

A menos que você esteja preocupado com o suporte para o código que você escreveu especificamente para o mysql 5.6+, então eu não acho que exista uma razão convincente para evitar o mariadb (além do gosto pessoal e possivelmente das opções de suporte).

Se você precisa de recursos 5.6+, sugiro que verifique se suas necessidades específicas são suportadas (e possivelmente, avalie o 'custo' de fazer algumas alterações).

A maioria das coisas que 'requerem' o mysql que eu executei ou instalei, por alguns anos, parecem ser inteiramente felizes em usar o mariadb, e o mariadb tem uma intenção explícita de ser um drop-in para o (agora) Oracle MySQL

Você não menciona as preocupações que você tem sobre a mudança, mas eu sugiro que você pelo menos considere reavaliar seus medos sobre o MariaDB - além de tudo, você pode achar que torna a sua vida mais fácil de usar as opções padrão da sua distro escolhida do que a necessidade de lidar com alternativas de integração.

    

Answer 2

Parece não haver nenhuma razão técnica para você não prosseguir com os pacotes fornecidos pela Oracle (eles se comprometeram a publicar pacotes stretch do Debian). Claro, existem vários ângulos não técnicos que levaram muitos usuários para o MariaDB, e você também pode querer fatorá-los. Mas isso é serverfault, e prefiro ver perguntas e respostas sendo escritas em torno de questões técnicas, em vez de questões políticas.

Se a mudança para o MariaDB for um "grande passo" técnico (incomum, mas possível ...), fique no MySQL 5.6 ou leve o "pequeno passo" para 5.7. A devida diligência é necessária aqui ...

As escolhas de distro poupam o seu trabalho de configuração, mas esse é o seu ÚNICO valor acrescentado. Eu normalmente não atribuo muita importância a isso, em última análise, é uma escolha de Ops. No mundo DevOps, costumo escolher as ferramentas que tornam os desenvolvedores / testadores mais felizes e produtivos, e confio em Ops para poder implantar, mesmo às custas de "mais horas de configuração" (normalmente um evento , em vez de uma atividade contínua como dev / test).

Dois centavos extras:

1. Não deixe a preguiça definir seu ambiente. Verifique o MariaDB!

2. Fique longe dos repositórios instáveis. Na maioria das vezes eles estão OK, mas o banco de dados não é algo que você deseja usar sem "olhos suficientes".

Answer 3

Maria e Percona são substitutas do MySQL. Mudar do MySQL para o Maria seria um passo menor do que atualizar para uma versão mais nova do MySQL, particularmente se você estiver usando um mecanismo de armazenamento não padrão. (O InnoDB tornou-se o padrão a partir da versão 5.5.5; MyISAM era o padrão antes disso.)

Maria afirma ser uma substituta do MySQL. link

A Wikipedia migrou do MySQL para o MariaDB. link

O Google migrou do MySQL para o MariaDB. link

A Red Hat usa o MariaDB em vez do MySQL. link

O SUSE Enterprise Linux usa o MariaDB em vez do MySQL. link

Arch usa MariaDB em vez do MySQL. link

Esta pergunta pode ser uma candidata para o link .

A Oracle Corporation tem interesse em impedir que software de banco de dados de código aberto interfira em seu produto comercial. Só isso não é motivo para desconfiar do MySQL, mas é um fato notável.