Índice
MD5 Checksums
ou GnuPG
Este capítulo descreve como obter e instalar o MySQL:
Para uma lista de sites no quais você pode obter o MySQL, veja Secção 2.2.1, “Como obter o MySQL”.
Para saber quais são as plataformas suportadas, veja em Secção 2.2.3, “Sistemas Operacionais suportados pelo MySQL”. Por favor perceba que nem todas as plataformas suportadas são igualmente boas para executar o MySQL. Algumas são mais robustas e eficientes que outras - ver Secção 2.2.3, “Sistemas Operacionais suportados pelo MySQL” para detalhes.
Várias versões do MySQL estão disponíveis em distribuições binárias e fonte. Nós também fornecemos acesso público à nossa árvore fonte atual para aqueles que desejam ver nossos desenvolvimentos mais recentes e nos ajudar a testar novos códigos. Para determinar que versão e tipo da distribuição você deve usar, veja Secção 2.2.4, “Qual versão do MySQL deve ser usada”. Se ainda restar dúvidas, use uma a distribuição binária.
Instruções de instalação para distribuições binária e fonte são descritos em Secção 2.2.9, “Instalando uma Distribuição Binária do MySQL” e Secção 2.3, “Instalando uma distribuição com fontes do MySQL”. Cada conjunto de instruções inclui uma seção sobre problemas específicos de sistemas que você pode precisar.
Para procedimentos pós-instalação, veja Secção 2.4, “Configurações e Testes Pós-instalação”. Estes procedimentos podem ser aplicados caso você use uma distribuição binária ou fonte do MySQL.
Este capítulo cobre a instalação do MySQL em plataformas onde oferecemos pacotes usando oformato de empacotamento nativo da respectiva plataforma. No entanto, as distribuições binárias do MySQL estão disponíveis para muitas outras plataformas, veja Secção 2.2.9, “Instalando uma Distribuição Binária do MySQL” para instruções gerais de instalação para estes pacotes que se aplicam a todas as plataformas.
Veja Secção 2.2, “Detalhes Gerais de Instalação” para mais informações sobre quais outras distribuições binárias estão disponíveis e como obtê-las.
O processo de instalação para o MySQL no Windows tem os seguintes passos:
Instale a distribuição.
Configure um arquivo de opção se necessário.
Selcione o servidor que você quer usar.
Inicie o servidor.
O MySQL para Windows está disponível em dois formatos de distribuição:
A distribuição binária contém um programa de instalação que instala que você precisa e assim possa iniciar o servidor imediatamente.
A distribuição fonte contém todo o código e os arquivos suportados para construir o executável usando o compilador VC++ 6.0. See Secção 2.3.7, “Instalando o MySQL a partir do Fonte no Windows”.
Geralmente, a melhor opção é a distribuição binária. É mais simples e você não precisa de nenhuma ferramenta adicional para ter o MySQL em execução.
Para executar o MySQL no Windows, você precisará do seguinte:
Um sistema operacional Windows de 32 bits como 9x, ME, NT, 2000 ou XP. A família NT (Windows NT, 2000 e XP) lhe permite executar o servidor MySQL como um serviço. See Secção 2.1.1.7, “Iniciando o MySQL no Windows NT, 2000, ou XP”.
Suporte ao protocolo TCP/IP.
Um cópia da distribuição binária do MySQL para Windows, o qual pode ser feito download em http://www.mysql.com/downloads/.
Nota: A distribuição de arquivos são fornecidas no formato zip e recomendamos o uso de um cliente FTP com opção de resumo para evitar corrompimento de arquivos durante o processo de download.
Um programa ZIP
para descompactar os
arquivos da distribuição.
Espaço suficiente em disco para descompactar, instalar e criar o banco de dados de acordo com suas exigências.
Se você planeja se conectar ao servidor MySQL via ODBC,
você também precisará do dirver
MyODBC
. See Secção 12.2, “Suporte ODBC ao MySQL”.
Se você precisa de tabelas com tamanho maior que 4GB,
instale o MySQL em um sistema de arquivos NTFS ou mais
novo. Não se esqueça de usar MAX_ROWS
e AVG_ROW_LENGTH
quando criar tabelas.
See Secção 6.5.3, “Sintaxe CREATE TABLE
”.
Para instalar o MySQL no Windows usando uma distribuição binária, siga este procedimento:
Se você estiver trabalhando em uma máquina Windows NT, 2000, ou XP, esteja certo de que você está logado com um usuário com privileios de administrador.
Se você estiver fazendo uma atualização de uma instalação MySQL mais nova, é necessário parar o servidor atual. Em máquinas com Windows NT, 200 ou XP, se você estiver executando o servidor como um serviço, pare-o com o comando:
C:\> NET STOP MySQL
Se você planeja usar um servidor diferente depois da
atualização (por exemplo, se você quiser executar o
mysqld-max
em vez do
mysqld
), remova o serviço existente:
C:\mysql\bin> mysqld --remove
Você pode reinstalar o serviço com o servidor próprio depois de atualizar.
Se você não estiver executando o servidor MySQL como um serviço, pare desta forma:
C:\mysql\bin> mysqladmin -u root shutdown
Finalize o programa WinMySQLAdmin
se
ele estiver em execução.
Descompacte os arquivos de distribuição em um diretório temporário.
Execute o programa setup.exe
para
iniciar o processo de instalação. Se você quiser
instalar em um diretório diferente do padrão
(c:\mysql
), use o botão
Browse
para especificar seu diretório
preferido. Se você não instalar o MySQL no local
padrão, você precisará epecificar o local onde você
inicia o servidor. O modo mais fácil de se fazer isto é
usar um arquivo de opção, como descrito em
Secção 2.1.1.3, “Preparando o Ambiente MySQL do Windows”.
Finalize o processo de instalação.
Se você precisar especificar opções de inicialização quando executar o servidor, você pode indentifica-los na linha de comando ou colocá-los em um arquivo de opção. Par opções que são usadas sempre que o servidor iniciar, você achará mais conveniente utilizar um arquivo de opcão para especificar a configuração do seu MySQL. Isto é particularmente verdade sob as seguintes circunstâncias:
A localização do diretório de instalação ou dados
são diferentes dos locais padrão
(c:\mysql
e
c:\mysql\data
).
Você precisa ajustar as configurações do servidor. Por
exemplo, para usar as tabelas transacionais
InnoDB
no MySQL versão 3.23, você
deve criar manualmente dois novos diretórios para guardar
os arquivos de dados e de log do InnoDB
--- por exemplo, c:\ibdata
e
c:\iblogs
. Você também poderá
adicionar algumas linhas extras ao arquivo de opção,
como descrito em Secção 7.5.3, “Opções de Inicialização do InnoDB”. (A partir
do MySQL 4.0, o InnoDB cria os seus arquivos de log e
dados no diretório de dados por padrão. Isto significa
que você não precisa configurar o InnoDB explicitamente.
Você ainda deve fazê-lo se desejar, e um arquivo de
opção será útil neste caso.)
No Windows, o instalador do MySQL coloca o diretório de dados
diretamente sob o diretório onde você instalou o MySQL. Se
você quisesse utilizar um diretório de dados em um local
diferente, você deve copiar todo o conteúdo do diretórios
data
para a nova localização. Por
exemplo, por padrão, o instalador coloca o MySQL em
C:\mysql
e o diretório de dados em
C:\mysql\data
. Se você quiser usar um
diretório de dados de E:\mydata
, você
deve fazer duas coisas:
Mova o diretório de dados de
C:\mysql\data
para
E:\mydata
.
Use uma opção --datadir
para
especificar a nova localização do diretório de dados
cada vez que você iniciar o servidor.
Quando o servidor MySQL inicia no Windows, ele procura pelas
opções em dois arquivos: O arquivo
my.ini
no diretório Windows e o arquivo
chamado C:\my.cnf
. O diretório do
Windows é normalmente chamado C:\WINDOWS
ou C:\WinNT
. Você pode determinar a sua
localização exata a partir do valor da variável de ambiente
WINDIR
usando o seguinte comando:
C:\> echo %WINDIR%
O MySQL procura pelas opções primeiro no arquivo
my.ini
, e então pelo arquivo
my.cnf
. No entanto, para evitar
confusão, é melhor se você usar apenas um destes arquivos.
Se o seu PC usa um boot loader onde o drive
C:
não é o drive de boot, sua única
opção é usar o arquivo my.ini
.
Independente de qual arquivo usar, ele deve ser no formato
texto.
Um arquivo de opção pode ser criado e modificado com
qualquer editor de texto como o programa
Notepad
. Por exemplo, se o MySQL está
instalado em D:\mysql
e o diretório de
dados está localizado em D:\mydata\data
,
você pode criar o arquivo de opção e definir uma seção
[mysqld]
para especificar valores para os
parâmetros basedir
e
datadir
:
[mysqld] # defina basedir com o seu caminho de instalação basedir=D:/mysql # defina datadir com o local do diretório de dados, datadir=D:/mydata/data
Note que os nome de caminho do Windows são específicados em arquivos de opção usando barras normais em ves de barra invertida. Se você usar barras invertidas, você deve usá-las em dobro.
Outro modo de se gerenciar um arquivo de opção é usar a
ferramenta WinMySQLAdmin
. Você pode
encontrar o WinMySQLAdmin
no diretório
bin
de sua instalação MySQL, assim como
um arquivo de ajuda contendo instruções para usá-lo. O
WinMySQLAdmin
tem a capacidade de editar os
seus arquivos de opção, mas note o seguinte:
WinMySQLAdmin
usa apenas o arquivo
my.ini
.
Se o WinMySQLAdmin
encontra o arquivo
C:\my.cnf
, ele o renomeará para
C:\my_cnf.bak
para disabilitá-lo.
Agora você está pronto para testar o servidor.
Iniciado com o MySQL 3.23.38, a distribuição Windows inclui ambos binários, normal e o MySQL-Max. Aqui está uma lista dos diferentes servidores MySQL dos quais você pode escolher:
Binario | Descrição |
mysqld | Compilado com debugger integral e conferência automática de alocação
de memória, links simbólicos, BDB
e tabelas InnoDB . |
mysqld-opt | Binário otimizado. A partir da versão 4.0 o InnoDB
está habilitado. Antes desta versão, este servidor
não tem suporte a tabelas transacionais. |
mysqld-nt | Binário otimizado para NT/2000/XP com suporte para named pipes. |
mysqld-max | Binário otimizado com suporte para links simbólicos, tabelas
BDB e InnoDB . |
mysqld-max-nt | Como o mysqld-max , porém compilado com suporte para
named pipes. |
Todos os binários acima são otimizados para processadores Intel modernos mas deve funcionar em qualquer processador Intel i386 ou melhor.
Os servidores mysqld-nt
e
mysqld-max-nt
suportam conexões named
pipe. Se você usar um destes servidores, o uso de named pipes
está sujeito a estas condições:
Os servidores devem ser executados em uma versão do Windows que suporte named pipes (NT, 2000, XP).
A partir da versão 3.23.50, named pipes só estarão
habilitados se você iniciar estes servidores com a
opção --enable-named-pipe
.
Os servidores podem ser executados no Windows 98 ou Me, mas o TCP/IP deve estar instalado, e as conexões named pipes não podem ser usadas.
No Windows 95, estes servidores não podem ser usados.
No Windows 95, 98, ou Me, cliente MySQL sempre se conecta ao servidor usando TCP/IP. Nos sistemas baseados no NT, como o Windows NT, 2000, ou XP, os clientes possuem duas opções. Eles podem usar TCP/IP, ou eles podem usar um named pipe se o servidor suportar conexões named pipes.
Para informações sobre qual servidor binário executar, veja Secção 2.1.1.3, “Preparando o Ambiente MySQL do Windows”.
Esta seção lhe dá um visão geral da inicialização de um servidor MySQL. A seguinte seção fornce informação mais específica para versões particulares do Windows.
Os exemplos nesta seção assumem que o MySQL está instalado
sob a localização padrão, C:\mysql
.
Ajuste o caminho mostrado nos exemplos se você tiver o MySQL
instalado em um local diferente.
Fazer um teste a partir do prompt de comando do em uma janela de console (uma janela ``DOS'') é a melhor coisa a fazer porque o servidor mostra a mensagem de status que aparece na janela do DOS. Se alguma coisa estiver errado com sua configuração, estas mensagens tornarão mais fácil para você de identificar e corrigir qualquer problema.
Tenha certeza que você está no diretório onde o servidor é localizado e então entre este comando:
shell> mysqld --console
Para servidores que incluem suporte InnoDB
,
você deve ver as seguintes mensagens assim que o servidor
iniciar:
InnoDB: The first specified datafile c:\ibdata\ibdata1 did not exist: InnoDB: a new database to be created! InnoDB: Setting file c:\ibdata\ibdata1 size to 209715200 InnoDB: Database physically writes the file full: wait... InnoDB: Log file c:\iblogs\ib_logfile0 did not exist: new to be created InnoDB: Setting log file c:\iblogs\ib_logfile0 size to 31457280 InnoDB: Log file c:\iblogs\ib_logfile1 did not exist: new to be created InnoDB: Setting log file c:\iblogs\ib_logfile1 size to 31457280 InnoDB: Log file c:\iblogs\ib_logfile2 did not exist: new to be created InnoDB: Setting log file c:\iblogs\ib_logfile2 size to 31457280 InnoDB: Doublewrite buffer not found: creating new InnoDB: Doublewrite buffer created InnoDB: creating foreign key constraint system tables InnoDB: foreign key constraint system tables created 011024 10:58:25 InnoDB: Started
Quando o servidor finaliza sua sequência de inicialização, você deve ver algo como abaixo, que indica que o servidor está pronto para o conexão com o cliente:
mysqld: ready for connections Version: '4.0.14-log' socket: '' port: 3306
O servidor continuará a gravar no console qualquer saída de diagnóstico adicional que ele produza. Você pode abrir uma nova janela de console na qual se executará os programas clientes.
Se você omitir a opção --console
, o
servidor grava a saída do diagnóstico no log de erro no
diretório de dados. O log de erro é o arquivo com a
extensão .err
.
No Windows 95, 98 ou Me, o MySQL usa TCP/IP para conectar um cliente a um servidor. (Isto permitirá que qualquer máquina na sua rede se conecte a seu servidor MySQL.) Por isto, você deve ter certeza de que o suporte TCP/IP está instalado na sua máquina antes de iniciar o MySQL. Você pode encontrar o TCP/IP no seu CD-ROM do Windows.
Note que se você estiver usando uma versão antiga do Win95 (por exemplo, OSR2). É preferível que você use um pacote antigo Winsock; para o MySQL é necessário o Winsock 2! Você pode obter o Winsock mais novo em http://www.microsoft.com. O Windows 98 tem a nova biblioteca Winsock 2, portanto não é necessário atualizar a biblioteca.
Para iniciar o servidor mysqld
, você deve
iniciar uma janela do Prompt (Janela ``MS-DOS'') e digitar:
shell> C:\mysql\bin\mysqld
Isto irá iniciar o mysqld
em segundo
plano. Isto é, depois do servidor iniciar, você deve ver
outro prompt de comando. (Note que se você iniciar o servidor
deste modo no Windows NT, 2000 ou XP, o servidor irá executar
em segundo plano e nenhum prompt de comando aparecerá até
que o servidor finalize. Por isto, você deve abrir outro
prompt de comando para executar programas clientes enquanto o
servidor estriver em execução.)
Você pode finalizar o servidor MySQL executando:
shell> C:\mysql\bin\mysqladmin -u root shutdown
Isto chama o utilitário administrativo do MySQL
mysqladmin
para conectar ao servidor e
manda-lo finalizar. O comando conecta como
root
que é a conta administrativa padrão
no sistema de permissões do MySQL. Por favor, note que o
sistema de permissões do MySQL é totalmente independente de
qualquer login de usuário sob o Windows.
Se o mysqld
não iniciar, por favor,
verifique o log de erro para ver se o servidor escreveu alguma
mensagem que possa indicar a causa do problema. Você pode
também tentar iniciar o servidor com mysqld
--console
; neste caso, você pode obter alguma
informação útil na tela que pode ajudar a resolver o
problema.
A última opção é iniciar o mysqld
com
--standalone --debug
. Neste caso o
mysqld
irá escrever em um arquivo log
C:\mysqld.trace
que deve conter a razão
pela qual o mysqld
não inicia. See
Secção E.1.2, “Criando Arquivos Trace (Rastreamento)”.
Use mysqld --help
para mostrar todas as
opções que o mysqld
entende!
Na família NT (Windows NT, 2000 ou XP) o modo recomendado de
executar o MySQL é instalá-lo como um serviço do Windows. O
Windows então inicia e para o servidor MySQL automaticamente
quando o Windows inicia e para. Um servidor instalado como um
serviço também pode ser controlado a partir da linha de
comando usando os comandos NET
, ou com o
utilitário gráfico Serviços
.
O utilitário Serviços
(o Service
Control Manager
do Windows) pode ser encontrado no
Painel de Controle
do Windows (em
Ferramentas Administrativas
no Windows
2000). É recomendado que se feche o utilitário
Serviços
enquanto realiza a operações de
instalação ou remoção do servidor a partir desta linha de
comando. Isto evita alguns erros estranhos.
Para ter o MySQL funcionando com TCP/IP no Windows NT 4, você deve instalar o service pack 3 (ou mais novo)!
Antes de instalar o MySQL como um serviço, você deve primeiro parar o servidor atual em execução usando o seguinte commando:
shell> C:\mysql\bin\mysqladmin -u root shutdown
Isto chama o utilitário administrativo do MySQL
mysqladmin
para conectar ao servidor e
mandá-lo parar. O comando conecta com root
que é a conta administrativa padrão no sistema de
permissões do MySQL. Por favor, note que o sistema de
permissões do MySQL é totalmente independente de qualquer
login de usuário sob o Windows.
Agora instale o servidor como um serviço:
shell> mysqld --install
Se você não definir um nome para o serviço, ele é
instalado com o nome MySQL
. Uma vez
instalado, ele pode ser imediatamente iniciado a partir do
utilitário Serviços
, ou usando o comando
NET START MySQL
. (Este comando é caso
insensitivo).
Uma vez em execução, o mysqld
pode ser
parado usando o utilitário de Serviços ou usando o comando
NET STOP MySQL
, ou o comando
mysqladmin shutdown
.
Se você tiver problemas instalando o
mysqld
como um servico usando apenas o nome
do servidor, tente instalá-lo usando seu caminho compelto:
shell> C:\mysql\bin\mysqld --install
A partir do MySQL 4.0.2, você pode especificaro nome do
serviço depois da opção --install
. A
partir do MySQL 4.0.3, você pode especificar uma opção
--defaults-file
depois do nome do serviço
para indicar onde o servidor deve obter opções ao iniciar. A
regras que determinam o nome do serviço e os arquivos de
opção que o servidor usa são as seguintes:
Se você não especificar um nome de serviço, o servidor
usa o nome padrão do MySQL
e o
servidor lê as opções do grupo
[mysqld]
no arquivo de opções
padrão.
Se você especificar um nome de serviço depois da opção
--install
, o servidor ignora o grupo de
opção [mysqld]
em vez de ler opções
do grupo que tem o mesmo nome que o serviço. O servidor
le opções do arquivo de opções padrão.
Se você especificar uma opção
--defaults-file
depois do nome de
serviço, o servidor ignora o arquivo de opções padrão
e lê opções apenas a partir do grupo
[mysqld]
do arquivo indicado.
Nota: Antes do MySQL 4.0.17,
um servidor instalado como um serviço do Windows tinha
problema na inicialização se o seu caminho ou nome do
serviço possuisse espaços. Por esta razão, evite instalar o
MySQL em um diretório como C:\Program
Files
ou usar um nome de serviço contendo espaço.
No caso normal que você instala o servidor com
--install
mas nenhum nome de serviço, o
servidor é instalado com um nome de serviço de
MySQL
.
Como um exemplo mais complexo, considere o seguinte comando:
shell> C:\mysql\bin\mysqld --install mysql --defaults-file=C:\my-opts.cnf
Aqui, um nome de serviço é dado depois de opção
--install
. Se nenhuma opção
--defaults-file
for dada, este comando teria
o efeito de fazer o servidor ler o grupo
[mysql]
a partir do arquivo de opções
padrão. (Isto seria uma má idéia, porque aquele grupoo de
opção é para ser usado pelo programa cliente
mysql
.) No entanto, como a opção
--defaults-file
está presente, o servidor
lê as opções apenas a partir do arquivo indicado, e apenas
do grupo de opção [mysqld]
.
Você também pode especificar as opções como
``Parâmetros de inicialização
'' no
utilitário de Serviços
do Windows antes
de você iniciar o serviço MySQL.
Uma vez que o servidor MySQL é instalado, o Windows irá
iniciar o serviço automaticamente sempre que o Windows
inicia. O serviço também pode ser iniciado imediatamente a
partir do utilitário Serviços
ou usando o
comando NET START MYSQL
. O comando
NET
não é caso sensitivo.
Note que quando executado como um serviço, o
mysqld
não têm acesso a um console e
então nenhuma mensagem pode ser vista. Se o
mysqld
não iniciar, verifique o log de
erros par ver se o servidor gravou alguma mensagem lá
indicando a causa do problema. O log de erro está localizado
no diretório c:\mysql\data
. É o arquivo
com um sufixo .err
.
Quando o mysqld
está executando como um
serviço, ele pode ser parado usando o utilitários
Serviços
, o comando NET STOP
MYSQL
, ou o comando mysqladmin
shutdown
. Se o serviçp estiver em execução quando
o Windows desliga, o Windows irá parar o servidor
automaticamente.
A partir do MySQL versão 3.23.44, você pode escolher entre
instalar o servidor como um serviço Manual
se você não deseja que os serviços sejam executados
automaticamente durante o processo de inicialização. Para
fazer isto, use a opção --install-manual
em
vez da opção --install
.
shell> C:\mysql\bin\mysqld --install-manual
Para remover um serviço que está instalado como um serviço,
primeiro pare-o se ele estiver em execução. Então use a
opção --remove
para removê-lo:
shell> mysqld --remove
Um problema com a finalização automática do serviço MySQL
é que, para versões do MySQL anteriores a 3.23.49, o Windows
esparava apenas por alguns segundos para o desligamento
completo, e matava os processos do servidor de banco de dados
se o tempo limite fosse excedido. Isto potencialmente causava
problemas. (Por exemplo, o mecanimo de armazenamento
InnoDB
deverá fazer uma recuperação de
falhas na próxima inicialização). A partir do MySQL
3.23.49, o Windows irá esperar mais para que a finalização
do MySQL Server esteja completa. Se você notar que ainda não
é o suficiente para a sua instalação, não é seguro
executar o MySQL Server como um serviço. Em vez disso,
execute-o a partir do prompt de comando, e finalize-o com
mysqladmin shutdown
.
A alteração para avisar para o Windows para esperar mais
quando parar o servidor MySQL funciona apenas com o Windows
2000 e XP, mas não para o Windows NT. No NT, o Windows espera
apenas 20 segundos para que o serviço seja finalizado, e
depois desso ele mata o processo do serviço. Você pode
aumentar este padrão abrindo o Editor de Registro
(\winnt\system32\regedt32.exe
) e editar o
valor de WaitToKillServiceTimeout
em
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control
na árvore do Registro. Especifique o novo valor mais largo em
milisegundos (por exemplo 12000 para que o Windows NT espere
até 120 segundos).
Se você não quiser iniciar o mysqld
como
um serviço, você pode iniciá-lo a partir da linha de
comando do mesmo modo que em versões do Windows que não são
baseados no NT. Para instruções use
Secção 2.1.1.6, “Iniciando o MySQL no Windows 95, 98, ou Me”.
O MySQL suporta TCP/IP em todas as plataformas Windows. Os
servidores mysqld-nt
e
mysql-max-nt
suportam named pipes no NT,
2000 e XP. No entanto, o padrão é usar TCP/IP, independente
da plataforma:
Named pipes é atualmente mais lento que TCP/IP em muitas configurações do Windows.
Alguns usuários encontraram problemas ao finalizar o servidor MySQL quando era usado named pipes.
A partir da versão 3.23.50, named pipes só está habilitado
para o mysqld-nt
e
mysql-max-nt
se eles forem iniciados com a
opção --enable-named-pipe
.
Você pode forçar que um cliente MySQL use named pipes
especificando a opção --pipe
ou
especificando .
como nome de máquina. Use
a opção --socket
para especificar o nome do
pipe. No MySQL 4.1, você deve usar a opção
--protocol=PIPE
.
Você pode testar se o MySQL está funcionando executando qualquer dos seguintes comandos:
C:\>C:\mysql\bin\mysqlshow
C:\>C:\mysql\bin\mysqlshow -u root mysql
C:\>C:\mysql\bin\mysqladmin version status proc
C:\>C:\mysql\bin\mysql test
Se o mysqld
está lento para responder a
suas conexões no Win95/Win98, provavelmente existe um
problema com seu DNS. Neste caso, inicie o
mysqld
com a opção
--skip-name-resolve
e use somente
localhost
e números IP na coluna
Host
das tabelas de permissões do MySQL.
Existem duas versões da ferramenta de linha de comando MySQL:
Binario | Descrição |
mysql | Compilado em Windows nativo, oferecendo capacidades de edição de texto muito limitadas. |
mysqlc | Compilado com o compilador Cygnus GNU, que oferece edição
readline . |
Se você desejar usar o mysqlc
, deve ter
uma cópia da biblioteca cygwinb19.dll
em
algum lugar que o mysqlc
possa
encontrá-la. Se sua distribuição do MySQL não tiver esta
biblioteca instalada no mesmo diretório que o
mysqlc
(o diretório bin
sob o diretório base sa dua instalação do MySQL). Se sua
distribuição não tem a biblioteca
cygwinb19.dll
no diretório
bin
, olhe no diretório
lib
para encontrá-lo e copiá-lo para o
seu diretório de sistema no Windows.
(\Windows\system
ou um lugar parecido).
Os privilégios padrões no Windows dão a todos usuários
locais privilégios totais para todos os bancos de dados sem
necessidade de especificar uma senha. Para deixar o MySQL mais
seguro, você deve configurar uma senha para todos os usuário
e remover a linha na tabela mysql.user
que
tem Host='localhost'
e
User=''
.
Você também deve adicionar uma senha para o usuário
root
. O exemplo seguinte exemplo inicia
removendo o usuário anônimo que tem todos os privilégios, e
então configura uma senha para o usuário
root
:
C:\>C:\mysql\bin\mysql mysql
mysql>DELETE FROM user WHERE Host='localhost' AND User='';
mysql>FLUSH PRIVILEGES;
mysql>QUIT
C:\>C:\mysql\bin\mysqladmin -u root password your_password
Depois de configurar a senha, se você desejar desligar o
servidor mysqld
, você pode usar o seguinte
comando:
C:\> mysqladmin --user=root --password=sua_senha shutdown
Se você estiver usando o servidor de uma antiga versão
shareware do MySQL versão 3.21m o comando
mysqladmin
para configurar uma senha irá
falhar com um erro: parse error near 'SET
password'
. A correção para este problema é
atualizar para uma versão mais nova do MySQL.
Com as versões atuais do MySQL você pode facilmente
adicionar novos usuários e alterar privilégios com os
comandos GRANT
e REVOKE
.
See Secção 4.4.1, “A Sintaxe de GRANT
e REVOKE
”.
O modo recomendado para instalar o MySQL no Linux é usando um
arquivo RPM. Os RPMs do MySQL atualmente são construídos na
versão 7.3 do sistema Suse Linux mas deve funcionar em outras
versões de Linux que suportam rpm
e usam
glibc
.
Se você tiver problemas com um arquivo RPM (por exemplo, se
você receber o erro ``Sorry, the host 'xxxx' could not
be looked up
''), veja
Secção 2.6.2.1, “Notas Linux para distribuições binárias”.
Na maioria dos casos, você só precisa instalar os pacotes
servidor MySQL
e o cliente
MySQL
para ter uma instalação funcional do MySQL. Os
outros pacotes não são exigidos para uma instalação padrão.
Se você quiser executar um servidor MySQL Max que tenha
capacidades adicionais, você deve instalar o RPM
MySQL-Max
depois de instalar o RPM
MySQL-server
. See
Secção 4.8.5, “mysqld-max
, om servidor mysqld
extendido”.
Se você tiver um dependência de falha ao tentar instalar os
pacotes do MySQL 4.0 (ex.: ``error: removing these
packages would break dependencies: libmysqlclient.so.10 is
needed by ...
''), você também deve instalar o pacote
MySQL-shared-compat
, o qual inclui ambas as
bibliotecas para compatibilidade com versões anteriores
(libmysqlclient.so.12
para MySQL 4.0 e
libmysqlclient.so.10
para MySQL 3.23).
Muitas distribuições Linux ainda vêm com o MySQL 3.23 a elas
normalmente ligam as aplicações dinamicamente para economizar
espaço em disco. Se estas bibliotecas compartilhadas estão em
pacotes separados (ex.; MySQL-shared
), é
suficiente simplesmente deixar estes pacotes instalados e apenas
atualizar os pacotes do servidor e cliente MySQL (que são
estaticamente ligados e não dependem de bibliotecas
compartilhadas). Para distribuições que incluem as bibliotecas
compartilhadas no mesmo pacote que o servidor MySQL (ex.: Red
Hat Linux), você também pode instalar nosso RPM
MySQL-shares
3.23 ou usar o pacote
compatível com MySQL-shared
.
Os seguintes pacotes RPM estão disponíveis:
MySQL-server-VERSION.i386.rpm
O servidor MySQL. Você ira precisar dele a não ser que
você apenas queira se conectar a um servidor MySQL
executando em outra máquina. Note que este pacote era
chamado MySQL-VERSION.i386.rpm
antes do
MySQL 4.0.10.
MySQL-Max-VERSION.i386.rpm
O servidor MySQL Max. Este seridor tem capacidades
adicionais que o servidor no ROM
MySQL-server
não tem. Você deve
instalar o RPM MySQL-server
primeiro,
porque o RPM MySQL-Max
depende dele.
MySQL-client-VERSION.i386.rpm
Os programas clientes padrões do MySQL. Provavelmente você sempre instalará este pacote.
MySQL-bench-VERSION.i386.rpm
Testes e comparativos de performances (benchmarks).
Necessita do Perl e módulos do
BDB-mysql
.
MySQL-devel-VERSION.i386.rpm
As bibliotecas e arquivos include necessários se você precisa para compilar outros clientes MySQL, como nos módulos Perl.
MySQL-shared-VERSION.i386.rpm
Este pacote contém as bibliotecas compartilhadas
(libmysqlclient.so*
) que certas
linguagens e aplicações nencessárias para carregar
dinâmicamente e usar o MySQL.
MySQL-shared-compat-VERSION.i386.rpm
Este pacote inclui o biblioteca compartilhada para MySQL
3.23 e MySQL 4.0. Instale este pacote em vez do
MySQL-shared
, se você tiver aplicações
instaladas que são dinâmicamente ligadas ao MySQL 3.23 mas
você quer atualizar para o MySQL 4.0 sem quebrar as
dependências da biblioteca. Este pacote esta disponível
desde o MySQL 4.0.13.
MySQL-embedded-VERSION.i386.rpm
A biblioteca do servidor embutido MySQL (MySQL 4.0).
MySQL-VERSION.src.rpm
Este contém o código fonte para todos os pacotes acima. Ele também pode ser usado para tentar construir RPMs para outras arquiteturas (por exemplo, Alpha ou SPARC).
Para ver todos os arquivo em um pacote RPM, (por exemplo, um RPM
MySQL-server
), execute:
shell> rpm -qpl MySQL-server-VERSION.i386.rpm
Para realizar uma instalação mínima padrão, execute:
shell> rpm -i MySQL-server-VERSION.i386.rpm MySQL-client-VERSION.i386.rpm
Para instalar somente o pacote cliente, execute:
shell> rpm -i MySQL-client-VERSION.i386.rpm
O RPM fornece um recurso para verificar a integridade e
autenticidade dos pacotes antes de instalá-los. Se você quiser
aprender mais sobre este recurso, veja
Secção 2.2.2, “Verificando a Integridade do Pacote Usando MD5 Checksums
ou GnuPG
”.
O RPM coloca dados sob o /var/lib/mysql
. O
RPM também cria as entradas apropriadas em
/etc/rc.d/
para iniciar o servidor
automaticamente na hora do boot. (Isto significa que se você
realizou uma instalação anterior e fez alterações em seu
script de inicialização, você pode desejar criar uma cópia
do script para que você não perca ao instalar um RPM mais
novo). Veja Secção 2.4.3, “Inicializando e parando o MySQL automaticamente.” para mais
informações sobre como o MySQL pode ser iniciado
automaticamente na inicialização do sistema.
Se você quiser instalar o RPM do MySQL em uma distribuição
Linux mais antiga que não suporte scripts de inicialização no
/etc/init.d
(diretamente ou via link
simbólico), você deve criar um link simbólico que aponte para
a localização onde o seu script de instalação está
atualmente instalado. Por exemplo, se esta localização for
/etc/rc.d/init.d
, use estes comandos antes
de intalar o RPM para criar /etc/init.d
como um link simbólico que aponte lá:
shell> cd /etc; ln -s rc.d/init.d .
No entanto, todas as distribuições de Linux atuais já devem
suportar este novo layout de diretório que usa
/etc/init.d
já que ele é exigido para
compatibilidade LBS (Linux Standard Base).
Se o arquivo RPM que você instalar inclui o
MySQL-server
, o daemon
mysqld
deve estar pronto e em execução
após a instalação. Agora você já deve poder iniciar o
MySQL. See Secção 2.4, “Configurações e Testes Pós-instalação”.
Se alguma coisa der errado, você encontrar maiores informações no capítulo de instalação. See Secção 2.2.9, “Instalando uma Distribuição Binária do MySQL”.
A partir do MySQL 4.0.11, você pode instalar o MySQL no Mac OS
X 10.2 (``Jaguar'') usando um pacote do binário do Mac OS X
PKG
em vez da distribuição binário em
tarball. Note que versões mais antigas do Mac OS X (ex.:
10.1.x) não são suportadas por este pacote.
Este pacote está localizado dentro de um arquivo de imagem de
disco (.dmg
). que você primeiro precisa
montar com um duplo clique em sua ícone no Finder. Ele deve
então montar a imagem e exibir o seu conteúdo.
NOTA: Antes de proceder com a
instalação, tenha certeza que você finalizou todas as
instâncias do MySQL em execução usando o MySQL Manager
Aplication (no Mac OS X Server) ou via mysqladmin
shutdown
na linha de comando.
Para relamente instalar o MySQL PKG, de um duplo clique na ícone do pacote. Isto inicia o Mac OS Package Installer, que irá guia-lo pela instalação do MySQL.
O Mac OS X PKG do MySQL irá se instalar em
/usr/local/mysql-<version>
e também
instalrá um link simbólico
/usr/local/mysql
, apontando para a nova
localização. Se um diretório chamado
/usr/local/mysql
já existe, ele será
renomeado para /usr/local/mysql.bak
em
primeiro lugar. Adicionalmente, ele irá instalar a tabela de
permissões do banco de dados MySQL executando
mysql_install_db
depois da instalação.
O layout de instalação é similar a aquele da distribuição
binária, todos os binários do MySQL estão localizados no
diretório /usr/local/mysql/bin
. O socket
MySQL será colocado em /tmp/mysql.sock
por
padrão. See Secção 2.2.5, “Layouts de Instalação”.
A instalação do MySQL exige uma conta de usuário do Mac OS X
chamada mysql
(uma conta de usuário com este
nome existe por padrão no Mac OS X 10.2 e acima).
Se você estiver executando o MAC OS X Server, você já terá uma versão do MySQL instalado:
Mac OS X Server 10.2-10.2.2 vem com o MySQL 3.23.51 instalado
Mac OS X Server 10.2.3-10.2.6 vem com o MySQL 3.23.53
Mac OS X Server 10.3 vem com o MySQL 4.0.14
Esta seção do manual cobre a instalação apenas do MySQL Mac OS X PKG oficial. Leia o ajuda da Apple sobre a instalação do MySQL (Execute o aplicativo ``Help View'', selecione a ajuda do ``Mac OS X Server'' e faça uma busca por ``MySQL'' e leia o item entitulado ``Installing MySQL'').
Note especialmente, que a versão pré-instalada do MySQL no Mac
OS X Server é iniciado com o comando
safe_mysqld
em vez de
mysqld_safe
.
Se anteriormente você usava pacotes do MySQL de Marc Liyanage para Mac OS X de http://www.entropy.ch, você pode simplesmente seguir as intruções de atualização para pacotes usando o layout de instalação dos binário como dados em suas páginas.
Se você está atualizado da versão 3.23.xx de Marc ou do versão Mac OS X Server do MySQL para o MySQL PKG oficial, você também deve converter a tabela de privilégios do MySQL existente para o formato atual, porque alguns novos privilégios de segurança foram adicionados. See Secção 2.5.6, “Atualizando a Tabela de Permissões”.
Se você preferisse iniciar automaticamente o MySQL durante o
boot do sistema, você tambén precisa instalar o MySQL Startup
Item. A partir do MySQL 4.0.15, ele é parte do disco de
instalação do Mac OS X como um pacote de instalação
separado. Simplesmente de um duplo clique no ícone
MySQLStartupItem.pkg
e siga as instruções
para instalá-lo.
Note que isto só precisa ser feito uma vez! Não há necessidade de se instalar o Startup Item toda vez que se atualizar o pacote do MySQL.
Devido a um erro no instalador de pacotes do Mac OS X, algumas
vezes você pode ver a mensagem de erro You cannot
install this software on this disk. (null)
no diálogo
de seleção do disco de destino. Se este erro ocorrer,
simplesmente clique no botão Go Back
uma vez
para retornar a tela anterior. Agora clique em
Continue
para avançar para a seleção do
disco de destino novamente - agora você deve estar apto a
escolher o disco destino corretamente. Nós informamos este erro
a Apple e eles estão investigando este problema.
O Startup Item será instalado em
/Library/StartupItems/MySQL
. Ele adiciona
uma variável MYSQLCOM=-YES-
ao arquivo de
configuração do sistema
(/etc/hostconfig
). Se você desejasse
diasbilitar a inicialização automática do MySQL, simplesmente
altere o valor desta variável para
MYSQLCOM=-NO-
.
No Mac OS X Server, o script de instalação do Startup Item
disabilitará automaticamente a inicialização da instalação
padrão do MySQL alterando a variável MYSQL
em /etc/hostconfig
para
MYSQL=-NO-
. Isto é para evitar conflitos na
inicialização. No entanto, ele não desliga um servidor MySQL
ajá em execução.
Depois da instalação, você pode iniciar o MySQL executando os seguintes comandos em um janela de terminal. Note qye você preceisa ter privilégios de administrador para realizar esta tarefa.
Se você tiver instalado o Startup Item:
shell> sudo /Library/StartupItems/MySQL/MySQL start
(Enter your password, if necessary)
(Press Control-D or enter "exit" to exit the shell)
Se você não tiver instalado o Startup Item, digite a seguinte sequência de comandos:
shell>cd /usr/local/mysql
shell>sudo ./bin/mysqld_safe
(Enter your password, if necessary) (Press Control-Z) shell>bg
(Press Control-D or enter "exit" to exit the shell)
Agora você deve conseguir se conectar ao servidor MySQL, ex.:
executando /usr/local/mysql/bin/mysql
Se você instalar o MySQL pela primeira vez,
lembre-se de consigurar uma senha para o
usuário root
do MySQL!
Isto é feito com os seguintes comandos:
/usr/local/mysql/bin/mysqladmin -u root password <password> /usr/local/mysql/bin/mysqladmin -u root -h `hostname` password <password>
Por favor, tenha certeza que o comando
hostname
na segunda linha está entre
crases (`), assim a shell pode
substituí-la com a saída deste comando (o nome da máquina
deste sistema)!
Você também pode querer adicionar aliases ao seu arquivo de
resursos do sheel para acessar mysql
e
mysqladmin
da linha de comando:
alias mysql '/usr/local/mysql/bin/mysql' alias mysqladmin '/usr/local/mysql/bin/mysqladmin'
De forma alternativa, você pode simplesmente adicionar
/usr/local/mysql/bin
a sua variável de
ambiente PATH
, ex.: adicionando o seguinte ao
arquivo $HOME/.tcshrc
:
setenv PATH ${PATH}:/usr/local/mysql/bin
Note que instalar um novo MySQL PKG não remove o diretório de uma instalação mais antiga. Infelizmente o Mac OS X Installer ainda não oferece a funcionalidade exigida para atualizar apropriadamente pacotes instalados anteriormente.
Depois de copiar os arquivos de banco de dados do MySQL sobre os
da versão anterior e inicializar o nova versão com sucesso,
você deve remover os arquivos da instalação antiga para
economizar espaço em disco. Adicionalmente você também deve
remover versões mais antigas do diretório do Package Receipt
localizados em
/Library/Receipts/mysql-<version>.pkg
.
A partir da versão 4.0.11, o MySQL está disponível para a Novell NetWare na forma de pacote do binário. Para servir o MySQL, o servidor NetWare deve suprir estas exigências:
NetWare versão 6.5, ou NetWare 6.0 com Support Pack 3 instalado (Você pode obtê-lo em http://support.novell.com/filefinder/13659/index.html). O sistema deve obedecer as exigências mínimas da Naveel para executar a respectiva versão do NetWare.
Os dados do MySQL, assim com os seus binários, devem ser instalados em um volume NSS; volumes tradicionais não são suportados.
O pacote binário para o NetWare pode ser obtido em http://www.mysql.com/downloads/.
Se você estiver executando o MySL no NetWare 6.0, sugerimos que
você utilize a opção --skip-external-locking
na linha de comando. Também será necessário utilizar
CHECK TABLE
e REPAIR TABLE
em vez de myisamchk
, porque
myisamchk
faz uso de lock externo. Lock
externo possui problemas com NetWare 6.0; o problema foi
eliminado no NetWare 6.5.
Se você estiver atualizando de um instaação anterior, para o servidor MySQL. Isto é feito a partir do console do servidor, usando:
SERVER: mysqladmin -u root shutdown
Conecte-se no servidor alvo a partir de uma máquina cliente com acesso ao local onde você instalará o MySQL.
Extraia o pacote zip binário em seu servidor. Tenha
certeza de permitir que os caminhos no arquivo zip sejam
usados. É seguro simplesmente extrair os arquivos para
SYS:\
.
Se você estiver atualizando de uma instalando anterior,
você pode precisar copiar os diretórios de dados (ex.:
SYS:MYSQL\DATA
) agora, assim como
my.cnf
se você o tiver costumizado.
Você pode então deletar a cópia antiga do MySQL.
Você pode desejar renomear o diretório para algo mais
consistente e fácil de usar. Recomendamos usar o
SYS:MYSQL
; exemplos no manual o
usarão para se referir ao diretório de instalação em
geral.
No console do servidor, adicione um caminho de busca no diretório contendo os NLMs do MySQL. Por exemplo:
SERVER: SEARCH ADD SYS:MYSQL\BIN
Instale o banco de dados inicial, se necessário,
digitando mysql_install_db
no console
do servidor.
Inicie o servidor MySQL usando
mysqld_safe
no console do servidor.
Para finalizar a instalação, você também deve
adicionar os seguintes comandos ao
autoexec.ncf
. Por exemplo, se sua
instalação do MySQL está em
SYS:MYSQL
e você quiser que o MySQL
inicie automaticamente, você pode adicionar estas linhas:
#Starts the MySQL 4.0.x database server SEARCH ADD SYS:MYSQL\BIN MYSQLD_SAFE
Se você estiver usando NetWare 6.0, você deve adicionar
o parâmetro --skip-external-locking
:
#Starts the MySQL 4.0.x database server SEARCH ADD SYS:MYSQL\BIN MYSQLD_SAFE --skip-external-locking
Se houver uma instalação existente do MySQL no servidor,
verifique a existencia de comandos de inicialização do MySQL
em autoexec.ncf
, e edite ou delete-os se
necessário.
MD5 Checksums
ou GnuPG
Confira a homepage da MySQL homepage (http://www.mysql.com/) para informações sobre a versão atual e para instruções de download.
Nosso principal espelho de download está localizado em: http://mirrors.sunsite.dk/mysql/.
Para uma lista atualizada completa dos mirrors de download da MySQL, veja http://www.mysql.com/downloads/mirrors.html. Você também encontrará informação sobre como se tornar um mirror do MySQL e como relatar um mirror ruim ou desatualizado.
Depois de fazer o download do pacote MySQL que serve às suas necessidades e antes de tentar instalá-lo, você deve ter certeza de que ele esta intacto e não foi manipulado.
A MySQL AB oferece dois tipos de verificação de integridade:
MD5 checksums
e assinaturas criptografadas
usando GnuPG
, o GNU Privacy
Guard
.
Verificando o MD5
Checksum
Depois de fazer o download do pacote, você deve verificar se o MD5 checksum corresponde a aquele fornecido na página de download do MySQL. Cada pacote tem um checksum individual, que você pode verificar com o seguinte comando:
shell> md5sum <pacote>
Note que nem todos os sistemas operacionais suportam o comando
md5sum
- em alguns ele é simplesmente
chamado md5
, outros não o possuem. No Linux,
ele é parte do pacote GNU Text Utilities
,
que está disponível para uma grande faixa de plataformas.
Você pode fazer o download do código fonte em
http://www.gnu.org/software/textutils/.
Se você tiver o OpenSSL
instalado, você
também pode usar o comando openssl md5
<pacote>
. Uma implementação do comando
md5
para DOS/Windows está disponível em
http://www.fourmilab.ch/md5/.
Exemplo:
shell> md5sum mysql-standard-4.0.10-gamma-pc-linux-i686.tar.gz
155836a7ed8c93aee6728a827a6aa153
mysql-standard-4.0.10-gamma-pc-linux-i686.tar.gz
Você deve verificar se o resultado do checksum corresponde a aquele impresso no página de download logo abaixo do respectivo pacote.
A maioria do sites mirrors também oferecem um arquivo chamado
MD5SUMS
, que também inclui o MD5 checksums
para todos os arquivos incluídos no diretório
Downloads
. Note no entanto que é muito
fácil de modificar este arquivo e ele não é um método muito
confiável. Caso esteja em dúvida, você deve consultar
diferentes sites mirroers e comparar os resultados.
Verificação de Assinatura Usando
GnuPG
Um método de verificação de integridade de um pacote mais
confiável é o uso de assinaturas criptografadas. A MySQL AB
usa o GNU Privacy Guard
(GnuPG
), uma alternativa Open
Source
para o bem conhecido Pretty Good
Privacy
(PGP
) de Phil Zimmermann.
Veja
http://www.gnupg.org/
and
http://www.openpgp.org/
para mais informações sobre
OpenPGP
/GnuPG
e como obter
e instalar o GnuPG
em seus sistema. A maioria
das distribuições de Linux já vêm com o
GnuPG
instalado por padrão.
A partir do MySQL 4.0.10 (Fevereiro de 2003), a MySQL AB
começou a assinar o seus pacotes de download com
GnuPG
. Assinaturas criptografadas são um
método bem mais confiável de verificação da integridade e
autenticidade de um arquivo.
Para verificar a assinatura de um pacote específico, você
primeiro precisa obtter uma cópia da chave pública GPG da
MySQL AB (<build@mysql.com>
). Você também pode
cortá-la e colá-la diretamente daqui ou obtê-la em
http://www.keyserver.net/.
Key ID: pub 1024D/5072E1F5 2003-02-03 MySQL Package signing key (www.mysql.com) <build@mysql.com> Fingerprint: A4A9 4068 76FC BD3C 4567 70C8 8C71 8D3B 5072 E1F5 Public Key (ASCII-armored): -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org mQGiBD4+owwRBAC14GIfUfCyEDSIePvEW3SAFUdJBtoQHH/nJKZyQT7h9bPlUWC3 RODjQReyCITRrdwyrKUGku2FmeVGwn2u2WmDMNABLnpprWPkBdCk96+OmSLN9brZ fw2vOUgCmYv2hW0hyDHuvYlQA/BThQoADgj8AW6/0Lo7V1W9/8VuHP0gQwCgvzV3 BqOxRznNCRCRxAuAuVztHRcEAJooQK1+iSiunZMYD1WufeXfshc57S/+yeJkegNW hxwR9pRWVArNYJdDRT+rf2RUe3vpquKNQU/hnEIUHJRQqYHo8gTxvxXNQc7fJYLV K2HtkrPbP72vwsEKMYhhr0eKCbtLGfls9krjJ6sBgACyP/Vb7hiPwxh6rDZ7ITnE kYpXBACmWpP8NJTkamEnPCia2ZoOHODANwpUkP43I7jsDmgtobZX9qnrAXw+uNDI QJEXM6FSbi0LLtZciNlYsafwAPEOMDKpMqAK6IyisNtPvaLd8lH0bPAnWqcyefep rv0sxxqUEMcM3o7wwgfN83POkDasDbs3pjwPhxvhz6//62zQJ7Q7TXlTUUwgUGFj a2FnZSBzaWduaW5nIGtleSAod3d3Lm15c3FsLmNvbSkgPGJ1aWxkQG15c3FsLmNv bT6IXQQTEQIAHQUCPj6jDAUJCWYBgAULBwoDBAMVAwIDFgIBAheAAAoJEIxxjTtQ cuH1cY4AnilUwTXn8MatQOiG0a/bPxrvK/gCAJ4oinSNZRYTnblChwFaazt7PF3q zIhMBBMRAgAMBQI+PqPRBYMJZgC7AAoJEElQ4SqycpHyJOEAn1mxHijft00bKXvu cSo/pECUmppiAJ41M9MRVj5VcdH/KN/KjRtW6tHFPYhMBBMRAgAMBQI+QoIDBYMJ YiKJAAoJELb1zU3GuiQ/lpEAoIhpp6BozKI8p6eaabzF5MlJH58pAKCu/ROofK8J Eg2aLos+5zEYrB/LsrkCDQQ+PqMdEAgA7+GJfxbMdY4wslPnjH9rF4N2qfWsEN/l xaZoJYc3a6M02WCnHl6ahT2/tBK2w1QI4YFteR47gCvtgb6O1JHffOo2HfLmRDRi Rjd1DTCHqeyX7CHhcghj/dNRlW2Z0l5QFEcmV9U0Vhp3aFfWC4Ujfs3LU+hkAWzE 7zaD5cH9J7yv/6xuZVw411x0h4UqsTcWMu0iM1BzELqX1DY7LwoPEb/O9Rkbf4fm Le11EzIaCa4PqARXQZc4dhSinMt6K3X4BrRsKTfozBu74F47D8Ilbf5vSYHbuE5p /1oIDznkg/p8kW+3FxuWrycciqFTcNz215yyX39LXFnlLzKUb/F5GwADBQf+Lwqq a8CGrRfsOAJxim63CHfty5mUc5rUSnTslGYEIOCR1BeQauyPZbPDsDD9MZ1ZaSaf anFvwFG6Llx9xkU7tzq+vKLoWkm4u5xf3vn55VjnSd1aQ9eQnUcXiL4cnBGoTbOW I39EcyzgslzBdC++MPjcQTcA7p6JUVsP6oAB3FQWg54tuUo0Ec8bsM8b3Ev42Lmu QT5NdKHGwHsXTPtl0klk4bQk4OajHsiy1BMahpT27jWjJlMiJc+IWJ0mghkKHt92 6s/ymfdf5HkdQ1cyvsz5tryVI3Fx78XeSYfQvuuwqp2H139pXGEkg0n6KdUOetdZ Whe70YGNPw1yjWJT1IhMBBgRAgAMBQI+PqMdBQkJZgGAAAoJEIxxjTtQcuH17p4A n3r1QpVC9yhnW2cSAjq+kr72GX0eAJ4295kl6NxYEuFApmr1+0uUq/SlsQ== =YJkx -----END PGP PUBLIC KEY BLOCK-----
Você pode importar esta chave em seu pasta de chaves publicas
GPG
usando gpg --import
.
Veja a documentação de GPG
para mais
informações de como trabalhar com chaves públicas.
Depois de fazer o download e importar a chave publica criada,
faça o download do pacote MySQL desejado e da assinatura
correspondente, que também está disponível na página de
download. A assinatura tem a extensão
.asc
. Por exemplo, a assinatura de
mysql-standard-4.0.10-gamma-pc-linux-i686.tar.gz
seria
mysql-standard-4.0.10-gamma-pc-linux-i686.tar.gz.asc
.
Tenha certeza que ambos os arquivos estão armazenados no mesmo
diretório e então execute o seguinte comando para verificar a
assinatura para este arquivo:
shell>gpg --verify <package>.asc
Exemplo: shell>gpg --verify mysql-standard-4.0.10-gamma-pc-linux-i686.tar.gz.asc
gpg: Warning: using insecure memory! gpg: Signature made Mon 03 Feb 2003 08:50:39 PM MET using DSA key ID 5072E1F5 gpg: Good signature from "MySQL Package signing key (www.mysql.com) <build@mysql.com>"
A mensagem "Good signature" indica que está tudo certo.
Verificando Assinatura Usando
RPM
Para pacotes RPM
, não há assinaturas
separadas - pacotes RPM
atualmente têm uma
assinatura GPG
incluída e MD5
checksum
. Você pode verificá-los executando o
seguinte comando:
shell>rpm --checksig <package>.rpm
Exemplo: shell>rpm --checksig MySQL-server-4.0.10-0.i386.rpm
MySQL-server-4.0.10-0.i386.rpm: md5 gpg OK
Nota: Se você estiver usando
RPM 4.1 e ele reclamar sobre (GPG) NOT OK (MISSING
KEYS: GPG#5072e1f5)
(mesmo se você a importou para
detro de sua pasta de chaves publicas GPG), você precisa
importá-las para dentro de sua pasta de chaves RPM primeiro.
RPM 4.1 não utiliza mais ias suas pastas de chaves GPG (e o
próprio GPG), mas mantém sua própria pasta de chaves (porque
ele é um aplicativo do sistema e a pasta de chaves públicas do
GPG é um arquivo específico do usuário). Para importar a
chave pública do MySQL em uma pasta de chaves RPM, use os
seguintes comandos:
shell>rpm --import <pubkey>
Exemplo: shell>rpm --import mysql_pubkey.asc
Caso você note que as assinaturas MD5
checksum
ou GPG
não coincidem,
tente primeiro fazer o download do pacote respectivo mais uma
vez, talvez de outro site mirror. Se você não obter sucesso na
verificação da integridade do pacote repetidas vezes,
notifique-nos sobre tais incidentes incluindo o nome completo do
pacote e o site que você tem utilizado para fazer o download
pelos emails <webmaster@mysql.com>
ou
<build@mysql.com>
.
Nós ulitizamos o GNU Autoconf, para que seja possível portar o MySQL para todos sistemas operacionais modernos com threads Posix funcionando e um compilador C++. (Para compilar somente o código cliente, um compilador C++ é necessário mas threads não.) Nós mesmos usamos e desenvolvemos o software primeiramente no Linux (SuSE e red Hat), FreeBSD e Sun Solaris (Versões 8 e 9).
Perceba que para alguns sistemas operacionais, o suporte nativo a thread funciona somente nas últimas versões. O MySQL compila com sucesso nas seguintes combinações de sistema operacional/pacote de thread:
AIX 4.x com threads nativas. See Secção 2.6.6.4, “Notas IBM-AIX”.
Amiga.
BSDI 2.x com o pacote incluído MIT-pthreads. See Secção 2.6.4.5, “Notas BSDI Versão 2.x”.
BSDI 3.0, 3.1 e 4.x com threads nativas. See Secção 2.6.4.5, “Notas BSDI Versão 2.x”.
SCO OpenServer with a recent port of the FSU Pthreads package. See Secção 2.6.6.9, “Notas SCO”.
SCO UnixWare 7.0.1. See Secção 2.6.6.10, “Notas SCO Unixware Version 7.0”.
DEC Unix 4.x com threads nativas. See Secção 2.6.6.6, “Notas Alpha-DEC-UNIX (Tru64)”.
FreeBSD 2.x com o pacote incluído MIT-pthreads. See Secção 2.6.4.1, “Notas FreeBSD”.
FreeBSD 3.x e 4.x com threads nativas. See Secção 2.6.4.1, “Notas FreeBSD”.
FreeBSD 4.x com Linuxthreads. See Secção 2.6.4.1, “Notas FreeBSD”.
HP-UX 10.20 com o pacote incluído MIT-pthreads ou DCE threads. See Secção 2.6.6.2, “Notas HP-UX Versão 10.20”.
HP-UX 11.x com as threads nativas. See Secção 2.6.6.3, “Notas HP-UX Versão 11.x”.
Linux 2.0+ com LinuxThreads 0.7.1+ ou
glibc
2.0.7+. See
Secção 2.6.2, “Notas Linux (Todas as versões)”.
Mac OS X Server. See Secção 2.6.5, “Notas Mac OS X”.
NetBSD 1.3/1.4 Intel e NetBSD 1.3 Alpha (Necessita GNU make). See Secção 2.6.4.2, “Notas NetBSD”.
Novell NetWare 6.0. See Secção 2.6.8, “Notas Novell NetWare”.
OpenBSD > 2.5 com threads nativas. OpenBSD < 2.5 com o pacote incluído MIT-pthreads . See Secção 2.6.4.3, “Notas OpenBSD”.
OS/2 Warp 3, FixPack 29 e OS/2 Warp 4, FixPack 4. See Secção 2.6.7, “Notas OS/2”.
SGI Irix 6.x com threads nativas. See Secção 2.6.6.8, “Notas SGI Irix”.
Solaris 2.5 e superior com threads nativas nas plataformas SPARC e x86. See Secção 2.6.3, “Notas Solaris”.
SunOS 4.x com o pacote incluído MIT-pthreads. See Secção 2.6.3, “Notas Solaris”.
Tru64 Unix
Windows 9x, Me, NT, 2000 e XP. See Secção 2.6.1, “Notas Windows”.
Perceba que nem todas as plataformas são apropriadas para executar o MySQL. Os seguintes fatores determinam se uma certa plataforma é apropriada para uma missão crítica pesada:
Estabilidade geral da biblioteca thread. Uma plataforma pode ter excelente reputação, entretanto, se a biblioteca thread é instável no código que é usado pelo MySQL, mesmo se todo o resto for perfeito, o MySQL irá ser tão estável quanto a biblioteca thread.
A habilidade do kernel e/ou a biblioteca thread tirar vantagem do SMP em sistemas multi-processados. Em outras palavras, quando um proceesso cria uma thread, deve ser possível para aquela thread executar em uma CPU diferente que o processo original.
A habilidade do kernel e/ou a biblioteca thread executar
várias threads que adiquire/libera um bloqueio mutex sobre
uma pequena região crítica frequentemente sem trocas de
contexto excessivos. Em outras palavras, se a
implementação de pthread_mutex_lock()
requisitar a CPU muito rapidamente, isto irá afetar o MySQL
tremendamente. Se esse detalhe não estiver sendo cuidado,
adicionar CPUs extras podem deixar o MySQL mais lento.
Estabilidade e performance geral do sistema de arquivos.
Habilidade do sistema de arquivos em lidar com arquivos grandes de forma eficiente, se suas tabelas forem grandes.
Nosso nível de experiência aqui na MySQL AB com a plataforma. Se nós conhecemos bem uma plataforma, introduzimos otimizações/correçoes específicas para ela habilitadas na hora da compilação. Nós também podemos fornecer conselhos sobre como configurar seu sistema otimizadamente para o MySQL.
O volume de testes feitos internamente de configurações similares.
O número de usuários que tem executado o MySQL com sucesso naquela plataforma em configurações similares. Se esse número for alto, as chances de se ter alguma surpresa específica da plataforma fica muito menor.
Baseado nos critérios acima, as melhores plataformas para a execução do MySQL até este ponto são o x86 com SuSe Linux 8.2, kernel 2.4 e ReiserFS (ou qualquer distribuição Linux similar) e Sparc com Solaris (2.7-9). FreeBSD vem em terceiro, mas realmente temos esperanças que ele irá se unir ao clube dos tops uma vez que a biblioteca thread está melhorando. Nós também acreditamos que em certo ponto iremos estar aptos para incluir todas as outras plataformas em que o MySQL compila e executa, mas não tão bem e com o mesmo nível de estabilidade e performance, na categoria superior. Isto necessitará de algum esforço da nossa parte em cooperação com os desenvolvedores dos componentes do Sistema Operacional/Biblioteca que o MySQL depende. Se você tiver interesse em melhorar algum de nossos componentes, está em uma posição para influenciar seu desenvolvimento, e precisa de instruções mais detalhadas sobre o que o MySQL necessita para uma melhor execução, envie um e-mail para lista de email ``insternals'' do MySQL. See Secção 1.7.1.1, “As Listas de Discussão do MySQL”.
Por favor, perceba que a comparação acima não é para dizer que um SO é melhor ou pior que o outro em geral. Nós estamos falando sobre a escolha de um SO para um propósito dedicado: executar o MySQL, e comparamos as plataformas levando isto em consideração. Desta forma, o resultado desta comparação seria diferente se nós incluíssemos mais detalhes. E em alguns casos, a razão de um SO ser melhor que o outro pode ser simplesmente porque colocamos mais esforço nos testes e otimização para aquela plataforma em particular. Estamos apenas colocando nossas observações para ajudá-lo na decisão de qual plataforma usar o MySQL na sua configuração.
A primeira decisão a ser feita é se você deve usar a última versão de desenvolvimento ou a última versão estável:
Normalmente, se você estiver usando o MySQL pela primeira vez ou tentando portá-lo para algum sistema em que não exista distribuição binária, recomendamos o uso da versão estável (atualmente Versão 5.0.6-beta). Repare que todos os lançamentos do MySQL são conferidos com os testes comparativos de performance e um conjunto extenso de testes antes de cada lançamento.
Senão, caso você esteja trabalhando com um antigo sistema e quiser atualizá-lo, mas não que correr o risco com uma atualização sem correções, você deve faze-lo do mesmo ramo que você está usando (onde aenas o último número da versão é mais novo que o seu). Nós temos tentado corrigir somente erros fatais e torná-los menores, com alterações relativamente seguras para aquela versão.
A segunda decisão a ser feita é se você deseja usar uma distribuição fonte ou binária. Na maioria dos casos provavelmente você deverá usar a distribuição binária, se alguma existir para sua plataforma, será normalmente muito mais fácil para instalar do que a distribuição em código fonte.
Nos seguites casos você provavelmente será mais bem servido com uma instalação baseada em código fonte:
Se você desejar instalar o MySQL em algum lugar expecífico. (O padrão das distribuições binárias é estar``pronto para rodar'' em qualquer lugar, mas talvez você deseje ainda mais flexibilidade).
Para estar apto e satisfazer diferentes requisições dos
usuários, estaremos fornecendo duas versões binárias
diferentes; Uma compilada com os manipuladores de tabelas
não transacionais (um binário rápido e pequeno) e um
configurado com as mais importantes opções extendidas como
tabelas transacionais. Ambas versões são compiladas da
mesma distribuição fonte. Todos clientes
MySQL
nativos pode conectar com ambas
versões do MySQL.
A distribuição binária extendida é marcada com o sufixo
-max
e é configurada com as mesmas
opções de mysqld-max
. See
Secção 4.8.5, “mysqld-max
, om servidor mysqld
extendido”.
Se você deseja usar o RPM MySQL-Max
,
primeiramente você deve instalar o RPM
MySQL-server
padrão.
Se você deseja configurar mysqld
com
alguns recursos extras que NÃO estão nas distribuições
binárias. Segue abaixo a lista das opções extras mais
comuns que você pode querer usar:
--with-innodb
--with-berkeley-db
(padrão para o
MySQL 4.0 e seguintes)
--with-raid
(não disponível para
todas as plataformas)
--with-libwrap
--with-named-z-lib
(Isto é feito para
alguns dos binários)
--with-debug[=full]
A distribuição binária padrão é normalmente compilada com suporte para todos conjuntos de caracteres e deve funcionar em uma variedade de processadores para a mesma família do processador.
Se você precisar de um servidor MySQL mais rápido você
pode querer recompilá-lo com suporte para somente o
conjunto de caracteres que você precisa, usar um compilador
melhor (como pgcc
) ou usar opções de
compiladores para usar otimizações para seu processador.
Se você encontrar um erro e relatá-lo para o time de desenvolvimento do MySQL você provavelmente receberá um patch que será necessário aplicá-lo para a distribuição fonte para ter o bug corrigido.
Se você deseja ler (e/ou modificar) o código C e C++ que é o MySQL, você pode obter uma distribuição fonte. O código fonte é sempre o manual final. Distribuições fontes também contem mais testes e exemplos que as distribuições binárias.
O esquema de nomes do MySQL usa números de versões que
consistem de tres números e um sufixo. Por exemplo, um nome de
lançamento como mysql-4.1.0-alpha
é
interpretado da seguinte maneira:
O primeiro número (4
) é a versão
principal e também descreve o formato dos arquivos. Todas
releases da Versão 4 tem o mesmo formato de arquivo.
O segundo número (1
) é o nível da
distribuição.
O terceiro número (0
é o número da
versão do nível de distribuição. Este é incrementado
para cada nova distribuição. Normalmente você desejará a
última versão para o nível de publicação que tiver
escolhido.
O sufixo (alpha
) indica o nível de
estabilidade da versão. Os possíveis sufixo são:
alpha
indica que a versão contém
grandes seções de novos códigos que não foram 100%
testados. Bugs conhecidos (normalmente não tem nenhum)
devem estar documentados na seção News. See
Apêndice D, Histórico de Alterações do MySQL. Existem também novos comandos e
extensões na maioria das publicações alpha.
Desenvolvimento ativo que podem envolver maiores
alterações no código pode ocorrer numa versão alpha,
mas tudo será testado antes de fazer a publicação.
Não podem existir erros conhecidos em nenhuma
publicação do MySQL.
beta
significa que todo o novo
código foi testado. Não serão adicionados novos
recursos que podem causar algum tipo de corrompimento.
Não deve existir bugs conhecidos. Uma alteração de
versão de alpha para beta ocorre quando não existir
nenhum relato de erro fatal com uma versão alpha por
pelo menos um mês e não planejarmos adicionar nenhum
recurso que pode deixar algum antigo comando menos
confiável.
gamma
é o beta que já tem sido
usado a algum tempo e parece funcionar bem. Apenas
pequenas correções são adicionadas. Isto é o que
muitas empresas chamam de release.
Se não existir um sufixo, significa que esta versão já está sendo executada há algum tempo em diferentes locais sem relatos de erros além dos específicos de certas plataformas. Somente correções de erros críticos são adicionados ao release. Isto é o que chamamos de uma distribuição estável.
No processo de desenvolvimento do MySQL, várias versões coexistem e estão em um estágio diferente. Naturalmente, correções de erros relevantes de uma série anterior são propagados.
Para a antiga série 3.23
estável/de
produção, novas versões só são liberadas para erros
críticos.
A série atual (4.0
) é de qualidade
estável/produção. Nenhum novo recurso que possa
influenciar a estabilidade do código é adicionado.
No ramo alpha 4.1
principal, novos
recursos são adicionados. Fontes e binários estão
disponíveis para uso e teste em sistemas de
desenvolvimento.
O ramo de desenvolvimento 5.0
só está
disponível para a árvore do BitKeeper.
Todas as versões do MySQL funcionam sobre nossos testes padrões e comparativos para garantir que eles são relativamente seguros para o uso. Como os testes padrões são extendidos ao longo do tempo para conferir por todos os bugs antigos encontrados, o pacote de testes continua melhorando.
Perceba que todas publicações de versões foram testadas pelo menos com:
Um pacote de testes interna
Faz parte de um sistema de produção para um cliente. Ela tem diversas tabelas com centenas de megabytes de dados.
O diretório mysql-test
contém um
conjunto extensivo de casos de teste. Nós executamos estes
testes para cada servidor binário.
O pacote de comparativos da MySQL
Este executa uma série de consultas comuns. É também um teste para ver se o último conjunto de otimizações fez o código mais rápido. See Secção 5.1.4, “O Pacote de Benchmark do MySQL”.
O teste crash-me
Este tenta determinar quais recursos o banco de dados suporta e quais são suas capacidades e limitações. See Secção 5.1.4, “O Pacote de Benchmark do MySQL”.
Outro teste é que nós usamos a versão do MySQL mais nova em nosso ambiente de produção interna, em pelo menos uma máquina. Nós temos mais de 100 gigabytes de dados com que trabalhar.
Esta seção descreve o layout padrão dos diretórios criados pela instalção das distribuições binária e fonte.
Uma distribuição binária é instalada descompactando-a no
local de instalação de sua escolha (tipicamente
/usr/local/mysql
) e cria os seguintes
diretórios nesses locais:
Diretório | Conteúdo do diretório |
bin | Programas clientes e o servidor mysqld |
data | Arquivos Log, bancos de dados |
docs | Documentação, Log de alterações |
include | Arquivos de cabeçalho (headers) |
lib | Bibliotecas |
scripts | mysql_install_db |
share/mysql | Arquivos de mensagem de erro |
sql-bench | Benchmarks - testes comparativos |
Uma distribuição baseada em código fonte é instalada depois
de você configurá-la e compilá-la. Por padrão, a
instalação copia os arquivos em
/usr/local
, nos seguintes subdiretórios:
Diretório | Conteúdo do diretório |
bin | Programas clientes e scripts |
include/mysql | Arquivos de cabeçalho (headers) |
info | Documentação no formato Info |
lib/mysql | Bibliotecas |
libexec | O servidor mysqld |
share/mysql | Arquivos com mensagens de erros |
sql-bench | Benchmarks e o teste crash-me |
var | Bancos de dados e arquivos log |
Dentro de um diretório de instalação, o layout de uma instalação baseada em fontes diferencia de uma instalação binária nas seguintes formas:
The mysqld
server is installed in the
libexec
directory rather than in the
bin
directory.
The data directory is var
rather than
data
.
mysql_install_db
is installed in the
/usr/local/bin
directory rather than in
/usr/local/mysql/scripts
.
The header file and library directories are
include/mysql
and
lib/mysql
rather than
include
and lib
.
You can create your own binary installation from a compiled
source distribution by executing the script
scripts/make_binary_distribution
.
O MySQL está evoluindo muito rapidamente na MySQL AB e nós queremos compartilhar isto com outros usuários MySQL. Sempre que temos alguns recursos úteis que outros acham necessáio, tentamos fazer um release.
Também tentamos ajudar usuários que solicitam recursos que são de fácil implementação. Tomamos notas do que nossos usuários licenciados gostariam de ter,especialmente do que nossos clientes com suporte extendido desejam e tentamos ajudá-los.
Não existe uma real necessidade para baixar uma nova release. A seção News irá dizer se a nova versão tem alguma coisa que você precisa. See Apêndice D, Histórico de Alterações do MySQL.
Usamos a seguinte política quando estamos atualizando o MySQL:
Para cada pequena atualização, o último número na versão é incrementado. Quando tiver um maior número de novos recursos ou menor incompatibilidade com versões antigas, o segundo número na versão é incrementado. Quando o formato de arquivo altera, o primeiro número é aumentado.
Versões estáveis testadas aparecem na média de uma a duas vezes por ano, mas se pequenos bugs são encontrados, uma versão será lançada apenas com as correções dos erros.
Releases funcionais aparecem na média a cada 4-8 semanas.
Distribuições binárias para algumas plataformas será feita por nós somente para releases mais importantes. Outras pessoas podem fazer distribuições binárias para outros sistemas mas provavelmente com menos frequencia.
Nós normalmente disponibilizamos os patches logo que localizamos e corrigimos pequenos bugs. Eles normalmente são imediatamente disponibilizados em nosso repositório publico do BitKeeper. Eles serão incluídos na próxima distribuição.
Para bugs não críticos, mas irritantes, disponibilizamos patches se eles são enviados para nós. De qualquer forma, iremos combinar vários deles em um patch maior.
Se existitr, por algum motivo, um bug fatal numa versão criaremos uma nova release o mais cedo possível. Gostaríamos que outras empresas fizessem isto também.
A versão estável atual é a 3.23; nós já mudamos o desenvolvimento em atividade para a versão 4.0. Bugs contiuarão a ser corrigidos na versão estável. Não acreditamos em um congelamento completo, pois isto abandona a correções de bugs e coisas que ``devem ser feitas.'' ``Alguma coisa congelada'' significa que talvez possamos adicionar pequenas coisas que ``com certeza não afetará nada que já esteja funcionando.''
O MySQL usa um esquema de nomes um pouco diferente da maioria dos outros produtos. Em geral é relativamente seguro utilizar qualquer versão que tenha sido lançado a algumas semanas e que não tenham sido sustituída por uma nova versão. See Secção 2.2.4, “Qual versão do MySQL deve ser usada”.
Colocamos muito tempo e esforço em tornar nossas
distribuições livres de erros. Pelo nosso conhecimento, não
liberamos uma única versão do MySSQL com qualquer erro
conhecido
'fatal'.
Um erro fatal é algo que faz o MySQL falhar com o uso normal, traz respostas erradas para consultas normais ou tem um problema de segurança.
Nós temos documentados todos os problemas conhecidos, bugs e assuntos que são dependentes das decisões de projeto. See Secção 1.8.6, “Erros Conhecidos e Deficiências de Projetos no MySQL”.
Nosso objeto é corrigir tudo que é possível, mas sem correr o risco de tornarmos uma versão menos estável. Em certos casos, isto significa que podemos corrigir um problema na(s) versão(ões) de desenvolvimento, mas não o corrigirmos na versão estável (produção). Naturalmente, documentamos tais problemas para que o usuários esteja ciente.
Aqui está um descrição de como nosso processo de contrução funciona:
Monitoramos erros de nossa lista de suporte ao cliente, a lista de email externa do MySQL e o banco de dados de bugs em http://bugs.mysql.com/.
Todos os erros relatados em versões usadas são inseridos nio banco de dados de bugs.
Quando corrigimos um erro, sempre tentamos fazer um caso de teste para ele e incluí-lo em nosso sistema de teste para assegurar que o erro nunca retornará. (Cerca de 90% de todos os erros corrigidos têm um caso de teste.)
Também criamos casos de teste para todos os novos recursos adicionados ao MySQL.
Antes de começarmos a fazer uma nova distribuição do MySQL, asseguramos que todos os erros repetitíveis relatados para a versão do MySQL (3.23.x, 4.0.x, etc) estão corrigidos. Se algo for impossível de corrigir (devido a alguma decisão de projeto interno no MySQL), documentaremos isto no manual. See Secção 1.8.6, “Erros Conhecidos e Deficiências de Projetos no MySQL”.
Nós fazemos uma construção para todas as plataformas para as quais suportamos binários (mais de 15 plataformas) e executamos nosso pacote de teste e benchmarks para todas elas.
Não publicaremos um binário para uma plataforma na qual os testes do pacote de benchmarks falharam. Se for um erro geral na fonte, o corrigimos e fazemos as contruções mais os teste em todos os sistemas novamente.
Se nós, durante a o porcesso de construção e teste (que leva de 2 a 3 dias) recebermos um relatório sobre um erro fatal (por exemplo, um que cause um core dump), o corrigiremos e reiniciaremos o processo de construção).
Depois de publicarmos os binários em
http://www.mysql.com/,
enviamos um email de anúncio nas listas de email
mysql
e announce
. See
Secção 1.7.1.1, “As Listas de Discussão do MySQL”. A mensagem de anúncio
contém uma lista de todas as alterações da distribuição
e qualquer problema conhecido com ela. (A seção 'problemas
conhecidos' na notas das distribuições só tem sido
necessária em algumas da distribuições.)
Para darmos acesso rapidamente aos nossos usuários dos últimos recursos do MySQL, fazemos uma nova distribuição do MySQL a cada 4-8 semanas. Instantâneos do código finte são contruídos diariamente e estão disponíveios em http://downloads.mysql.com/snapshots.php.
Se, depois da distribuição estar pronta, recebermos
qualquer relatório que houve (depois de tudo) qualquer
coisa criticamente errada com a construção em uma
plataforma específica, corrigiremo-na imediatamente e
liberaremos um nova distribuição 'a'
para aquela plataforma. Graças aos nosso grande base de
usuários, problemas são encontrados rapidamente.
Nosso registro para boas distribuições feitas é muito boa. Nas últimas 150 distribuições, tivemos que fazer uma nova contrução para menos de 10 distribuições (em 3 destes casos, o erro era uma biblioteca glibc com problema em uma de nossas máquinas que levamos um longo tempo para encontrar.
Como um serviço, nós na MySQL AB fornecemos um conjunto de distribuições binárias do MySQL que são compiladas no nosso site ou em sites onde os clientes cordialmente nos dão acesso as suas máquinas.
Em adição aos binários forncedios em formatos de pacotes
específicos da plataforma (veja
Secção 2.1, “Instalação rápida padrão do MySQL”), oferecemos
distribuições binários para outras plataformas através de
arquivos tar compactados (.tar.gz
).
Estas distribuições são geradas usando o script
Build-tools/Do-compile
que compila o código
fonte e cria o arquivo binário em tar.gz
usando scripts/make_binary_distribution
.
Estes binários são configurados e construídos com os
seguintes compiladores e opções.
Binários construídos no sistema de desenvolvimento da MySQL AB:
Linux 2.4.xx x86 com gcc
2.95.3
CFLAGS="-O2 -mcpu=pentiumpro" CXX=gcc CXXFLAGS="-O2
-mcpu=pentiumpro -felide-constructors" ./configure
--prefix=/usr/local/mysql --with-extra-charsets=complex
--enable-thread-safe-client --enable-local-infile
--enable-assembler --disable-shared
--with-client-ldflags=-all-static
--with-mysqld-ldflags=-all-static
Linux 2.4.xx Intel Itanium 2 com ecc
(Intel C++ Itanium Compiler 7.0)
CC=ecc CFLAGS="-O2 -tpp2 -ip -nolib_inline" CXX=ecc
CXXFLAGS="-O2 -tpp2 -ip -nolib_inline" ./configure
--prefix=/usr/local/mysql --with-extra-charsets=complex
--enable-thread-safe-client --enable-local-infile
Linux 2.4.xx Intel Itanium com ecc
(Intel
C++ Itanium Compiler 7.0)
CC=ecc CFLAGS=-tpp1 CXX=ecc CXXFLAGS=-tpp1
./configure --prefix=/usr/local/mysql
--with-extra-charsets=complex --enable-thread-safe-client
--enable-local-infile
Linux 2.4.xx alpha com ccc
(Compaq C
V6.2-505 / Compaq C++ V6.3-006)
CC=ccc CFLAGS="-fast -arch generic" CXX=cxx
CXXFLAGS="-fast -arch generic -noexceptions -nortti"
./configure --prefix=/usr/local/mysql
--with-extra-charsets=complex --enable-thread-safe-client
--enable-local-infile --with-mysqld-ldflags=-non_shared
--with-client-ldflags=-non_shared --disable-shared
Linux 2.4.xx s390 com gcc
2.95.3
CFLAGS="-O2" CXX=gcc CXXFLAGS="-O2
-felide-constructors" ./configure --prefix=/usr/local/mysql
--with-extra-charsets=complex --enable-thread-safe-client
--enable-local-infile --disable-shared
--with-client-ldflags=-all-static
--with-mysqld-ldflags=-all-static
Linux 2.4.xx x86_64 (AMD64) com gcc
3.2.1
CXX=gcc ./configure --prefix=/usr/local/mysql
--with-extra-charsets=complex --enable-thread-safe-client
--enable-local-infile --disable-shared
Sun Solaris 8 x86 com gcc
3.2.3
CC=gcc CFLAGS="-O3 -fno-omit-frame-pointer" CXX=gcc
CXXFLAGS="-O3 -fno-omit-frame-pointer -felide-constructors
-fno-exceptions -fno-rtti" ./configure
--prefix=/usr/local/mysql
--localstatedir=/usr/local/mysql/data
--libexecdir=/usr/local/mysql/bin
--with-extra-charsets=complex --enable-thread-safe-client
--enable-local-infile --disable-shared
--with-innodb
Sun Solaris 8 sparc com gcc
3.2
CC=gcc CFLAGS="-O3 -fno-omit-frame-pointer" CXX=gcc
CXXFLAGS="-O3 -fno-omit-frame-pointer -felide-constructors
-fno-exceptions -fno-rtti" ./configure
--prefix=/usr/local/mysql --with-extra-charsets=complex
--enable-thread-safe-client --enable-local-infile
--enable-assembler --with-named-z-libs=no
--with-named-curses-libs=-lcurses --disable-shared
Sun Solaris 8 sparc 64bit com gcc
3.2
CC=gcc CFLAGS="-O3 -m64 -fno-omit-frame-pointer"
CXX=gcc CXXFLAGS="-O3 -m64 -fno-omit-frame-pointer
-felide-constructors -fno-exceptions -fno-rtti" ./configure
--prefix=/usr/local/mysql --with-extra-charsets=complex
--enable-thread-safe-client --enable-local-infile
--enable-assembler --with-named-z-libs=no
--with-named-curses-libs=-lcurses --disable-shared
Sun Solaris 9 sparc com gcc
2.95.3
CC=gcc CFLAGS="-O3 -fno-omit-frame-pointer" CXX=gcc
CXXFLAGS="-O3 -fno-omit-frame-pointer -felide-constructors
-fno-exceptions -fno-rtti" ./configure
--prefix=/usr/local/mysql --with-extra-charsets=complex
--enable-thread-safe-client --enable-local-infile
--enable-assembler --with-named-curses-libs=-lcurses
--disable-shared
Sun Solaris 9 sparc com cc-5.0
(Sun Forte
5.0)
CC=cc-5.0 CXX=CC ASFLAGS="-xarch=v9" CFLAGS="-Xa
-xstrconst -mt -D_FORTEC_ -xarch=v9" CXXFLAGS="-noex -mt
-D_FORTEC_ -xarch=v9" ./configure --prefix=/usr/local/mysql
--with-extra-charsets=complex --enable-thread-safe-client
--enable-local-infile --enable-assembler
--with-named-z-libs=no --enable-thread-safe-client
--disable-shared
IBM AIX 4.3.2 ppc com gcc
3.2.3
CFLAGS="-O2 -mcpu=powerpc -Wa,-many " CXX=gcc
CXXFLAGS="-O2 -mcpu=powerpc -Wa,-many -felide-constructors
-fno-exceptions -fno-rtti" ./configure
--prefix=/usr/local/mysql --with-extra-charsets=complex
--enable-thread-safe-client --enable-local-infile
--with-named-z-libs=no --disable-shared
IBM AIX 4.3.3 ppc com xlC_r
(IBM Visual
Age C/C++ 6.0)
CC=xlc_r CFLAGS="-ma -O2 -qstrict -qoptimize=2
-qmaxmem=8192" CXX=xlC_r CXXFLAGS ="-ma -O2 -qstrict
-qoptimize=2 -qmaxmem=8192" ./configure
--prefix=/usr/local/mysql
--localstatedir=/usr/local/mysql/data
--libexecdir=/usr/local/mysql/bin
--with-extra-charsets=complex --enable-thread-safe-client
--enable-local-infile --with-named-z-libs=no
--disable-shared --with-innodb
IBM AIX 5.1.0 ppc com gcc
3.3
CFLAGS="-O2 -mcpu=powerpc -Wa,-many" CXX=gcc
CXXFLAGS="-O2 -mcpu=powerpc -Wa,-many -felide-constructors
-fno-exceptions -fno-rtti" ./configure
--prefix=/usr/local/mysql --with-extra-charsets=complex
--with-server-suffix="-pro" --enable-thread-safe-client
--enable-local-infile --with-named-z-libs=no
--disable-shared
HP-UX 10.20 pa-risc1.1 com gcc
3.1
CFLAGS="-DHPUX -I/opt/dce/include -O3 -fPIC"
CXX=gcc CXXFLAGS="-DHPUX -I/opt/dce /include
-felide-constructors -fno-exceptions -fno-rtti -O3 -fPIC"
./configure --prefix=/usr/local/mysql
--with-extra-charsets=complex --enable-thread-safe-client
--enable-local-infile --with-pthread
--with-named-thread-libs=-ldce --with-lib-ccflags=-fPIC
--disable-shared
HP-UX 11.11 pa-risc2.0 64 bit com aCC
(HP
ANSI C++ B3910B A.03.33)
CC=cc CXX=aCC CFLAGS=+DD64 CXXFLAGS=+DD64
./configure --prefix=/usr/local/mysql
--with-extra-charsets=complex --enable-thread-safe-client
--enable-local-infile --disable-shared
HP-UX 11.11 pa-risc2.0 32bit com aCC
(HP
ANSI C++ B3910B A.03.33)
CC=cc CXX=aCC CFLAGS="+DAportable"
CXXFLAGS="+DAportable" ./configure --prefix=/usr/local/mysql
--localstatedir=/usr/local/mysql/data
--libexecdir=/usr/local/mysql/bin
--with-extra-charsets=complex --enable-thread-safe-client
--enable-local-infile --disable-shared
--with-innodb
Apple Mac OS X 10.2 powerpc com gcc
3.1
CC=gcc CFLAGS="-O3 -fno-omit-frame-pointer" CXX=gcc
CXXFLAGS="-O3 -fno-omit-frame-pointer -felide-constructors
-fno-exceptions -fno-rtti" ./configure
--prefix=/usr/local/mysql --with-extra-charsets=complex
--enable-thread-safe-client --enable-local-infile
--disable-shared
FreeBSD 4.7 i386 com gcc
2.95.4
CFLAGS=-DHAVE_BROKEN_REALPATH ./configure
--prefix=/usr/local/mysql --with-extra-charsets=complex
--enable-thread-safe-client --enable-local-infile
--enable-assembler --with-named-z-libs=not-used
--disable-shared
QNX Neutrino 6.2.1 i386 with gcc
2.95.3qnx-nto 20010315
CC=gcc CFLAGS="-O3 -fno-omit-frame-pointer" CXX=gcc
CXXFLAGS="-O3 -fno-omit-frame-pointer -felide-constructors
-fno-exceptions -fno-rtti" ./configure
--prefix=/usr/local/mysql --with-extra-charsets=complex
--enable-thread-safe-client --enable-local-infile
--disable-shared
Os seguintes binários são contruídos em sistemas de terceiros gentilmente cedidos para a MySQL AB pou outros usuários. Pou favor, note que eles só são fornecidos como cortesia. Uma vez que a MySQL AB não tem total controle sobre estes sistemas, nós podemos fornecer apenas suporte limitado para os binários construídos nestes sistemas.
SCO Unix 3.2v5.0.6 i386 com gcc
2.95.3
CFLAGS="-O3 -mpentium" LDFLAGS=-static CXX=gcc
CXXFLAGS="-O3 -mpentium -felide-constructors" ./configure
--prefix=/usr/local/mysql --with-extra-charsets=complex
--enable-thread-safe-client --enable-local-infile
--with-named-z-libs=no --enable-thread-safe-client
--disable-shared
SCO OpenUnix 8.0.0 i386 com CC
3.2
CC=cc CFLAGS="-O" CXX=CC ./configure
--prefix=/usr/local/mysql --with-extra-charsets=complex
--enable-thread-safe-client --enable-local-infile
--with-named-z-libs=no --enable-thread-safe-client
--disable-shared
Compaq Tru64 OSF/1 V5.1 732 alpha com
cc/cxx
(Compaq C V6.3-029i / DIGITAL C++
V6.1-027)
CC="cc -pthread" CFLAGS="-O4 -ansi_alias -ansi_args
-fast -inline speed -speculate all" CXX="cxx -pthread"
CXXFLAGS="-O4 -ansi_alias -fast -inline speed -speculate all
-noexceptions -nortti" ./configure --prefix=/usr/local/mysql
--with-extra-charsets=complex --enable-thread-safe-client
--enable-local-infile --with-prefix=/usr/local/mysql
--with-named-thread-libs="-lpthread -lmach -lexc -lc"
--disable-shared --with-mysqld-ldflags=-all-static
SGI Irix 6.5 IP32 com gcc
3.0.1
CC=gcc CFLAGS="-O3 -fno-omit-frame-pointer"
CXXFLAGS="-O3 -fno-omit-frame-pointer -felide-constructors
-fno-exceptions -fno-rtti" ./configure
--prefix=/usr/local/mysql --with-extra-charsets=complex
--enable-thread-safe-client --enable-local-infile
--disable-shared
FreeBSD 5.0 sparc64 com gcc
3.2.1
CFLAGS=-DHAVE_BROKEN_REALPATH ./configure
--prefix=/usr/local/mysql
--localstatedir=/usr/local/mysql/data
--libexecdir=/usr/local/mysql/bin
--with-extra-charsets=complex --enable-thread-safe-client
--enable-local-infile --disable-shared
--with-innodb
As seguintes opções de compilação foram usadas nos pacotes binários que a MySQL AB costumava fornecer no passado. Estes binários não são mais atualizados, mas as opções de compilação são mantidas aqui com o propósito de referência.
Linux 2.2.xx sparc com egcs
1.1.2
CC=gcc CFLAGS="-O3 -fno-omit-frame-pointer" CXX=gcc
CXXFLAGS="-O3 -fno-omit-frame-pointer -felide-constructors
-fno-exceptions -fno-rtti" ./configure
--prefix=/usr/local/mysql --with-extra-charsets=complex
--enable-thread-safe-client --enable-local-infile
--enable-assembler --disable-shared
Linux 2.2.x com x686 com gcc
2.95.2
CFLAGS="-O3 -mpentiumpro" CXX=gcc CXXFLAGS="-O3
-mpentiumpro -felide-constructors -fno-exceptions -fno-rtti"
./configure --prefix=/usr/local/mysql --enable-assembler
--with-mysqld-ldflags=-all-static --disable-shared
--with-extra-charsets=complex
SunOS 4.1.4 2 sun4c com gcc
2.7.2.1
CC=gcc CXX=gcc CXXFLAGS="-O3 -felide-constructors"
./configure --prefix=/usr/local/mysql --disable-shared
--with-extra-charsets=complex --enable-assembler
SunOS 5.5.1 (e acima) sun4u com egcs
1.0.3a ou 2.90.27 ou gcc 2.95.2 e mais novo
CC=gcc CFLAGS="-O3" CXX=gcc CXXFLAGS="-O3
-felide-constructors -fno-exceptions -fno-rtti" ./configure
--prefix=/usr/local/mysql --with-low-memory
--with-extra-charsets=complex --enable-assembler
SunOS 5.6 i86pc com gcc
2.8.1
CC=gcc CXX=gcc CXXFLAGS=-O3 ./configure
--prefix=/usr/local/mysql --with-low-memory
--with-extra-charsets=complex
BSDI BSD/OS 3.1 i386 com gcc
2.7.2.1
CC=gcc CXX=gcc CXXFLAGS=-O ./configure
--prefix=/usr/local/mysql
--with-extra-charsets=complex
BSDI BSD/OS 2.1 i386 com gcc
2.7.2
CC=gcc CXX=gcc CXXFLAGS=-O3 ./configure
--prefix=/usr/local/mysql
--with-extra-charsets=complex
AIX 2 4 com gcc
2.7.2.2
CC=gcc CXX=gcc CXXFLAGS=-O3 ./configure
--prefix=/usr/local/mysql
--with-extra-charsets=complex
Qualquer que tenha mais opções otimizadas para qualquer das configurações listadas acima pode sempre enviá-los para a lista de email ``internals'' do MySQL. See Secção 1.7.1.1, “As Listas de Discussão do MySQL”.
Distribuições RPM que anteceda o MySQL versão 3.22 são contribuições dos usuários. Os RPMs gerados por nós da MySQL AB só começaram a ser fornecidos a partir da versão 3.22 do MySQL.
Se você deseja compilar uma versão para depuração do MySQL,
você deve adicionar --with-debug
ou
--with-debug=full
para as linhas de
configuração acima e remover qualquer opção
-fomit-frame-pointer
.
Para distribuições do Windows, por favor, veja Secção 2.1.1, “Instalando o MySQL no Windows”.
Este capítulo cobre a instalação da distribuição binária
do MySQL (.tar.gz
Archives) para várias
plataformas (veja MySQL binaries
para uma
lista detalhada).
Em adição a estes pacotes genéricos, também oferecemos binários em formatos de pacote específicos da plataforma para plataformas selecionadas. Veja Secção 2.1, “Instalação rápida padrão do MySQL” para mais informações sobre como\ intalá-los.
As distribuições genéricas do MySQL estão empacotados com
arquivos GNU tar com compactação gzip
(.tar.gz
). Você precisa das seguintes
ferramentas para instalar um distribuição binária do MySQL:
GNU gunzip
para descompactar a
distribuição.
Um tar
razoável para descompactar a
distribuição. Sabemos que o GNU tar
funciona. Algumas implementações tar
que vêm pré-instaladas como o sistema operacional (ex. Sun
tar
) possuem problemas (com nome de
arquivos grandes, por exemplo) Neste caso, você deve
instalar o GNU tar
primeiro.
Se você tiver problemas, sempre use
mysqlbug
ao enviar dúvidas para a
lista de email do MySQL. Mesmo se o problema não for um bug,
mysqlbug
colhe informações do sistema que
ajudarão os outros a solucionar o seu problema. Se não usar
mysqlbug
, você terá diminuída a
probabilidade de conseguir a solução do seu problema. Você
encontrará o mysqlbug
no diretório
bin
depois de descompactar a
distribuição. See Secção 1.7.1.3, “Como relatar erros ou problemas”.
Os comando básicos que você deve executar para instalar e usar uma distribuição binária do MySQL são:
shell>groupadd mysql
shell>useradd -g mysql mysql
shell>cd /usr/local
shell>gunzip < /path/to/mysql-VERSION-OS.tar.gz | tar xvf -
shell>ln -s full-path-to-mysql-VERSION-OS mysql
shell>cd mysql
shell>scripts/mysql_install_db
shell>chown -R root .
shell>chown -R mysql data
shell>chgrp -R mysql .
shell>bin/mysqld_safe --user=mysql &
Se a sua versão do MySQL é mais antiga que a 4.0, substitua
bin/safe_mysqld
por
bin/mysqld_safe
no comando final.
Você pode adicionar novos usuários usando o script
bin/mysql_setpermission
se você instalar os
módulos Perl DBI
e
DBD-mysql
.
Uma descrição mais detalhada é apresentada a seguir.
Para instalar uma distribuição binária, siga estes passos, então proceda com a Secção 2.4, “Configurações e Testes Pós-instalação”, para a configuração da pós istalação e testes:
Escolha o diretório sob o qual você deseja descompactar a
distribuição e a mova para dentro dele. No exemplo a
seguir, descompactamos a distribuição sob
/usr/local
e criamos um diretório
/usr/local/mysql
dentro do qual o MySQL
é instalado. (As seguintes instruções, consequentemente,
assumem que você tem permissão para criar arquivos em
/usr/local
. Se este diretório é
protegido, você precisará realizar a instalação como
root
.)
Obtenha um arquivo de distribuição de um dos sites listados em Secção 2.2.1, “Como obter o MySQL”.
As distribuições binárias do MySQL são fornecidas como
arquivos tar
compactados e tem nomes como
mysql-VERSÃO-SO.tar.gz
, onde
VERSÃO
é um número (por exemplo,
3.21.15
) e SO
indica o
tipo de sistema operacional para o qual a distribuição é
pretendida (por exemplo,
pc-linux-gnu-i586
).
Se você ver uma distribuição binária marcada com o
sufixo -max
, significa que o binário tem
suporte para tabelas transacionais e outros recursos. See
Secção 4.8.5, “mysqld-max
, om servidor mysqld
extendido”. Note que todos os binários
são contruídos a partir da mesma distribuição fonte do
MySQL.
Adicione um usuário e grupo para o
mysqld
ser executado:
shell>groupadd mysql
shell>useradd -g mysql mysql
Estes comandos adicionam o grupo mysql
e
o usuário mysql
. A sintaxe para
useradd
e groupadd
podem diferir um pouco nas diversas versões de Unix. Eles
tambémpodem ser chamado adduser
e
addgroup
. Você pode desejar criar o
grupo e usuário com outro nome, diferente de
mysql
.
Chame o diretório no qual se pretende fazer a instalação:
shell> cd /usr/local
Descompacte a distribuição, que criará o diretório de instalação. Então crie um link simbólico para aquele diretório:
shell>gunzip < /path/to/mysql-VERSÃO-SO.tar.gz | tar xvf -
shell>ln -s full-path-to-mysql-VERSÃO-SO mysql
O primeiro comando cria um diretório chamado
mysql-VERSÃO-SO
. O segundo comando
cria um link simbólico para o diretório. Isto torna a
referência ao diretório de instalação mais fácil,
chamado como /usr/local/mysql
.
Altere para p diretório de instalação:
shell> cd mysql
Você encontrará diversos arquivos e subdiretórios no
diretório mysql
. O mais importante para
propósitos de instalação são os subdiretórios
bin
e scripts
.
Este diretório contém o programa cliente e o servidor.
Você deve adicionar o caminho completo deste diretório
a sua variável de ambiente PATH
e
assim a sua shell encontrará o programa MySQL de forma
apropriada. See Apêndice F, Variáveis de Ambientes do MySQL.
scripts
Este diretório contém o script
mysql_install_db
usado para
inicializar o banco de dados mysql
contendo a tabela de permissões que armazenam o
servidor de permissões de acesso.
Caso você desejasse usar o mysqlaccess
e
a distribuição do MySQL está em um local diferente do
padrão, você deve alterar a localização para onde o
mysqlaccess
espera encontrar o cliente
mysql
. Edite o script
bin/mysqlaccess
aproximadamente na
linha 18. Procure pela linha que se parece com a apresentada
abaixo:
$MYSQL = '/usr/local/bin/mysql'; # path to mysql executable
Altere o caminho para o local onde o
mysql
atualmente está armazaenado em seu
sistema. Se você não fizer isto receberá uma mensagem de
erro Broken pipe
quando executar o
mysqlaccess
.
Crie as tabelas de permissão do MySQL (necessário apenas se você não tiver instalado o MySQL anteriormente):
shell> scripts/mysql_install_db
Note que as versões mais antigas que a 3.22.10 iniciam o
servidor MySQL quando você executa o
mysql_install_db
. Isto não ocorre mais.
Altere o proprietário dos binários para o
root
e o proprietário do diretório de
dados para o usuário com o quel você executará o
mysqld
:
shell>chown -R root /usr/local/mysql/.
shell>chown -R mysql /usr/local/mysql/data
shell>chgrp -R mysql /usr/local/mysql/.
O primeiro comando altera o atributo
owner
dos arquivos para o usuário
root
, o segundo altera o atributo
owner
do diretório de dados para o
usuário mysql
e o terceiro altera o
atributo group
para o grupo
mysql
.
Se você quiser instalar o suporte para a interface Perl
DBI
/DBD
, veja
Secção 2.7, “Comentários de Instalação do Perl”.
Se você desejasse que o MySQL seja iniciado automaticamente
quando você iniciar a sua máquina, você pode copiar
support-files/mysql.server
para o local
onde o seu sistema tem os arquivos de inicialização. Mais
informações podem ser encontradas no script
support-files/mysql.server
e em
Secção 2.4.3, “Inicializando e parando o MySQL automaticamente.”.
Depois de tudo estar descompactado e instalado, você deve inicializar e testar a sua distribuição.
Você pode iniciar o servidor MySQL com o seguinte comando:
shell> bin/mysqld_safe --user=mysql &
Se a sua versão do MySQl for mais antiga do que a 4.0,
substitua bin/safe_mysqld
por
bin/mysqld_safe
no comando.
Agora prossiga com Secção 4.8.2, “mysqld-safe
, o wrapper do mysqld
” e See
Secção 2.4, “Configurações e Testes Pós-instalação”.
Antes de você continuar com as instalações dos fontes, confira antes se nosso binário está disponível para sua plataforma e se ela funcionará para você. Nós colocamos muito esforço para ter certeza que nossos binários são contruídos com as melhores opções possíveis.
Você precisa das seguintes ferramentas para contruir e instalar o MySQL a partir do código fonte:
GNU gunzip
para descompactar a
distribuição.
Um tar
razoável para desempacotar a
distribuição. Sabe-se que o GNU tar
funciona. Algumas implementações tar
que
vêm pré-instaladas como o sistema operacional (ex. Sun
tar
) possuem problemas (com nome de
arquivos grandes, por exemplo) Neste caso, você deve instalar
o GNU tar
primeiro.
Um compilador ANSI C++ funcional. gcc
>=
2.95.2, egcs
>= 1.0.2 ou egcs
2.91.66
, SGI C++, e SunPro C++ são alguns dos
compiladores que sabemos que funcionam. A
libg++
não é necessária quando o
gcc
for usado. gcc
2.7.x
tem um bug que torna impossível compilar alguns arquivos C++
perfeitamente corretos, como o
sql/sql_base.cc
. Se você possui somente
o gcc
2.7.x você deve atualiza-lo para
conseguir compilar o MySQL. gcc
2.8.1 é
também conhecido por ter problemas em algumas plataformas
portanto ele deve ser evitado se existir um novo compilador
para a plataforma.
gcc
>= 2.95.2 é recomendado quando
compilar o MySQL Versão 3.23.x.
Um bom programa make
. GNU
make
é sempre recomendado e é algumas
vezes necessário. Se você tiver problemas, recomendamos
tentar o GNU make
3.75 ou mais novo.
Se você estiver usando uma versão recente de
gcc, recente o bastante para
entender a opção -fno-exceptions
, é
MUITO IMPORTANTE que você a use.
De outra forma, você pode compilar um binário que quebra
randomicamente. Nós também recomendamos que você use
-felide-constructors
e
-fno-rtti
juntas com
-fno-exception
. Se estiver com dúvidas, faça
o seguinte:
CFLAGS="-O3" CXX=gcc CXXFLAGS="-O3 -felide-constructors -fno-exceptions \ -fno-rtti" ./configure --prefix=/usr/local/mysql --enable-assembler \ --with-mysqld-ldflags=-all-static
Na maioria dos sistemas você irá obter um binário rápido e estável com essas opções.
Se você tiver problemas, SEMPRE USE
mysqlbug
quando postar questões
para a lista de email do MySQL Mesmo se o problema não for um
bug, mysqlbug
recolhe informações do sistema
que facilitará aos outros resolverem seu problema. Por não suar
mysqlbug
, você perde a vantagem de ter seu
problema resolvido! Você irá encontrar
mysqlbug
no diretório
scripts
depois de desempacotar a
distribuição. See Secção 1.7.1.3, “Como relatar erros ou problemas”.
Os comandos básicos que você deve executar para instalar o MysQL a partir da distribuição fonte são:
shell>groupadd mysql
shell>useradd -g mysql mysql
shell>gunzip < mysql-VERSION.tar.gz | tar -xvf -
shell>cd mysql-VERSION
shell>./configure --prefix=/usr/local/mysql
shell>make
shell>make install
shell>scripts/mysql_install_db
shell>chown -R root /usr/local/mysql
shell>chown -R mysql /usr/local/mysql/var
shell>chgrp -R mysql /usr/local/mysql
shell>cp support-files/my-medium.cnf /etc/my.cnf
shell>/usr/local/mysql/bin/mysqld_safe --user=mysql &
Se a sua versão do MySQL é mais antiga que a 4.0, substitua
bin/safe_mysqld
por
bin/mysqld_safe
no comando final.
Se você deseja ter suporte para tabelas InnoDB, você deve
editar o arquivo /etc/my.cnf
e remover o
caractere #
antes dos parâmetros que iniciam
com innodb_...
. See
Secção 4.1.2, “Arquivo de Opções my.cnf
”. See
Secção 7.5.3, “Opções de Inicialização do InnoDB”.
Se você iniciar de um RPM fonte, então faça o seguinte:
shell> rpm --rebuild --clean MySQL-VERSION.src.rpm
Isto irá criar um RPM binário que você pode instalar.
Você pode adicionar novos usuários utilizando o script
bin/mysql_setpermission
se você instalar os
módulos Perl DBI
e
DBD-mysql
.
Segue uma descrição mais detalhada.
Para instalar uma distribuição fonte, siga os passos a seguir, então prossiga para Secção 2.4, “Configurações e Testes Pós-instalação”, para inicialização do pós-instalação e testes:
Escolha o diretório sobre o qual você deseja descompactar a distribuição e vá para ele.
Obtenha um arquivo de distribuição de algum dos sites listados em Secção 2.2.1, “Como obter o MySQL”.
Se você esta interessado em usar tabelas Berkeley DB com
MySQL, você precisará obter uma versão com o patch do
código fonte do Berkeley DB. Por favor leia o capítulo
sobre tabelas Berkeley DB antes de continuar. See
Secção 7.6, “Tabelas BDB
ou BerkeleyDB
”.
Distribuições fontes do MySQL são fornecidas como
arquivos tar
compactados e tem nomes como
mysql-VERSION.tar.gz
, onde
VERSION
é um número como 5.0.6-beta.
Adicione um usuário e grupo para o mysql
executar assim:
shell>groupadd mysql
shell>useradd -g mysql mysql
Estes comandos adicionam o grupo mysql
e
o usuário mysql
. A sintaxe para
useradd
e groupadd
podem mudar um pouco em diferentes versões de Unix. Elas
podem também ser chamadas adduser
e
addgroup
. Você pode escolher outros
nomes para o usuário e grupo em vez de
mysql
.
Descompacte a distribuição para o diretório corrente:
shell> gunzip < /path/to/mysql-VERSION.tar.gz | tar xvf -
Este comando cria um diretório com o nome
mysql-VERSION
.
Mude para o diretório da distribuição descompactada:
shell> cd mysql-VERSION
Note que agora você deve configurar e construir o MySQL a partir deste diretório raiz da distribuição. Você não pode construí-lo em um diretório diferente.
Configure o release e compile tudo:
shell>./configure --prefix=/usr/local/mysql
shell>make
Quando você executar configure
, você
pode desejar especificar algumas opções. Execute
./configure --help
para uma lista das
opções. Secção 2.3.3, “Opções típicas do configure
”, discute
algumas das opções mais usadas.
Se o configure
falhar, e você for enviar
uma mensagem para lista de email do MySQL para pedir ajuda,
por favor, inclua qualquer linhas de
config.log
que você acha que pode
ajudar a resolver o problema. Também inclua as últimas
linhas da saída de configure
se o
configure
abortar. Envie o relatório de
erros usando o script mysqlbug
. See
Secção 1.7.1.3, “Como relatar erros ou problemas”.
Se a compilação falhar, veja Secção 2.3.5, “Lidando com Problemas de Compilação”, para uma ajuda com um varios problemas comuns.
Instalar tudo:
shell> make install
Você deve executar este comando como
root
.
Crie as tabelas de permissões do MySQL (necessárias só se você não tiver instalado o MySQL anteriormente):
shell> scripts/mysql_install_db
Note que as versões do MySQL anteriores à versão 3.22.10
iniciam o servidor MySQL quando você executa
mysql_install_db
. Isto não acontece
mais!
Altere o dono dos binários para root
e
do diretório dados para o usuário que irá executar o
mysqld
:
shell>chown -R root /usr/local/mysql
shell>chown -R mysql /usr/local/mysql/var
shell>chgrp -R mysql /usr/local/mysql
O primeiro comando altera o atributo de
proriedade
dos arquivos para o usuário
root
, o segundo altera o atributo de
propriedade
do diretório de dados para o
usuário mysql
, e o terceiro altera o
atributo de grupo
para o grupo
mysql
.
Se você deseja instalar suporte para a interface Perl
DBI
/DBD
, veja
Secção 2.7, “Comentários de Instalação do Perl”.
Se você deseja que o MySQL inicie automaticamente quando
você ligar sua máquina, você pode copiar
support-files/mysql.server
para o local
onde seu sistema tem seus arquivos de incialização. Mais
informações podem ser encontradas no próprio script
support-files/mysql.server
e em
Secção 2.4.3, “Inicializando e parando o MySQL automaticamente.”.
Depois de tudo ter sido instalado, você deve iniciar e testar sua distribuição usando este comando:
shell> /usr/local/mysql/bin/mysqld_safe --user=mysql &
Se a sua versão do MySQL for mais antiga do que 4.0, substitua
safe_mysqld
por
mysqld_safe
no comando:
Se o comando falhar imediatamente com mysqld daemon
ended
então você pode achar alguma informação no
arquivo
diretório-dados-mysql/'nome_maquina'.err
.
A razão pode ser que você já possua outro servidor
mysqld
sendo executado. See
Secção 4.2, “Executando Múltiplos MySQL Servers na Mesma Máquina”.
Algumas vezes patches aparecem na lista de mensagens ou são colocados na área de patches do MySQL. (http://www.mysql.com/downloads/patches.html).
Para aplicar um patch da lista de mensagens, salve a mensagem em que o patch aparece em um arquivo, mude para o diretório raiz da sua distribuição fonte de seu MySQL e execute estes comandos:
shell>patch -p1 < patch-file-name
shell>rm config.cache
shell>make clean
Patches do site FTP são distribuídos como arquivos texto ou
como arquivos compactados com gzip
. Aplique
um patch no formato texto como mostrado acima para patches da
lista de mensagens. Para aplicar um patch compactado, mude para
o diretório raiz da árvore fonte do MySQL e execute estes
comandos:
shell>gunzip < patch-file-name.gz | patch -p1
shell>rm config.cache
shell>make clean
Depois de aplicar um patch siga as instruções para uma
instalação normal a partir dos fontes começando com o passo
./configure
. Depois de executar o passo
make install
, reinicie seu servidor MySQL.
Você pode precisar derrubar algum servidor atualmente em
execução antes de executar make install
.
(Use mysqladmin shutdown
para fazer isto.)
Alguns sistemas não lhe permitem instalar uma nova versão do
programa se ele substitui agum que estiver em execução.
O script configure
fornece uma grande gama de
controle sobre como você configura sua distribuição MySQL.
Normalmente você faz isto usando opções na linha de comando
do configure
. Você também pode alterar
configure
usando algumas variáveis de
ambiente. See Apêndice F, Variáveis de Ambientes do MySQL. Para uma
lista de opções suportadas pelo configure
,
execute este comando:
shell> ./configure --help
Algumas das opções mais usadas normalmente com o
configure
estão descritas a seguir:
Para compilar apenas as bibliotecas clientes do MySQL e
programas clientes e não o servidor, use a opção
--without-server
:
shell> ./configure --without-server
Se você não possui um compilador C++,
mysql
não irá compilar (ele é o
programa cliente que exige C++). Neste caso, você pode
remover o código no configure
que testa
pelo compilador C++ e executar
./configure
com a opção
--without-server
. O passo da compiação
continuará tentaindo construir mysql
,
mas você pode ignorar as advertências sobre
mysql.cc
. (Se o make
parar, tente make -k
para continuar com o
resto da compilação mesmo se erros ocorrerem.)
Se você quiser uma biblioteca embutida do MySQL
(libmysqld.a
) você deve usar a opção
--with-embedded-server
.
Se você não deseja que seus arquivos de logs e diretórios
de bancos de dados fiquem localizados sobre
/usr/local/var
, use o comando
configure
; algo parecido com um destes:
shell>./configure --prefix=/usr/local/mysql
shell>./configure --prefix=/usr/local \
--localstatedir=/usr/local/mysql/data
O primeiro comando altera o diretório instalação para que
tudo seja instalado sobre
/usr/local/mysql
em vez do padrão
/usr/local
. O segundo comando preserva
o diretório da instalação padrão, mas altera a
localização padrão para diretórios de bancos de dados
(normalmente /usr/local/var
) e altera
para /usr/local/mysql/data
. Depois de ter
compilado o MySQL, você pode alterar estas opçãoes com
arquivos de opções. See Secção 4.1.2, “Arquivo de Opções my.cnf
”.
Se você estiver usando Unix e deseja que o arquivo socket
do MySQL fique em um diretório diferente do padrão
(normalmente no diretório /tmp
ou
/var/run
) use o comando
configure
da seguinte forma:
shell> ./configure --with-unix-socket-path=/usr/local/mysql/tmp/mysql.sock
Perceba que o arquivo fornecido deve ter um caminho absoluto
! Você também pode, mais tarde, alterar a localização de
mysql.sock
usando os arquivos de
opções do MySQL. See
Secção A.4.5, “Como Proteger ou AlterarHow to Protect or Change the MySQL Socket File /tmp/mysql.sock
”.
Se você deseja compilar programas linkeditados
estaticamente (por exemplo, para criar uma distribuição
binária, obter mais velocidade, ou evitar problemas com
algumas distribuições Red Hat Linux), execute
configure
desta forma:
shell>./configure --with-client-ldflags=-all-static \
--with-mysqld-ldflags=-all-static
Se você estiver usando gcc
e não tem
libg++
ou libstdc++
instalados você pode dizer ao configure
para usar o gcc
como seu compilador C++:
shell> CC=gcc CXX=gcc ./configure
Quando você usar como
seu compilador
C++, ele não tentará ligar com o libg++
ou libstdc++
. Isto pode ser uma boa
idéia para se fazer se você tiver as bibliotecas acimas
instaladas, já que algumas versões destas bibliotecas tem
causado problemas estranhos para usuários do MySQL no
passado.
Segue algumas configurações de variáveis de ambiente comuns, dependendo do compilador que você estiver usando:
Compiler | Recommended options |
gcc 2.7.2.1 | CC=gcc CXX=gcc CXXFLAGS="-O3 -felide-constructors" |
egcs 1.0.3a | CC=gcc CXX=gcc CXXFLAGS="-O3 -felide-constructors -fno-exceptions -fno-rtti" |
gcc 2.95.2 | CFLAGS="-O3 -mpentiumpro" CXX=gcc CXXFLAGS="-O3 -mpentiumpro \ -felide-constructors -fno-exceptions -fno-rtti" |
pgcc 2.90.29 or newer | CFLAGS="-O3 -mpentiumpro -mstack-align-double" CXX=gcc \ CXXFLAGS="-O3 -mpentiumpro -mstack-align-double -felide-constructors \ -fno-exceptions -fno-rtti" |
Na maioria dos casos você pode obter um binário MySQL razoavelmente otimizado usando as opções acima e adicionar as seguintes opções para a linha de configuração:
--prefix=/usr/local/mysql --enable-assembler \ --with-mysqld-ldflags=-all-static
A linha completa de configuração deverá ser, em outras palavras, algo como o seguinte para todas as versões recentes do gcc:
CFLAGS="-O3 -mpentiumpro" CXX=gcc CXXFLAGS="-O3 -mpentiumpro \ -felide-constructors -fno-exceptions -fno-rtti" ./configure \ --prefix=/usr/local/mysql --enable-assembler \ --with-mysqld-ldflags=-all-static
Os binários que fornecemos no site Web MySQL em http://www.mysql.com são todos compilados com otimização plena e deve ser perfeito para a maioria dos usuários. See Secção 2.2.8, “Binários MySQL compilados pela MySQL AB”. Existem algumas definições de configuração que você pode alterar para criar um binário ainda mais rápido, mas isto é somente para usuários avançados. See Secção 5.5.3, “Como a Compilação e a Ligação Afetam a Velocidade do MySQL”.
Se a construção falhar e produzir erros sobre seu
compilador ou linkeditor não estarem aptos para criarem a
biblioteca compartilhada
libmysqlclient.so.r#
('r#
' é um número de versão), você
pode evitar este problema fornecendo a opção
--disable-share
para o
configure
. Neste caso,
configure
não construirá uma biblioteca
libmysqlclient.so.*
compartilhada.
Você pode configurar o MySQL para não usar valores de
campos DEFAULT
para campos
não-NULL
(isto é, campos que não podem
ser NULL
). See
Secção 1.8.5.2, “Restrições de NOT NULL
”.
shell> CXXFLAGS=-DDONT_USE_DEFAULT_FIELDS ./configure
Por padrão, o MySQL usa o conjunto de caracteres ISO-8859-1
(Latin1). Para alterar o conjunto padrão, use a opção
--with-charset
:
shell> ./configure --with-charset=CHARSET
CHARSET
pode ser um de
big5
, cp1251
,
cp1257
, czech
,
danish
, dec8
,
dos
, euc_kr
,
gb2312
, gbk
,
german1
, hebrew
,
hp8
, hungarian
,
koi8_ru
, koi8_ukr
,
latin1
, latin2
,
sjis
, swe7
,
tis620
, ujis
,
usa7
, ou win1251ukr
.
See Secção 4.7.1, “O Conjunto de Caracteres Utilizado para Dados e Ordenação”.
Se você desja converter os caracteres entre o servidor e o
cliente, você deve dar uma olhada no comando SET
OPTION CHARACTER SET
. See
Secção 5.5.6, “Sintaxe de SET
”.
Cuidado: Se você alterar o
conjunto de caracteres depois de ter criado qualquer tabela,
você deve executar myisamchk -r -q
--set-character--set=charset
em cada tabela. Seus
índices podem ser ordenados incorretamente. (Isto pode
acontecer se você instalar o MySQL, criar algumas tabelas,
depois reconfigurar o MySQL para usar um conjunto diferente
de caracteres e reinstalá-lo).
Com a opção --with-extra-charset=LISTA
você pode definir qual conjunto de caracteres adicionais
deve ser compilado no servidor.
Aqui LISTA
é uma lista de conjuntos de
caracteres separados por espaços,
complex
para incluir todos caracteres que
não podem ser carregados dinamicamente ou
all
para incluir todos os conjuntos nos
binários.
Para configurar o MySQL com código para depuração, use a
opção --with-debug
:
shell> ./configure --with-debug
Isto inclui uma alocação segura de memória que pode encontrar alguns erros e fornecer saída sobre o que está acontecendo. See Secção E.1, “Depurando um Servidor MySQL”.
Se seus programas clientes usam threads, você precisará
também compilar uma versão thread-safe da biblioteca
cliente do MySQL com as opções do configure
--enable-thread-safe-client
. Isto irá
criar uma biblioteca libmysqlclient_r
com
o qual você deverá ligar suas aplicações que fazem uso
de threads. See Secção 12.1.14, “Como Fazer um Cliente em Threads”.
Opções que pertençam a sistemas particulares podem ser encontrados na seção com detalhes específicos de sistemas neste manual. See Secção 2.6, “Notas específicas para os Sistemas Operacionais”.
CUIDADO: Você deve ler esta seção somente se você estiver interessado em nos ajudar a testar nossos novos códigos. Se você só deseja deixar o MySQL funcionando em seus sistema, você deve usar uma distribuição padrão (pode ser uma distribuição binária ou fonte).
Para obter noss mais nova árvore de desenvolvimento, use estas instruções:
Faça download do BitKeeper em http://www.bitmover.com/cgi-bin/download.cgi. Você precisará do Bitkeeper 3.0 ou posterior para acessar nosso repositório.
Siga as instruções para instalá-lo.
Depois que o BitKeeper estiver instalado, primeiro vá ao diretório no qual você deseja trabalhar e então use um dos seguintes comandos para clonar o ramo da versão MySQL de sua escolha:
Para clonar o ramo 3.23 (antigo), use este comando:
shell> bk clone bk://mysql.bkbits.net/mysql-3.23 mysql-3.23
Para clonar o ramo 4.0 (estável/produção), use este comando:
shell> bk clone bk://mysql.bkbits.net/mysql-4.0 mysql-4.0
Para clonar o ramo 4.1 alfa, use este comando:
shell> bk clone bk://mysql.bkbits.net/mysql-4.1 mysql-4.1
Para clonar o ramo de desenvolvimento 5.0, use este comando:
shell> bk clone bk://mysql.bkbits.net/mysql-5.0 mysql-5.0
Nos exemplos anteriores a árvore binária será configurada
no subdiretório mysql-3.23/
,
mysql-4.0/
,
mysql-4.1/
, ou
mysql-5.0/
do diretório atual.
Se você está atrás de um firewall e só pode iniciar
conexões HTTP, você também pode o
BitKeeper
via HTTP.
Se vocÊ precisa usar um servidor proxy, simplesmente
configure a variável de ambiente
http_proxy
para apontar para o seu proxy:
shell> export http_proxy="http://seu.servidor.proxy:8080/"
Agora, simplesmente substitua o bk://
com
o http://
ao fazer um clone. Exemplo:
shell> bk clone http://mysql.bkbits.net/mysql-4.1 mysql-4.1
O download inicial da árvore fonte pode demorar um pouco, dependendo da velocidade de sua conexão; seja paciente.
Você precisará do GNU
make
, autoconf 2.53 (ou
posterior)
, automake 1.5
,
libtool 1.4
e m4
para
executar o próximo conjunto de comandos. Embora muitos
sistemas operacionais já venham com suas próprias
implementações do make
, as chances de
que a sua compilação falhe com mensagens de erros
estranhas são altas. Consequentemente é altamente
recomendado usar o GNU make
(algumas
vezes também chamado gmake
).
Felizmente, um grande número de sistemas operacionais já vem com a ferramente GNU pré instalada ou são fornecidos pacotes de instalação da mesma. De qualquer forma, elas podem ser encontradas nos seguintes locais:
Se você estiver tentando configurar o MySQL 4.1 você
também precisará do bison 1.75
.
Versões mais antigas do bison
podem
exiobir este erro: sql_yacc.yy:#####: fatal error:
maximum table size (32767) exceeded
. Nota: o
tamanho máximo da tabela não é realmente excedido, o erro
é causado por um bug nas versões mais novas do
bison
.
Versões do MySQL anteriores a 4.1 podem também compilar
com outras implementações yacc
(e.g.
BSD yacc
91.7.30). Para versões
posteriores, GNU bison
é uma exigência.
O comando comum para fazer em uma shell é:
cd mysql-4.0 bk -r edit aclocal; autoheader; autoconf; automake (cd innobase; aclocal; autoheader; autoconf; automake) # for InnoDB (cd bdb/dist; sh s_all ) # for Berkeley DB ./configure # Adicione suas opções favoritas aqui make
Caso apareçam alguns erros estranhos durantes este
estágio, confira se você realmente tem a
libtool
instalada!
Uma coleção de nossos scripts de configuração padrões
está localizada no subdiretório
BUILD/
. Se preferir, você pode usar
BUILD/compile-pentium-debug
. Para
compilar em uma arquitetura diferente, modifique o script
removendo opções que são específicas da arquitetura
Pentium.
Quando a construção estiver pronta, execute make
install
. Seja cuidadoso com isto em uma máquina
de produção; o comando pode sobrescrever sua versão atual
instalada. Se você tem outra instalação do MySQL, nós
recomendamos que você execute
./configure
com valores diferentes para
as opções prefix
,
tcp-port
e
unix-socket-path
que as usadas pelo seu
servidor em produção.
Seja rígido com sua nova instalação e tente fazer com que
os novos recursos falhem. Inicie executando make
test
. See Secção 14.1.2, “Pacotes de Teste do MySQL”.
Se você chegar ao estágio make
e a
distribuição não compilar, por favor relate-o para
<bugs@lists.mysql.com>
. Se você instalou as
últimas versões das ferramentas GNU exigidas, e elas
falharam tentando processar nossos arquivos de
configuração, por favor informe isto também. Entretanto,
se você executar aclocal
e obtêm um
erro de command not found
não o
reporte.Tenha certeza que todas as ferramentas necessárias
estejam instaladas e que sua variável
PATH
esteja corretamente configurada para
que sua shell possa encontrá-la.
Depois da operação inicial bk clone
para obter a árvore fonte, você deve executar bk
pull
periodicamente para obter as atualizações.
Você pode examinar o histórico de alterações para a
árvore com todos os diffs usando bk
sccstool
. Se você ver alguns diffs estranhos ou
código sobre o qual você tenha alguma dúvida, não hesite
em enviar um e-mail para lista de email ``internals'' do
MySQL. See Secção 1.7.1.1, “As Listas de Discussão do MySQL”. Além disso, se
você acha que tem uma idéia melhor em como fazer algo,
envie um email para o mesmo endereço com um patch.
bk diffs
irá produzir um patch para
você após fazer as alterações no código fonte. Se você
não tiver tempo para codificar sua idéia, apenas envie uma
descrição.
BitKeeper tem um ótimo
utilitário de ajudar que você pode acessar via bk
helptool
.
Note que qualquer commit (bk ci
ou
bk citool
) irá disparar o envio da
mensagem com as alterações para nossa lista de email
internos, bem como a submissão openlogging.org usual apenas
com os comentários da alteração. Geralmente você não
precisar usar commit (já que o árvore pública não
permitirá bk push
), mas é preferível
usar o método bk diffs
descrito
arteriormente.
Você também pode procurar alterações, comentários e código fonte online procurando por ex. http://mysql.bkbits.net:8080/mysql-4.1 para MySQL 4.1.
O manual está em uma árvore separad que pode ser clonada com:
shell> bk clone bk://mysql.bkbits.net/mysqldoc mysqldoc
Existe também um árvore pública do BitKeeper para o MySQL Control Center e Connector/ODBC. Eles podem ser clonados da seguintes forma, respectivamente:
Para clonar o MySQL Control center, use o seguinte comando:
shell> bk clone http://mysql.bkbits.net/mysqlcc mysqlcc
Para clonar o Connector/ODBC, use o seguinte comando:
shell> bk clone http://mysql.bkbits.net/myodbc3 myodbc3
Todos programas MySQL compilam de forma limpa sem alertas no
solaris usando gcc
. Em outros sistemas,
alertas podem ocorrer devido a diferenças em arquivos include
dos sistemas. Veja Secção 2.3.6, “Notas MIT-pthreads” para avisos
que podem ocorrer usando MIT-pthreads. Para outros problemas,
confira a lista abaixo.
A solução para vários problemas envolve reconfiguração. Se você precisa reconfigurar, faça notas do seguinte:
Se configure
é executado depois dele já
ter sido chamado, ele pode usar informação que foi colhida
durante a chamada anterior. Esta informação é armazenada
no arquivo config.cache
. Quando
configure
inicia, ele procura por este
arquivo, lê seu conteúdo, se ele existir, assumindo que
aquela informação continua correta. Essa conjetura é
inválida quando você reconfigurar.
Cada vez que você executa configure
,
você deve executar make
de novo para
recompilar. Entretanto, você pode desejar remover primeiro
antigos arquivos objeto de construções anteriores, porque
eles foram compilados usando diferentes opções de
configuração.
Para prevenir antigas informações de configurações ou
arquivos objetos de serem usados, execute estes comandos antes
de re-executar configure
:
shell>rm config.cache
shell>make clean
Uma alternativa, seria executar make
distclean
A lista abaixo descreve alguns dos problemas compilando o MySQL que tem sido encontrados com mais frequencia:
Se você obtêm erros quando
sql_yacc.cc
como os mostrados abaixo,
você provavelmente tem de falta de memória ou espaço de
swap:
Internal compiler error: program cc1plus got fatal signal 11 ou Out of virtual memory ou Virtual memory exhausted
O problema é que gcc
necessita de grande
quantidade de memória para compilar
sql_yacc.cc
com funções inline. Tente
executando configure
com a opção
--with-low-memory
:
shell> ./configure --with-low-memory
Esta opção adiciona -fno-inline
na a
linha de compilação se você estiver usando
gcc
e -O0
se você
estiver usando outro programa. Você deve tentar a opção
--with-low-memory
mesmo se você tiver
muita memória e espaço de swap que você ache ser
suficieente para não ocorrer erros. Este problema tem
ocorrido mesmo em sistemas com boas configurações de
hardware e a opção --with-low-memory
geralmente corrige isto.
Por padrão, configure
escolhe
c++
como o nome do compilador e GNU
c++
liga com -lg++
. Se
você estiver usando gcc
, este
comportamento pode causar problemas durante a compilação,
como o seguinte:
configure: error: installation or configuration problem: C++ compiler cannot create executables.
Você podem também ter problemas durante a compilação
relacionados à g++
,
libg++
ou libstdc++
.
Uma causa destes problemas é que você pode não ter
g++
ou você pode ter
g++
mas não ter o
libg++
ou o libstdc++
.
De uma olhada no arquivo config.log
.
Ele deve conter a razão exata do porque seu compilador C++
não funciona! Para trabalhar evitando estes problemas,
você pode usar gcc
como seu compilador
C++. Tente configurar a variável de ambiente
CXX
para "gcc -O3"
.
Por exemplo:
shell> CXX="gcc -O3" ./configure
Isto funciona porque gcc
compila código
fonte C++ tão bem quanto g++
faz, mas
não ifaz a ligação em libg++
ou
libstdc++
por padrão.
Outra forma de corrigir estes problemas, com certeza, é
instalando g++
, libg++
e libstdc++
. No entanto gostariamos de
lhe recomendar a não usar libg++
ou
libstdc++
com o MySQL já que isto irá
aumentar o tamanho do binário do mysqld sem lhe trazer
nenhum benefício. Algumas versões destas bibliotecas
também tem causado problemas estranhos para os usuários
MySQL no passado.
Usar gcc
como compilador C++ também é
exigido, se você quiser compilar o MySQL com a
funcionalidade RAID (veja Secção 6.5.3, “Sintaxe CREATE TABLE
”
para mais informações sobre tipos de tabela RAID) e você
estiver usando o GNU gcc
versão 3 e
acima. Se você obter erros como estes abaixo durante o
estágio de ligação quando você configurar o MySQL para
compilar com a opção --with-raid
, tente
usar o gcc
como o seu compilador C++
definindo a variável de ambiente CXX
mencionada acima:
gcc -O3 -DDBUG_OFF -rdynamic -o isamchk isamchk.o sort.o libnisam.a ../mysys/libmysys.a ../dbug/libdbug.a ../strings/libmystrings.a -lpthread -lz -lcrypt -lnsl -lm -lpthread ../mysys/libmysys.a(raid.o)(.text+0x79): In function `my_raid_create': : undefined reference to `operator new(unsigned)' ../mysys/libmysys.a(raid.o)(.text+0xdd): In function `my_raid_create': : undefined reference to `operator delete(void*)' ../mysys/libmysys.a(raid.o)(.text+0x129): In function `my_raid_open': : undefined reference to `operator new(unsigned)' ../mysys/libmysys.a(raid.o)(.text+0x189): In function `my_raid_open': : undefined reference to `operator delete(void*)' ../mysys/libmysys.a(raid.o)(.text+0x64b): In function `my_raid_close': : undefined reference to `operator delete(void*)' collect2: ld returned 1 exit status
Se sua compilação falhar com erros, como um dos seguintes,
você deve atualizar sua versão de make
para GNU make
:
making all in mit-pthreads make: Fatal error in reader: Makefile, line 18: Badly formed macro assignment or make: file `Makefile' line 18: Must be a separator (: or pthread.h: No such file or directory
O Solaris e o FreeBSD são conhecidos por terem alguns
problemas com o make
.
O GNU make
versão 3.75 irá funcionar.
Se você deseja definir algumas opções que devem ser
usadas pelo seu compilador C ou C++, adicione as opções
para as variáveis de ambiente CFLAGS
e
CXXFLAGS
. Você pode também especificar
os nomes do compilador a ser usado da mesma forma utilizando
CC
e CXX
. Exemplo:
shell>CC=gcc
shell>CFLAGS=-O3
shell>CXX=gcc
shell>CXXFLAGS=-O3
shell>export CC CFLAGS CXX CXXFLAGS
Olhe em Secção 2.2.8, “Binários MySQL compilados pela MySQL AB” para uma lista de definição de opções que tenham sido úteis em vários sistemas.
Se você recebeu uma mensagem de erro como esta, é
necessário atualizar o compilador gcc
:
O gcc
2.8.1 funciona, mas recomendamos o
uso do gcc
2.95.2 ou
egcs
1.0.3a em seu lugar.
Se você obtem erros como estes vistos abaixo enquanto
estiver compilando o mysqld
, o
configure
não detectou corretamente o
tipo do último argumento para accept()
,
getsockname()
ou
getpeername()
:
cxx: Error: mysqld.cc, line 645: In this statement, the referenced type of the pointer value "&length" is "unsigned long", which is not compatible with "int". new_sock = accept(sock, (struct sockaddr *)&cAddr, &length);
Para corrigir isto, edite o arquivo
config.h
(que é gerado pelo
configure
). Procure por estas linhas:
/* Define as the base type of the last arg to accept */ #define SOCKET_SIZE_TYPE XXX
Altere XXX
para size_t
ou int
, dependendo de seu sistema
operacional. (Perceba que você deverá fazer isto cada vez
que você executar configure
, porque
configure
regenera
config.h
.)
O arquivo sql_yacc.cc
é gerado pelo
sql_yacc.yy
. Normalmente o processo de
construção não necessita criar
sql_yacc.cc
, porque o MySQL já vem com
uma cópia pré-gerada. Entretanto, se você necessita
recriá-lo você pode encontrar este erro:
"sql_yacc.yy", line xxx fatal: default action causes potential...
Isto é um indício de que sua versão do
yacc
é deficiente. Provavelmente você
precisará instalar o bison
(a versão
GNU de yacc
) e usá-lo no lugar do
yacc
.
Se você necessita depurar mysqld
ou um
cliente MySQL, execute configure
com a
opção --with-debug
, então recompile e
ligue seus clientes com a nova biblioteca cliente. See
Secção E.2, “Depurando um cliente MySQL.”.
Se você tem um erro de compilação no Linux (ex. SuSE Linux 8.1 ou Red Hat Linux 7.3) parecido com o seguinte:
libmysql.c:1329: warning: passing arg 5 of `gethostbyname_r' from incompatible pointer type libmysql.c:1329: too few arguments to function `gethostbyname_r' libmysql.c:1329: warning: assignment makes pointer from integer without a cast make[2]: *** [libmysql.lo] Error 1
Por padrão, o script configure
tenta
determinar o número correto de argumentos usando o
compilador GNU C++ g++
. Ele testa os
resultados errados permitidos, se o g++
não está instalado. Existem dois modos de contornar este
problema:
Certifique-se de que o GNU C++ g++
está instalado. Em algumas distribuições Linux, o
pacote exigido é chamado gpp
, em
outro ele é chamado gcc-c++
.
Use o gcc
como o seu compilador C++
configurando a variáavel de ambiente
CXX
para gcc
:
export CXX="gcc"
Note que você precisa executar o
configure
novamente após isto.
Esta seção descreve alguns dos detalhes envolvidos no uso de MIT-pthreads.
Note que no Linux você NÃO
deve usar
MIT-pthreads mas instalar LinuxThreads! See
Secção 2.6.2, “Notas Linux (Todas as versões)”.
Se seu sistema não fornece suporte nativo a thread, você precisará construir o MySQL usando o pacote MIT-pthreads. Isto inclui antigos sistemas FreeBSD, SunOS 4.X, Solaris 2.4 e anteriores entre outros. See Secção 2.2.3, “Sistemas Operacionais suportados pelo MySQL”.
Note que a partir do MySQL 4.0.2, MIT-pthreads não fazem mais parte da distribuição fonte. Se você precisar deste pacote, você precisa fazer o download dele separadamente em http://www.mysql.com/Downloads/Contrib/pthreads-1_60_beta6-mysql.tar.gz
Depois do download, extraia este arquivo fonte no nível mais
alto do diretório de fontes do MySQL. Ele criará um novo
subdiretório mit-pthreads
.
Na maioria dos sitemas, você pode forçar o uso de
MIT-pthreads executando o configure
com a
opção --with-mit-threads
:
shell> ./configure --with-mit-threads
Construção em um diretório não fonte não é suportado com o uso de MIT-pthreads, porque nós queremos minimizar nossas alterações para este código.
As verificações que determinam se MIT-pthreads será usado
ou não, ocorrerá somente durante a parte do processo de
configuração que trata com o código do servidor. Se você
configurou a distribuição usando
--without-server
para construir somente o
código cliente, clientes não irão saber se o MIT-pthreads
está sendo usado e irá usar conexões socket Unix por
padrão. Como os sockets Unix não funcionam sob
MIT-pthreads, isto significa que você precisará usar
-h
ou --host
quando
executar programas clientes.
Quando o MySQL é compilado usando MIT-pthreads, travas de
sistema são desabilitadas por padrão por razões de
performance. Você pode dizer ao servidor para usar travas
de sistema com a opção
--external-locking
. Isto só é necessário
se você quiser executar dois servidores MySQL no mesmo
diretório de dados (no que não é recomendado)
Algumas vezes o comando pthread bind()
falha ao ligar a um socket sem nenhuma mensagem de erro
(pelo menos no Solaris). O resultado é que todas conexões
ao servidor falham. Por exemplo:
shell> mysqladmin version
mysqladmin: connect to server at '' failed;
error: 'Can't connect to mysql server on localhost (146)'
A solução para isto é matar o servidor
mysqld
e reiniciá-lo. Isto só aconteceu
conosco quando forçamos uma queda do servidor e fizemos uma
reinicialização imediata.
Com MIT-pthreads, a chamada de sistema
sleep()
não é interrompível com
SIGINT
(break). Isto só é percebido
quando você executa mysqladmin --sleep
.
Você deve esperar pela chamada sleep()
para terminar, antes da interrução ser servida e o
processo parar.
Na ligação, você pode receber mensagens de alerta como estes (pelo menos no Solaris); elas podem ser ignoradas:
ld: warning: symbol `_iob' has differing sizes: (file /my/local/pthreads/lib/libpthread.a(findfp.o) value=0x4; file /usr/lib/libc.so value=0x140); /my/local/pthreads/lib/libpthread.a(findfp.o) definition taken ld: warning: symbol `__iob' has differing sizes: (file /my/local/pthreads/lib/libpthread.a(findfp.o) value=0x4; file /usr/lib/libc.so value=0x140); /my/local/pthreads/lib/libpthread.a(findfp.o) definition taken
Alguns outros alertas também podem ser ignorados:
implicit declaration of function `int strtoll(...)' implicit declaration of function `int strtoul(...)'
Não colocamos readline
para funcionar
com MIT-pthreads. (Isto não é necessário, mas pode ser
interessante para alguns.)
Estas instruções descrevem como construir o binário do MySQL a partir do fonte paras versões 4.1 e acima no Windows. As instruções são fornecidas para construir binários a partir de uma distribuição fonte padrão ou a partir da árvore do BitKeeper que contém o fonte do desenvolvimento mais atuais.
Nota: As instruções neste documento estão restritas aos usuários que queiram testar o MySQL no Windows a partir da última distribuição fonte ou da árvore do BitKeeper. Para uso em produção, a MySQL AB não aconselha que você utilize um servidor MySQL construído por você mesmo a partir de um fonte. Normalmente é melhor usar uma distribuição binária precompilada do MySQL que é construída especificamente para desempenho otimizado no Windows pela MySQL AB. Instruções para instalar uma distribuição binária está disponível em Secção 2.1.1, “Instalando o MySQL no Windows”.
Para construir o MySQL no Windows a partir do fonte, você precisa dos seguintes compiladores e recursos disoníveis em seu sistema Windows:
Compilador VC++ 6.0 (atualizado com o SP 4 ou 5 e pacote Pre-processador) O pacote Pre-processador é necessário para a macro assembler. Mais detalhes em: http://msdn.microsoft.com/vstudio/downloads/updates/sp/vs6/sp5/faq.aspx.
Aproximadamente 45 MB de espaço em disco.
64 MB de RAM
Você também precisará de um distribuição fonte para o Windows. Existem dois modos de conseguir uma distribuição fonte do MySQL versão 4.1 e acima:
Obtenha um pacote de uma distribuição fonte pela MySQL AB para a versão do MySQL que você está particularmente interessado. Distribuições fontes empacotadas estão disponíveis para versões distribuídas do MySQ e podem ser obtidas em http://www.mysql.com/downloads/.
Você pode empacotar um distribuição fonte você mesmo a partir da ultima árvore fonte de desenvolvimento do BitKeeper. Se você planeja fazer isto, você deve criar o pacote em um sistema Unix e então transfrí-lo para seu sistema Windows. (A razão para isto é que alguns dos passos de configuração e construção exigem ferramentas que funcionam apenas no Unix.) A abordagem do BitKeeper, exige:
Um sistema executando Unix ou um sistema tipo Unix, como o Linux
BitKeeper 3.0 instalado neste sistema. Você pode obter o BitKeeper em http://www.bitkeeper.com/.
Se você estiver usando uma distribuição fonte do Windows, você pode ir diretamente para Secção 2.3.7.1, “Construindo o MySQL Usando VC++”. Para contruir a partir da árvore do BitKeeper, vá para Secção 2.3.7.2, “Criando um Pacote Fonte do Windows a partir da Última Fonte de Desenvolvimento”.
Se você encontrar alguma coisa que não está funcionando como
esperado, ou tiver sugestões sobre o mode de melhorar o
processo de construção atual no Windows, envie uma mensagem
para a lista de email win32
. See
Secção 1.7.1.1, “As Listas de Discussão do MySQL”.
Nota: O MySQL 4.1 e arquivos do espeço de trabalho do VC++ são compatíveis com o Microsoft Visual Studio 6.0 e as edições acima (7.0/.NET) e testados pela equipe da MySQL AB antes de cada distribuição.
Siga este procedimento para construir o MySQL:
Crie um diretório de trabalho (ex.:
workdir
).
Descompacte a distribuição fonte no diretório
mencionado acima usando Winzip
ou outra
ferramenta que possa ler arquivos
.zip
.
Inicie o compilador VC++ 6.0.
No menu File
, selecione Open
Workspace
.
Abra o workspace mysql.dsw
que você
encontrar no diretório de trabalho.
No menu Build
, selcione o menu
Set Active Configuration
.
Clique sobre a tela selecionada mysqld - Win32
Debug
e clique OK.
Pressione F7
para iniciar a
construção da depuração do servidor, bibliotecas e
alguns aplicativos clientes.
Compile as versões distribuídas que você desejar, do mesmo modo.
Versões depuradas dos programas e bibliotecas são
colocados nos diretórios
client_debug
e
lib_debug
. Versões liberadas dos
programas e bibliotecas são colocados nos diretórios
client_release
e
lib_release
. Note que se você quiser
construir tanto versões liberadas quanto depuradas você
pode selecionar a opção ``build all'' do menu
Build
.
Teste o servidor. O servidor construído usando as
instruções anteriores irá esperar que o diretório base
e de dados do MySQL seja C:\mysql
e
C:\mysql\data
por padrão. Se você
quiser testar o seu servidor usando o diretório raiz de
uma árvore fonte e seu diretório de dados como o
diretório base e o diretório de dados, você precisará
dizer ao servidor os seus caminhos. Você também pode
fazer into na linha de comando com as opções
--basedir
e --datadir
,
ou colocar opções apropriadas no arquivo de opções (o
arquivo C:\my.cnf
ou
my.ini
no diretório do Windows). Se
você tiver um diretório de dados existente em qualquer
lugar que você queira usar, você pode especificá-lo no
se caminho.
Inicie o ser servidor a partir do diretório
client_release
ou
client_debug
, dependendo de qual
servidor você queira usar. O instruções gerais de
inicializaão do servidor estão em
Secção 2.1.1, “Instalando o MySQL no Windows”. Você precisará
adaptar as instruções de forma apropriada se você
quiser usar um diretório base ou diretório de dados
diferente.
Quando o servidor está em execução de modo independente
ou como um serviço daseado em sua configuração, tente
se conectar a ele pelo utilitário interativo
mysql
de linha de comando que existe em
seu diretório client_release
ou
client_debug
.
Quando você estiver certo de que os programas que você construiu estão funcionando corretamente, pare o servidor. Então instale o MySQL da seguinte forma:
Crie o diretório para instalar os arquivos do MySQL. Por
exemplo, para instalar dentro de
C:\mysql
), use estes comandos:
C: mkdir \mysql mkdir \mysql\bin mkdir \mysql\data mkdir \mysql\share mkdir \mysql\scripts
Se você quiser compilar outros clientes e ligá-los ao MySQL, você também deve criar diversos diretórios adicionais:
mkdir \mysql\include mkdir \mysql\lib mkdir \mysql\lib\debug mkdir \mysql\lib\opt
Se você quiser fazer um benchamrk do MySQL, crie este diretório:
mkdir \mysql\sql-bench
Benchmark exigem suporte Perl.
Copie do diretório workdir
para o
diretório c:\mysql
os seguintes
diretórios:
copy client_release\*.exe C:\mysql\bin copy client_debug\mysqld.exe C:\mysql\bin\mysqld-debug.exe xcopy scripts\*.* C:\mysql\scripts /E xcopy share\*.* C:\mysql\share /E
Se você quiser compilar outros clientes e ligá-los ao MySQL, você também deve fazer isto:
copy lib_debug\mysqlclient.lib C:\mysql\lib\debug copy lib_debug\libmysql.* C:\mysql\lib\debug copy lib_debug\zlib.* C:\mysql\lib\debug copy lib_release\mysqlclient.lib C:\mysql\lib\opt copy lib_release\libmysql.* C:\mysql\lib\opt copy lib_release\zlib.* C:\mysql\lib\opt copy include\*.h C:\mysql\include copy libmysql\libmysql.def C:\mysql\include
Se você quiser fazer um benchmark do MySQL, você também deve fazer isto:
xcopy sql-bench\*.* C:\mysql\bench /E
Configure e inicie o servidor da mesma forma que a distribuição binária do Windows. See Secção 2.1.1.3, “Preparando o Ambiente MySQL do Windows”.
Para construir o último pacote fonte do Windows a partir da arvoré fonte atual do BitKeeper, use as seguintes instruções. Por favor, note que este procedimento deve ser realizado em um sistema executando um sistema opercional Unix ou similar. (Sabe-se que este procedimento funciona bem com o Linux, por exemplo.)
Clone a árvore fonte do BitKeeper para o MySQL (versão 4.1 ou acima, como desejado). Para mais informações sobre como clonar a árvore fonte veja as instruções em Secção 2.3.4, “Instalando pela árvore de fontes do desenvolvimento”.
Configure e construa as distribuições para que você tenha um binário do servidor para trabalhar. Um modo de se fazer isto é executar o seguinte comando no diretório de mais alto nível de sua árvore fonte:
shell> ./BUILD/compile-pentium-max
Depois de se certificar que o processo de construção foi completado com sucesso, execute o seguinte script utilitário a a partir do diretório de nível mais alto da sua arvore fonte:
shell> ./scripts/make_win_src_distribution
Este script cria um pacote fonte Windows. para ser usado em seu sistema Windows. Você pode fornecer diferentes opções para o script baseado em suas necessidades. Ele aceita as seguintes opções:
--debug Depura, sem criar o pacote --tmp Especifica a localização temporária --suffix Nome de sufixo para o pacote --dirname Nome do diretório onde os arquivos são copiados (intermediario) --silent Não apresenta uma lista dos arquivos processados --tar Cria um pacote tar.gz em vez de .zip --help Mostra esta mensagem de ajuda
Por padrão, make_win_src_distribution
cria um arquivo zipado com o nome
mysql-VERSION-win-src.zip
, onde
VERSION
representa a versão de sua
árvore fonte do MySQL.
Faça uma copia ou upload para a sua máquina o pacote fonte Windows que você tiver criado. Para compilá-lo use as instruções em Secção 2.3.7.1, “Construindo o MySQL Usando VC++”.
Uma vez instalado o MySQL (de uma distribuição binária ou fonte), você deve inicializar as tabelas de concessões, iniciar o servidor e ter certeza que o servidor está funcionando bem. Você pode também desejar que o servidor inicie e pare automaticamente quando seu sistema iniciar e desligar.
Normalmente você instala as tabelas de concessões e inicia o servidor assim para instalações baseadas em uma distribuição fonte:
shell>./scripts/mysql_install_db
shell>cd diretorio_instalação_mysql
shell>./bin/mysqld_safe --user=mysql &
Para uma distribuição binária (sem ser pacotes RPM ou PKG), faça isto:
shell>cd diretorio_instalação_mysql
shell>./bin/mysql_install_db
shell>./bin/mysqld_safe --user=mysql &
O script mysql_install_db
cria o banco de dados
mysql
que irá armazenar todos privilégios do
banco de dados, o banco de dados test
que você
poderá usar para testar o MySQL e também entradas de privilégio
para o usuário que usa o mysql_install_db
e o
usuário root
. As estrandas são criadas sem
senhas. O script mysqld_safe
inicia o servidor
mysqld
. (Se sua versão for anterior a 4.0, use
safe_mysqld
em vez de
mysqld_safe
.)
mysql_install_db
não irá sobrescrever nenhuma
tabela de privilégios antiga, então deve ser seguro executá-lo
em quaisquer circunstâncias. Se você não deseja ter o banco de
dados test
você pode removê-lo com
mysqladmin -u root drop test
depois de iniciar
o servidor.
Testes são geralmente facilmente feitos de um diretório raiz da
distribuição MySQL. Para uma distribuição binária, este é
seu diretório de instalação (normalmente algo como
/usr/local/mysql
). Para uma distrubuição
fonte, este é o diretório principal da sua árvore fonte do
MySQL.
Nos comandos mostrados abaixo nesta seção e nas seguintes
subseções, BINDIR
é o caminho para a
localização na qual os programas como
mysqladmin
e mysqld_safe
estão
instalados. Para uma distribuição binária este é o diretório
bin
. Para uma distribuição fonte,
BINDIR
é provavelmente
/usr/local/bin
, a menos que você especifique
um diretório de instalação diferente de
/usr/local
quando você executa
configure
. EXECDIR
é a
localização na qual o servidor mysqld
está
instalado. Para uma distribuição binária, isto é o mesmo que
BINDIR
. Para uma distribuição fonte,
EXECDIR
é provavelmente
/usr/local/libexec
.
Os testes são descritos em detalhes abaixo:
Se necessário, inicie o servidor mysqld
e
configure as tabelas de concessões iniciais contendo os
privilégios que determinam como os usuários estão
permitidos a conectar ao servidor. Isto é feito normalmente
com o script mysql_install_db
:
shell> scripts/mysql_install_db
Normalmente, mysql_install_db
precisa ser
executado somente na primeira vez que você instala o MySQL.
Portanto, se você estiver atualizando uma instalação
existente, você pode pular este passo. (entretanto,
mysql_install_db
é realmente seguro de
usar e não irá atualizar nenhuma tabela que já exista,
então se você não tem certeza do que fazer, você pode
sempre executar mysql_install_db
.)
mysql_install_db
cria seis tabelas
(user
, db
,
host
, tables_priv
,
columns_priv
e func
) no
banco de dados mysql
. Uma descrição dos
privilégios iniciais é fornecido em
Secção 4.4.4, “Configurando os Privilégios Iniciais do MySQL”. De forma resumidao,
estes privilégios permitem que o usuário root faça qualquer
coisa no MySQL, e permitem a qualquer um a criar ou usar
bancos de dados com o nome de 'test'
ou
iniciando com 'test_'
.
Se você não configurar as tabelas de concessões, o seguinte erro irá aparecer no arquivo log quando você não iniciar o servidor:
mysqld: Can't find file: 'host.frm'
O erro acima pode também ocorrer com uma distribuição
binária do MySQL se você não iniciar o MySQL executando o
./bin/mysqld_safe
! See
Secção 4.8.2, “mysqld-safe
, o wrapper do mysqld
”.
Você deve precisar executar
mysql_install_db
como
root
. Entretanto, se você preferir, pode
executar o servidor MySQL como um usuário
(não-root
) sem privilégios, desde que o
usuário possa ler e escrever arquivos no diretório de banco
de dados. Instruções para executar o MySQL como um usuário
sem privilégios é detalhado em
Secção A.3.2, “Como Executar o MySQL Como Um Usuário Normal”
Se você tiver problemas com o
mysql_install_db
, veja
Secção 2.4.1, “Problemas Executando o mysql_install_db
”.
Existem algumas alternativas para executar o script
mysql_install_db
como ele é fornecido na
distribuição MySQL:
Você pode querer editar o
mysql_install_db
antes de executá-lo,
para alterar os privilégios iniciais que são instalados
nas tabelas de concessões. Isto é útil se você deseja
instalar o MySQL em várias máquinas com os mesmos
privilégios. Neste caso, é provável que você só
precise adicionar algumas instruções
INSERT
extras para as tabelas
mysql.user
e
mysql.db
.
Se você deseja alterar o conteúdo da tabelas de
concessões depois de instalá-las, você pode executar
mysql_install_db
, então usar
mysql -u root mysql
para conectar às
tabelas de concessões como o usuário
root
e usar instruções SQL para
modificá-las diretamente.
É possível recriar as tabelas de permissões
completamente depois delas já terem sido criadas. Você
pode querer fazer isto se você já instalou as tabelas
mas deseja recriá-las depois das edições
mysql_install_db
.
Para maiores informações sobre estas alternativas, veja Secção 4.4.4, “Configurando os Privilégios Iniciais do MySQL”.
Inicie o servidor MySQL assim:
shell>cd diretorio_instalacao_mysql
shell>bin/mysqld_safe &
Se a sua versão do MySQL for mais antiga do que 4.0,
substitua bin/safe_mysqld
por
bin/mysqld_safe
no comando:
Se você tiver problemas iniciando o servidor, veja Secção 2.4.2, “Problemas Inicializando o Servidor MySQL”.
Use mysqladmin
para verificar se o servidor
está em execução. Os seguintes comandos fornecem um teste
simples para conferir se o servidor está em funcionamento e
respondendo às conexões:
shell>BINDIR/mysqladmin version
shell>BINDIR/mysqladmin variables
A saída de mysqladmin version
varia muito
pouco dependendo de sua plataforma e versão do MySQL, mas
deve ser similar a esta mostrada abaixo:
shell> BINDIR/mysqladmin version
mysqladmin Ver 8.14 Distrib 3.23.32, for linux on i586
Copyright (C) 2000 MySQL AB & MySQL Finland AB & TCX DataKonsult AB
This software comes with ABSOLUTELY NO WARRANTY. This is free software,
and you are welcome to modify and redistribute it under the GPL license.
Server version 3.23.32-debug
Protocol version 10
Connection Localhost via Unix socket
TCP port 3306
UNIX socket /tmp/mysql.sock
Uptime: 16 sec
Threads: 1 Questions: 9 Slow queries: 0
Opens: 7 Flush tables: 2 Open tables: 0
Queries per second avg: 0.000
Memory in use: 132K Max memory used: 16773K
Para ter uma idéia do que você pode fazer com
BINDIR/mysqladmin
, invoque-o com a opção
--help
.
Verifique se você pode desligar o servidor:
shell> BINDIR/mysqladmin -u root shutdown
Verifique que você possa reiniciar o servidor. Faça isto
usando mysqld_safe
ou chamado o
mysqld
diretamente. Por exemplo:
shell> BINDIR/mysqld_safe --log &
Se o mysqld_safe
falhar, tente executá-lo
do diretório de instalação do MySQL (se você já não
estiver lá). Se não funcionar, veja
Secção 2.4.2, “Problemas Inicializando o Servidor MySQL”.
Execute alguns testes básicos para verificar se o servidor está funcionando. A saída deve ser similar ao mostrado abaixo:
shell>BINDIR/mysqlshow
+-----------+ | Databases | +-----------+ | mysql | +-----------+ shell>BINDIR/mysqlshow mysql
Database: mysql +--------------+ | Tables | +--------------+ | columns_priv | | db | | func | | host | | tables_priv | | user | +--------------+ shell>BINDIR/mysql -e "SELECT host,db,user FROM db" mysql
+------+--------+------+ | host | db | user | +------+--------+------+ | % | test | | | % | test_% | | +------+--------+------+
Também existe uma suite de benchmark no diretório
sql-bench
(sob o diretório de
instalação do MySQL) que você pode usar para comparar como
o MySQL se comporta em diferentes plataformas. O diretório
sql-bench/Results
contém os resultados
de várias execuções em diferentes bancos de dados e
plataformas. Os seguintes módulos Perl adicionais são
necessários para executar o pacote de benchamrk:
DBI DBD-mysql Data-Dumper Data-ShowTable
Estes módulos podem ser obtidos em CPAN http://www.cpan.org/. See Secção 2.7.1, “Instalando Perl no Unix”.
O diretório sql-bench/Results
contém os
resultados de várias execuções em diferentes bancos de
dados e plataformas. Para executar todos testes, execute estes
comandos:
shell>cd sql-bench
shell>run-all-tests
Se você não possui o diretório
sql-bench
, você provavelmente está
usando uma distribuição binária RPM. (Distribuições
fontes RPMs incluem o diretório com os benchmarks.) Neste
caso, você deve primeiramente instalar a suite de benchmark
antes de poder usá-lo. A partir da versão 3.22 do MySQL,
começaram a existir arquivos RPMs de benchmark chamados
mysql-bench-VERSION-i386.rpm
que contém
código ie dados de benchmark.
Se você tem uma distribuição fonte, você também pode
executar os testes no subdiretório
tests
. Por exemplo, para executar
auto_increment.tst
, faça isto:
shell> BINDIR/mysql -vvf test < ./tests/auto_increment.tst
Os resultados esperados são mostrados no arquivo
./tests/auto_imcrement.res
.
O propósito do script mysql_install_db
é
gerar novas tabelas de privilégios. Ele não irá afeter nenhum
outro dado! Ele também não fará nada se você já tem a
tabela de privilégio do MySQL instalada.
Se você deseja refazer suas tabelas de privilégios, você deve
desligar o servidor mysqld
, se ele já está
executando, então faça assim:
mv diretorio-dados-mysql/mysql diretorio-dados-mysql/mysql-old mysql_install_db
Esta seção relaciona alguns problemas que podem ser
encontrados ao executar mysql_install_db
:
mysql_install_db
não instala as tabelas de permissões
Você pode descobrir que o
mysql_install_db
falha ao instalar as
tabelas de permissões e termina depois de mostrar as
seguintes mensagens:
starting mysqld daemon with databases from XXXXXX mysql daemon ended
Neste caso, você deve examinar o arquivo de log com muito
cuidado! O log deve se encontrar no diretório
XXXXXX
nomeado pela mensagem de erro, e
deve indicar porque mysqld
não
inicializa. Se você não entende o que aconteceu, inclua o
log quando você postar um relato de erro usando
mysqlbug
! See
Secção 1.7.1.3, “Como relatar erros ou problemas”.
Já existe um daemon
mysqld
sendo executado
Neste caso, provavelmente não será necessário executar o
mysql_install_db
. Você deve executar o
mysql_install_db
somente uma vez, quando
você instalar o MySQL da primeira vez.
Instalair um segundo daemon
mysqld
não funciona quando um
daemon
estiver em execução.
Isto pode acontecer quando você já tiver uma instalação
do MySQL existente, mas deseja colocar uma nova instalação
em um diferente lugar (por exemplo, para testes, ou talvez
você simplesmente deseja executar duas instalações ao
mesmo tempo). Geralmente o problema que ocorre quando você
tenta executar o segundo servidor é que ele tenta usar o
mesmo socket e porta que o outro. Neste caso você irá
obter a mensagem de erro: Can't start server: Bind
on TCP/IP port: Address already in use
ou
Can't start server: Bind on unix
socket...
. See Secção 4.2, “Executando Múltiplos MySQL Servers na Mesma Máquina”.
Você não tem direito de escrita no
diretório /tmp
Se você não tem direito de escrita para criar um arquivo
socket no local padrão (em /tmp
) ou
permissão para criar arquivos temporáris em
/tmp,
você irá obter um erro quando
executar mysql_install_db
ou quando
iniciar ou usar mysqld
.
Você pode especificar socket e diretório temporário diferentes, como segue:
shell>TMPDIR=/algum_dir_tmp/
shell>MYSQL_UNIX_PORT=/algum_dir_tmp/mysqld.sock
shell>export TMPDIR MYSQL_UNIX_PORT
algum_dir_tmp
deve ser o caminho para o
mesmo diretório no qual você tem permissão de escrita.
See Apêndice F, Variáveis de Ambientes do MySQL.
Depois disto você deve estar apto para executar
mysql_install_db
e iniciar o servidor com
estes comandos:
shell>scripts/mysql_install_db
shell>BINDIR/mysqld_safe &
mysqld
falha
imediatamente
Se você estiver executando RedHat Versão 5.0 com uma
versão de glibc
anterior a 2.0.7-5 você
deve ter certeza que você instalou todos os patches para a
glibc
! Existe muita informação sobre
isto nos arquivos das listas de mensagens do MySQL. Links
para os arquivos de correio estão disponíveis online em
http://lists.mysql.com/.
Veja também Secção 2.6.2, “Notas Linux (Todas as versões)”.
Você pode também iniciar o mysqld
manualmente usando a opção
--skip-grant-tables
e adicionar a informação de
privilégios usando o mysql
:
shell>BINDIR/mysqld_safe --skip-grant-tables &
shell>BINDIR/mysql -u root mysql
Do mysql
, execute manualmente os comandos
SQL em mysql_install_db
. Tenha certeza de
executar mysqladmin flush_privileges
ou
mysqladmin reload
após dizer ao servidor
para recarregar as tabelas de permissões.
Se você for usar tabelas que suportem transações (BDB, InnoDB), primeiro deve-se criar um arquivo my.cnf e configurar opções de inicialização para os tipos de tabelas que você planeja usar. See Capítulo 7, Tipos de Tabela do MySQL.
Geralmente, você inicia o servidor mysqld
de
uma das três maneiras:
Invocando mysql.server
. Este script é
usado primariamente na inicialização e finalização do
sistema, e é descrito de forma mais completa em
Secção 2.4.3, “Inicializando e parando o MySQL automaticamente.”.
Invocando mysqld_safe
, que tenta
determinar as opções apropriadas para
mysqld
e então executá-lo com estas
opções. See Secção 4.8.2, “mysqld-safe
, o wrapper do mysqld
”.
Para o Windows NT/2000/XP, veja Secção 2.1.1.7, “Iniciando o MySQL no Windows NT, 2000, ou XP”.
Invocando o mysqld
diretamente.
Quando o daemon mysqld
inicia, ele altera o
diretório para o diretório de dados. É neste diretório que
ele espera gravar arquivos de log e o arquivo pid (com o ID do
processo) e onde ele espera encontrar os bancos de dados.
A localização do diretório de dados é especificada quando a
distribuição é compilada. Entretanto, se o
mysqld
espera encontrar o diretório de dados
em lugar diferente de onde ele realmente está no seu sistema,
ele não funcionará corretamente. Se você tiver problemas com
caminhos incorretos você pode encontrar quais opções o
mysqld
permite e quais são as
configurações do caminho padrão chamando o
mysqld
com a opção --help
.
Você pode sobrescrever os padrões especificando os caminhos
corretos como argumentos de linha de comando ao
mysqld
. (Estas opções também podem ser
usadas com o mysqld_safe
).
Normalmente você precisaria indicar ao
mysqld
somente o diretório base sob o qual o
MySQL é instalado. Você pode fazer isso usando a opção
--basedir
. Você pode também usar
--help
para conferir o efeito das opeções
para se alterar o caminho (perceba que --help
deve ser a opção final do comando
mysqld
. Por exemplo:
shell> EXECDIR/mysqld --basedir=/usr/local --help
Uma vez que você determina as configurações de caminho que
você deseja, inicie o servidor sem a opção
--help
.
Qualquer que tenha sido o método utilizado para iniciar o
servidor, se houver falha na inicialização, confira o arquivo
de log para ver se você pode entender o porquê. Arquivos log
estão localizados no diretório dados (normalmente
/usr/local/mysql/data
para uma
distribuição binária, /usr/local/var
para uma distribuição fonte,
\mysql\data\mysql.err
no Windows.) Procure
no diretório de dados por arquivos com nomes no formato
nome_maquina.err
e
nome_maquina.log
onde
nome_maquina
é o nome do servidor. Então
confira as últimas linhas destes arquivos:
shell>tail nome_maquina.err
shell>tail nome_maquina.log
Se você encontrar algo como o seguinte no arquivo log:
000729 14:50:10 bdb: Recovery function for LSN 1 27595 failed 000729 14:50:10 bdb: warning: ./test/t1.db: No such file or directory 000729 14:50:10 Can't init databases
Significa que você não inicializou o mysqld
com --bdb-no-recover
e o Berkeley DB encontrou
algo errado com seus arquivos log quando ele tentou recuperar
seus bancos de dados. Para poder continuar, você deve mover o
antigo arquivo log Berkeley DB do diretório do banco de dados
para outro lugar, onde poderá examiná-los posteriormente. Os
arquivos log são nomeados log.0000000001
,
onde o número irá incrementar com o tempo.
Se você estiver executando o mysqld
com
suporte a tabelas BDB e o mysqld
falhar no
início, pode ser devido a alguns problemas com o arquivo de
recuperação BDB. Neste caso você pode tentar iniciar o
mysqld
com --bdb-no-recover
.
Se isto ajudar, então você pode remover todos os arquivos
log.*
do diretório de dados e tentar
iniciar o mysqld
novamente.
Se você obter o seguinte erro, significa que algum outro
programa (ou outro servidor mysqld
) já está
usando a porta TCP/IP ou socket mysqld
está
tentando usar:
Can't start server: Bind on TCP/IP port: Address already in use ou Can't start server: Bind on unix socket...
Use ps
para ter certeza que você não tem
outro servidor mysqld
em execução. Se você
não consegue encontrar outro servidor, você pode tentar
executar o comando telnet sua_maquina
numero_porta_tcp-ip
e apertar ENTER
várias vezes. Se você não obter uma mensagem como
telnet: Unable to connect to remote host: Connection
refused
, algo está usando a mesma porta TCP/IP que o
mysqld
está tentando usar. Veja
Secção 2.4.1, “Problemas Executando o mysql_install_db
” e
Secção 4.2, “Executando Múltiplos MySQL Servers na Mesma Máquina”.
Se o mysqld
está atualmente em execução,
você pode verificar as configurações que ele está usando
executando este comando:
shell> mysqladmin variables
ou
shell> mysqladmin -h 'your-host-name' variables
Se você obter o Errcode 13
, que significa
Permission denied
, ao iniciar o
mysqld
isto significa que você não pode ter
o direito de leitura/criação de arquivos no diretório do
banco de dados ou log. Neste caso você também deve iniciar o
mysqld
como usuário root
ou alterar a permissão para os arquivos e diretórios
envolvidos para uqe você tenha o direito de usá-los.
Se o mysqld_safe
inicia o servidor mas você
não consegue se conectar a ele, tenha certeza que você tem uma
entrada no arquivo /etc/hosts
que parece
com isto:
127.0.0.1 localhost
Este problema só ocorre em sistemas que não possuem uma biblioteca thread funcional e para o qual o MySQL deve estar configurado para usar MIT-pthreads.
Se você não consegue iniciar o mysqld
você
pode tentar criar um arquivo para rastreamento de erros (trace)
para encontrar o problema. See
Secção E.1.2, “Criando Arquivos Trace (Rastreamento)”.
Se você estiver utilizando tabelas InnoDB, procure pelas opções especificas de inicialização do InnoDB. See Secção 7.5.3, “Opções de Inicialização do InnoDB”.
Se você estiver usando tabelas BDB (Berkeley DB), você deve se
familiarizar com as diferentes opções especificas de
inicialização do BDB. Secção 7.6.3, “Opções de Inicialização do BDB
”.
Os scripts mysql.server
e
mysqld_safe
podem ser usados para iniciar o
servidor automaticamente na inicialização do sistema.
mysql.server
também pode ser usado para
parar o servidor.
O script mysql.server
pode ser usado para
inicializar ou parar o servidor utilizando-o com os argumentos
start
ou stop
:
shell>mysql.server start
shell>mysql.server stop
mysql.server
pode ser encontrado no
diretório share/mysql
sob o diretório de
instalação do MySQL ou no diretório
support-files
da árvore fonte do MySQL.
Note que se você usa o pacote RPM do Linux
(MySQL-server-VERSÃO.rpm
), o script
mysql.server
já estará instalada como
/etc/init.d/mysql
- você não precisa
instalá-lo manualmente. Veja Secção 2.1.2, “Instalando o MySQL no Linux” para
mais informações sobre pacotes RPM Linux.
No Mac OS X, você pode instalar um pacote do MySQL Startup Item separado para habilitar a inicialização automática do MySQL no boot so sistema. Veja Secção 2.1.3, “Instalando o MySQL no Mac OS X” para maiores detalhes.
Antes do mysql.server
iniciar o servidor, ele
vai para o diretório de instalação do MySQL, e então chama o
mysqld_safe
. Você pode precisar editar o
mysql.server
se tiver uma distribuição
binária instalada em um local não-padrão. Modifique-o para
chamar o diretório (cd
) apropriado antes de
executar o safe_mysql
. Se você deseja que o
servidor seja executado com um usuário específico, adicione
uma linha user
apropriada para o arquivo
/etc/my.cnf
, como será visto
posteriormente nesta seção.
mysql.server stop
desliga o servidor MySQL
enviando um sinal para ele. Você pode desligar o servidor
manualmente executando mysqladmin shutdown
.
Você precisa adicionar estes comandos start e stop nos lugares
apropriados de seus arquivos /etc/rc.*
quando você quiser iniciar o MySQL automaticamente no seu
servidor.
On most current Linux distributions, it is sufficient to copy
the file mysql.server
into the
/etc/init.d
directory (or
/etc/rc.d/init.d
on older Red Hat systems).
Afterwards, run the following command to enable the startup of
MySQL on system bootup:
shell> chkconfig --add mysql.server
No FreeBSD o script de inicialização normalmente deve ir no
diretório /usr/local/etc/rc.d/
. A página
do manual rc(8)
também diz que os scripts
neste diretório só são executados, se o seu nome de base
corresponder padrão global da sheel *.sh
.
Qualquer outro arquivo ou diretório presente dentro do
diretório são silenciosamente ignorados. Em outra palavras, no
FreeBSD você deve instalar o arquivo
mysql.server
como
/usr/local/etc/rc.d/mysql.server.sh
para
habilitar a inicialização automática.
Como uma alternativa para o exposto acima, alguns sistemas
operacionais também usam /etc/rc.local
ou
/etc/init.d/boot.local
para inicializar
serviços adicionais durante o boot. Para iniciar o MySQL usando
este método, você poderia poderia adicionar algo como o
seguinte a ele:
/bin/sh -c 'cd /usr/local/mysql; ./bin/mysqld_safe --user=mysql &'
Você também pode adicionar opções para
mysql.server
em um arquivo global
/etc/my.cnf
. Um típico arquivo
/etc/my.cnf
pode parecer com isto:
[mysqld] datadir=/usr/local/mysql/var socket=/var/tmp/mysql.sock port=3306 user=mysql [mysql.server] basedir=/usr/local/mysql
O script mysql.server
entende as seguintes
opções: datadir
, basedir
e pid-file
.
A seguinte tabela mostra quais grupos de opções cada script de inicialização lê dos arquivos de opções:
Script | Grupos de opções |
mysqld | [mysqld] , [server] e
[mysqld-major-version] |
mysql.server | [mysql.server] , [mysqld] , e
[server] |
mysqld_safe | [mysql.server] , [mysqld] , e
[server] |
Para compatibilidade com versões anteriores, o
mysql.server
também lê o grupo
[mysql_server]
e
mysqld_safe
também lê o grupo
[safe_mysqld]
. No entanto, você deve
atualizar os seus arquivos de opções para usar os grupos
[mysql.server]
e
[mysqld_safe]
.
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
.
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. See 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
. See
Secçã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:
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. See Secção D.2, “Alterações na distribuição 4.1.x (Alpha)”.
Se você estiver executando o MySQL Server no Windows, veja também Secção 2.5.8, “Atualizando o MySQL 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 Secção 2.5.6, “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 MySQL 4.1 tem um protocolo cliente/servidor extendido que oferece tais recursos como instruções preparadas e conjuntos de múltiplos resultados.) See Secçã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 Secção 4.3.11, “Hashing de Senhas no MySQL 4.1”.
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 Secçã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
. See Secçã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 Secção 2.5.6, “Atualizando a Tabela de Permissões”. Até
que este script esteja executando todos os usuários 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 usuários,
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). See Secçã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 usuários 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
usuários isto nunca é necessário).
A seguintes variáveis/opções de inicializaçao foram renomeadas:
Nome Antigo | Novo Nome. |
myisam_bulk_insert_tree_size | bulk_insert_buffer_size |
query_cache_startup_type | query_cache_type |
record_buffer | read_buffer_size |
record_rnd_buffer | read_rnd_buffer_size |
sort_buffer | sort_buffer_size |
warnings | log-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 Antigo | Novo Nome. |
SQL_BIG_TABLES | BIG_TABLES |
SQL_LOW_PRIORITY_UPDATES | LOW_PRIORITY_UPDATES |
SQL_MAX_JOIN_SIZE | MAX_JOIN_SIZE |
SQL_QUERY_CACHE_TYPE | QUERY_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. See
Secçã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
. See
Secçã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()
. See
Secçã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 Secção 2.5.8, “Atualizando o MySQL no Windows”. Se você estiver usando replicação, veja Secção 4.11.2, “Visão Geral da Implementação da Replicação”.
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.
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
Secçã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.
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 usuários
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). See
Secçã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
.
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.
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.) See Secçã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 usuário 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.
Qaundo atualizar o MySQL no Windows, siga os passo abaixo:
Faça o download do última distribuição MySQL do Windows.
Escolha uma hora do dia com pouco uso, onde a parada para manutenção é aceitável.
Alerte os usuários que ainda estão ativos para sua parada de manutenção.
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
).
Finalize o programa WinMySQLAdmin
se ele
estiver em execução.
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.
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.
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).
Atualize a tabela de permissões. O procedimento está descrito em Secçã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.
Esta seção descreve assuntos específicos para usar MySQL no Windows.
Aqui temos notas sobre como conectar a um servidor MySQL
através de uma conexão remota e segura usando o SSH (por
David Carlson <dcarlson@mplcomm.com>
:
Instale um cliente SSH na sua máquina Windows. Como um
usuário, o melhor opção paga que encontrei é o
SecureCRT
da
http://www.vandyke.com/.
Outra opção é o f-secure
da
http://www.f-secure.com/.
Você também pode encontrar algumas versões livres no
Google em
http://directory.google.com/Top/Computers/Security/Products_and_Tools/Cryptography/SSH/Clients/Windows/.
Inicie seu cliente SSH Windows. Configure
Host_Name = IP_ou_Nome_servidormysql
.
Configure userid=seu_userid
para logar
no seu servidor. Este valor userid
não
pode ser o mesmo do nome do usuário se sua conta MySQL.
Configure a porta de acesso. E também faça um acesso
remoto (Configure local_port: 3306
,
remote_host: ip_ou_nomeservidormysql
,
remote_port: 3306
) ou um acesso local
(configure port: 3306
, host:
localhost
, remote port:
3306
).
Salve tudo, senão você terá que refazer tudo da próxima vez.
Logue ao seu servidor com a sessão SSH que acabou de ser criada.
Na sua máquina Windows, inicie algumas aplicações ODBC (como o Access).
Crie um novo arquivo no Windows e ligue ao MySQL usando o
driver ODBC da mesma forma que você normalmente faz,
EXCETO pelo fato de digitar localhost
para a máquina servidora MySQL --- não
nomeservidormysql
.
Você agora deve ter uma conexão ODBC ao MySQL, criptografada com SSH.
Em seus arquivos fontes, você deve incluir
my_global.h
antes de
mysql.h
:
#include <my_global.h> #include <mysql.h>
my_global.h
inclui qualquer outro arquivo
necessário para compatibilidade de Windows (como o
windows.h
) se o arquivo é compilado no
Windows.
Você também pode ligar seu código coma biblioteca dinâmica
libmysq.lib
, que é apenas um wrapper
para carregar em libmysql.dll
sobre
demanda, ou ligar com a biblioteca estática
mysqlclient.lib
.
Perceba que como as bibliotecas clientes do MySQL são compiladas como bibliotecas threaded, você também deve compilar seu código para ser multi-threaded!
O MySQL para Windows tem provado ser muito estável. Esta versão do MySQL tem os mesmos recursos que sua versão correspondente Unix com as seguintes exceções:
Win95 e threads
O Win95 perde aproximadamente 200 bytes de memória
principal para cada thread criada. Cada conexão no MySQL
cria uma nova thread, portanto você não deve executar o
mysqld
por um longo tempo no Win95 se
seu servidor lida com várias conexões! WinNT e Win98
não sofrem deste bug.
Leituras simultâneas
O MySQL depende das chamadas pread()
e
pwrite()
para estar apto a misturar
INSERT
e SELECT
.
Atualmente nós usamos mutexes para emular
pread()
/pwrite()
.
Nós iremos, a longo prazo, trocar o nível da interface
de arquivos com uma interface virtual para que nós
possamos usar a interface
readfile()
/writefile()
no NT/2000/XP para obter mais velocidade. A
implementação atual limita o número de arquivos abertos
que o MySQL pode usar para 1024, o que significa que você
não conseguirá executar tantas threads simultâneas no
NT/2000/XP como no Unix.
Leitura de blocos
O MySQL usa uma leitura de blocos para cada conexão, que tem as seguintes implicações:
Uma conexão não irá ser disconectada automaticamente depois de 8 horas, como acontece com a versão Unix do MySQL.
Se uma conexão trava, é impossível a finaliza-la sem matar o MySQL.
mysqladmin kill
não irá
funcionar em uma conexão adormecida.
mysqladmin shutdown
não pode
abortar enquanto existirem conexões adormecidas.
Planejamos corrigir este problema quando nossos desenvolvedores Windows tiverem conseguido um boa solução.
DROP
DATABASE
Você não pode remover um banco de dados que está em uso por alguma thread.
Matando o MySQL do gerenciador de tarefas
Você não pode matar o MySQL do gerenciador de tarefas ou
com o utilitário shutdown no Win95. Você deve
desligá-lo com mysqladmin shutdown
.
Nomes case-insensitivo
Nomes de arquivos não são caso sensitivo no Windows, portanto, nomes de bancos de dados e tabelas do MySQL também não são caso sensitivo no Windows. A única restrição é que os nomes de bancos de dados e tabelas devem usar o mesmo caso em uma sentença fornecida. See Secção 6.1.3, “Caso Sensitivo nos Nomes”.
O caracter de diretório
‘\
’
Componentes de nomes de caminho no Win95 são separados
pelo caracter ‘\
’ o qual
também é o caractere de escape no MySQL. Se você
estiver usando LOAD DATA INFILE
ou
SELECT ... INTO OUTFILE
, use nomes de
arquivo no estilo Unix com caracteres
‘/
’:
mysql>LOAD DATA INFILE "C:/tmp/skr.txt" INTO TABLE skr;
mysql>SELECT * INTO OUTFILE 'C:/tmp/skr.txt' FROM skr;
Uma alternativa é dobrar o caracter
‘/
’:
mysql>LOAD DATA INFILE "C:\\tmp\\skr.txt" INTO TABLE skr;
mysql>SELECT * INTO OUTFILE 'C:\\tmp\\skr.txt' FROM skr;
Problems with pipes.
Pipes não funcionam com confiança na linha de comando do
Windows. Se o pipe incluir o caracter
^Z
/ CHAR(24)
, o
Windows achará que ele encontrou o fim de um arquivo e
abortará o programa.
Isto é um problma principalmente quando se tenta aplicar um log binário como a seguir:
mysqlbinlog binary-log-name | mysql --user=root
Se você obter um problema aplicando o log e suspeitar que
seja devido a um caracter
^Z
/CHAR(24)
você
pode usar a seguinte alternativa:
mysqlbinlog binary-log-file --result-file=/tmp/bin.sql mysql --user=root --eexecute "source /tmp/bin.sql"
O último comando pode também ser usado para leitura em qualquer arquivo sql que contenha dados binários.
erro: Can't open named
pipe
Se você utiliza um servidor MySQL versão 3.22 no NT com o os programas clientes MySQL mais novos, será apresentado o seguinte erro:
error 2017: can't open named pipe to host: . pipe...
Isto ocorre porque a versão do MySQL usa named pipes no
NT por padrão. Você pode evitar este erro usando a
opção --host=localhost
para os novos
clientes MySQL ou criar um arquivo de opções
c:\my.cnf
que contenha a seguinte
informação:
[client] host = localhost
A partir da versão 3.23.50, named pipes são habilitados
somente se o mysqld-nt
ou
mysqld-nt-max
for iniciado com a
opção --enable-name-pipe
.
Erro Access denied for
user
Se você tenta executar um programa cliente MySQL para
conectar a um servidor em execução na mesma máquina,
nas obtem o erro Access denied for user:
'some-user@unknown' to database 'mysql'
quando
acessar um servidor MySQL na mesma máquina, signifca que
o MySQL não pode resolver seu nome de máquina
corretamente.
Para corrigir isto, você deve criar um arquivo
\Windows\hosts
com a seguinte
informação:
127.0.0.1 localhost
ALTER
TABLE
Enquanto você está executando uma instrução
ALTER TABLE
, a tabela está bloqueada
para ser usado por outras threads. Isto ocorre devido ao
fato de que no Windows, você não pode deletar um aruivo
que está em uso por outra threads. No futuro, podemos
encontrar algum modo de contornarmos este problema.
DROP
TABLE
DROP TABLE
em uma tabela que está em
uso por uma tabela MERGE
não
funcionará no Windows porque o manipulador do
MERGE
faz o mapeamento da tabela
escondido da camada superior do MySQL. Como o Windows não
permite que você delete arquivos que estão abertos,
você primeiro deve descarregar todas as tabelas
MERGE
(com FLUSH
TABLES
) ou apagar a tabela
MERGE
antes de deletar a tabela.
Corrigiremos isto assim que introduzirmos views.
DATA DIRECTORY
e
INDEX DIRECTORY
As opções DATA DIRECTORY
e
INDEX DIRECTORY
para CREATE
TABLE
são ignoradas no Windows, porque ele não
suporta links simbólicos.
Aqui estão alguns assuntos em aberto para qualquer um que queira melhorar o MySQL no Windows:
Adicionar alguns ícones agradáveis para o start e shutdown na instalação do MySQL.
Seria muito interessante conseguir matar o
mysqld
do gerenciador de tarefas. Para
o momento, deve ser usado o mysqladmin
shutdown
.
Portar o readline
para Windows para uso
na ferramenta de linha de comando
mysql
.
Versões GUI dos clientes MySQL padrões
(mysql
, mysqlshow
,
mysqladmin
e
mysqldump
) seria ótimo.
Seria muito bom se as funções de leitura e escrita no
socket em net.c
fosse
interrompíveis. Isto tornaria possível matar threads
abertas com mysqladmin kill
no Windows.
Adicionar macros para usar os métodos mais rápidos de incremento/decremento de threads seguras fornecidos pelo Windows.
As notas abaixo a respeito da glibc aplicam-se somente na situação quando o MySQL é construido por você mesmo. Se você está executando Linux em uma máquina x86, na maioria dos casos é muito melhor para você usar nosso binário. Nós ligamos nossos binários com a melhor versão alterada da glibc, podemos escolher as melhores opções do compilador, em uma tentativa de torná-la funcional para um servidor muito exigido. Para um usuário comum, mesmo para configurações com várias conexões concorrentes e/ou tabelas excedendo o limite de 2 GB, nosso binário é, na maioria das vezes, a melhor escolha. Portanto se você ler o texto abaixo, e está em dúvida sobre o que deve fazer, tente usar o nosso binário primeiro para ver se ele preenche suas necessidades, e preocupe-se com uma construção própria apenas se você descobrir que nosso binário não é bom o suficiente para você. Neste caso, iríamos apreciar se fosse feito uma observação sobre isto, para que possamos fazer uma melhor versão bináris da próxima vez.
O MySQL usa LinuxThreads no Linux. Se você usa uma versão do
Linux que não tenha a glibc2
, você deve
instalar LinuxThreads antes de tentar compilar o MySQL. Você
pode obter o LinuxThreads em
http://www.mysql.com/downloads/os-linux.html.
NOTA: Temos visto alguns problemas estranhos com o Linux 2.2.14 e MySQL em sistemas SMP; Se você tem um sistema SMP, recomendamos a atualização para o Linux 2.4! Seu sistema ficará mais rápido e mais estável.
Perceba que as versões da glibc
iguais ou
anteriores à Versão 2.1.1 tem um bug fatal no tratamento do
pthread_mutex_timedwait
, que é usado quando
você executar instruções INSERT DELAYED
.
Recomendamos não usar INSERT DELAYED
antes
de atualizar a glibc
.
Se você planeja ter mais de 1000 conexões simultâneas, será
necessário fazer algumas alterações na LinuxThreads,
recompile-a e religue o MySQL ao novo
libpthread.a
. Aumente
PTHREAD_THREADS_MAX
em
sysdeps/unix/sysv/linux/bits/local_lim.h
para 4096 e abaixe o STACK_SIZE
no
linuxthreads/internals.h
para 256KB. Os
caminhos são relativos à raiz da glibc
.
Note que o MySQL não será estável com cerca de 600-1000
conexões se o valor de STACK_SIZE
for o
padrão de 2MB.
Se você tiver um problema com o MySQL, no qual ele não consiga abrir vários arquivos ou conexões, pode ser que você não tenha configurado o Linux para lidar com o número de arquivos suficiente.
No Linux 2.2 e posteriores, você pode conferir o valor para a alocação dos arquivos fazendo:
cat /proc/sys/fs/file-max cat /proc/sys/fs/dquot-max cat /proc/sys/fs/super-max
Se você possui mais de 16M de memória, deve ser adicionado o
seguinte no seu script de boot (ex.
/etc/rc/boot.local
no SuSE Linux):
echo 65536 > /proc/sys/fs/file-max echo 8192 > /proc/sys/fs/dquot-max echo 1024 > /proc/sys/fs/super-max
Você também pode executar os comandos acima da linha de comando como root, mas neste caso, os antigos limites voltarão a ser usados na próxima vez que o computador for reiniciado.
De forma alternativa, você pode configurar estes parâmteros
durante a inicialização usando a ferramenta
sysctl
, que é usada por muitas
distribuições Linux (No SuSE a partir da versão 8.0). Apenas
grave os seguintes valores em um arquivo chamado
/etc/sysctl.conf
:
# Aumente alguns valores para o MySQL fs.file-max = 65536 fs.dquot-max = 8192 fs.super-max = 1024
You should also add the following to
/etc/my.cnf
:
[mysqld_safe] open-files-limit=8192
Os parâmetros acima permitem o MySQL criar até 8192 conexões + arquivos.
A constante STACK_SIZE
na LinuxThreads
controla o espaçamento das pilhas threads no espaço de
endereçamento. Ela necessita ser grande o bastante para que
tenha espaço o suficiente para a pilha de cada thread, mas
pequena o bastante para manter a pilha de alguma thread
executando dos dados globais mysqld
.
Infelizmente, a implementação Linux de
mmap()
, como descobrimos em experiências,
irá desmapear uma região já mapeada se você solicitar o
mapeamento de um endereço já em uso, zerando os dados de toda
a página ao invés de retoernar. um erro. Portanto a segurança
do mysqld
ou qualquer outra aplicação
baseada em threads depende do comportamento gentil do código
que cria as threads. O usuário deve tomar medidas para
certirficar-se que o número de threads em funcionamento em
qualquer hora seja suficientemente baixo para que as pilhas das
threads permaneçam longe do monte global. Com
mysqld
você deve reforçar este
comportamento "gentil" configurando um valor razoável para a
variável max_connections
.
Se você mesmo construiu o MySQL e não deseja confusões
corrigindo LinuxThreads, você deve configurar
max_connections
para um valor máximo de 500.
Ele ainda deve ser menor se você tiver uma chave grande para o
buffer, grandes tabelas heap, ou outras coisas que fazem o
mysqld
alocar muita memória ou se você
estiver executando um kernel 2.2 com o patch de 2GB. Se você
estiver usando nosso binário ou RPM versão 3.23.25 ou
posterior, você pode seguramente configurar
max_connections
para 1500, assumindo que não
há uma grande chave de buffer ou tabelas heap com grande
quantidade de dados. Quanto mais você reduz
STACK_SIZE
em LinuxThreads mais threads você
pode criar seguramente. Recomendamos os valores entre 128K e
256K.
Se você usa várias conexões simultâneas, você pode sofrer
com um "recurso" do kernel 2.2 que penaliza um processo por
bifurcar-se ou clonar um filho na tentativa de prevenir um
ataque de separação. Isto faz com que o MySQL não consiga
fazer uma bom escalonamento, quando o número de clientes
simultâneos cresce. Em sistemas com CPU única, temos visto
isto se manifestar em uma criação muito lenta das threads,
tornando a conexão ao MySQL muito lenta. Em sistemas de
múltiplas CPUs, temos observado uma queda gradual na velocidade
das consultas quando o número de clientes aumenta. No processo
de tentar encontrar uma solução, recebemos um patch do kernel
de um de nossos usuários, que alega fazer muita diferença para
seu site. O patch está disponível aqui
(http://www.mysql.com/Downloads/Patches/linux-fork.patch).
Atualmente temos feito testes extensivos deste patch nos
sistemas de desenvolvimento e produção. A performance do
MySQL
obtem uma melhora significativa, sem
causar problemas e atualmente o recomendamos para nossos
usuários que continuando trabalhando com servidores muito
carregados em kernels 2.2. Este detalhe foi corrigido no kernel
2.4, portanto, se você não está satisfeito com a performance
atual do seu sistema, melhor do que aplicar um patch ao seu
kernel 2.2, pode ser mais fácil simplesmente atualizar para o
2.4, que lhe dará também uma melhora em seu sistemas SMP em
adição à correção do bug discutido aqui.
Estamos testando o MySQL no kernel 2.4 em uma máquina com 2
processadores e descobrimos que o MySQL escalona muito melhor -
virtualmente, não há nenhuma perda de desempenho no throughput
das consultas até cerca de 1000 clientes, e o fator da escala
do MySQL (computado com a razão do throughput máximo para o
thoughput de cada cliente.) foi de 180%. Temos observado
resultados similares em sistemas com 4 processadores -
virtualmente não há perda de desempenho quando o número de
clientes é incrementado até 1000 e o fator da escala foi de
300%. Portanto para um servidor SMP muito carregado nós
definitivamente recomendamos o kernel 2.4. Nós descobrimos que
é essencial executar o processo mysqld
com a
mais alta prioridade possível no kernel 2.4 para obter
performance máxima. Isto pode ser feito adicionando o comando
renice -20 $$
ao
mysqld_safe
. Nos nossos testes em uma
máquina com 4 processadores, o aumento da prioridade nos deu
60% de aumento no throughput com 400 clientes.
Atualmente estamos tentando coletar mais informações sobre
como o MySQL
atua no kernel 2.4 em sistemas
com 4 e 8 processadores. Se você tem acesso a um sistema deste
porte e tem feito alguns benchmarks, por favor envie um email
para <docs@mysql.com>
com os resultados - iremos
incluí-los neste manual.
Existe outro detalhe que afeta muito a performance do MySQL, especialmente em sistemas multi processados. A implementação de mutex em LinuxThreads na glibc-2.1 é muito ruim para programas com várias threads que travam o mutex por um tempo curto. Em um sistema SMP, ironicamente, se você liga o MySQL com LinuxThreads sem modificações, removendo processadores da máquina, a performance do MySQL é melhorada em alguns casos. Para corrigir este comportamento, disponibilizamos um patch para glibc 2.1.3, em linuxthreads-2.1-patch
Com a glibc-2.2.2, o MySQL
versão 3.23.36 irá usar o mutex adaptativo, que é muito
melhor,mesmo que o patch na
glibc-2.1.3. Avisamos,
entretando, que sobre algumas condições, o código mutex no
glibc-2.2.2 overspins, que
prejudica a performance do MySQL. A chance desta condição pode
ser reduzida mudando a prioridade do processo
mysqld
para a prioridade mais alta. Nós
também corrigimos o comportamento overspin com um patch,
disponível em
http://www.mysql.com/Downloads/Linux/linuxthreads-2.2.2.patch.
Ele combina a correção do overspin, número máximo de threads
e espaçamento das pilhas em um único patch. Você precisará
aplicá-lo no diretório linuxthreads
com
patch -p0 </tmp/linuxthreads-2.2.2.patch
.
Esperamos que seja incluído de alguma forma nos futuros
lançamentos da glibc-2.2
. De qualquer forma,
se você ligar com glibc-2.2.2
, ainda será
necessário corrigir STACK_SIZE
e
PTHREAD_THREADS_MAX
. Temos esperanças que os
padrões serão corrigidos para valores mais aceitáveis para
configurações pesadasa do MySQL no futuro, então sua
construção poderá ser reduzida a ./configure; make;
make install
.
Recomendamos que você use os patches acima para construir uma
versão estática especial de libpthread.a
e
use-a somente para ligações estáticas com o
MySQL
. Sabemos que os patches são seguros
para o MySQL
e pode melhorar significamente
sua performance, mas não podemos dizer nada sobre outras
aplicações. Se você ligar outras aplicações coma a versão
modificada da biblioteca ou construir uma versão alterada
compartilhada e instalá-la no seu sistema, você estará
fazendo por sua conta e risco e tenha atenção com outras
aplicações que dependem de LinuxThreads
.
Se você passar por problemas estranhos durante a instalação do MySQL ou com travamentos de alguns utilitários comuns, é muito provável que eles são relacionados a problemas de bibliotecas ou compilador. Se for este o caso, o uso de nosso binário será a solução.
Um problema conhecido com a distribuição binária é que com
antigos sistemas Linux que usam libc
(como o
RedHat 4.x ou Slackware), você obterá alguns problemas não
fatais com resolução de nomes. See
Secção 2.6.2.1, “Notas Linux para distribuições binárias”.
Quando estiver usando LinuxThreads você verá um mínimo de três processos em execução. Estes são de fato, threads. Existirá uma thread para o gerenciador LinuxThreads, uma thread para lidar com conexões e uma thread para tartar de alarmes e sinais.
Perceba que o kernel Linux e a biblioteca LinuxThread pode por padrão ter apenas 1024 threads. Isto significa que você pode ter até 1021 conexões ao MySQL em um sistema sem correção. A página http://www.volano.com/linuxnotes.html contém informações sobre como contornar este limite.
Se você ver um processo mysqld
daemon
finalizado com ps
, isto normalmente significa
que você encontrou um bug no MySQL ou que tenha uma tabela
corrompida. See Secção A.4.1, “O Que Fazer Se o MySQL Continua Falhando”.
Para obter um descarga do core no Linux se o
mysqld
finalizar com um sinal SIGSEGV, você
pode iniciar o mysqld
com a opção
--core-file
. Perceba que provavelmente você
também precisará aumentar o core file size
adicionando ulimit -c 1000000
para
mysqld_safe
ou iniciar
mysqld_safe
com
--core-file-sizes=1000000
, See
Secção 4.8.2, “mysqld-safe
, o wrapper do mysqld
”.
Se você estiver ligando seu próprio cliente MySQL e obter o erro:
ld.so.1: ./my: fatal: libmysqlclient.so.4: open failed: No such file or directory
Quando executá-los, o problema pode ser evitado com um dos seguintes métodos:
Se você estiver usando o compilador Fujitsu (fcc /
FCC)
você terá alguns problemas compilando o MySQL
porque os arquivos de cabeçalho Linux são muito orientados ao
gcc
.
A seguinte linha configure
deve funcionar com
fcc/FCC
:
CC=fcc CFLAGS="-O -K fast -K lib -K omitfp -Kpreex -D_GNU_SOURCE \ -DCONST=const -DNO_STRTOLL_PROTO" CXX=FCC CXXFLAGS="-O -K fast -K lib \ -K omitfp -K preex --no_exceptions --no_rtti -D_GNU_SOURCE -DCONST=const \ -Dalloca=__builtin_alloca -DNO_STRTOLL_PROTO \ '-D_EXTERN_INLINE=static __inline'" ./configure --prefix=/usr/local/mysql \ --enable-assembler --with-mysqld-ldflags=-all-static --disable-shared \ --with-low-memory
O MySQL necessita pelo menos do Linux versão 2.0
Aviso: Percebemos que alguns usuários do MySQL tiveram serios problemas de estabilidade com o MySQL e o kernel 2.2.14 do Linux. Se você estiver usando este kernel você deve atualizá-lo para o 2.2.19 (ou posterior) ou para o kernel 2.4. Se você tiver um gabinete multi-cpu, então você deve considerar seriamente o uso do kernel 2.4 uma vez que ele lhe trará uma melhora significante na velocidade.
A versão binária é ligada com -static
,
que significa que você normalmente não precisa se preocupar
com qual versão das bibliotecas do sistema você tem. Você
não precisa instalar LinuxThreads. Um programa ligado com a
opção -static
é um pouco maior que um
programa ligado dinamicamente e também um pouco mais rápido
(3-5%). Um problema, entretanto, é que você não pode usar
funções definidas pelo usuário (UDF) com um programa ligado
estaticamente. Se você for escrever ou usar funções UDF
(isto é algo para programadores C ou C++), você deve
compilar o MySQL, usando ligações dinamicas.
Se você estiver usando um sistema baseado em
libc
(em vez de um sistema
glibc2
), você, provavelmente, terá alguns
problemas com resolução de nomes de máquinas e
getpwnam()
com a versão binária. (Isto é
porque o glibc
infelizmente depende de
algumas bibliotecas externas para resolver nomes de máquinas
e getpwent()
, mesmo quando compilado com
-static
). Neste caso, você provavelmente
obterá a seguinte mensagem de erro quando executar
mysql_install_db
:
Sorry, the host 'xxxx' could not be looked up
ou o seguinte erro quando você tentar executar
mysqld
com a opção
--user
:
getpwnam: No such file or directory
Você pode resolver este problema usando de um dos modos seguintes:
Obtenha uma distribuição fonte do MySQL (uma
distribuição RPM ou tar.gz
) e a
instale.
Execute mysql_install_db --force
; Isto
não executará o teste resolveip
no
mysql_install_db
. O lado ruim é que
você não poderá usar nomes de máquinas nas tabelas de
permissões; você deve usar números IP no lugar (exceto
para localhost
). Se você estiver
usando uma release antiga do MySQL que não suporte
--force
, você deve remover o teste
resolveip
no
mysql_install
com um editor.
Inicie mysqld
com su
no lugar de usar --user
.
As distribuições binárias Linux-Intel e RPM do MySQL são configuradas para o máximo de desempenho possível. Nós sempre tentamos usar o compilador mais rápido e estável disponível.
Suporte MySQL ao Perl exige Perl Versão 5.004_03 ou mais novo.
Em algumas versões 2.2 do kernel Linux,você pode obter o
erro Resource temporarily unavailable
quando você faz várias novas conexões para um servidor
mysqld
sobre TCP/IP.
O problema é que o Linux tem um atraso entre o momento em que
você fecha um socket TCP/IP até que ele seja realmente
liberado pelo sistema. Como só existe espaço para um número
finito de slots TCP/IP, você irá obter o erro acima se você
tentar fazer muitas novas conexões TCP/IP durante um pequeno
tempo, como quando você executa o benchmark do MySQL
test-connect
sobre TCP/IP.
Nós enviamos emails sobre este problema várias vezes para diferentes listas de discussão Linux mas nunca conseguimos resolver este problema apropriadamente.
A única 'correção' conhecida , para este problema é usar
conexões persistentes nos seus clientes ou usar sockets, se
você estiver executando o servidor de banco de dados e
clientes na mesma máquina. Nós experamos que o kernel
Linux 2.4
corrija este problema no futuro.
O MySQL exige a versão 5.4.12 ou mais nova da
libc
. Sabe-se que funciona com a
libc
5.4.46. A versão 2.0.6 e posterior da
glibc
também deve funcionar. Existem
alguns problemas com os RPMs glibc
da
RedHat, portanto se você tiver problemas, confira se existe
alguma atualização! Sabemos que os RPMs
glibc
2.0.7-19 e 2.0.7-29 funcionam.
Se você estiver usando o Red Hat 8.0 ou uma nova biblioteca
glibc
2.2.x, você deve iniciar o
mysqld
com a opção
--thread-stack=192K
(Use -O
thread_stack=192K antes do MySQL 4
). Se você não
fizer isto o mysqld
finlizará em
gethostbyaddr()
porque a nova biblioteca
glibc exige mais de 128K de memória na pilha para esta
chamada. Este tamanho de pilha é o padrão agora no MySQL
4.0.10 e acima.
Se você está usando o gcc
3.0 e acima
para compilar o MySQL, você deve instalar a biblioteca
libstdc++v3
antes de compilar o MySQL; se
você não fizer isto, você obterá um erro sobre um símbolo
__cxa_pure_virtual
perdido durante a
ligação.
Em algumas distribuições Linux mais antigas,
configure
pode produzir um erro como este:
Syntax error in sched.h. Change _P to __P in the /usr/include/sched.h file. See the Installation chapter in the Reference Manual.
Faça apenas o que a mensagem de erro diz e adicione um
caractere sublinhado para a macro _P
que
tem somente um caractere sublinhado e então tente novamente.
Você pode obter alguns aviso quando estiver compilando; os mostrados abaixo podem ser ignorados:
mysqld.cc -o objs-thread/mysqld.o mysqld.cc: In function `void init_signals()': mysqld.cc:315: warning: assignment of negative value `-1' to `long unsigned int' mysqld.cc: In function `void * signal_hand(void *)': mysqld.cc:346: warning: assignment of negative value `-1' to `long unsigned int'
O mysql.server
pode ser encontrado no
diretório share/mysql
sob o diretório
de instalação MySQL ou no diretório
support-files
da árvore fonte MySQL.
Se o mysqld
sempre descarregar um core na
inicialização, o problema pode ser que você tenha um antigo
/lib/libc.a
. Tente renomeá-lo depois
remova sql/mysqld
e faça um novo
make install
e tente novamente. Este
problema foi relatado em algumas instalações Slackware.
Se você obter o seguinte erro quando ligar o
mysqld
, significa que seu
libg++.a
não está instalado
corretamente:
/usr/lib/libc.a(putc.o): In function `_IO_putc': putc.o(.text+0x0): multiple definition of `_IO_putc'
Você pode evitar o uso de libg++.a
executando configure
desta forma:
shell> CXX=gcc ./configure
Em algumas implementações, readdir_r()
está quebrada. O sintoma é que SHOW
DATABASES
sempre retorna um conjunto vazio. Isto
pode ser corrigido removendo HAVE_READDIR_R
do config.h
depois de configurar e antes
de compilar.
O MySQL Versão 3.23.12 é a primeira versão do MySQL que é testada no Linux-Alpha. Se você planeja usar o MySQL no Linux-Alpha, você deve ter certeza que possui esta versão ou mais nova.
Temos testado o MySQL no Alpha com nossos pacotes de benchmarks e testes, e ele parece funcinar muito bem.
Quando nós compilamos o binários MySQL padrões, nós estávamos usando SuSE 6.4, kernel 2.2.13-SMP, Compilador C Compaq (V6.2-504) e compilador C++ Compaq (V6.3-005) em uma máquina Compaq DS20 com um processador Alpha EV6.
Você pode encontrar os compiladores acima em http://www.support.compaq.com/alpha-tools. Usando estes compiladores, em vez do gcc, obtemos 9-14 % de melhora na performance com MySQL.
Note que a linha de configuração otimiza o binário para a CPU atual; isto significa que você só pode utilizar nosso binário se você tiver um processador Alpha EV6. Nós também compilamos estaticamente para evitar problemas de bibliotecas.
A partir das próximas distribuições adicionamos o
parâmetro -arch generic
em nossas opções
de compilação, o qual assegura que o binário execute em
todos os processadores Alpha. Nós também compilamos
estaticamente para evitar problemas de bibliotecas.
CC=ccc CFLAGS="-fast -arch generic" CXX=cxx \ CXXFLAGS="-fast -arch generic -noexceptions -nortti" \ ./configure --prefix=/usr/local/mysql --disable-shared \ --with-extra-charsets=complex --enable-thread-safe-client \ --with-mysqld-ldflags=-non_shared --with-client-ldflags=-non_shared
Se você deseja usar egcs a seguinte linha de configuração funcionou para nós:
CFLAGS="-O3 -fomit-frame-pointer" CXX=gcc \ CXXFLAGS="-O3 -fomit-frame-pointer -felide-constructors \ -fno-exceptions -fno-rtti" ./configure --prefix=/usr/local/mysql \ --disable-shared
Alguns problemas conhecidos quando executamos o MySQL no Linux-Alpha:
Debugar aplicações baseadas em threads como o MysQL não
irá funcionar com gdb 4.18
. Você deve
fazer download e usar o gdb 5.0!
Se você tentar ligar o mysqld
estaticamente quando usar o gcc
, a
imagem resultante irá descarregar um arquivo core no
início. Em outras palavras,
NÃO use
--with-mysqld-ldflags=-all-static
com
gcc
.
O MySQL deve funcionar no MkLinux com o mais novo pacote
glibc
(testado com glibc
2.0.7).
Para ter o MySQL funcionando no Qube2. (Linux Mips), você
precisará das bibliotecas glibc
mais novas
(Sabemos que glibc-2.0.7.29C2
funciona).
Você também deve usar o compilador egcs
C++ (egcs-1.0.2-9
, gcc
2.95.2
ou mais nova).
Para conseguir compilar o MySQL no Linux Ia64, usamos a
seguinte linha de compilação: Usando
gcc-2.96
:
CC=gcc CFLAGS="-O3 -fno-omit-frame-pointer" CXX=gcc \ CXXFLAGS="-O3 -fno-omit-frame-pointer -felide-constructors \ -fno-exceptions -fno-rtti" ./configure --prefix=/usr/local/mysql \ "--with-comment=Official MySQL binary" --with-extra-charsets=complex
No Ia64 os binários do cliente MySQL estão usando
bibliotecas compartilhadas. Isto significa se você instalar
nossa distribuição binárias em algum outro lugar diferente
de /usr/local/mysql
você precisa
modificar o /etc/ld.so.conf
ou adicionar
o caminho da o diretório onde está localizado o
libmysqlclient.so
na variável de
ambiente LD_LIBRARY_PATH
.
See Secção A.3.1, “Problemas de Ligação com a Biblioteca do Cliente MySQL”.
No Solaris, você deve ter problemas mesmo antes de descompactar
a distribuição MySQL! O tar
do Solaris não
pode tratar grandes nomes de arquivos, portanto você pode ver
um erro deste tipo quando descompactar o MySQL:
x mysql-3.22.12-beta/bench/Results/ATIS-mysql_odbc-NT_4.0-cmp-db2,informix,ms-sql,mysql,oracle,solid,sybase, 0 bytes, 0 tape blocks tar: directory checksum error
Neste caso, você deve usar o GNU tar
(gtar
) para desempacotar a distribuição.
Você pode encontrar uma cópia pré-compilada para Solaris em
http://www.mysql.com/downloads/os-solaris.html.
As threads nativas da Sun funcionam somente no Solaris 2.5 e superior. Para a versão 2.4 e anteriores, o MySQL irá automaticamente usar MIT-pthreads. See Secção 2.3.6, “Notas MIT-pthreads”.
Se você obter o seguinte erro de configure:
checking for restartable system calls... configure: error can not run test programs while cross compiling
Isto significa que alguma coisa está errada com a instalação
de seu compilador! Neste caso você deve atualizar seu
compilador para uma versão mais nova. Você também pode
resolver este problema inserindo a seguinte linha no arquivo
config.cache
:
ac_cv_sys_restartable_syscalls=${ac_cv_sys_restartable_syscalls='no'}
Se você está usando Solaris em um SPARC, o compilador
recomendado é o gcc
2.95.2. Você pode
encontrá-lo em
http://gcc.gnu.org/.
Perceba que egcs
1.1.1 e
gcc
2.8.1 não são estáveis no SPARC!
A linha do configure
recomendado quando
usando gcc
2.95.2 é:
CC=gcc CFLAGS="-O3" \ CXX=gcc CXXFLAGS="-O3 -felide-constructors -fno-exceptions -fno-rtti" \ ./configure --prefix=/usr/local/mysql --with-low-memory --enable-assembler
Se você possui um ultra sparc, você pode obter 4% a mais de performance adicionando "-mcpu=v8 -Wa,-xarch=v8plusa" para a CFLAGS e CXXFLAGS.
Se você possui o compilador Sun Workshop (Fortre) 5.3 (ou mais
novo), você pode executar configure
da
seguinte forma:
CC=cc CFLAGS="-Xa -fast -native -xstrconst -mt" \ CXX=CC CXXFLAGS="-noex -mt" \ ./configure --prefix=/usr/local/mysql --enable-assembler
Você pode criar um binário de 64 bits usando o compilador Forte da Sun com os seguintes parâmetros de compilação:
CC=cc CFLAGS="-Xa -fast -native -xstrconst -mt -xarch=v9" \ CXX=CC CXXFLAGS="-noex -mt -xarch=v9" ASFLAGS="-xarch=v9" \ ./configure --prefix=/usr/local/mysql --enable-assembler
Para criar um binário de 64 bits do Solaris usando
gcc
, e -m64
para
CFLAGS
e CXXFLAGS
. Note
que isto só funciona com o MySQL 4.0 e acima - o MySQL 3.23
não inclui as modificações exigidas para suportar isto.
No benchmark do MySQL, conseguimos um aumento de velocidade de 4% em um UltraSPARC usando o Forte 5.0 no modo 32 bit em comparação com o uso do gcc 3.2 com o parametro -mcpu.
Se você criar um binário de 64 bits, ele será 4$ mais lento
que o binário de 32 bits, mas o mysqld
poderá tratar mais threads e memória.
Se você tiver um problema com fdatasync
ou
sched_yield
, você pode corrigir isto
adicionando LIBS=-lrt
para a linha de
configuração
O seguinte paragráfo é relevante somente para compiladores mais antigos que o WorkShop 5.3:
Você também pode ter que editar o script
configure
para alterar esta linha:
#if !defined(__STDC__) || __STDC__ != 1
para isto:
#if !defined(__STDC__)
Se você ligar __STDC__
com a opção
-Xc
, o compilador Sun não pode compilar com
o arquivo de cabeçalho pthread.h
do
Solaris. Isto é um bug da Sun (compilador corrompido ou arquivo
include corrompido).
Se o mysqld
emitir a mensagem de erro
mostrada abaixo quando você executá-lo, você deve tentar
compilar o MySQL com o compilador Sun sem habilitar a opção
multi-thread (-mt
):
libc internal error: _rmutex_unlock: rmutex not held
Adicione -mt
a CFLAGS
e
CXXFLAGS
e tente novamente.
Se você estiver usando a versão SFW do gcc (que vem com o
Solaris 8), você deve adicionar
/opt/sfw/lib
a variável de ambiente
LD_LIBRARY_PATH
antes de executar a
configuração.
Se você estiver usando o gcc disponível em
sunfreeware.com
, você pode ter muitos
problemas. Você deve recompilar o gcc e GNU binutils na
máquina que você o executará para evitar qualquer problema.
Se você obter o seguinte erro quando estiver compilando o MySQL
com gcc
, significa que seu
gcc
não está configurado para sua versão
de Solaris:
shell> gcc -O3 -g -O2 -DDBUG_OFF -o thr_alarm ...
./thr_alarm.c: In function `signal_hand':
./thr_alarm.c:556: too many arguments to function `sigwait'
A coisa apropriada para fazer neste caso é obter a versão mais
nova do gcc
e compilá-lo com seu compilador
gcc
atual! Ao menos para o Solaris 2.5, a
maioria das versões binárias de gcc
tem
arquivos inúteis e antigos que irão quebrar todos programas
que usam threads (e possivelmente outros programas)!
O Solaris não fornece versões estáticas de todas bibliotecas
de sistema (libpthreads
) e
libdl
), portanto você não pode compilar o
MySQL com --static
. Se você tentar fazer isto,
receberá o erro:
ld: fatal: library -ldl: not found ou undefined reference to `dlopen' ou cannot find -lrt
Se vários processos tentar conectar muito rapidamente ao
mysqld
, você verá este erro no log do
MySQL:
Error in accept: Protocol error
Você deve tentar iniciar o servidor com a opção
--set-variable back_log=50
como uma solução
para esta situação. Note que
--set-variable=nome=valor
e -O
nome=valor
está obsoleto desde o MySQL 4.0. Use
apenas --back_log=50
. See
Secção 4.1.1, “Opções de Linha de Comando do mysqld
”.
Se você está ligando seu próprio cliente MySQL, você deve obter o seguinte erro quando tentar executá-lo:
ld.so.1: ./my: fatal: libmysqlclient.so.#: open failed: No such file or directory
O problema pode ser evitado por um dos seguintes métodos:
Se você tiver problemas com o configure tentando ligar com
-lz
e você não tem a
zlib
instalada, você terá duas opções:
Se você deseja usar o protocol de comunição de compactado você precisará obter e instalar a zlib from ftp.gnu.org.
Configure com --with-named-z-libs=no
.
Se você estiver usando o gcc e tiver problemas carregando
funções UDF
no MySQL, tente adicionar
-lgcc
para a linha de ligação para a
função UDF
.
Se você deseja que o MySQL inicie automaticamente, você pode
copiar support-files/mysql.server
para
/etc/init.d
e criar um link simbólico para
ele, chamado /etc/rc.3.d/S99mysql.server
.
Como o Solaris não suporta core files para aplicações
setuid()
, você não pode obter um core file
do mysqld
se você estiver usando a opção
--user
.
Você pode utilizar normalmente um binário Solaris 2.6 no Solaris 2.7 e 2.8. A maioria dos detalhes do Solaris 2.6 também se aplicam ao Solaris 2.7 e 2.8.
Note que o MySQL versão 3.23.4 e superiores devem estar aptos para autodetectar novas versões do Solaris e habilitar soluções para os problemas seguintes!
Solaris 2.7 / 2.8 tem alguns bugs nos arquivos include. Você
pode ver o seguinte erro quando você usa o
gcc
:
/usr/include/widec.h:42: warning: `getwc' redefined /usr/include/wchar.h:326: warning: this is the location of the previous definition
Se isto ocorrer, você pode fazer o seguinte para corrigir o problema:
Copie /usr/include/widec.h
para
.../lib/gcc-lib/os/gcc-version/include
e
mude a linha 41 :
#if !defined(lint) && !defined(__lint) para #if !defined(lint) && !defined(__lint) && !defined(getwc)
Uma alternativa é editar o
/usr/include/widec.h
diretamente. Desta
forma, depois de fazer a correção, você deve remover o
config.cache
e executar o
configure
novamente !
Se você obter erros como estes quando você executar o
make
, é porque o
configure
não encontrou o arquivo
curses.h
(provavelmente devido ao erro no
arquivo /usr/include/widec.h
):
In file included from mysql.cc:50: /usr/include/term.h:1060: syntax error before `,' /usr/include/term.h:1081: syntax error before `;'
A solução para isto é fazer uma das seguintes opções:
Configure com CFLAGS=-DHAVE_CURSES_H
CXXFLAGS=-DHAVE_CURSES_H ./configure
.
Edite o /usr/include/widec.h
como
indicado acima e re-execute o configure.
Remova a linha #define HAVE_TERM
do
arquivo config.h
e execute
make
novamente.
Se o seu ligador tiver problemas para encontrar o
-lz
quando ligar ao seu programa cliente,
provavelmente o problema é que seu arquivo
libz.so
está instalado em
/usr/local/lib
. Você pode corrigir isto
usando um dos seguintes métodos:
Adicione /usr/local/lib
ao
LD_LIBRARY_PATH
.
Adicione um link para libz.so
a
partir de /lib
.
Se você estiver usando o Solaris 8, você pode instalar a zlib opcional do CD de distribuição do Solaris 8.
Configure o MySQL com a opção
--with-named-z-libs=no
.
No Solaris 8 no x86, mysqld
irá
descarregar um core se você executar um 'strip' no mesmo.
Se você estiver usando gcc
ou
egcs
no Solaris X86 e você tiver problemas
com descarregos de core, você deve utilizar o seguinte
comando configure
:
CC=gcc CFLAGS="-O3 -fomit-frame-pointer -DHAVE_CURSES_H" \ CXX=gcc \ CXXFLAGS="-O3 -fomit-frame-pointer -felide-constructors -fno-exceptions -fno-rtti -DHAVE_CURSES_H" \ ./configure --prefix=/usr/local/mysql
Isto irá evitar problemas com a biblioteca
libstdc++
e com exceções C++.
Se isto não ajudar, você pode compilar uma versão com debug
e executá-lo com um arquivo de ratreamento (trace) ou sob
gdb
. See
Secção E.1.3, “Depurando o mysqld no gdb”.
Esta seção fornece informação para os vários tipos de BSD, assim como a versão específica para eles.
FreeBSD 4.x ou mais novo é recomendado para executação do MySQL uma vez que o pacote thread é muito mais integrado.
A mais fácil e portanto a forma preferida para instalá-lo é usar as portas mysql-server e mysql-client disponíveis em http://www.freebsd.org.
Usando-as você obtem:
Um MySQL funcional, com todas as otimizações conhecidas para trabalhar na sua versão habilitada do FreeBSD.
Configuração e construção automática.
Scripts de inicialização instalados em /usr/local/etc/rc.d.
Habilidade para ver quais arquivos estão instalados com pkg_info -L. E para remover todos com pkg_delete se você não quiser mais o MySQL na máquina.
É recomendado que você utilize MIT-pthreads no FreeBSD 2.x e
threads nativas nas Versões 3 e superiores. É possível
executar com threads nativas em algumas versões antigas
(2.2.x) mas você pode encontrar problemas ao finalizar o
mysqld
.
Infelizmente algumas chamadas de funções no FreeBSD ainda
não são totalmente seguras com threads, principalmente a
função gethostbyname()
, que é usada pelo
MySQL para converter nomes de máquinas em endereços IPs. Sob
certas circunstâncias, o processo mysqld
irá criar repentinamente um carga de CPU de 100% e ficará
sem resposta. Se você se deparar com isto, tente iniciar o
MySQL usando a opção --skip-name-resolve
.
Alternativamente, você pode ligar o MySQL no FreeBSD 4.x com a biblioteca LinuxThreads, que evita uns poucos problemas que a implementação da thread nativa do FreeBSD tem. Para uma comparação muito boa do LinuxThreads vs. threads nativas dê uma olhada no artigo "FreeBSD or Linux for your MySQL Server?" de Jeremy Zawodny em http://jeremy.zawodny.com/blog/archives/000697.html
Os problemas conhecidos usando LinuxThreads na FreeBSD são:
wait_timeout
não está funcionando
(provavemente problema de manipulação do signal em
FreeBSD/LinuxThreads). Isto deveria ter sido corrigido no
FreeBSD 5.0. O sintome á que conexões persistentes podem
se manter por um longo
tempo sem serem fechadas.
O Makefile
do MySQL necessita o GNU make
(gmake
) para funcionar. Se você deseja
compilar o MySQL, antes você precisará instalar o GNU
make
.
Tenha certeza que sua configuração de resolução de nomes
esteja correta. De outra forma você vai ter atrasos na
resolução ou falhas quando conectar ao
mysqld
.
Tenha certeza que a entrada localhost
no
arquivo /etc/hosts
esteja correta (de
outra forma você irá ter problemas conectando ao banco de
dados). O arquivo /etc/hosts
deve iniciar
com a linha:
127.0.0.1 localhost localhost.seu.dominio
O modo recomendado de compilar e instalar o MySQL no FreeBSD com gcc (2.95.2 e acima) é:
CC=gcc CFLAGS="-O2 -fno-strength-reduce" \ CXX=gcc CXXFLAGS="-O2 -fno-rtti -fno-exceptions -felide-constructors \ -fno-strength-reduce" \ ./configure --prefix=/usr/local/mysql --enable-assembler gmake gmake install ./scripts/mysql_install_db cd /usr/local/mysql ./bin/mysqld_safe &
Se você percber que o configure
usará
MIT-pthreads, você de ler as notas sobre MIT-pthreads. See
Secção 2.3.6, “Notas MIT-pthreads”.
Se o make install
não puder encontrar
/usr/include/pthreads
, é porque o
configure
não detectou que você precisava
de MIT-pthreads. Isto é corrigido executando estes comandos:
shell>rm config.cache
shell>./configure --with-mit-threads
O FreeBSD é também conhecido por ter um limite muito baixo
para o manipulador de arquivos. See
Secção A.2.17, “Arquivo Não Encontrado”. Descomente a
seção ulimit -n no mysqld_safe ou aumente os limites para o
usuário mysqld
no /etc/login.conf (e
reconstrua-o com cap_mkdb /etc/login.conf). Também tenha
certeza que você configurou a classe apropriada para este
usuário no arquivo de senhas (password) se você não estiver
usando o padrão (use: chpass nome_usuario_mysqld). See
Secção 4.8.2, “mysqld-safe
, o wrapper do mysqld
”.
Se você tiver muita memória você deve considerar em
reconstruir o Kernel para permitir o MySQL de usar mais de
512M de RAM. Dê uma olhada na opção
MAXDSIZ
na arquivo de configuração LINT para
maiores informações.
Se você tiver problemas com a data atual no MySQL, configurar
a variável TZ
provavelmente ajudará. See
Apêndice F, Variáveis de Ambientes do MySQL.
Para obter um sistema seguro e estável você deve usar
somente kernels FreeBSD que estejam marcados com
-STABLE
.
Para compilar no NetBSD você precisa do GNU
make
. De outra forma o compilador quebraria
quando o make
tentasse executar
lint
em arquivos C++.
No OpenBSD Versão 2.5, você pode compilar o MySQL com threads nativas com as seguintes opções:
CFLAGS=-pthread CXXFLAGS=-pthread ./configure --with-mit-threads=no
Nossos usuários relataram que o OpenBSD 2.8 tem um bug nas threads que causa problemas com o MySQL. Os desenvolvedores do OpenBSD já corrigiram o problema, mas em 25 de Janeiro de 2001 a correção foi disponível apenas no ramo ``-current''. Os sintomas deste bug nas threads são: resposta lenta, alta carga, alto uso de CPU e quedas do servidor.
Se você obter um erro como Error in accept:: Bad
file descriptor
ou erro 9 ao tentar abrir tabelas ou
diretórios, o problema é provavelmente que você não alocou
memória suficiente para os descritores de arquivo do MySQL.
Neste caso tente iniciar o mysqld_safe
como
root
com as seguintes opções:
shell> mysqld_safe --user=mysql --open-files-limit=2048 &
Se você obter o seguinte erro quando estiver compilando o
MySQL, seu valor ulimit
para memória
virtual é muito baixo:
item_func.h: In method `Item_func_ge::Item_func_ge(const Item_func_ge &)': item_func.h:28: virtual memory exhausted make[2]: *** [item_func.o] Error 1
Tente usar ulimit -v 80000
e executar o
make
novamente. Se isto não funcionar e
você estiver usando o bash
, tente trocar
para csh
ou sh
; alguns
usuários BSDI relataram problemas com bash
e ulimit
.
Se você utiliza gcc
, você pode também
ter de usar a opção --with-low-memory
para
o configure
estar apto a compilar o
sql_yacc.cc
.
Se você tiver problemas com a data atual no MySQL, configurar
a variável TZ
provavelmente ajudará. See
Apêndice F, Variáveis de Ambientes do MySQL.
Atualize para BSD/OS Versão 3.1. Se isto não for possível, instale BSDIpatch M300-038.
Use o seguinte comando quando configurar o MySQL:
shell>env CXX=shlicc++ CC=shlicc2 \
./configure \
--prefix=/usr/local/mysql \
--localstatedir=/var/mysql \
--without-perl \
--with-unix-socket-path=/var/mysql/mysql.sock
O comeando seguinte também funciona:
shell>env CC=gcc CXX=gcc CXXFLAGS=-O3 \
./configure \
--prefix=/usr/local/mysql \
--with-unix-socket-path=/var/mysql/mysql.sock
Você pode alterar as localizações dos diretórios se você desejar, ou apenas usar os padrões não especificando nenhuma localização.
Se você tiver problemas com performance sob alta carga, tente
usar a opção --skip-thread-priority
para
mysqld
! Isto irá executar todas as threads
com a mesma prioridade; no BSDI versão 3.1, isto fornece
melhor performance (pelo menos até o BSDI corrigir seu
organizador de threads).
Se você obter o erro virtual memory
exhausted
enquanto estiver compilando, deve tentar
usar ulimit -v 80000
e executar
make
novamente. Se isto não funcionar e
você estiver usando bash
, tente trocar
para csh
ou sh
; alguns
usuários BSDI relataram problemas com bash
e ulimit
.
O BSDI Versão 4.x tem alguns bugs relacionados às threads. Se você deseja usar o MySQL nesta versão, você deve instalar todas as correções relacionadas às threads. Pelo menos a M400-23 deve estar instalada.
Em alguns sistemas BSDI versão 4.x, você pode ter problemas
com bibliotecas compartilhadas. O sintoma é que você não
pode executar nenhum programa cliente, por exemplo,
mysqladmin
. Neste caso você precisa
reconfigurar o MySQL, para ele não usar bibliotecas
compartilhadas, com a opção
--disable-shared
.
Alguns clientes tiveram problemas no BSDI 4.0.1 que o binário
do mysqld
não conseguia abrir tabelas
depois de um tempo em funcionamento. Isto é porque alguns
bugs relacionados a biblioteca/sistema fazem com que o
mysqld
altere o diretório atual sem
nenhuma informação!
A correção é atualizar para a 3.23.34 ou depois de executar
configure
remova a linha $define
HAVE_REALPATH
de config.h
antes
de executar o make.
Perceba que com isso você não pode fazer um link simbólico de um diretório de banco de dados para outro diretório ou fazer um link simbólico a uma tabela para outro banco de dados no BSDI! (Criar um link simbólico para outro disco funciona).
O MySQL deve funcionar sem problemas no Mac OS X 10.x (Darwin). Você não precisa dos patches pthread para este SO.
Isto também se aplica ao Mac OS X 10.x Server. A compilação para a plataforma Server é a mesma para a versão cliente do Mac OS X. No entanto note que o MySQL vem preinstalado no Servidor !
Nosso binário para Mac OS X é compilado no Darwin 6.3 com a seguinte linha de configuração:
CC=gcc CFLAGS="-O3 -fno-omit-frame-pointer" CXX=gcc \ CXXFLAGS="-O3 -fno-omit-frame-pointer -felide-constructors \ -fno-exceptions -fno-rtti" ./configure --prefix=/usr/local/mysql \ --with-extra-charsets=complex --enable-thread-safe-client \ --enable-local-infile --disable-shared
Antes de tentar configurar o MySQL no MAC OS X server 1.2 (aka Rhapsody), primeiro você deve instalar o pacote pthread encontrado em: http://www.prnet.de/RegEx/mysql.html.
Alguma das distribuições binárias do MySQL para HP-UX é distribuida como um arquivo depot da HP e como um arquivo tar. Para usar o arquivo depot você deve estar executando pelo menos o HP-UX 10.x para ter acesso às ferramentas de arquivos depot da HP.
A versão HP do MySQL foi compilada em um servidor HP 9000/8xx sob HP-UX 10.20, usando MIT-pthreads. Sob esta configuração o MySQL funciona bem. O MySQL Versão 3.22.26 e mais novas também podem ser construidas com o pacote thread nativo da HP.
Outras configurações que podem funcionar:
HP 9000/7xx executando HP-UX 10.20+
HP 9000/8xx executando HP-UX 10.30
As seguintes configurações definitivamente não funcionarão:
HP 9000/7xx ou 8xx executando HP-UX 10.x where x < 2
HP 9000/7xx ou 8xx executando HP-UX 9.x
Para instalar a distribuição, utilze um dos comandos abaixo,
onde /path/to/depot
é o caminho completo
do arquivo depot:
Para instalar tudo, incluindo o servidor, cliente e ferramentas de desenvolvimento:
shell> /usr/sbin/swinstall -s /path/to/depot mysql.full
Para instalar somente o servidor:
shell> /usr/sbin/swinstall -s /path/to/depot mysql.server
Para instalar somente o pacote cliente:
shell> /usr/sbin/swinstall -s /path/to/depot mysql.client
Para instalar somente as ferramentas de desenvolvimento:
shell> /usr/sbin/swinstall -s /path/to/depot mysql.developer
O depot copia os binários e bibliotecas em
/opt/mysql
e dados em
/var/opt/mysql
. O depot também cria as
entradas apropriadas em /etc/init.d
e
/etc/rc2.d
para iniciar o servidor
automaticamente na hora do boot. Obviamente, para instalar o
usuário deve ser o root
.
Para instalar a distribuição HP-UX tar.gz, você deve ter
uma cópia do GNU tar
.
Existem alguns pequenos problemas quando compilamos o MySQL no
HP-UX. Nós recomendamos que você use o
gcc
no lugar do compilador nativo do HP-UX,
porque o gcc
produz um código melhor!
Nós recomendamos o uso do gcc
2.95 no
HP-UX. Não utilize opções de alta otimização (como -O6)
ja que isto pode não ser seguro no HP-UX.
A seguine linha do configure
deve funcionar
com o gcc 2.95:
CFLAGS="-I/opt/dce/include -fpic" \ CXXFLAGS="-I/opt/dce/include -felide-constructors -fno-exceptions \ -fno-rtti" CXX=gcc ./configure --with-pthread \ --with-named-thread-libs='-ldce' --prefix=/usr/local/mysql --disable-shared
A seguinte linha do configure
deve
funcionar com o gcc 3.1:
CFLAGS="-DHPUX -I/opt/dce/include -O3 -fPIC" CXX=gcc \ CXXFLAGS="-DHPUX -I/opt/dce/include -felide-constructors -fno-exceptions \ -fno-rtti -O3 -fPIC" ./configure --prefix=/usr/local/mysql \ --with-extra-charsets=complex --enable-thread-safe-client \ --enable-local-infile --with-pthread \ --with-named-thread-libs=-ldce --with-lib-ccflags=-fPIC --disable-shared
Para HP-UX Versão 11.x nós recomendamos o MySQL Versão 3.23.15 ou posterior.
Por causa de alguns bugs críticos nas bibliotecas padrão do HP-UX, você deve instalar as seguintes correções antes de tentar executar o MySQL no HP-UX 11.0:
PHKL_22840 Streams cumulative PHNE_22397 ARPA cumulative
Isto irá resolver um problema que tem como retorno
EWOLDBLOCK
de recv()
e
EBADF
de accept()
em
aplicações threads.
Se você estiver usando gcc
2.95.1 em um
sistema HP-UX 11.x sem correções, você obterá o erro:
In file included from /usr/include/unistd.h:11, from ../include/global.h:125, from mysql_priv.h:15, from item.cc:19: /usr/include/sys/unistd.h:184: declaration of C function ... /usr/include/sys/pthread.h:440: previous declaration ... In file included from item.h:306, from mysql_priv.h:158, from item.cc:19:
O problema é que o HP-UX não define consistentemente a
pthreads_atfork()
. Ela tem protótipos
coflitantes em
/usr/include/sys/unistd.h
:184 e
/usr/include/sys/pthread.h
:440 (detalhes
abaixo).
Uma solução é copiar
/usr/include/sys/unistd.h
em
mysql/include
e editar
unistd.h
alterando-o para coincidir com a
definição em pthread.h
. Aqui está o
diff:
183,184c183,184 < extern int pthread_atfork(void (*prepare)(), void (*parent)(), < void (*child)()); --- > extern int pthread_atfork(void (*prepare)(void), void (*parent)(void), > void (*child)(void));
Depois disto, a seguinte linha configure deve funcionar:
CFLAGS="-fomit-frame-pointer -O3 -fpic" CXX=gcc \ CXXFLAGS="-felide-constructors -fno-exceptions -fno-rtti -O3" \ ./configure --prefix=/usr/local/mysql --disable-shared
Segue algumas inforamações que um usuário do HP-UX Versão 11.x nos enviou sobre compilação do MySQL com o compilador HP-UX:
CC=cc CXX=aCC CFLAGS=+DD64 CXXFLAGS=+DD64 ./configure --with-extra-character-set=complex
Você pode ignorar qualquer erro do tipo:
aCC: warning 901: unknown option: `-3': use +help for online documentation
Se você obter o seguinte erro do configure
checking for cc option to accept ANSI C... no configure: error: MySQL requires a ANSI C compiler (and a C++ compiler). Try gcc. See the Installation chapter in the Reference Manual.
Confira se você não tem o caminho para o compilador K&R antes do caminho para o compilador C e C++ do HP-UX.
Outra razão para não estar compilando é você não definir
o parâmetro +DD64
acima.
Outra possibilidade para o HP-UX 11 é usar o binário MySQL para HP-UX 10.20. Recebemos relatos de alguns usuários de que esses binários funcionam bem no HP-UX 11.00. Se você encontrar problemas, verifique o nível do pacth de seu HP-UX.
Detecção automática de xlC
está
faltando no Autoconf, portando um comando
configure
deste tipo é necessário quando
estiver compilando o MySQL (Este exemplo usa o compilador
IBM):
export CC="xlc_r -ma -O3 -qstrict -qoptimize=3 -qmaxmem=8192 " export CXX="xlC_r -ma -O3 -qstrict -qoptimize=3 -qmaxmem=8192" export CFLAGS="-I /usr/local/include" export LDFLAGS="-L /usr/local/lib" export CPPFLAGS=$CFLAGS export CXXFLAGS=$CFLAGS ./configure --prefix=/usr/local \ --localstatedir=/var/mysql \ --sysconfdir=/etc/mysql \ --sbindir='/usr/local/bin' \ --libexecdir='/usr/local/bin' \ --enable-thread-safe-client \ --enable-large-files
Acima estão as opções usadas para compilar a distribuição MySQL que pode ser encontrada em http://www-frec.bull.com/.
Se você alterar o -O3
para
-O2
na linha de configuração acima, você
também deve remover a opção -qstrict
(isto é uma limitação no compilador C da IBM).
Se você estiver usando gcc
ou
egcs
para compilar o MySQL, você
DEVE usar a opção
-fno-exceptions
, já que o manipulador de
exceções no gcc
/egcs
não é seguro para threads! (Isto foi testado com
egcs
1.1). Existem também alguns problemas
conhecidos com o assembler da IBM que pode gerar código
errado quando usado com gcc.
Nós recomendamos a seguinte linha do
configure
com egcs
e
gcc 2.95
no AIX:
CC="gcc -pipe -mcpu=power -Wa,-many" \ CXX="gcc -pipe -mcpu=power -Wa,-many" \ CXXFLAGS="-felide-constructors -fno-exceptions -fno-rtti" \ ./configure --prefix=/usr/local/mysql --with-low-memory
O -Wa,-many
é necessário para o
compilador ser bem sucedido. IBM está ciente deste problema
mas não está com pressa de corrigí-lo devido ao fato do
problema poder ser contornado. Nós não sabemos se o
-fno-exceptions
é necessário com
gcc 2.9.5
, mas como o MySQL não utiliza
exceções e a opção acima gera código mais rápido,
recomendamos que você sempre use esta opção com o
egcs/gcc
.
Se você tiver algum problema com código assembler tente alterar o -mcpu=xxx para o seu processador. Normalmente power2, power ou powerpc podem ser usados, de uma maneira alternativa você pode precisar usar 604 ou 604e. Não tenho certeza mas acredito que usar "power" deve satisfazer a maioria dos casos, mesmo em uma máquina power2.
Se você não sabe qual é o seu processador, utilize o comando "uname -m", isto irá fornecer a você uma string que parece com "000514676700", com um formato de xxyyyyyymmss onde xx e ss são sempre 0s, yyyyyy é o ID único do sistema e mm é o ID da CPU Planar. Uma tabela destes valores podem ser encontrados em http://publib.boulder.ibm.com/doc_link/en_US/a_doc_lib/cmds/aixcmds5/uname.htm. Isto irá lhe fornecer um tipo de máquina e um modelo de máquina que você pode usar para determinar que tipo de cpu você tem.
Se você tiver problemas com sinais (MySQL finaliza sem notificação sob alta carga) você pode ter encontrado um bug de SO com threads e sinais. Neste caso você pode dizer ao MySQL para não usar sinais configurando-o com:
shell>CFLAGS=-DDONT_USE_THR_ALARM CXX=gcc \
CXXFLAGS="-felide-constructors -fno-exceptions -fno-rtti \
-DDONT_USE_THR_ALARM" \
./configure --prefix=/usr/local/mysql --with-debug --with-low-memory
Isto não afeta a performance do MySQL, mas tem o efeito
colateral que você não pode matar clientes que estão
``dormindo'' em uma conexão com mysqladmin
kill
ou mysqladmin shutdown
.
Neste caso, o cliente morrerá quando ele chegar no próximo
comando.
Em algumas versões do AIX, ligando com
libbind.a
faz o
getservbyname
descarregar core. Isto é
erro no AIX e deve ser relatado para a IBM.
Para o AIX 4.2.1 e gcc você tem que fazer as seguintes alterações.
Depois de configurar, edite o config.h
e
include/my_config.h
e altere a linha que
diz
#define HAVE_SNPRINTF 1
para
#undef HAVE_SNPRINTF
E finalmente, no mysqld.cc
você precisa
adicionar um protótipo para initgroups.
#ifdef _AIX41 extern "C" int initgroups(const char *,int); #endif
Se você precisar se alocar muita memória para o processo
mysqld, não é suficiente apenas definir 'ulimit -d
unlimited'. Você também deve configurar no
mysqld_safe
algo do tipo:
export LDR_CNTRL='MAXDATA=0x80000000'
Você pode encontrar mais sobre o uso de muita memória em: http://publib16.boulder.ibm.com/pseries/en_US/aixprggd/genprogc/lrg_prg_support.htm.
No SunOS 4, é necessário a MIT-pthreads para compilar o
MySQL, o que significa que você precisa do GNU
make
.
Alguns sistemas SunOS 4 tem problemas com bibliotecas
dinâmicas e libtool
. Você pode usar a
seguinte linha do configure
para evitar
este problema:
shell> ./configure --disable-shared --with-mysqld-ldflags=-all-static
Quando compilando readline
, você pode
obter alguns avisos sobre definições duplicadas que podem
ser ignoradas.
Ao compilar o mysqld
, vão existir alguns
alertas sobre implicit declaration of
function
que também podem ser ignoradas.
Se você está usando o egcs 1.1.2 no Digital Unix, você atualizar par o gcc 2.95.2, já que o egcs no DEC tem vários erros graves !
Quando compilando programas com threads no Digital Unix, a
documentação recomenda usar a opção
-pthread
para cc
e
cxx
e as bibliotecas -lmach
-lexc
(em adição para
-lpthread
). Você deve executar o
configure
parecido com isto:
CC="cc -pthread" CXX="cxx -pthread -O" \ ./configure --with-named-thread-libs="-lpthread -lmach -lexc -lc"
Quando compilando o mysqld
, você deve ver
alguns avisos como estes:
mysqld.cc: In function void handle_connections()': mysqld.cc:626: passing long unsigned int *' as argument 3 of accept(int,sockadddr *, int *)'
Você pode ignorar estes altertas com segurança. Eles ocorrem
porque o configure
só pode detectar erros
e não alertas.
Se você inicia o servidor diretamente da linha de comando,
você pode ter problemas com a finalização do servidor ao
sair (log out). (Quando você sai, seu processo superior
recebe um sinal SIGHUP
.) Se isto acontecer,
tente iniciar o servidor desta forma:
shell> nohup mysqld [options] &
nohup
faz com que o comando que o segue
ignore qualquer sinal SIGHUP
enviado pelo
terminal. De forma alternativa, inicie o servidor executando
mysqld_safe
, o qual invoca o
mysqld
usando nohup
por
você. See Secção 4.8.2, “mysqld-safe
, o wrapper do mysqld
”.
Se você tiver problemas quando compilar mysys/get_opt.c, apenas remova a linha #define _NO_PROTO do inicio do arquivo!
Se você estiver utilizando o compilador CC da Compac, a seguinte linha de configuração deverá funcionar:
CC="cc -pthread" CFLAGS="-O4 -ansi_alias -ansi_args -fast -inline speed all -arch host" CXX="cxx -pthread" CXXFLAGS="-O4 -ansi_alias -ansi_args -fast -inline speed all -arch host \ -noexceptions -nortti" export CC CFLAGS CXX CXXFLAGS ./configure \ --prefix=/usr/local/mysql \ --with-low-memory \ --enable-large-files \ --enable-shared=yes \ --with-named-thread-libs="-lpthread -lmach -lexc -lc" gnumake
Se você tiver problemas com a libtool, ao compilar com
bibliotecas compartilhadas como no exemplo acima, quando
estiver ligando ao mysqld
, você deve
conseguir contornar este problema usando:
cd mysql /bin/sh ../libtool --mode=link cxx -pthread -O3 -DDBUG_OFF \ -O4 -ansi_alias -ansi_args -fast -inline speed \ -speculate all \ -arch host -DUNDEF_HAVE_GETHOSTBYNAME_R \ -o mysql mysql.o readline.o sql_string.o completion_hash.o \ ../readline/libreadline.a -lcurses \ ../libmysql/.libs/libmysqlclient.so -lm cd .. gnumake gnumake install scripts/mysql_install_db
Se você tiver problemas com compilação e tem o DEC
CC
e o gcc
instalados,
tente executar o configure
desta forma:
CC=cc CFLAGS=-O CXX=gcc CXXFLAGS=-O3 \ ./configure --prefix=/usr/local/mysql
Se você tiver problemas com o arquivo
c_asm.h
, você pode criar e usar um
arquivo c_asm.h
'burro' com:
touch include/c_asm.h CC=gcc CFLAGS=-I./include \ CXX=gcc CXXFLAGS=-O3 \ ./configure --prefix=/usr/local/mysql
Perceba que os seguintes problemas com o programa
ld
pode ser corrigido fazendo o download do
último kit de atualização da DEC (Compaq) de
http://ftp.support.compaq.com/public/unix/.
Com o OSF1 V4.0D e o compilador "DEC C V5.6-071 no Digital
Unix V4.0 (Rev. 878)" o compilador tem alguns comportamentos
estranhos (simbolos asm
indefinidos).
/bin/ld
também aparece estar quebrado
(problemas com erros _exit undefined
ocorrendo ao ligar no mysqld
). Neste
sistema, temos compilado o MySQL com a seguinte linha
configure
, depois de substituir
/bin/ld
com a versão do OSF 4.0C:
CC=gcc CXX=gcc CXXFLAGS=-O3 ./configure --prefix=/usr/local/mysql
Com o compilador da Digital "C++ V6.1-029", o seguinte deve funcionar:
CC=cc -pthread CFLAGS=-O4 -ansi_alias -ansi_args -fast -inline speed -speculate all \ -arch host CXX=cxx -pthread CXXFLAGS=-O4 -ansi_alias -ansi_args -fast -inline speed -speculate all \ -arch host -noexceptions -nortti export CC CFLAGS CXX CXXFLAGS ./configure --prefix=/usr/mysql/mysql --with-mysqld-ldflags=-all-static \ --disable-shared --with-named-thread-libs="-lmach -lexc -lc"
Em algumas versões do OSF1, a função
alloca()
está quebrada. Corrija isto
removendo a linha no config.h
que define
'HAVE_ALLOCA'
.
A função alloca()
pode também ter um
protótipo incorreto em
/usr/include/alloca.h
. O alerta resultante
deste erro pode ser ignorado.
configure
irá usar a seguinte biblioteca
thread automaticamente:
--with-named-thread-libs="-lpthread -lmach -lexc
-lc"
.
Quando usar o gcc
, você também pode
tentar executar configure
desta forma:
shell> CFLAGS=-D_PTHREAD_USE_D4 CXX=gcc CXXFLAGS=-O3 ./configure ....
Se você tiver problemas com sinais (MySQL finalzar inesperadamente sobre alta carga), você pode ter encontrado um erro com threads e sinais no SO. Neste caso você pode dizer ao MySQL para não usar sinais configurando-o com:
shell>CFLAGS=-DDONT_USE_THR_ALARM \
CXXFLAGS=-DDONT_USE_THR_ALARM \
./configure ...
Isto não afeta a performance do MySQL, mas tem efeitos
colaterais que não permitem finalizar clientes que estão
``dormindo'' em uma conexão com mysqladmin
kill
ou mysqladmin shutdown
.
Neste caso o cliente irá morrer quando ele receber o próximo
comando.
Com gcc
2.95.2, você provavelmente
encontrará o seguinte erro de compilação:
sql_acl.cc:1456: Internal compiler error in `scan_region', at except.c:2566 Please submit a full bug report.
Para corrigir isto você deve alterar para o diretório
sql
e fazer um ``corta e cola'' da última
linha gcc
, mas altere
-O3
para -O0
(ou
adicione -O0
imediatamente depois de
gcc
se você não tiver algumas opção
-O
na sua linha de compilação.) Depois
disto feito você deve apenas voltar ao diretório superior e
executar make
novamente.
Se você estiver usando Irix Versão 6.5.3 ou mais novo, o
mysqld
só irá conseguir criar threads se
você executá-lo como um usuário com privilégios de
CAP_SCHED_MGT
(como
root
) ou dar ao servidor
mysqld
este privilégio com o seguinte
comando shell:
shell> chcap "CAP_SCHED_MGT+epi" /opt/mysql/libexec/mysqld
Você pode precisar indefinir alguns simbolos em
config.h
depois de executar
configure
e antes de compilar.
Em algumas implementações Irix, a função
alloca()
está quebrada. Se o servidor
mysqld
morrer em alguma instrução
SELECT
, remova as linhas de
config.h
que definem
HAVE_ALLOC
e
HAVE_ALLOC_H
. Se mysqladmin
create
não funciona, remova a linha do
config.h
que define
HAVE_READDIR_R
. Você também deve precisar
remover a linha HAVE_TERM_H
.
A SGI recomenda que você instale todos os patches desta página: http://support.sgi.com/surfzone/patches/patchset/6.2_indigo.rps.html
No mínimo, você deve instalar o último rollup do kernel, o
último rollup rld
, e o último rollup
libc
.
Definitivamente você precisará de todos patches POSIX nesta página, para suporte pthreads:
http://support.sgi.com/surfzone/patches/patchset/6.2_posix.rps.html
Se você obter o seguinte erro quando estiver compilando o
mysql.cc
:
"/usr/include/curses.h", line 82: error(1084): invalid combination of type
Digite o seguinte no diretório topo da sua árvore fonte do MySQL:
shell>extra/replace bool curses_bool < /usr/include/curses.h \
> include/curses.h
shell>make
Existem relatos de problemas com organização de threads. Se somente uma thread estiver executando, o sistema fica lento. Pode se evitar isto iniciando outro cliente. Isto pode acarretar num crescimento de 2 para 10 vezes na velocidade de execução para a outra thread. Isto é um problema não compreendido com threads Irix; você deve improvisar para encontrar soluções até que isto seja resolvido.
Se você estiver compilando com gcc
, você
pode usar o seguinte comando configure
:
CC=gcc CXX=gcc CXXFLAGS=-O3 \ ./configure --prefix=/usr/local/mysql --enable-thread-safe-client \ --with-named-thread-libs=-lpthread
No Irix 6.5.11 com Irix C nativo e compiladores C++ ver. 7.3.1.2, o seguinte irá funcionar
CC=cc CXX=CC CFLAGS='-O3 -n32 -TARG:platform=IP22 -I/usr/local/include \ -L/usr/local/lib' CXXFLAGS='-O3 -n32 -TARG:platform=IP22 \ -I/usr/local/include -L/usr/local/lib' ./configure \ --prefix=/usr/local/mysql --with-innodb --with-berkeley-db \ --with-libwrap=/usr/local \ --with-named-curses-libs=/usr/local/lib/libncurses.a
A versão atual foi testado somente nos sistemas ``sco3.2v5.0.4'' e ``sco3.2v5.0.5''. A versãoo para o ``sco 3.2v4.2'' também tem tido muito progresso.
Até o momento o compilador recomendado no OpenServer é o gcc 2.95.2. Com isto você deve estar apto a compilar o MySQL apenas com:
CC=gcc CXX=gcc ./configure ... (opções)
Para o OpenServer 5.0.X você precisa usar gcc-2.95.2p1 ou mais novo da Skunkware. http://www.SCO.com/skunkware/ e ecolher o pacote OpenServer browser ou por ftp em ftp to ftp2.SCO.com no diretório pub/skunkware/osr5/devtools/gcc.
Você precisa do GCC versão 2.5.x para este produto e do sistema de desenvolvimento. Eles são necessários nesta versão do SCO Unix. Você não pode usar apenas o sistema GCC Dev.
Você deve obter o pacote FSU Pthreads e instalá-lo primeiro. Pode ser obtido em http://www.cs.wustl.edu/~schmidt/ACE_wrappers/FSU-threads.tar.gz. Você pode também obter um pacote precompilado de http://www.mysql.com/Downloads/SCO/FSU-threads-3.5c.tar.gz.
FSU Pthreads pode ser compilado com SCO Unix 4.2 com tcpip, ou OpenServer 3.0 ou OpenDesktop 3.0 (OS 3.0 ODT 3.0), com o Sistema de Desenvolvimento da SCO instalado usando uma boa versão do GCC 2.5.x ODT ou OS 3.0, no qual você necessitará de uma boa versão do GCC 2.5.x. Existem vários problemas sem uma boa versão. Esta versão do produto necessita do sistema de Desenvolvimento SCO Unix. Sem ele, você estará perdendo as bibliotecas e o editor de ligação necessário.
Para construir a FSU Pthreads no seu sistema, faça o seguinte:
Execute ./configure
no diretório
threads/src
e selecione a opção
SCO OpenServer. Este comando copia
Makefile.SCO5
para
Makefile
.
Execute make
.
Para instalar no diretório padrão
/usr/include
, use o usuário
root, depois mude para o diretório
thread/src
e execute
make install
Lembre de usar o GNU make
quando
estiver construindo o MySQL.
Se você não iniciou o mysqld_safe
como root, você provavelmente só irá obter, por
padrão, os 110 arquivos abertos por processo. O
mysqld
irá gravar uma nota sobre isto
no arquivo log.
Com o SCO 3.2V5.0.5, você deve usar o FSU Pthreads versão 3.5c ou mais nova. Você deve também usar o gcc 2.95.2 ou mais novo.
O seguinte comando configure
deve
funcionar:
shell> ./configure --prefix=/usr/local/mysql --disable-shared
Com SCO 3.2V4.2, você deve usar FSU Pthreads versão 3.5c
ou mais nova. O seguinte comando
configure
deve funcionar:
shell>CFLAGS="-D_XOPEN_XPG4" CXX=gcc CXXFLAGS="-D_XOPEN_XPG4" \
./configure \
--prefix=/usr/local/mysql \
--with-named-thread-libs="-lgthreads -lsocket -lgen -lgthreads" \
--with-named-curses-libs="-lcurses"
Você pode ter alguns problemas com alguns arquivos de
inclusão. Neste caso, você pode encontrar novos arquivos
de inclusão específicos do SCO em
http://www.mysql.com/Downloads/SCO/SCO-3.2v4.2-includes.tar.gz.
Você deve descompactar este arquivo no diretório
include
da sua árvore fonte do
MySQL.
Notas de desenvolvimento SCO:
O MySQL deve detectar automaticamente FSU Pthreads e ligar
o mysqld
com -lgthreads
-lsocket -lgthreads
.
As bibliotecas de desenvolvimento SCO são re-entrantes nas FSU Pthreads. A SCO diz que suas bibliotecas de funções são re-entrantes, então elas devem ser re-entrantes com as FSU-Pthreads. FSU Pthreads no OpenServer tentam usar o esquema SCO para criar bibliotecas re-entrantes.
FSU Pthreads (ao menos a versão em
http://www.mysql.com)
vem ligada com GNU malloc
. Se você
encontrar problemas com uso de memória, tenha certeza que
o gmalloc.o
esteja incluído em
libgthreads.a
e
libgthreads.so
.
Na FSU Pthreads, as seguintes chamadas de sistema são
compatíveis com pthreads: read()
,
write()
, getmsg()
,
connect()
, accept()
,
select()
e wait()
.
O CSSA-2001-SCO.35.2 (O patch é listado de costume como patch de segurança erg711905-dscr_remap ver 2.0.0) quebra FSU threads e deixa o mysqld instável. Você deve remove-lo se você deseja executar o mysqld em uma máquina OpenServer 5.0.6.
A SCO fornece Patches do Sistema Operacional em ftp://ftp.sco.com/pub/openserver5 para OpenServer 5.0.x
A SCO fornece correções de segurança e libsocket.so.2 em ftp://ftp.sco.com/pub/security/OpenServer e ftp://ftp.sco.com/pub/security/sse para OpenServer 5.0.x
Correções de segurança pre-OSR506. També a correção do telnetd em ftp://stage.caldera.com/pub/security/openserver/ ou ftp://stage.caldera.com/pub/security/openserver/CSSA-2001-SCO.10/ com a libsocket.so.2 e libresolv.so.1 com instruções para instalar em sistemas pre-OSR506.
É provavelmente uma boa idéia para instalar os patches acima tentando compilar/usar o MySQL.
Se você deseja instalar o DBI no SCO, você deve editar o
Makefile
em DBI-xxx e cada subdiretório.
Note que o exemplo abaixo considera o gcc 2.95.2 ou mais novo:
OLD: NEW: CC = cc CC = gcc CCCDLFLAGS = -KPIC -W1,-Bexport CCCDLFLAGS = -fpic CCDLFLAGS = -wl,-Bexport CCDLFLAGS = LD = ld LD = gcc -G -fpic LDDLFLAGS = -G -L/usr/local/lib LDDLFLAGS = -L/usr/local/lib LDFLAGS = -belf -L/usr/local/lib LDFLAGS = -L/usr/local/lib LD = ld LD = gcc -G -fpic OPTIMISE = -Od OPTIMISE = -O1 OLD: CCCFLAGS = -belf -dy -w0 -U M_XENIX -DPERL_SCO5 -I/usr/local/include NEW: CCFLAGS = -U M_XENIX -DPERL_SCO5 -I/usr/local/include
Isto é porque o carregador dinâmico Perl não irá carregar
os módulos DBI
se elas foram compiladas
com icc
ou cc
.
Perl trabalha melhor quando compilado com
cc
.
Você deve usar uma versão de MySQL pelo menos tão recente quando a Versão 3.22.13 e UnixWare 7.1.0 porque esta versão corrige alguns problemas de portabilidade sob o Unixware.
Nós temos compilado o MySQL com o seguinte comando
configure
no UnixWare Versão 7.1.x:
CC=cc CXX=CC ./configure --prefix=/usr/local/mysql
Se você deseja usar o gcc
, deverá ser
usado o gcc
2.95.2 ou mais novo.
CC=gcc CXX=g++ ./configure --prefix=/usr/local/mysql
A SCO fornece Patches do Sistema Operacional em ftp://ftp.sco.com/pub/unixware7 para UnixWare 7.1.1 e 7.1.3 ftp://ftp.sco.com/pub/openunix8 para OpenUNIX 8.0.0
A SCO fornece informação sobre Security Fixes em ftp://ftp.sco.com/pub/security/OpenUNIX para OpenUNIX ftp://ftp.sco.com/pub/security/UnixWare para UnixWare
O MySQL usa poucos arquivos aberto. Por isto, você deve
adicionar uma linha parecida com a abaixo em seu arquivo
CONFIG.SYS
:
SET EMXOPT=-c -n -h1024
Se você não fizer isto, provavelmente vai ter o seguinte erro:
File 'xxxx' not found (Errcode: 24)
Quando usar o MysQL com OS/2 Warp 3, o FixPack 29 ou superior é necessário. Com OS/2 Warp 4, FixPack 4 ou acima é necessário. Isto é uma exigência da biblioteca Pthreads. O MySQL deve estar instalado em uma partição que suporta nomes longos de arquivos como no HPFS, FAT32, etc.
O script INSTALL.CMD
deve ser executado
pelo próprio CMD.EXE
do OS/2 e opde não
funcionar com shells substitutas como o
4OS2.EXE
.
O script scripts/mysql-install-db
foi
renomeado. Agora ele é chamado install.cmd
e é um script REXX, que irá atualizar as configurações
padrões de segurança do MySQL e criar os ícones na WorkPlace
Shell para o MySQL.
Suporte a módulos dinâmicos é compilado mas não totalmente testado. Módulos dinâmicos devem ser compilados usando a biblioteca run-time Pthreads.
gcc -Zdll -Zmt -Zcrtdll=pthrdrtl -I../include -I../regex -I.. \ -o example udf_example.cc -L../lib -lmysqlclient udf_example.def mv example.dll example.udf
Nota: Devido a limitações no
OS/2, o nome do módulo UDF não deve esceder 8 caracteres.
Módulos são armazenados no diretório
/mysql2/udf
; o script
safe-mysqld.cmd
irá colocar este diretório
na variável de ambiente BEGINLIBPATH
. Quando
usando módulos UDF, extensões específicas são ignoradas ---
consuidera-se que seja .udf
. Por exemplo,
no Unix, o módulo compartilhado deve ser nomeado
example.so
e você deve carregar uma
função dele desta forma:
mysql> CREATE FUNCTION metaphon RETURNS STRING SONAME "example.so";
No OS/2, o módulo deve ter o nome de
example.udf
, mas você não deve
especificar a extensão do módulo:
mysql> CREATE FUNCTION metaphon RETURNS STRING SONAME "example";
Portar o MySQL
para
NetWare
foi um grande esforço da
Novell
. Os clientes da Novell estarão
satisfeitos ao notarem que o NetWare 6.5 virá com os binários
do MySQL, completa com uma licença de uso comercial automatica
para todos os servidores executando esta versão do NetWare.
See Secção 2.1.4, “Instalando o MySQL no NetWare”.
MySQL para NetWare é compilado usando um combinação do
Metrowerks CodeWarrior for NetWare
e uma
versão especial de compilação cruzada do GNU autotools.
Verifique esta seção no futuro para mais informações sobre
construção e otimização do MySQL para NetWare.
O suporte Perl para o MySQL é fornecido pela interface cliente
DBI
/DBD
. See
Secção 12.5, “API Perl do MySQL”. O código do cliente Perl
DBD
/DBI
exige Perl Versão
5.004 ou posterior. A interface não
funcionará se você tiver uma versão mais do Perl.
O suporte MySQL Perl também exige que você tenha instalado o suporte a programação do cliente MySQL. Se você instalou o MySQL a partir de arquivos RPM, os programas cliente estão no cliente RPM, mas o suporte a programação do cliente está no RPM de desenvolvimento. Certifique de se instalar este RPM posteriormente.
Na Versão 3.22.8, o suporte Perl é distribuído separadamente do dsitribuição principal do MySQL. Se você quiser instalar o suporte Perl, os arquivos que você precisrá pode ser obtidos em http://www.mysql.com/downloads/api-dbi.html.
As distribuições Perl são fornecidas como arquios
tar
compactados e são chamados
MODULE-VERSION.tar.gz
, onde
MODULE
é o nome do modulo e
VERSION
é o número da versão. Você deve
conseguir as distribuições Data-Dumper
,
DBI
, e DBD-mysql
e
instalá-las nesta ordem. O procedimento de instalação é
mostrado aqui. O exemplo mostrado é para o módulo
Data-Dumper
, mas o procedimento é o mesmo
para todas as distribuições:
Descompacte as distribuições no diretório atual:
shell> gunzip < Data-Dumper-VERSION.tar.gz | tar xvf -
Este comando cria um diretório chamado
Data-Dumper-VERSION
.
Entre no diretório principal da distribuição descompactada:
shell> cd Data-Dumper-VERSION
Contrua a dsitribuição e compile tudo:
shell>perl Makefile.PL
shell>make
shell>make test
shell>make install
O comando make test
é importante porque
verifica que o módulo está funcionando. Note que ao executar
este comando durante a instalação do
DBD-mysql
para exercitar o código da
interface, o servidor MySQL deve estar em execução ou teste
irá falhar.
É uma boa idéia reconstruir e reinstalar a distribuição
DBD-mysql
mesmo se você instalar uma nova
distribuição do MySQL, particularmente se você notar
simntomas como se todos os seus scripts DBI
realizarem dump core depois de você atualizar o MySQL.
Se você não tem o direito para instalar os módulos Perl no diretório de sistema ou se você quiser instalar módulos Perl locais, a seguinte referência pode ajudá-lo:
http://servers.digitaldaze.com/extensions/perl/modules.html#modules
Procure sob o título Installing New Modules that
Require Locally Installed Modules
.
Para instalar o módulo DBD
do MySQL com
ActiveState Perl no Windows, você deve fazer o seguinte:
Obter o ActiveState Perl em http://www.activestate.com/Products/ActivePerl/ e instalá-lo.
Abrir um prompt do DOS.
Se exigido, configurar a variável
HTTP_proxy
. Por exemplo, você pode
tentar:
set HTTP_proxy=my.proxy.com:3128
Inicie o progrma PPM:
C:\> c:\perl\bin\ppm.pl
Se você já não o fez, instale o DBI
:
ppm> install DBI
Se der tudo certo, execute o seguinte comando:
install \ ftp://ftp.de.uu.net/pub/CPAN/authors/id/JWIED/DBD-mysql-1.2212.x86.ppd
O acima deve funcionar pelo menos com o ActiveState Perl Versão 5.6.
Se você não puder fazer o mostrado acima funcionar, você deve
instalar o driver MyODBC
e conectar ao
servidor MySQL através do ODBC:
use DBI; $dbh= DBI->connect("DBI:ODBC:$dsn",$user,$password) || die "Got error $DBI::errstr when connecting to $dsn\n";
Se Perl informar que não pode encontrar o módulo
../mysql/mysql.so
, então o problema mais
provável é que o Perl não pode localizar a biblioteca
compartilhada libmysqlclient.so
.
Você pode corrigir isto por qualquer um dos seguintes métodos:
Compile a distribuição DBD-mysql
com
perl Makefile.PL -static -config
em vez
de perl Makefile.PL
.
Copie libmysqlclient.so
para a
diretório onde sua bibliotecas compartilhadas estão
localizadas (provavelmente /usr/lib
ou
/lib
).
No Linux você pode adicionar o caminho do diretório onde
libmysqlclient.so
está localizado ao
arquivo /etc/ld.so.conf
.
Adicione o caminho do diretório onde
libmysqlclient.so
está localizada à
variável de ambiente LD_RUN_PATH
.
Se voce receber os seguintes erros de
DBD-mysql
, você provavelmente está usando
gcc
(ou usando um binário antigo compilado
com gcc
):
/usr/bin/perl: can't resolve symbol '__moddi3' /usr/bin/perl: can't resolve symbol '__divdi3'
Adicione -L/usr/lib/gcc-lib/... -lgcc
ao
comando de ligação quando a biblioteca
mysql.so
estiver construída (verifique a
saída de make
para
mysql.so
quando você compilar o cliente
Perl). A opção -L
deve especificar o
caminho do diretório onde libgcc.a
está
localizada no seu sistema.
Outra causa deste problema pode ser que Perl e o MySQL não são
compilados com gcc
. Neste caso, você pode
resolver o problema compilando ambos com gcc
.
Se você receber o seguinte erro de DBD-mysql
quando executar o teste:
t/00base............install_driver(mysql) failed: Can't load '../blib/arch/auto/DBD/mysql/mysql.so' for module DBD::mysql: ../blib/arch/auto/DBD/mysql/mysql.so: undefined symbol: uncompress at /usr/lib/perl5/5.00503/i586-linux/DynaLoader.pm line 169.
significa que você precisa adicionar a biblioteca compactada,
-lz
, a sua linha de ligação. Isto pode ser
feito com a seguinte alteração no arquivo
lib/DBD/mysql/Install.pm
:
$sysliblist .= " -lm";
Altere esta linha para:
$sysliblist .= " -lm -lz";
Depois disto, você deve executar 'make realclean' e proceder com o instalação desde o início.
Se você quiser usar o módulo Perl em um sistema que não
suporta ligação dinâmica (como SCO) você pode gerar uma
versão estática do Perl que inclui DBI
e
DBD-mysql
. O modo que isto funciona é que
você gera uma versão do Perl com o çodigo
DBI
ligado e instalado no topo do seu Perl
atual. Entao você o utiliza para construir uma versão do Perl
que adicionalmente tem o código DBD
ligado
em si, e instale-o.
No SCO, você deve ter as seguintes variáveis de ambiente configuradas:
shell>LD_LIBRARY_PATH=/lib:/usr/lib:/usr/local/lib:/usr/progressive/lib
ou shell>LD_LIBRARY_PATH=/usr/lib:/lib:/usr/local/lib:/usr/ccs/lib:\
/usr/progressive/lib:/usr/skunk/lib
shell>LIBPATH=/usr/lib:/lib:/usr/local/lib:/usr/ccs/lib:\
/usr/progressive/lib:/usr/skunk/lib
shell>MANPATH=scohelp:/usr/man:/usr/local1/man:/usr/local/man:\
/usr/skunk/man:
Primeiro crie um Perl que inclui um módulo
DBI
ligado estaticamente executando estes
comandos no diretório onde a sua distribuição
DBI
está localiada:
shell>perl Makefile.PL -static -config
shell>make
shell>make install
shell>make perl
Então você deve intalar o novo Perl. A saída de make
perl
indicará o comando make
exato
que você precisará executar para realizar a instalação. No
SCO, isto é make -f Makefile.aperl inst_perl
MAP_TARGET=perl
.
A seguir use o Perl récem criado para criar outro Perl que
também inclui uma DBD::mysql
estaticamente
ligado rodando estes comandos no diretório onde sua
distribuição DBD-mysql
está localizada:
shell>perl Makefile.PL -static -config
shell>make
shell>make install
shell>make perl
Finalmente você deve instalar este novo Perl. Novamente, a
saída de make perl
indica o comando a usar.
This is a translation of the MySQL Reference Manual that can be found at dev.mysql.com. The original Reference Manual is in English, and this translation is not necessarily as up to date as the English version.