XOOPS Brasil

 

5.6. Detalhes de Disco

  • Como mencionado acima, pesquisas em disco são o maior gargalo de desempenho. Estes problemas ficam cada vez mais aparentes quando os dados começam a crescer tanto que efetivo armazenamento em cache se torna impossível. Para grandes bancos de dados, onde você acessa dados mais ou menos aleatoriamente, você pode ter certeza de que precisará de pelo menos uma busca em disco para ler e várias para gravar os dados. Para minimizar este problema, utilize discos com menor tempo de pesquisa.

  • Aumente o número de eixo de discos disponíveis (e então reduza a sobrecarga da pesquisa) ligando arquivos simbolicamente em diferentes discos ou utilizando striping de discos.

    • Usando links simbólicos

      Significa que, para tabelas MyISAM, você liga simbolicamente o índice e/ou arquivos de dados ao local comum no diretório de dados em outro disco (que pode também ser striped). Isto torna os tempos de pesquisa e leitura melhor (Se os discos não são usados para outras coisas). Veja mais informações sobre isto na Seção 5.6.1, “Utilizando Links Simbólicos”.

    • Striping

      Striping significa que você possui vários discos e coloca o primeiro bloco no primeiro disco, o segundo bloco no segundo disco, e o N-simo no (N módulo número_de_discos) disco, e assim por diante. Isto significa que se o seu tamanho de dados normais é menos que o tamanho do bloco (ou perfeitamente alinhado) você irá obter um desempenho muito melhor. Striping é muito dependente do SO e do tamanho do bloco. Portanto meça a performance de sua aplicação com diferentes tamanhos de blocos. Veja mais informações sobre isto na Seção 5.1.5, “Utilizando seus Próprios Benchmarks”.

      Perceba que a diferença de velocidade para striping é muito dependente dos parâmetros. Dependendo de como você configura os parâmetros do striping e do número de discos você pode obter uma diferença de várias ordens de grandeza. Note que você deve escolher a otimização randômica ou pelo acesso sequencial.

  • Para confiabilidade você pode desejar utilizar RAID 0+1 (striping + espelhamento) mas neste caso você irá precisar de 2*N discos para armazenar N discos de dados. Isto é provavelmente a melhor opção se você possuir dinheiro! Você pode também, entretanto, ter que investir em algum software gerenciador de volumes para lidar com isto eficientemente.

    Uma boa opção é variar os níveis de RAID de acordo com a importância do dado. a Por exemplo, ter dados com alguma importância que podem ser regenerados em um armazenamento RAID 0 enquanto os dados realemtente importantes como informações de máquinas e logs em um sistema RAID 0+1 ou RAID de N discos. RAID N pode ser um problema se você tem várias escritas devido ao tempo para atualizar os bits de paridade.

  • No Linux, você pode obter um desempenho muito melhor (cerca de 100% sobre carga pode ser comum) utilizando hdparm para configurar sua interface de disco! O exemplo a seguir deve ser muito útil para o MySQL (e provavelmente várias outras aplicações):

    hdparm -m 16 -d 1
    

    Perceba que o desempenho e confiança ao utilizar o exemplo acima depende de seu hardware, portanto nós sugerimos que você teste bem seu sistema depois de utilizar hdparm! Por favor consulte a página do manual (man) do hdparm para maiores informações! Se o hdparm não for usado corretamente, poderá resultar em corrupção do sistema de arquivos, assim realize backups de tudo antes de experimentar!

  • Você pode também configurar os parâmetros para o sistema de arquivos que o banco de dados usa:

    • Se você não precisa saber quando os arquivos foram acessados pela última vez (o que é realmente útil em um servidor de banco de dados), você pode montar o seu sistema de arquivos com a opção -o noatime. Isto faz com que ele evite a atualização do último tempo de acesso no inode e com isto também evita algumas buscas em disco.

    • Em vários sistemas operacionais os discos podem ser montados com a opção 'async' para configurar o sistema de arquivos a ser atualizado de modo assíncrono. Se o seu computador é razoavelmente estável, isto deve fornecer mais desempenho sem sacrificar a segurança. (Esta opção é ligada por padrão no Linux.)

5.6.1. Utilizando Links Simbólicos

