Tokyo Tyrant ulog / gerenciamento de log de atualização

2

Estou testando o Tokyo Tyrant em uma configuração master-master e descobri que o ulog está fora de controle e trava o disco.

No começo eu achei a opção -ulim útil e limitei o tamanho do arquivo de log, no entanto ele simplesmente passa para um novo log, deixando os antigos para bagunçar a partição.

Suponho que escreverei um script de shell que excluirá ulogs anteriores a X, assim que eu descobrir o quão longe o Tokyo Tyrant precisa no log de atualização para fazer o failover.

Alguém tem alguma experiência com este Tokyo Tyrant? Você sente (reconhecendo que cada instalação é diferente com base no que está sendo armazenado) para o tamanho ideal do ulog versus quanto uma instância do Tokyo Tyrant precisa procurar no ulog para assumir o status de mestre?

Obrigado nathan

    
por Nathan Milford 16.06.2009 / 20:37

3 respostas

1

Apenas para acompanhar, abaixo está a resposta de Mikio Hirabayashi (desenvolvedor do TT) a um e-mail com a mesma redação:

If you can confirm only one slave, which is another part of dual master, accesses the master server, please query the delay time to the slave by the command "tcrmgr inform -st ..." and you can determine which file can be removed.

A execução desse comando permitirá que você veja a distância de um escravo atrás de um mestre. Uma vez que você saiba que pode gastar algum tempo para encontrar o tamanho correto de volume de negócios e ter muitos arquivos do tipo ulog de volta, você pode jogar lixo e se sentir seguro. Provavelmente, é melhor fazê-lo sob uma carga que simula um dia pesado em seus bancos de dados chave / valor do Tokyo Tyrant, etc.

Eu descaradamente escrevi um script do stackoverflow:

> #!/bin/bash
> 
> # Deletes all but the newest 5 files to keep Tokyo Tyrant ulogs from
> killing the disk.
> logdir='/path/to/ttserver/ulog/' 
> mydir='ls -t $logdir' it=1
> 
> for file in $mydir
>     do
>         if [ $it -gt 5 ]
>         then
>             echo file $it will be deleted: $logdir$file
>             #rm -rf $file
>         fi
>         it=$((it+1))
>     done

A resposta do @kubanskamac estava correta em resumo, mas o Mikio dá o comando para iniciar a otimização.

    
por 25.06.2009 / 04:37
1

FYI, escrevi um script de gerenciamento do ulog que leva em conta o atraso da replicação:

link

    
por 28.04.2010 / 18:07
0

Aviso: esta é a primeira vez que ouço falar do Tokyo Tyrant. Acabei de ver alguns padrões familiares olhando para os documentos.

Nos sistemas transacionais (por exemplo, bancos de dados) eu sei, atenção é dada a dois tipos de eventos inesperados:

  • falha de energia - quando você perde por algum motivo o conteúdo do cache de RAM, mas após a reinicialização ainda é possível acessar arquivos de disco
  • falha de disco - você não consegue mais acessar dados de seus arquivos de disco; os arquivos são perdidos ou contêm apenas lixo; você precisa restaurar a partir do backup

Cada registro passa geralmente por três estágios de existência:

  1. Log ativo que foi apenas criado com transações muito novas; os dados que ele contém ainda não foram salvos em arquivos de dados; você absolutamente precisa disso para restaurar a consistência dos arquivos de dados em caso de falha de energia
  2. Depois que os dados são confirmados (gravados em arquivos de banco de dados), o log agora é chamado log confirmado ; os dados estão no disco em dois formatos / locais diferentes - neste log e no arquivo de banco de dados; você não precisa deste log em caso de falha de energia, mas você precisa em caso de falha de disco - depois de restaurar o arquivo de banco de dados (da semana anterior?), você pode reaplicar todas as transações de logs ativos + confirmados consecutivos na mesma ordem cronológica seqüência para chegar a nova cópia de dados; se você perdeu os logs mais recentes, perdeu as transações recentes, mas pelo menos ainda tem um banco de dados bastante novo e completamente consistente
  3. Após o backup do arquivo de banco de dados (consistentemente copiado para local seguro), seu log torna-se log de archive . Você não precisa dele para se proteger contra qualquer falha.

Eu não tenho idéia de como descobrir quais de seus ulogs são cometidos pelo Tokyo Tyrant. Mas talvez este esboço geral ajude.

    
por 16.06.2009 / 22:16

Tags