Introdução
Uma oficina comunitária mantém sua programação por sala, o endereço de contato para visitantes e uma nota de acesso em uma pasta compartilhada do HDFS. Antes de editar a programação, você precisa de um ponto de recuperação que ainda mostre os arquivos aprovados depois das alterações na pasta atual.
Primeiro, você lerá os dados normais, criará um snapshot nativo como proprietário comum e fará duas alterações controladas. Você já deve conhecer caminhos do HDFS, upload de arquivos, diretórios e permissões básicas de proprietário e grupo. Este laboratório apresenta snapshots e seus caminhos históricos. Use Terminal do início ao fim; todos os dados são independentes dos outros laboratórios. A estimativa do autor é de 40 minutos, incluindo leitura e recuperação de erros comuns.
Salvar os arquivos aprovados antes de editar
Nesta etapa, você lerá a programação em uso e criará um ponto de recuperação com nome. Comece em Terminal. cd altera o diretório de trabalho local deste shell; os caminhos iniciados por /user/labex/ nos comandos HDFS pertencem ao HDFS, não ao disco local.
cd /home/labex/project
Leia a programação atual:
hdfs dfs -cat /user/labex/snapshot-workshop/team/schedule.csv
Os campos separados por vírgulas indicam uma sala e sua atividade:
room,session
A,Printmaking
B,Bookbinding
A pasta da equipe também contém contacts.csv e notes.txt. Liste seu conteúdo:
hdfs dfs -ls /user/labex/snapshot-workshop/team
Esses arquivos compartilhados normais pertencem a labex, com o grupo bigdata. O usuário preparado analyst pertence a esse grupo e pode ler, mas não escrever. Você é o proprietário comum, não a identidade de serviço do NameNode, hdfs. O ambiente de ensino usa autenticação simples; ele não demonstra segurança Kerberos.
Um snapshot é uma visão histórica somente para leitura de um diretório em um momento com nome. Um administrador habilitou snapshots apenas nesta pasta do curso. Você mesmo cria o ponto de recuperação real. -createSnapshot recebe o diretório atual, seguido do nome do snapshot:
hdfs dfs -createSnapshot /user/labex/snapshot-workshop/team morning-approved
A resposta informa um caminho nativo terminado em .snapshot/morning-approved. O componente especial .snapshot seleciona o histórico; ele não é um diretório de backup comum criado com -mkdir. Leia a programação histórica:
hdfs dfs -cat /user/labex/snapshot-workshop/team/.snapshot/morning-approved/schedule.csv
Ela contém as mesmas duas atividades aprovadas. Liste os três arquivos históricos:
hdfs dfs -ls /user/labex/snapshot-workshop/team/.snapshot/morning-approved
O snapshot também inclui o contato e a nota de acesso originais. Se um comando informar No such file or directory, compare a grafia do caminho com esta listagem e repita apenas a leitura que falhou. Se -createSnapshot informar que o nome já existe, examine esse snapshot em vez de excluí-lo ou recriá-lo. Não execute a preparação do ambiente novamente: ela se recusa a sobrescrever o trabalho existente.
Agora você tem um ponto de recuperação real anterior à edição. Uma cópia baixada localmente ou uma pasta comum com o mesmo nome não criaria esse histórico nativo.
Comparar o histórico com o trabalho posterior
Nesta etapa, você adicionará trabalho novo válido, provocará um erro limitado e observará que o snapshot permanece inalterado. Continue no mesmo Terminal.
O arquivo da atividade posterior da oficina está disponível localmente. Leia-o primeiro:
cat /home/labex/project/incoming/late-session.csv
Ele contém a sala C e Paper Folding. Envie-o para a pasta atual da equipe. Ele faz parte da programação atual e deve ser preservado em qualquer recuperação posterior:
hdfs dfs -put /home/labex/project/incoming/late-session.csv /user/labex/snapshot-workshop/team/late-session.csv
Mantenha o grupo de compartilhamento correto com -chgrp. O modo de arquivo 640 permite leitura e escrita ao proprietário, leitura ao grupo e nenhum acesso ao arquivo para os demais usuários:
hdfs dfs -chgrp bigdata /user/labex/snapshot-workshop/team/late-session.csv
hdfs dfs -chmod 640 /user/labex/snapshot-workshop/team/late-session.csv
Agora examine uma substituição propositalmente incorreta:
cat /home/labex/project/incoming/schedule-draft.csv
Ela contém A,CANCELLED. O próximo upload sobrescreve deliberadamente apenas o arquivo atual de programação indicado. A opção -f permite substituir esse destino; aqui, você a usa apenas por se tratar de uma edição controlada. Ela não afeta o snapshot.
hdfs dfs -put -f /home/labex/project/incoming/schedule-draft.csv /user/labex/snapshot-workshop/team/schedule.csv
O segundo erro controlado remove apenas o arquivo atual de contato. Primeiro confirme o caminho exato:
hdfs dfs -ls /user/labex/snapshot-workshop/team/contacts.csv
hdfs dfs -rm /user/labex/snapshot-workshop/team/contacts.csv
Não use curinga, remoção recursiva nem a raiz da equipe. Leia a programação alterada e depois sua versão histórica:
hdfs dfs -cat /user/labex/snapshot-workshop/team/schedule.csv
hdfs dfs -cat /user/labex/snapshot-workshop/team/.snapshot/morning-approved/schedule.csv
O resultado atual mostra o cancelamento; o histórico ainda contém Printmaking e Bookbinding. Leia o contato histórico com a identidade real de leitura compartilhada. sudo -u analyst executa apenas esse cliente com essa identidade comum de teste; o caminho absoluto do cliente seleciona a ferramenta HDFS preparada:
sudo -u analyst /usr/local/bin/hdfs dfs -cat /user/labex/snapshot-workshop/team/.snapshot/morning-approved/contacts.csv
O endereço continua sendo visitors@example.test, embora o arquivo atual de contato esteja ausente. Confira a listagem atual:
hdfs dfs -ls /user/labex/snapshot-workshop/team
Ela contém a programação alterada, a nota inalterada e a nova atividade. Se o upload anterior do novo arquivo informou que o destino já existe, leia o arquivo existente em vez de excluí-lo ou ampliar o upload. Se uma remoção repetida informar que o contato está ausente, a exclusão controlada já ocorreu; examine a listagem e continue.
Deixe esse estado final como está. O próximo laboratório fornece seu próprio cenário danificado e independente, e ensina a recuperação. Os snapshots compartilham o armazenamento do HDFS: seus blocos não são cópias de backup independentes e, portanto, não protegem contra a perda de todo o sistema de armazenamento.
Resumo
Você criou um snapshot nativo do HDFS antes da edição e distinguiu seus arquivos históricos protegidos da pasta atual alterada. A atividade adicionada depois existe apenas na programação atual; substituir a pasta inteira pelo histórico descartaria trabalho válido. Você também leu o histórico com a identidade real de leitura compartilhada analyst.
