XOOPS Brasil

 

2.5. Atualizando/Desatualizando o MySQL

Antes de fazer uma atualização, você deve fazer o backup de seus bancos de dados antigos.

Você sempre pode mover os arquivos de formato e de dados do MySQL entre diferentes versões na mesma arquitetura enquanto você tiver versão base do MySQL. A versão base atual é 4. Se você alterar o conjunto de caracteres quando executar o MySQL, você deve executar myisamchk -r -q --set-character--set=charset em todas tabelas. De outra forma seus índices podem não ser corretamente ordenados, porque alterar o conjunto de caracteres também pode alterar a ordenação.

Se você tem receio de novas versões, você sempre pode renomear seu antigo mysqld para algo como mysqld-'número-da-versão-antiga'. Se o seu novo mysqld comportar de maneira inesperada, você simplesmente pode desliga-lo e reiniciar com seu antigo mysqld!

Se depois de uma atualização, você tiver problemas com programas clientes recompilados como Commands out of sync ou ``core dumps'' inexperados, você provavelmente usou um arquivo de cabeçalho ou de biblioteca antigo na compilação de seus programas. Neste caso você deve conferir a data de seu arquivo mysql.h e da biblioteca libmysqlclient.a para verificar que eles são da nova distribuição MySQL. Se não, por favor, recompile seus programas!

Se você tiver problemas, como na inicialização do novo servidor mysqld ou caso você não consiga conectar sem uma senha, confira se o seu arquvo my.cnf é o mesmo da antiga instalação! Você pode conferir com isto: nome-programa --print-defaults. Se isto não produzir outra saída além do nome do programa, você tem um arquivo my.cnf ativo que está afetando a operacionalidade do servidor!

É uma boa idéia reconstruir e reinstalar o módulo Perl DBD-mysql sempre que instalar uma nova versão do MySQL. O mesmo se aplica para outras interfaces MySQL, como Python MySQLdb.

2.5.1. Atualizando da Versão 4.0 para 4.1

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

