Atualizando da Versão 4.0 para 4.1

Varias comportamentos visíveis foram alteradas entre o MariaDB e o MariaDB para corrigir erros críticos e tornar o MariaDB mais compatível com o padrão ANSI SQL. Estas alterações podem afetar à sua aplicação.

Alguns dos comportamentos do MariaDB no 4.0 podem ser testados antes de realizar uma atualização completa para a versão 4.1, adicionamos às últimas distribuições do MariaDB (a paritr da 4.0.12) a opção de inicialização --new para o mysqld.

Esta opção lhe dá o comportamento da versão 4.1 para as alterações mais críticas. Você também pode habilitar estes comportamentos para a conexão de uma determinado cliente com o comando SET @@new=1, ou desabilitá-lo se ele for iniciado com SET @@new=0.

Se você acredita que algumas das alterações da versão 4.1 o afetarão, recomendamos que antes de atualizar para a versão 4.1, você faça o download da última distribuição do MariaDB e o execute com a opção --new adicionando o seguinte ao seu arquivo de configuração:

[mysqld-4.0]
new

Deste modo você pode testar o novo comportamento com seus aplicativos na versão 4.0 para certificar-se que eles funcionam. Isto o ajudará a ter uma transição suave quando realizar uma atualização completa do MariaDB 4.1. Fazendo isto do modo acima irá assegurar que você não execute acidentalemte a versão 4.1 com a opção --new mais tarde.

A seguinte lista descreve alterações que podem afetar aplicações e que você deve observar ao atualizar para a versão 4.1:

• TIMESTAMP agora é retornado como uma string com o formato 'YYYY-MM-DD HH:MM:SS'. (A opção --new pode ser usada a partir da versão 4.0.12 para fazer um servidor 4.0 se comportar como 4.1 a este respeito.) Se você quiser tê-lo com um número (como a Versão 4.0 faz) deve-se adicionar +0 a coluna TIMESTAMP a eles:

  mysql> SELECT ts_col + 0 FROM tbl_name;
  

  Tamanhos de display para TIMESTAMP não são mais suportados. Por exemplo, se você declarar um coluna como TIMESTAMP(10), o (10) é ignorado.

  Esta mudança era necessária para compatibilidade com os padrões SQL. Em uma versão futura. Em uma versão futura, uma alteração adicional será feita (compatível com versões anteriores com esta mudaça), permitindo que o tamanho do timestamp indique o número desejado de dígitos de frações de um segundo.

• Valores binários (0xFFDF) agora são assumidos como strings em vez de números. Isto corrige o problema com conjunto de caracteres onde é conveniente colocar a string como um valor binário. Com esta alteração você deve usar CAST() se você quiser comparar valores binários numericamente como inteiros:

  SELECT CAST(0XFEFF AS UNSIGNED INTEGER) < CAST(0XFF AS UNSIGNED INTEGER)
  

  Se você não usa CAST(), uma comparação lexicográfica da string será feita:

  mysql> SELECT 0xFEFF < 0xFF;
   -> 1
  

  Usando itens binários em um contexto numérico ou comparando-os usando o operador = deve funcionar como antes. (A opção --new pode ser usado para fazer o servidor 4.0 se comportar como 4.1 a partir da versão 4.0.13.)

• Para funções que produzem um valor DATE, DATETIME, ou TIME, o resultado retornado para o cliente agora está corrigido para ter um tipo temporal. Por exemplo, no MySQL, você tem este resultado:

  mysql> SELECT CAST('2001-1-1' as DATETIME);
   -> '2001-01-01 00:00:00'
  

  No MariaDB 4.0, o resultado é diferente:

  mysql> SELECT CAST('2001-1-1' as DATETIME);
  -> '2001-01-01'
  

