Question

Nous nous sommes toujours demandé pourquoi l'un de nos clusters indique qu'un nœud Analytics possède des données.J'ai modifié les ips, les jetons et les identifiants d'hôte pour plus de lisibilité

% nodetool status

Datacenter: Cassandra
=====================
Status=Up/Down|/ State=Normal/Leaving/Joining/Moving
--  Address     Load       Owns   Host ID      Token         Rack
UN  172.32.x.x  46.83 GB   18.5%  someguid     0             rack1
UN  172.32.x.x  60.26 GB   33.3%  anotherguid  ranbignumber  rack1
UN  172.32.x.x  63.51 GB   14.8%  anothergui   ranbignumber  rack1
Datacenter: Analytics
=====================
Status=Up/Down|/ State=Normal/Leaving/Joining/Moving
--  Address     Load       Owns   Host ID   Token          Rack
UN  172.32.x.x  28.91 GB   0.0%   someguid  100            rack1
UN  172.32.x.a  30.41 GB   33.3%  someguid  ranbignumber   rack1
UN  172.32.x.x  17.46 GB   0.0%   someguid  ranbignumber   rack1

Alors, le nœud Analytics avec l'adresse IP 172.32.x.a possède-t-il réellement des données ?Si oui, devons-nous le sauvegarder ?La mise hors service du nœud déplacerait-elle également les données vers les nœuds appropriés ?

Il s'agit du nœud auquel je fais référence à partir du statut nodetool ci-dessus qui se trouve dans Datacenter Analytics :

UN  172.32.x.a  30.41 GB   33.3%  someguid  ranbignumber   rack1

Encore les questions (mis à jour avec les réponses fournies ci-dessous).

  1. Devons-nous sauvegarder ce nœud ? Répondre:OUI
  2. Ce nœud devrait-il avoir des données ?Répondre: OUI, sinon les performances analytiques seront affectées.
  3. S'il ne doit pas contenir de données, la mise hors service de nodetool déplacera-t-elle les données vers les autres nœuds ? Répondre:AUCUNE stratégie de réplication ne conduit à cela

Voici la mise à jour pour

% nodetool status our_important_keyspace

Datacenter: Cassandra
=====================
Status Address     Load       Owns (effective)  
UN     2           63.16 GB   81.5%             
UN     1           47.21 GB   33.3%             
UN     3           59.87 GB   85.2%
Datacenter: Analytics
=====================
Status Address     Load       Owns (effective)
UN     3           17.74 GB   33.3%  
UN     2           30.62 GB   33.3%
UN     1           29.21 GB   33.3%

Sauvegarder Analytics aujourd'hui - réponse géniale, et nous a probablement évité une tonne de douleur.

Était-ce utile?

La solution

La première chose que vous devez faire est d'exécuter nodetool status ou dsetool ring en utilisant l'espace de clés dans lequel vos données sont stockées.Cela vous montrera la propriété dictée par la stratégie de réplication de cet espace de clés.Ce que vous regardez maintenant est très probablement la propriété telle que définie par les valeurs brutes des jetons.Si votre espace de clés était nommé "important_data", vous exécuteriez "nodetool status important_data".

Cette stratégie de réplication sur votre espace de clés est essentielle pour déterminer quels nœuds sont responsables des données de votre cluster.Dans tous les cas, un cluster multi-DC doit utiliser une NetworkTopologyStrategy qui permet de spécifier le nombre de répliques de vos données qui doivent résider dans chaque centre de données.Par exemple, si vous souhaitez vous assurer que les données sont répliquées deux fois dans le cluster Cassandra mais une seule fois dans le cluster Analytics, vous utiliserez une stratégie de topologie de réseau telle que {'Cassandra':2, 'Analytics':1 }.Cela signifierait que chaque élément de données est répliqué 3 fois à l'échelle du cluster.Si vous souhaitez vraiment que les données ne soient pas copiées vers les nœuds d'analyse (cela nuirait aux performances d'analyse), vous pouvez définir « Analytics :0 » ou omettre complètement cette phrase.

Votre stratégie de sauvegarde doit toujours sauvegarder au moins une réplique complète des données, mais il est probablement plus simple de simplement sauvegarder chaque nœud ou au moins chaque nœud d'un centre de données (car vous pouvez amorcer les autres à partir de celui-ci).

Le nœud ne disposera de données que si vous le souhaitez via la stratégie de réplication et dans ce cas, vous devrez le mettre hors service lors de la suppression du nœud, comme vous le feriez avec n'importe quel nœud du cluster.La plupart des utilisateurs trouvent utile d'avoir des répliques dans leurs centres de données d'analyse, car cela permet un accès plus rapide lors de l'utilisation de divers outils d'analyse.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top