2.6. Notas específicas para os Sistemas Operacionais

2.6.1. Notas Windows

Esta seção descreve assuntos específicos para usar MySQL no Windows.

2.6.1.1. Conectando em um MySQL Rematamente a Windows Utilizando SSH

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 utilizador, 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 utilizador 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.

2.6.1.2. Compilando clientes MySQL no Windows

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!

2.6.1.3. MySQL para Windows Comparado com o MySQL para Unix

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.

2.6.2. Notas Linux (Todas as versões)

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 utilizador 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 utilizador 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 utilizadores, 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 utilizadores 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:

Ligue o cliente com a seguinte opção (no lugar de -Lpath): -Wl,r/path-libmysqlclient.so.
Copie libmysqclient.so para /usr/lib.
Adicione o caminho do diretório onde libmysqlclient.so está localizado para a variável de ambiente LD_RUN_PATH antes de executar seu cliente.

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

2.6.2.1. Notas Linux para distribuições binárias

O MySQL necessita pelo menos do Linux versão 2.0

Aviso: Percebemos que alguns utilizadores 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 utilizador (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.

2.6.2.2. Notas Linux x86

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

2.6.2.3. Notas Linux SPARC

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.

2.6.2.4. Notas Linux Alpha

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.

2.6.2.5. Notas Linux PowerPC

O MySQL deve funcionar no MkLinux com o mais novo pacote glibc (testado com glibc 2.0.7).

2.6.2.6. Notas Linux MIPS

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).

2.6.2.7. Notas Linux IA-64

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”.

2.6.3. Notas Solaris

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:

Ligue o cliente com a seguinte opção (em vez de -Lpath): -Wl,r/full-path-to-libmysqlclient.so.
Copie o arquivo libmysqclient.so para /usr/lib.
Adicione o caminho do diretório onde libmysqlclient.so está localizado à variável de ambiente LD_RUN_PATH antes de executar seu cliente.

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.

2.6.3.1. Notas Solaris 2.7/2.8

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.

2.6.3.2. Notas Solaris x86

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”.

2.6.4. Notas BSD

Esta seção fornece informação para os vários tipos de BSD, assim como a versão específica para eles.

2.6.4.1. Notas FreeBSD

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 utilizador 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 utilizador 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.

2.6.4.2. Notas NetBSD

Para compilar no NetBSD você precisa do GNU make. De outra forma o compilador quebraria quando o make tentasse executar lint em arquivos C++.

2.6.4.3. Notas OpenBSD

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

2.6.4.4. Notas OpenBSD 2.8

Nossos utilizadores 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 &

2.6.4.5. Notas BSDI Versão 2.x

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 utilizadores 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.

2.6.4.6. Notas BSD/OS Versão 3.x

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 utilizadores BSDI relataram problemas com bash e ulimit.

2.6.4.7. Notas BSD/OS Versão 4.x

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).

2.6.5. Notas Mac OS X

2.6.5.1. Mac OS X 10.x

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

See Secção 2.1.3, “Instalando o MySQL no Mac OS X”.

2.6.5.2. Mac OS X Server 1.2 (Rhapsody)

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.

See Secção 2.1.3, “Instalando o MySQL no Mac OS X”.

2.6.6. Notas de Outros Unix

2.6.6.1. Notas HP-UX para distribuições binárias

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 utilizador deve ser o root.

Para instalar a distribuição HP-UX tar.gz, você deve ter uma cópia do GNU tar.

2.6.6.2. Notas HP-UX Versão 10.20

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

2.6.6.3. Notas HP-UX Versão 11.x

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 utilizador 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 utilizadores 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.

2.6.6.4. Notas IBM-AIX

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.

2.6.6.5. Notas SunOS 4

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.

2.6.6.6. Notas Alpha-DEC-UNIX (Tru64)

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

2.6.6.7. Notas Alpha-DEC-OSF1

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.

2.6.6.8. Notas SGI Irix

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 utilizador 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

2.6.6.9. Notas SCO

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:
1. Execute ./configure no diretório threads/src e selecione a opção SCO OpenServer. Este comando copia Makefile.SCO5 para Makefile.
2. Execute make.
3. Para instalar no diretório padrão /usr/include, use o utilizador 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.

2.6.6.10. Notas SCO Unixware Version 7.0

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

2.6.7. Notas OS/2

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";

2.6.8. Notas Novell NetWare

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.

2.6.9. Notas BeOS

Nós já falamos com alguns desenvolvedores BeOS que disseram que o MySQL está 80% portado para o BeOS, mas nós não sabemos qual a situação no momento.