Utilizando Links Simbólicos para Tabelas

Antes do MariaDB 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 MariaDB 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 MariaDB 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. Leia "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 MariaDB.
• 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 MariaDB 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 MariaDB, 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.

Retornar