Antes do MySQL 4.0 você não deve utilizar tabelas com
ligações simbólicas, se você não tiver muito cuidado com
as mesmas. O problema é que se você executar ALTER
TABLE
, REPAIR TABLE
ou
OPTIMIZE TABLE
em uma tabela ligada
simbolicamente, os links simbólicos serão removidas e
substituidos pelos arquivos originiais. Isto acontece porque o
comando acima funcinoa criando um arquivo temporário no
diretório de banco de dados e quando o comando é completo,
substitui o arquivo original pelo arquivo temporário.
Você não deve ligar simbolicamente tabelas em um sistema que
não possui uma chamada realpath()
completa. (Pelo menos Linux e Solaris suportam
realpath()
No MySQL 4.0 links simbólicos só são suportados
completamente por tabelas MyISAM
. Para
outros tipos de tabelas você provavelmente obterá problemas
estranhos ao fazer qualquer um dos comandos mencionados acima.
O tratamento de links simbólicos no MySQL 4.0 funciona da
seguinte maneira (isto é mais relevante somente para tabelas
MyISAM
.
No diretório de dados você sempre terá o arquivo de definições das tabelas e os arquivos de índice e o arquivo de dados. O arquivo de dados e o arquivo de índice podem ser movidos para qualquer lugar e substituidos no diretorio de dados pelos links simbólicos. O arquivo de definição não pode.
Você pode ligar simbolicamente o arquivo índice e o arquivo de dados para diretórios diferentes, independente do outro arquivo.
A ligação pode ser feita partir do sistema operacional
(se o mysqld
não estiver em
execução) ou usando as opções DATA
DIRECTORY
ou INDEX DIRECTORY
em CREATE TABLE
. See
Secção 6.5.3, “Sintaxe CREATE TABLE
”.
myisamchk
não irá substituir um link
simbólico pelo índice/arquivo. Ele funciona diretamente
nos arquivos apontados pelos links simbólicos. Qualquer
arquivo temporário será criado no mesmo diretório que o
arquivo de dados/índice está.
Quando você remove uma tabela que está usando links
simbólicos, o link e o arquivo para o qual ela aponta
são apagados. Esta é uma boa razão pela qual você
não
deve executar
mysqld
como root
e
não deve permitir que pessoas tenham acesso de escrita ao
diretórios de bancos de dados do MySQL.
Se você renomear uma tabela com ALTER TABLE
RENAME
e não deseja alterar o banco de dados, o
link simbólico para o diretório de banco de dados será
renomeada corretamente.
Se você utiliza ALTER TABLE RENAME
para mover uma tabela para outro banco de dados, então a
tabela será movida para outro diretório de banco de
dados e os links simbólicos antigos e os arquivos para os
quais eles apontam serão removidos.
Se você não utiliza links simbólicos, você deve usar a
opção --skip-symlink
do
mysqld
para garantir que ninguém pode
usar mysqld
para apagar ou renomear um
arquivo fora do diretório de dados.
O que ainda não é suportado:
ALTER TABLE
ignora todas as opções de
tabela DATA DIRECTORY
e INDEX
DIRECTORY
.
SHOW CREATE TABLE
não relata se a
tabela possui links simbólicos antes do MySQL 4.0.15.
Isto também é verdade para mysqldump
que usa SHOW CREATE TABLE
para gerar
instruções CREATE TABLE
.
BACKUP TABLE
e RESTORE
TABLE
não respeitam links simbólicos.
O arquivo frm
nunca deve ser um link
simbólico (como dito anteriormente, apenas os dados e
índices podem ser links simbólicos). Fazer isto (por
exemplo para fazer sinônimos), produzirá resultados
errados. Suponha que você tenha um banco de dados
db1
sob o diretório de dados do MySQL,
uma tabela tbl1
neste banco de dados e
você faça um link simbólico tbl2
no
diretório db1
que aponmta para
tbl1
:
shell>cd /path/to/datadir/db1
shell>ln -s tbl1.frm tbl2.frm
shell>ln -s tbl1.MYD tbl2.MYD
shell>ln -s tbl1.MYI tbl2.MYI
Agora se uma thread lê db1.tbl1
e
outra thread atualiza db1.tbl2
, haverá
problemas: a cache de consultas será enganada (ela
acreditará que tbl1
não foi
atualizado e retornará resultados desatualizados), o
comando ALTER
em
tbl2
também irá falhar.
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.