Alguns dos comportamentos do MySQL 4.1 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 MySQL 4.0 (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 MySQL 4.0 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 MySQL 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 4.1, você tem este resultado:

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

    No MySQL 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. Veja mais informações sobre isto na Capítulo 9, Conjunto de Caracteres Nacionais e Unicode. A informação do conjunto de caracteres é mostrada por SHOW CREATE TABLE e mysqldump. (O MySQL 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 MySQL 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. Veja mais informações sobre isto na Seção 4.9.7, “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 MySQL 4.1 a partir de uma versão mais nova do MySQL envolve os serguintes passos:

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 MySQL 4.1 tem um protocolo cliente/servidor extendido que oferece tais recursos como instruções preparadas e conjuntos de múltiplos resultados.) Veja mais informações sobre isto na Seção 12.1.4, “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 MySQL 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 Seção 4.3.11, “Hashing de Senhas no MySQL 4.1”.

2.5.2. Atualizando da Versão 3.23 para 4.0

Em geral, o que você deve fazer é atualizar para a versão 4.0 um versão mais nova do MySQL:

  • Após o upgrade, atualize a tabela de permissões para adicionar novos privilégios e recursos. O procedimento usa o script mysql_fix_privilege_tables e está descrito em Seção 2.5.6, “Atualizando a Tabela de Permissões”.

  • Edite qualquer script de inicialização ou arquivo de configuração para não utilizar nenhuma das opções obsoletas listadas posteriormente nesta seção.

  • Converta seua arquivos ISAM antigos para arquivos MyISAM com o comando: mysql_convert_table_format database. (Este é um script Perl; ele exige que o DBI esteja instalado). Paa converter a tabela em um dado banco de dados, use este comando:

    shell> mysql_convert_table_format database db_name
    

    Note que ele deve ser usado apenas se você usar se todas as tabelas em um dado banco de dados são ISAM ou MyISAM. Para evitar a conversão de tabelas de outros tipos para MyISAM, você pode listar explicitamente o nome de suas tabelas ISAM depois do nome do banco de dados na linha de comando. Você também pode executar uma instrução ALTER TABLE table_name TYPE=MyISAM para cada tabela ISAM para convertê-la para MyISAM.

    Para descobir o tipo de uma determinada tabela, use esta instrução:

    mysql> SHOW TABLE STATUS LIKE 'tbl_name';
    
  • Certifique-se de que você não tem nenhum cliente MySQL que utiliza bibliotecas compartilhadas (com o Perl DBD-mysql). Se você tiver, você deve recompilá-las já que as estruturas usadas em libmysqlclient.so foram alteradas. O mesmo se aplica a outras interfaces MySQL, como Python MySQLdb.

O MySQL 4.0 funcionará mesmo se você não fizer o acima, mas você não poderá usar os novos privilégios de segurança pois o MySQL 4.0 e você podem encontrar problemas ao atualizar o MySQL para a versão 4.1 ou mais nova. O formato do arquivo ISAM ainda funciona no MySQL 4.0 mas está obsoleto e será disabilitado (não compilado por padrão) no MySQL 4.1. Em vez disso deve se usar tabelas MyISAM.

Clientes antigos devem funcionar com um servidor versão 4.0 sem nenhum problema.

Mesmo se você fizer o indicado acima, você ainda pode voltar para o MySQL 3.23.52 ou mais novo se você encontrar problemas com o MySQL da série 4.0. Neste caso você deve usar o mysqldump para fazer um dump de qualquer tabela que use um índice full-text e recarregar o arquivo de dump no servidor 3.23 (pois o 4.0 usa um novo formato para índices full-text).

A seguir está uma lista mais completa com o que deve ser observado para atualizar para a versão 4.0;

  • O MySQL 4.0 tem vários novos privilégios na tabela mysql.user. Veja mais informações sobre isto na Seção 4.4.1, “A Sintaxe de GRANT e REVOKE.

    Para fazer estes novos privilégios funcionarem, deve se atualizar a tabela de permissões. O procedimento está descrito em Seção 2.5.6, “Atualizando a Tabela de Permissões”. Até que este script esteja executando todos os utilizadores têm os privilégios SHOW DATABASES, CREATE TEMPORARY TABLES e LOCK TABLES. Os privilégios SUPER e EXECUTE tiram o seu valor de PROCESS. REPLICATION SLAVE e REPLICATION CLIENT tiram o seu valor de FILE.

    Se você tiver qualquer script que crie novos utilizadores, você pode querer alterá-los para usar os novos privilégios. Se você não está usando o comando GRANT nos scripts, este é um bom momento para alterar os seus scripts e usar GRANT em vez de modificar a tabela de permissões diretamente.

    A partir da versão 4.0.2 a opção --safe-show-database está obsoleta (e não faz mais nada). Veja mais informações sobre isto na Seção 4.3.3, “Opções de Inicialização para o mysqld em Relação a Segurança.”.

    Se você receber um erro Access denied para novos utilizadores na versão 4.0.2, você deve verificar se você precisa de alguma das novas concessões que você não precisava antes. Em particular, você precisará REPLICATION SLAVE (em vez de FILE) para novos slaves.

  • safe_mysqld é renomeado para mysqld_safe. Para compatibilidade com versões anteriores, as distribuições binárias, irão, por algum tempo, incluir safe_mysqld como um link simbólico para mysqld_safe.

  • Suporte para InnoDB agora está incluído na distribuição binária. Se você contruir o MySQL a partir de um fonte, o InnoDB está configurado por padrão, Se você não usar o InnoDB e quiser economizar memória ao executar o servidor que possui suorte a InnoDB habilitado, use a opção de inicialização do servidor. Para compilar o MySQL sem suporte ao InnoDB, execute configure com a opção --without-innodb.

  • O parâmetro de inicialização myisam_max_extra_sort_file_size e myisam_max_extra_sort_file_size são dados agora em bytes. (eram dados em megabytes antes da versão 4.0.3).

    O lock de sistema externo dos arquivos MyISAM/ISAM agora está desligado por padrão. Pode se ligá-los fazendo --external-locking. (Para a maioria dos utilizadores isto nunca é necessário).

  • A seguintes variáveis/opções de inicializaçao foram renomeadas:

    Nome AntigoNovo Nome.
    myisam_bulk_insert_tree_sizebulk_insert_buffer_size
    query_cache_startup_typequery_cache_type
    record_bufferread_buffer_size
    record_rnd_bufferread_rnd_buffer_size
    sort_buffersort_buffer_size
    warningslog-warnings
    --err-log--log-error (para mysqld_safe)

    As opções de inicialização record_buffer, sort_buffer e warnings ainda funcionarão no MySQL 4.0 mas estãp obsoletas.

  • As seguintes veriáveis SQL mudaram o nome.

    Nome AntigoNovo Nome.
    SQL_BIG_TABLESBIG_TABLES
    SQL_LOW_PRIORITY_UPDATESLOW_PRIORITY_UPDATES
    SQL_MAX_JOIN_SIZEMAX_JOIN_SIZE
    SQL_QUERY_CACHE_TYPEQUERY_CACHE_TYPE

    Os nomes antigos ainda funcionam no MySQL 4.0 mas estão obsoletos.

  • Você deve usar SET GLOBAL SQL_SLAVE_SKIP_COUNTER=# em vez de SET SQL_SLAVE_SKIP_COUNTER=#.

  • As opções de inicialização --skip-locking e --enable-locking foram renomeadas para --skip-external-locking e --external-locking.

  • SHOW MASTER STATUS agora retorna um conjunto vazio se o log binário não estiver habilitado.

  • SHOW SLAVE STATUS agora retorna um conjunto vazio se o slave não está inicializado.

  • O mysqld agora tem a opção --temp-pool habilitada por padrão já que isto da melhor rendimento com alguns SO (Principalmente no Linux).

  • Colunas DOUBLE e FLOAT agora respeitam o parâmetro UNSIGNED no armazenamento (antes, UNSIGNED era ignortado por estas colunas).

  • ORDER BY coluna DESC ordena valores NULL por último, como no MySQL 4.0.11. Na versão 3.23 e anteriores da versão 4.0, isto nem sempre era consistente.

  • SHOW INDEX tem duas colunas a mais (Null e Index_type) que ele tinha nas versões 3.23.

  • CHECK, SIGNED, LOCALTIME e LOCALTIMESTAMP são agora palavras reservadas.

  • O resultado de todos os operadores bitwise (|, &, <<, >> e ~) agora são unsigned. Isto pode causar problemas se você estiver usando-as em um contexto onde você quer um resultado com sinal. Veja mais informações sobre isto na Seção 6.3.5, “Funções de Conversão”.

  • Nota: quando você usa subtração entre valores inteiros onde um deles é do tipo UNSIGNED, o resultado será sem sinal. Em oyras palavras, antes de atualizar para o MySQL 4.0, você deve verificar sua aplicação para os casos onde você está subtraindo um valor de uma entidade sem sinal e quer um número negativo como resposta ou subtraindo um valor sem sinal de uma coluna do tipo inteiro. Você pode disabilitar este comportamento usando a opção --sql-mode=NO_UNSIGNED_SUBTRACTION ao iniciar o mysqld. Veja mais informações sobre isto na Seção 6.3.5, “Funções de Conversão”.

  • Para usar MATCH ... AGAINST (... IN BOOLEAN MODE) com suas tabelas, você precisa recontruí-las com REPAIR TABLE nome_tabela USE_FRM.

  • LOCATE() e INSTR() são caso sensitivo se um dos argumentos é uma string binária. De outra forma elas são caso-insensitivo.

  • STRCMP() agora usa o conjunto de caracteres atual ao fazer comparações, o que significa que o comportamento padrão das comparações agora é caso-insensitivo.

  • HEX(string) agora retorna os caracteres na string convertidos para hexadecimal. Se você quiser converter um número para hexadecimal, você deve se assugurar que você chama HEX() com um argumento numérico.

  • Na versão 3.23, INSERT INTO ... SELECT sempre tem o IGNORE habilitado. Na versão 4.0.1, o MySQL irá parar (e possívelmente fazer um roll back) por padrão no caso de mysqld_safe ser renomeado para mysqld_safe. Por algum tempo incluiremos em nossa distribuição binária o mysqld_safe como um link simbólico para mysqld_safe.

  • um erro se você não especificar IGNORE.

  • As funções antigas da API C mysql_drop_db(), mysql_create_db() e mysql_connect() não sã mais suportadas a menos que você compile o MySQL com CFLAGS=-DUSE_OLD_FUNCTIONS. No entanto, é preferível alterar o cliente para utilizar a nova API 4.0.

  • Na estrutura MYSQL_FIELD, length e max_length foram alterados de unsigned int para unsigned long. Isto não deve causar problemas, exceto que eles podem gerar mensagens de avisos quando quando usado como argumento em uma classe printf() de funções.

  • Você deve usar TRUNCATE TABLE quando quiser deletar todos os registros de uma tabela e você não precisa obter uma contagen de quantas colunas forma deletadas. (DELETE FROM table_name retorna a contagem de linhas na versão 4.0, e TRUNCATE TABLE é mais rápido.)

  • Você receberá um erro se tiver um LOCK TABLES ativo ou transações ao tentar executar TRUNCATE TABLE ou DROP DATABASE.

  • Você deve usar inteiros para armazenar valores em colunas BIGINT (em vez de usar strings, como você fez no MySQL 3.23). Usar strings ainda funicona, mas usar inteiros é mais eficiente.

  • O formato de SHOW OPEN TABLE alterou.

  • Clientes multi-thread devem usar mysql_thread_init() e mysql_thread_end(). Veja mais informações sobre isto na Seção 12.1.14, “Como Fazer um Cliente em Threads”.

  • Se você quiser recompilar o módulo Perl DBD::mysql, você deve conseguir o DBD-mysql versão 1.2218 ou mais novo porque os módulos DBD mais antigos usam a chamada obsoleta mysql_drop_db(). A versão 2.1022 ou mais nova é recomendada.

  • Na versão RAND(seed) retorna uma série de número randômicas diferente que na 3.23; isto foi feito para uma diferenciação maior de RAND(seed) e RAND(seed+1).

  • O tipo padrão retornado por IFNULL(A,B) agora está configurado para ser o mais 'geral' dos tipos de A e B. (A ordem geral-para-específco é string, REAL ou INTEGER).

Se você estiver executando o MySQL Server no Windows, veja Seção 2.5.8, “Atualizando o MySQL no Windows”. Se você estiver usando replicação, veja Seção 4.11.2, “Visão Geral da Implementação da Replicação”.

2.5.3. Atualizando da versão 3.22 para 3.23

A Versão 3.23 do MySQL suporta tabelas do novo tipo MyISAM e do antigo tipo ISAM. Você não necessita converter suas antigas tabelas para usá-las com a versão 3.23. Por padrão, todas novas tabelas serão criadas usando o tipo MyISAM (a menos que você inicie o mysqld com a opção --default-table-type=isam). Você pode converterr uma tabela ISAM para uma formato MyISAM com ALTER TABLE nome_tabela TYPE=MyISAM ou com o script Perl mysql_convert_table_format.

Os clientes versões 3.22 e 3.21 irão trabalhar sem quaisquer problemas com um servidor versão 3.23.

As seguintes listas dizem o que você deve conferir quando atualizar para a versão 3.23:

  • Todas tabelas que usam o conjunto de caracteres tis620 devem ser corrigidos com myisamchk -r ou REPAIR TABLE.

  • Se você fizer um DROP DATABASE em um banco de dados ligado simbolicamente, a ligação e o banco de dados original serão apagados. (Isto não acontece na 3.22 porque o configure não detecta a disponibilidade da chamada de sistema readlink).

  • OPTIMIZE TABLE agora funciona somente para tabelas MyISAM. Para outros tipos de tabelas, você pode usar ALTER TABLE para otimizar a tabela. Durante o OPTIMIZE TABLE a tabela é, agora, bloqueada para prevenir que seja usada por outras threads.

  • O cliente MySQL mysql é, agora, inicializado por padrão com a opção --no-named-commands (-g). Esta opção pode ser desabilitada com --enable-named-commands (-G). Isto pode causar problemas de imcompatibilidade em alguns casos, por exemplo, em scripts SQL que usam comandos sem ponto e vírgula! Comandos longos continuam funcionando.

  • Funções de data que funcionam em partes de datas (como MONTH()) não retornará 0 para datas 0000-00-00. (No MySQL 3.22 estas funções retornam NULL.)

  • Se você estiver usando a ordem de classificação de caracteres alemã para tabelas ISAM, você deve reparar todas suas tabelas com isamchk -r, porque foram feitas alterações na sua ordem de classificação!

  • O tipo padrão de retorno de IF() irá agora depender de ambos argumentos e não apenas do primeiro argumento.

  • Colunas AUTO_INCREMENT não devem ser usadas para armazenar números negativos. A razão para isto é que números negativos causam problemas quando o -1 passa para 0. Você não deve armazenar 0 em uma coluna AUTO_INCREMENT também; CHECK TABLE irá reclamar sobre valores 0 porque eles podem alterar se você fizer um dump e restaurar a tabela. AUTO_INCREMENT é, agora, tratado em um nível mais baixo para tabelas MyISAM e é muito mais rápido que antes. Para tabelas MyISAM números antigos também não são mais reusados, mesmo se você apagar algumas linhas da tabela.

  • CASE, DELAYED, ELSE, END, FULLTEXT, INNER, RIGHT, THEN e WHEN agora são palavras reservadas.

  • FLOAT(X) agora é um tipo de ponto flutuante verdadeiro e não um valor com um número fixo de decimais.

  • Quando estiver declarando colunas usando o tipo DECIMAL(tamanho,dec, o argumento tamanho não inclui mais um lugar para o símbolo do ponto decimal.

  • Uma string TIME agora deve estar em um dos seguintes formatos: [[[DAYS] [H]H:]MM:]SS[.fraction] ou [[[[[H]H]H]H]MM]SS[.fraction]

  • LIKE agora compara strings usando as mesmas regras de comparação de caracteres que o operador '='. Se você precisa do antigo compartamento, você pdoe compilar o MySQL com a opção CXXFLGAS=-DLIKE_CMP_TOUPPER.

  • REGEXP agora é caso insensitivo se nenhuma das strings forem binárias.

  • Quando for necessário dar manutenção ou reparar tabelas MyISAM .MYI deve ser usado a instrução CHECK TABLE ou o comando myisamchk. Para tabelas ISAM (.ISM), use o comando isamchk

  • Se desejar que os arquivos mysqldump sejam compatíveis entre as versões 3.22 e 3.23 do MySQL, não deve ser usados as opções --opt ou --full com o mysqldump.

  • Confira todas suas chamadas à DATE_FORMAT() para ter certeza que exista um ‘%’ antes de cada caractere formatador. (Versões mais antigas que o MySQL 3.22 aceitaivam esta sintaxe.)

  • mysql_fetch_fields_direct() agora é uma função (era uma macro) e ela retorna um ponteiro para um MYSQL_FIELD no lugar de um MYSQL_FIELD.

  • mysql_num_fields() não pode mais ser usada em um objeto MYSQL* (agora é uma função que obtem valores MYSQL_RES* como um argumento). Com um objeto MYSQL* agora voce deve usar mysql_field_count().

  • No MySQL Versão 3.22, a saída de SELECT DISTINCT ... era na maioria das vezes ordenada. Na Versão 3.23, você deve usar GROUP BY ou ORDER BY para obter a saída ordenada.

  • SUM() agora retorna NULL, em vez de 0 se não existir registros coincidentes. Isto é de acordo com o ANSI SQL.

  • Um AND ou OR com valores NULL agora retornam NULL no lugar de 0. Isto afetará, em grande parte, pesquisas que usam NOT em uma expressão AND/OR como NOT NULL = NULL.

  • LPAD() e RPAD() reduzirão a string resultante se ela for maior que o tamanho do argumento.

2.5.4. Atualizando da versão 3.21 para 3.22

Nada que afetaria a compatibilidade foi alterada entre a versão 3.21 e 3.22. A única dificuldade é que novas tabelas que são criadas com colunas do tipo DATE usarão a nova forma de armazenar a data. Você não pode acessar esses novos campos com uma versão antiga de mysqld.

Depois de instalar o MySQL versão 3.22, você deve iniciar o novo servidor e depois executar o script mysql_fix_privilege_tables. Isto adicionará os novos privilégios que você precisará para usar o comando GRANT. Se você se esquecer disto, sera retornado o erro Access denied quando você tentar usar ALTER TABLE, CREATE INDEX ou DROP INDEX. O procedimento para atualizar a tabela de permissões está descrito em Seção 2.5.6, “Atualizando a Tabela de Permissões”.

A interface API C para mysql_real_connect() foi alterada. Se você tem um programa cliente antigo que chama essa função, você deve colocar um 0 para o novo argumento db (ou recodificar o cliente para enviar o elemento db para conexões mais rápidas). Você também deve chamar mysql_init() antes de chamar mysql_real_connect()! Esta alteração foi feita para permitir à nova função mysql_options() salvar opções na estrutura do manipulador do MYSQL.

A variável key_buffer do mysqld foi renomeada para key_buffer_size, mas você ainda pode usar o antigo nome nos seus arquivos de inicialização.

2.5.5. Atualizando da versão 3.20 para 3.21

Se você estiver executando uma versão mais antiga que a Versão 3.20.28 e deseja mudar para a versão 3.21 você deve fazer o seguinte:

Inicie o servidor mysqld versão 3.21 com a opção --old-protocol para usá-lo com clientes de uma distribuição da versão 3.20 Neste caso, a nova função cliente mysql_errno() não irá retornar erro do servidor, somente CR_UNKNOWN_ERROR (mas isto funciona para erros de clientes) e o servidor usa a forma função password() anterior a 3.21 para verificação, ao invés do novo método.

Se você NÃO estiver usando a opção --old-protocol para mysqld, você precisará fazer as seguir alterações:

  • Todo o código cliente deve ser recompilado. Se você usa o ODBC, deve obter o novo driver MyODBC 2.x.

  • O script scripts/add_long_password deve ser executado para converter o campo Password na tabela mysql.user para CHAR(16).

  • Todas as senhas devem ser reatribuidas na tabela mysql.user (para obter 62-bits no lugar de senhas 31-bits).

  • O formato das tabelas não foi alterado, então não é preciso converter nenhuma tabela.

A versão do MySQL 3.20.28 e superiores podem manipular o novo formato da tabela de utilizadores sem afetar os clientes. Se você tem uma versão do MySQL mais nova que 3.20.28, senhas não irão mais funcionar se você converter a tabela de usuaios. Por segurança, você primeiro deve fazer uma atualização para a versão 3.20.28, pelo menos, e então atualizar para a versão 3.21.

O novo código cliente trabalha com um servidor mysqld 3.20.x, portanto se houver problemas com 3.21.x você deve usar o antigo servidor 3.20.x sem a necessidade de recompilar os clientes novamente.

Se você não está usando a opção --old-protocol para o mysqld, antigos clientes não poderão se conectar e exibirão a seguinte mensagem de erro:

ERROR: Protocol mismatch. Server Version = 10 Client Version = 9

A nova interface PERL DBI/DBD também suporta a antiga interface mysqlperl. A única alteração que deve ser feita se você usa o mysqlperl é alterar os argumentos para a função connect(). Os novos argumentos são: host, database, user, password (note que os argumentos user e password foram alterados de lugar). Veja mais informações sobre isto na Seção 12.5.2, “A interface DBI.

As seguintes alterações podem afetar consultas em antigas aplicações:

  • HAVING deve ser especificada antes de qualquer cláusula ORDER BY.

  • Os parâmetros para LOCATE() foram trocados.

  • Agora existem algumas palavras reservadasi novas. As mais notáveis são DATE TIME e TIMESTAMP.

2.5.6. Atualizando a Tabela de Permissões

Algumas distribuições introduzem alterações a estrutura da tabelas de permissões (a tabela no banco de dados mysql) para adicionar novos privilégios ou recursos. Para ter certeza de que as suas tabelas de permissões estão corretas quando você atualizar para uma nova versão do MySQL, você deve atualizar a sua tabela de permissão também.

Em sistemas Unix ou semelhantes, atualize a tabela de permissões executando o script mysql_fix_privilege_tables:

shell> mysql_fix_privilege_tables

Você deve executar este script enquanto o servidor está em execução. Ele tenta se conectar ao servidor na máquina local como root. Se sua conta root exige uma senha, indique a senha na linha de comando. Para o MySQL 4.1 e acima, especifique a senha assim:

shell> mysql_fix_privilege_tables --password=senha_root

Antes do MySQL 4.1, especifique a senha desta forma:

shell> mysql_fix_privilege_tables senha_root

O script realiza mysql_fix_privilege_tables qualquer ação necessária para converter sua tabela de permissões para o formato atual. Você pode ver alguns avisos Duplicate column name, durante a execução, eles podem ser ignorados.

Depois de executar o script, pare o servidor e o reinicie.

No Windows, não existe uma modo fácil de se atualizar a tabela de permissões até o MySQL 4.0.15. A partir desta versão, as distribuições do MySQL incluem um script SQL mysql_fix_privilege_tables.sql que você pode executar usando o cliente mysql. Se sua instalação do MySQL está localizada em C:\mysql, o comando se parecerá com este:

C:\mysql\bin> mysql -u root -p mysql
mysql> SOURCE C:\mysql\scripts\mysql_fix_privilege_tables.sql

Se sua instalação está localizada em algum outro diretório, ajuste o caminha apropriadamente.

O comando irá lhe pedir a senha do root; digite-a quando pedido.

Como no procedimento com o Unix, você pode ver alguns avisos Duplicate column name enquanto o mysql processa as instruções no script mysql_fix_privilege_tables.sql; eles podem ser ignorados.

Depois de executar o script, para o servidor e reinicie-o.

2.5.7. Atualizando para outra arquitetura

Se você estiver usando o MySQL Versão 3.23, você pode copiar os arquivos .frm, .MYI e .MYD para tabelas MyISAM entre diferentes arquiteturas que suportem o mesmo formato de ponto flutuante. (O MySQL cuida de cada detalhe de troca de bytes.) Veja mais informações sobre isto na Seção 7.1, “Tabelas MyISAM.

Os arquivos ISAM de dados e índices (*.ISD e *.ISM respectivamente) são dependentes da arquitetura e em alguns casos dependentees do Sistema Operacional. Se você deseja mover suas aplicações para outra máquina que tem uma arquitetura ou SO diferentes da sua máquina atual, você não deve tentar mover um banco de dados simplesmente copiando os arquivos para a outra máquina. Use o mysqldump.

Por padrão, o mysqldump irá criar um arquivo contendo declarações SQL. Você pode então transferir o arquivo para a outra máquina e alimentá-la como uma entrada para o cliente mysql.

Utilize mysqldump --help para ver quais opções estão disponíveis. Se você está movendo os dados para uma versão mais nova do MySQL, você deve usar mysqldump --opt com a nova versão para obter uma descarga rápida e compacta.

A mais fácil (mas não a mais rápida) forma para mover um banco de dados entre duas máquinas é executar os seguintes comandos na máquina em que o banco de dados se encontra:

shell> mysqladmin -h 'nome da outra maquina' create nome_bd
shell> mysqldump --opt nome_bd \
| mysql -h 'nome da outra maquina' nome_bd

Se você deseja copiar um banco de dados de um máquina remota sobre uma rede lenta, pode ser usado:

shell> mysqladmin create nome_bd
shell> mysqldump -h 'nome de outra maquina' --opt --compress nome_bd \
| mysql nome_bd

O resultado pode também ser armazenado em um arquivo, depois transfira o arquivo para a máquina destino e carregue o arquivo no banco de dados. Por exemplo você pode descarregar um banco de dados para um arquivo na máquina origem desta forma:

shell> mysqldump --quick nome_bd | gzip > nome_bd.contents.gz

(O arquivo criado neste exemplo está compactado.) Transfria o arquivo contendo o conteúdo do banco de dados para a máquina destino e execute estes comandos:

shell> mysqladmin create nome_bd
shell> gunzip < nome_bd.contents.gz | mysql nome_bd

Também pode ser usado mysqldump e mysqlimport para ajudar na transferência do banco de dados. Para grandes tabelas, isto é muito mais rápido do que usar simplesmente mysqldump. Nos comandos abaixo, DUMPDIR representa o caminho completo do diretório que você utiliza para armazenar a saída de mysqldump.

Primeiro, crie o diretório para os arquivos de saída e descarregue o banco de dados:

shell> mkdir DUMPDIR
shell> mysqldump --tab=DUMPDIR nome_bd

Depois transfira os arquivo no diretório DUMPDIR para algum diretório correspondente na máquina destino e carregue os arquivos no MySQL assim:

shell> mysqladmin create nome_bd # cria o banco de dados
shell> cat DUMPDIR/*.sql | mysql nome_bd # cria tabelas no banco de dados
shell> mysqlimport nome_bd DUMPDIR/*.txt # carrega dados nas tabelas

Não se esqueça de copiar o banco de dados mysql também, porque é nele que as tabelas de permissões (user, db e host) são armazenadas. Você pode ter que executar comandos como o utilizador root do MySQL na nova máquina até que você tenha o banco de dados mysql no lugar.

Depois de importar o banco de dados mysql para a nova máquina, execute mysqladmin flush-privileges para que o servidor recarregue as informações das tabelas de permissões.

2.5.8. Atualizando o MySQL no Windows

Qaundo atualizar o MySQL no Windows, siga os passo abaixo:

  1. Faça o download do última distribuição MySQL do Windows.

  2. Escolha uma hora do dia com pouco uso, onde a parada para manutenção é aceitável.

  3. Alerte os utilizadores que ainda estão ativos para sua parada de manutenção.

  4. Pare o Servidor MySQL em execução (por exemplo, com NET STOP mysql ou com o utilitário de Serviços se você estiver exeutando MySQL como um serviço, ou com mysqladmin shutdown).

  5. Finalize o programa WinMySQLAdmin se ele estiver em execução.

  6. Execute o script de instalação do arquivo de distribuição do Windows, clicando no botão "Install" no WinZip e seguindo os passos da instalação do script.

  7. Você pode sobrescrever a sua instalação antiga do MySQL (normalmente em C:\mysql), ou instalá-la em um diretório diferente, como C:\mysql4. Sobrescrever a instalação antiga é o recomendado.

  8. Reinicie o serviço MySQL Server (por exemplo, com NET START mysql se você executar o MySQL como um serviço, ou chamado o mysqld diretamente).

  9. Atualize a tabela de permissões. O procedimento está descrito em Seção 2.5.6, “Atualizando a Tabela de Permissões”.

Situações de erros possíveis:

A system error has occurred.
System error 1067 has occurred.
The process terminated unexpectedly.

Este erro significa que seu arquivo my.cnf (por padrão C:\my.cnf) contém uma opção que não pode ser reconhecido pela MySQL. Você pode verificar que este é o caso tentando reiniciar o MySQL com o arquivo my.cnf renomeado, por exemplo, para my_cnf.old para prevenirt o servidor de usá-lo. Uma vez verificado isto, você precisa identificar qual parâmetro é o culpado. Crie um novo arquivo my.cnf e mova as partes do arquivo antigo para ele (reiniciando o servidor depois de mover cada parte) até que você determine qual opção está fazendo a inicialização do servidor falhar.