Resync de Geo-replicação de GlusterFS

Question

Estamos usando dois servidores separados por uma WAN para replicar aproximadamente 1 TB de dados.

No lado mestre, temos um único servidor com um volume do Gluster exportado para vários outros servidores que gravam dados.

No lado do escravo, temos um único servidor com um volume do Gluster exportado como um compartilhamento somente leitura para servidores de recuperação de desastre.

Com o passar do tempo, o escravo ficou fora de sincronia com o mestre, ao som de 200gb, arquivos que deveriam estar lá e arquivos que foram apagados. Não parece haver muita consistência nisso.

Qual é a maneira mais simples de forçar o cluster a verificar todos os arquivos no escravo e replicá-lo novamente onde necessário?

A documentação sugere:

Description: GlusterFS Geo-replication did not synchronize the data completely but still the geo-replication status display OK.

Solution: You can enforce a full sync of the data by erasing the index and restarting GlusterFS Geo-replication. After restarting, GlusterFS Geo-replication begins synchronizing all the data, that is, all files will be compared with by means of being checksummed, which can be a lengthy /resource high utilization operation, mainly on large data sets (however, actual data loss will not occur). If the error situation persists, contact Gluster Support.

Mas não se refere a onde esse índice pode estar.

#   gluster volume geo-replication share gluk1::share stop
Stopping geo-replication session between share & gluk1::share has been successful
# gluster volume set share geo-replication.indexing off
volume set: failed: geo-replication.indexing cannot be disabled while geo-replication sessions exist

Este desligamento do índice falha enquanto a conexão ainda existe e a documentação não menciona esse requisito.

Alguma sugestão?

    

Answer 1

Seus escravos ficaram fora de sincronia porque a Geo-replicação do GlusterFS é não destinada a vários conjuntos de dados em mudança (FS distribuídos), em vez de recuperação de desastres (backup somente leitura).

Em resumo, a replicação geográfica é um modelo mestre / escravo, onde apenas o site principal envia gravações / alterações, e quaisquer alterações são periodicamente sincronizadas com o somente leitura escravo.

Para ter um verdadeiro sistema de arquivos replicado e distribuído, você precisaria usar o recurso "Replicated Volume" do GlusterFS. A desvantagem é que, com o esquema de replicação atual, as gravações são forçadas a serem síncronas: isso significa que, se você estiver replicando entre um link WAN, até mesmo as gravações locais intra-LAN serão tão lentas quanto o caminho da WAN. Para superar esse limite, uma " New Style Replication " é considerada para inclusão, mas parece para não ser implementado ainda (pelo menos na distribuição corporativa estável).

Voltando à sua situação atual, você está em um "cenário de cérebro dividido" clássico e não tenho certeza do que pode fazer: seu mestre e seus escravos têm visões diferentes dos volumes subjacentes e provavelmente acumularam mudanças diferentes e incompatíveis para os mesmos arquivos. Eu acho que você teve que (mais ou menos) revisá-los manualmente ...