Parece que ibdata1 é como uma fatia de disco. Nos sistemas de arquivos UFS do Solaris (UNIX) (o comum antes do ZFS), seria necessário separar o disco c0t0d0 em fatias, digamos que uma unidade de 10 GB seria cortada em três seções, 4 GB, 1 GB e 5 GB. Esses seriam sistemas de arquivos de tamanho fixo. Os 4 GB para, digamos, SO. 1 GB para troca e 5 GB para software e dados.
swap pode ser armazenado em um arquivo em um sistema de arquivos, mas para desempenho ele geralmente é armazenado em sua própria seção do disco.
O ibdata1 pode ser vinculado à sua própria fatia para aumentar o desempenho? É claro que seria preciso pensar cuidadosamente antes de decidir qual tamanho fixo é ideal e também saber como verificar os níveis de uso.
Um link simbólico pode ser colocado de .../mysql/data/ibdata1para /dev/rdsk/c0t0d0s3. O MySQL então o veria como um arquivo, mas poderia ter um desempenho melhor porque não precisa passar pela camada do sistema de arquivos, ele gravaria diretamente em uma seção designada do disco.
- alguem ja tentou isso?
- Alguém acha que isso é uma má ideia? (Lembre-se de que essa ideia é apenas para servidores de banco de dados somente InnoDB. Não para servidores multiuso.)
- Funcionaria (o innodb precisa verificar o tamanho do arquivo? Caso contrário, deve funcionar.)
- O uso pode ser verificado?
Em primeiro lugar, quais são os tipos de entrada que residem em ibdata1? Quatro (4) tipos de entrada:
Sempre que uma tabela InnoDB experimenta DDL, DML ou sendo usada em uma transação, todos esses quatro tipos de entradas são lidos ou gravados. Enquanto isso, se innodb_file_per_table estiver desativado, todos esses tipos de entrada residirão em ibdata1. Se estiver ativado, apenas Table MetaData e MVCC Data residiriam em ibdata1, enquanto as Table Data Pages e Index Data Pages residiriam na subpasta do banco de dados como um arquivo .ibd.
Isso sendo considerado, o que aconteceria se ibdata1 fosse colocado em outro volume e vinculado a um link simbólico?
Para começar, como o MySQL representa uma tabela independentemente do mecanismo de armazenamento? Como um arquivo .frm. Onde vivem os arquivos .frm? No diretório de dados. O que há de errado com isso?
Aqui está um exemplo:
Usando o datadir padrão de /var/lib/mysql, vamos usar uma tabela InnoDB chamada mydb.mytable.
Com innodb_file_per_table desabilitado, tudo ficaria em ibdata1 (que você está propondo fazer um link simbólico e enviar para outro volume de dados). Para a tabela mydb.mytable, isto é o que você teria:
Imagine isso agora: você acessa a tabela, o MySQL primeiro acessa /var/lib/mysql/mydb/mytable.frm e depois acessa as páginas de dados e índice em ibdata1 para mydb.mytable. Isso estaria acontecendo constantemente com cada acesso de mydb.mytable. Esse vaivém em cascata tornaria as coisas um pouco mais lentas e você pode não obter o desempenho esperado movendo ibdata1 para algum outro volume de dados. Na verdade, o efeito cascata agora seria um fator do número de tabelas InnoDB multiplicado por dois (2).
Imagine ter innodb_file_per_table ativado. Agora você teria uma configuração ligeiramente diferente:
Essa cascata seria um pouco pior porque a cascata para acesso à tabela agora ocorreria entre três arquivos em vez de dois.
Aqui está mais um cenário que alguns pensaram: Em vez de mover o ibdata1 para um volume diferente, que tal habilitar innodb_file_per_table e mover os arquivos .ibd para um ou mais volumes de dados diferentes? O efeito cascata agora seria um fator do número de tabelas InnoDB multiplicado por três (3). Percona expressou razões muito boas para não fazer isso, que você achará úteis .