Você pode mover tabelas e bancos de dados do diretório de banco de dados para outras localizações e trocá-los por links simbólicas para os novos locais. Você pode fazer isto, por exemplo, para mover um banco de dados para um sistema de arquivos com mais espaço livre ou aumentar a velocidade de seu sistema esipalhando suas tabelas para discos diferentes.

A maneira recomendada de se fazer isto é ligar simbolicamente bancos de dados a discos diferentes e só ligar tabelas como último recurso.

5.6.1.1. Utilizando Links Simbólicos para Bancos de Dados

No Unix, a maneira de ligar simbolicamente um banco de dados é, primeiramente, criar um diretório em algum disco onde você possui espaço livre e então criar uma ligação simbólica para ele a partir do diretório do banco de dados do MySQL.

shell> mkdir /dr1/databases/test
shell> ln -s /dr1/databases/test mysqld-datadir

O MySQL não suporta que você ligue um diretório a vários bancos de dados. Trocando um diretório de banco de dados com uma ligação simbólica irá funcionar bem desde que não sejam feitos links simbólicos entre os bancos de dados. Suponha que você tenha um banco de dados db1 sob o diretório de dados do MySQL, e então criar uma ligação simbólica db2 que aponte para db1.

shell> cd /caminho/para/diretorio/dados
shell> ln -s db1 db2

Agora, para qualquer tabela tbl_a em db1, também aparecerá uma tabela tbl_a em db2. Se uma thread atualizar db1.tbl_a e outra atualizar db2.tbl_a, ocorrerão porblemas.

Se você realmente precisar disto, você deve alterar o código seguinte em mysys/mf_format.c:

if (flag & 32 || (!lstat(to,&stat_buff) && S_ISLNK(stat_buff.st_mode)))

para

if (1)

No Windows você pode utilizar links simbólicos para diretórios compilando o MySQL com -DUSE_SYMDIR. Isto lhe permite colocar diferentes bancos de dados em discos diferentes. Veja mais informações sobre isto na Seção 5.6.1.3, “Usando Links Simbólicos para Bancos de Dados no Windows”.

5.6.1.2. Utilizando Links Simbólicos para Tabelas

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. Veja mais informações sobre isto na Seçã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.

5.6.1.3. Usando Links Simbólicos para Bancos de Dados no Windows

A partir do MySQL versão 3.23.16, o mysqld-max e servidores mysql-max-nt na distribuição MySQL são compilados com a opção -DUSE_SYMDIR. Isto permite que você coloque um diretório de banco de dados em discos diferentes adicionando um link simbólico para ele. (Isto é parecido com o a com que links simbólicos funcionam no Unix, embora o procedimento para configurar o link seja diferente).

No Windows, você cria um link simbólico para um banco de dados MySQL criando um arquivo que contem o caminho para o diretório de destino. Salve o arquivo no diretório de dados usando o nome de arquivo nome_bd.sym, onde nome_bd é o nome do banco de dados.

Por exemplo, se o diretório de dados do MySQL é C:\mysql\data e você precisa ter o banco de dados foo localizado em D:\data\foo, você deve criar o arquivo C:\mysql\data\foo.sym que contêm o caminho D:\data\foo\. Depois disto, todas tabelas criadas no banco de dados foo serão criadas no D:\data\foo. O diretório D:\data\foo deve existir para ele funcionar. Note também que o link simbólico não será usado se um diretório com o nome do banco de dados existe no diretório de dados MySQL. Isto significa que se você já tem um diretório de banco de dados chamado foo no direorio de dados, você deve movê-lo para D:\data antes do link simbólico ser efetivado. (Para evitar problemas, o servidor não deve estar executando quando você mover o diretório do banco de dados.)

Note que devido a penalidade que você tem na velocidade quando abre todas as tabelas, nós não habilitamos esta opção por padrão, mesmo se você compilar o MySQL com suporte a isto. Para habilitar links simbólicos você deve colocar no seu arquivo my.cnf ou my.ini a seguinte entrada:

[mysqld]
symbolic-links

No MySQL 4.0 --simbolic-links está habilitado por padrão. Se você não precisa usá-lo você pode usar a opção skip-symbolic-linkd.