Solução de problemas

Aviso de que a versão “dev” não é reconhecida

O aviso “WARN: Não foi possível analisar a versão “dev” relatada pelo servidor, supondo que as mais recentes backup/restore APIs sejam suportadas” pode ser exibido durante a migração. Esse aviso pode ser ignorado.

A migração falhou durante a fase de restauração

No caso de uma falha na migração durante o estágio de restauração, os usuários podem usar o --retry-restore-dir sinalizador para tentar novamente a restauração. Use o --retry-restore-dir sinalizador com um caminho para um diretório previamente salvo para pular o estágio de backup e tentar novamente o estágio de restauração. O diretório de backup criado usado para uma migração será indicado se a migração falhar durante a restauração.

Os possíveis motivos para uma falha na restauração incluem:

• Token de destino inválido do InfluxDB — Um bucket existente na instância de destino com o mesmo nome da instância de origem. Para migrações de bucket individuais, use a --dest-bucket opção de definir um nome exclusivo para o bucket migrado.

• Falha de conectividade, seja com os hosts de origem ou de destino ou com um bucket S3 opcional.

Diretrizes operacionais básicas do Amazon Timestream para InfluxDB

A seguir estão as diretrizes operacionais básicas que todos devem seguir ao trabalhar com o Amazon Timestream para o InfluxDB. Observe que o Acordo de Nível de Serviço do Amazon Timestream para InfluxDB exige que você siga estas diretrizes:

• Use métricas para monitorar seu uso de memória, CPU e armazenamento. Você pode configurar CloudWatch a Amazon para notificá-lo quando os padrões de uso mudarem ou quando você se aproximar da capacidade de sua implantação. Dessa maneira, é possível manter a disponibilidade e a performance do sistema.

• Escale sua instância de banco de dados quando estiver se aproximando dos limites de capacidade de armazenamento. É preciso ter algum buffer de armazenamento e memória para acomodar aumentos imprevistos na demanda de seus aplicativos. Lembre-se de que, neste momento, você precisará criar uma nova instância e migrar seus dados para conseguir isso.

• Se a carga de trabalho do seu banco de dados exigir I/O mais do que você provisionou, a recuperação após um failover ou falha no banco de dados será lenta. Para aumentar a I/O capacidade de uma instância de banco de dados, faça um ou todos os seguintes:

  • Migre para uma instância de banco de dados diferente com maior I/O capacidade.

  • Se você já estiver usando o armazenamento de armazenamento incluído do Influx IOPS, provisione um tipo de armazenamento com maior IOPS incluído.

• Se seu aplicativo cliente estiver armazenando em cache os dados do Domain Name Service (DNS) de suas instâncias de banco de dados, defina um valor time-to-live (TTL) de menos de 30 segundos. O endereço IP subjacente de uma instância de banco de dados pode ser alterado após um failover. Dessa forma, armazenar os dados do DNS em cache por um longo período pode ocasionar falhas de conexão. Sua aplicação pode tentar se conectar a um endereço IP que não está mais em serviço.

Recomendações de RAM para a instância de banco de dados

Uma prática recomendada de desempenho do Amazon Timestream para InfluxDB é alocar RAM suficiente para que seu conjunto de trabalho resida quase completamente na memória. O conjunto de trabalho é composto de dados e índices que são usados frequentemente em sua instância. Quanto mais você usar a instância de banco de dados, mais o conjunto de trabalho crescerá.