• Valores DEFAULT não podem mais ser especificado para colunas AUTO_INCREMENT (Na versão 4.0, um valor DEFAULT é ignorado sem aviso, na 4.1 ocorre um erro).
• LIMIT não aceita mais argumentos negativos. Use 18446744073709551615 em vez de -1.
• SERIALIZE não é mais uma opção válida para sql_mode. Deve-se usar SET TRANSACTION ISOLATION LEVEL SERIALIZABLE. SERIALIZE também não é mais válido para a opção --sql-mode do mysqld. Use --transaction-isolation=SERIALIZABLE
• Todas tabelas e colunas strings agora têm um conjunto de caracter. Leia Conjunto de Caracteres Nacionais e Unicode. A informação do conjunto de caracteres é mostrada por SHOW CREATE TABLE e mysqldump. (O MariaDB versão 4.0.6 e acima pode ler o novo arquivo dump; versões mais antigas não podem.)
• O formato de definição de tabela usado nos arquivos .frm mudaram um pouco na versão 4.1. O MariaDB 4.0.11 e adiante leêm o novo formato .frm diretamente, mas versões mais antigas não podem. Se você precisa mover tabelas da versão 4.1. para uma mais nova que a 4.0.11, você de usar mysqldump. Leia "mysqldump, Descarregando a Estrutura de Tabelas e Dados".
• Se você estiver executando vários servidores na mesma máquina Windows, você deve usar uma opção --shared_memory_base_name diferentes para cada máquina
• A interface para agrupar funções UDF alterou um pouco. Você deve agora declarar uma função xxx_clear() para cada função de agrupamento.

Em geral, atualizar para o MariaDB a partir de uma versão mais nova do MariaDB envolve os serguintes passos:

• Verifique na seção de alterações se houve alguma mudança que pode afetar a sua aplicação.
• Leia os novos itens da versão 4.1 para ver quais itens interessantes que você pode usar na versão 4.1. Leia Seção D.2, "Alterações na distribuição 4.1.x (Alpha)".
• Se você estiver executando o MariaDB Server no Windows, veja também "Atualizando o MariaDB no Windows".
• Após o upgrade, atualize a tabela de permissões para gerar uma nova coluna Password maior que é necessária para tratamento seguro de senhas. O procedimento usa mysql_fix_privilege_tables e está descrito em "Atualizando a Tabela de Permissões". Estratégias alternativas para tratamento de senhas depois de uma atualização estão descritos posteriormente nesta seção.

O mecanismo de hashing da senha foi alterado na versão 4.1 para fornecer maior segurança, mas ele pode causar problemas de compatibilidade se você ainda tiver clientes que usam a biblioteca cliente 4.0 ou anterior. (É bastante indesejável que você tenha clientes 4.0 em situações onde o cliente conecta de uma máquina remota que ainda não tenha sido atualizada para a versão 4.1). A seguinte lista indica algumas estratégias possíveis de atualização. Elas representam o que se deve fazer para escolher se ter compatibilidade com clientes antigos e ter maior segurança.

• Não atualizar para a versão 4.1. Nenhum comportamento será alterado, mas é claro que você não poderá usar qualquer um dos novos recursos fornecido pelo protocolo cliente/servidor da versão 4.1. (O MariaDB tem um protocolo cliente/servidor extendido que oferece tais recursos como instruções preparadas e conjuntos de múltiplos resultados.) Leia "Instruções Preparadas da API C".
• Atualizar para a versão 4.1 e executar o script mysql_fix_privilege_tables para aumentar a coluna Password na tabela user e assim poder guardar hashes de senhas longos. Mas execute o servidor com a opção --old-passwords para fornecer compatibilidade com versões anteriores que premitem que clientes pre-4.1 continuem a conectar em suas contas de hash curto. Eventualmente, quando todos os seus clientes estiverem atualizados para a versão 4.1, você pode parar de usar a opção do servidor --old-passwords. Você também pode alterar as senhas em sua conta MariaDB para usar o novo formato que é mais seguro.
• Atualizar para versão 4.1 e executar o script mysql_fix_privilege_tables para aumentar a coluna Password na tabela user. Se você sabe que todos os clientes também foram atualizados para a versão 4.1, não execute o servidor com a opção --old-passwords. Em vez disso, altere a senha em todas as contas existentes para que elas tenham o novo formato. Uma instalação pura da versão 4.1 é o mais seguro.

Informações adicionais sobre hashing de senha em relação a autenticação no cliente e operações de alteração de senha podem ser encontrados em "Hashing de Senhas no MariaDB 4.1".

Retornar