Tenho os dados em storage com uma base de aproximadamente 500 Gb e sem problemas. Acredito ser fibra ou mesmo formatação dos discos do storage.
Em 19 de novembro de 2012 23:18, Bruno Silva <[email protected]>escreveu: > Tivemos problemas parecidos e era a fibra. > > Enviado pelo meu Nexus > Em 19/11/2012 20:14, "Tiago Adami" <[email protected]> escreveu: > > Em 19 de novembro de 2012 17:40, Fábio Gibon >> <[email protected]> escreveu: >> >>> Pessoal, >> >>> um cliente comprou uma storage e está fazendo testes com o >> >>> PGDATA nesta, porém está recebendo muitos erros de leitura. >> >> >> >> >> >> O problema não é o PostgreSQL, será que não tem disco com problema? >> > >> > Os discos/storage é zerado, isto não é garantia eu sei, mas nem pensei >> > nesta hipótese ainda. >> >> Eu não manjo muito de storage e a parte física. Mas já vi problema >> parecido quando houve problemas no cabo que liga a controladora do >> servidor à unidade de storage. >> >> >> Que tipo de erros ele esta recebendo? Que tipo de configuração está o >> >> Storage? Fez RAID? Via HW ou SW? >> > >> > Não tive acesso ainda, mas me disseram que é RAID 5 e veio assim do >> > fabricante (não sabem nada mais do que isto). >> >> Se cabeamento for descartado, não há como verificar os logs da >> controladora? Como você identificaria um disco com problema? Pode ser >> isso, apesar de que a controladora deveria descartar o disco sem >> interromper o serviço em caso de falha (depende também do número de >> discos, se for um RAID 5 com 3 discos as operações de R/W /deverão/ >> ser interrompidas. >> >> > Os erros são: BRT ERRO: não pôde ler bloco 134230 no arquivo >> > "base/123495397/123497034.1": leu somente 0 de 8192 bytes >> >> Já que é para testes, vou passar um teste fácil para identificar erros >> de disco que um técnico fez em minha presença: >> >> 1) Apague todos os arquivos dos discos - formate se possível; >> 2) Crie um arquivo com zeros de no máximo 49% do tamanho da unidade >> lógica (partição) - acredito que isso foi feito usando o "dd" para >> Linux/Unix; >> 3) Copie o arquivo na mesma unidade lógica (partição); >> >> Parece um teste ridículo, mas quando a escrita do arquivo estava quase >> atingindo 10% (conferido por um outro terminal via SSH e rodando o >> comando "timer -t 2 df -h" - acho que foi isso) a escrita foi abortada >> com um erro na controladora. >> >> No meu caso foi necessário apenas fazer o downgrade da versão do SO >> que tinha incompatibilidades com a versão do virtualizador Xen Server >> rodando e o problema foi resolvido. >> >> Bem, agora vi que seu SO é Windows. Tente copiar um arquivo grande o >> suficiente para fazer os pedaços se espalharem multiplamente entre os >> discos, e depois copie-o para a mesma partição e veja o resultado para >> simular operação de R/W. Se nenhum erro acontecer, acredito que você >> já poderá descartar erros de disco/controladora/drivers. >> >> -- >> TIAGO J. ADAMI >> http://www.adamiworks.com >> @tiadami >> _______________________________________________ >> pgbr-geral mailing list >> [email protected] >> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral >> > > _______________________________________________ > pgbr-geral mailing list > [email protected] > https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral > >
_______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
