Aujourd'hui je vous propose un petit billet pour comprendre ce qu'il peut se cacher derrière l'erreur CAS "ERROR: A block of records on a failed node could not be activated among the remaining worker nodes."
Cela peut vous aider dans vos investigations si vous y êtes confronté dans le cadre de l'utilisation de tables dans CAS.
Voici une copie d'écran de cette erreur dans SAS StudioV :
Pour faire simple, ce message d'erreur indique que, lors d'une tentative de lecture d'une table CAS en mémoire, l'accès d'une partie des données en mémoire n'est pas possible.
Number of rows (720) oes not match file row total (1440)[/caption]
Le CAS Controller n'a pu lire en mémoire que 720 lignes sur les 1440 lignes de ma table. Confronté à cette erreur, CAS cherche donc les blocs manquant dans son cache disque (CAS_DISK_CACHE). Mais le message d'erreur "A block of records on a failed node could not be activated among the remaining worker nodes" indique qu'il ne parvient pas à accéder aux blocs pour reconstituer les données de la table absents de la mémoire.
Dans mon cas, une analyse de process CAS montre qu'un des CAS workers n'est pas disponible. le CAS Controller est bien actif, mais sur l'une des CAS workers, aucun process cas n'est actif ( process caslaunch et cas absent). Je n'ai donc qu'un seul CAS worker au lieu de 2.
Avec REPLICATION à 0, l'espace occupé dans le cas disque de
Avec REPLICATION à 1, CAS peut reconstruire sa mémoire à partir des données dans le cache disque.
En affichant les détails de la table en mémoire via le code ci-dessous, on voit que la table n'est maintenant chargé que dans la mémoire d'un seul CAS Worker :
Avant le "crash" d'un de mes deux CAS workers, les blocs actifs était bien répliqués sur les deux CAS worker :
Hors, avec REPLICATION=0, les infomations sur la table montrens l'absence de blocs répliqués :
Pour faire simple, ce message d'erreur indique que, lors d'une tentative de lecture d'une table CAS en mémoire, l'accès d'une partie des données en mémoire n'est pas possible.
Analyse des logs du CAS Controller
CAS ne parvient pas à lire la totalité de la table CAS en mémoire, comme l'indique la log du CAS Controller (en mode debug) : [caption id="attachment_2874" align="aligncenter" width="1119"] Number of rows (720) oes not match file row total (1440)[/caption]
Le CAS Controller n'a pu lire en mémoire que 720 lignes sur les 1440 lignes de ma table. Confronté à cette erreur, CAS cherche donc les blocs manquant dans son cache disque (CAS_DISK_CACHE). Mais le message d'erreur "A block of records on a failed node could not be activated among the remaining worker nodes" indique qu'il ne parvient pas à accéder aux blocs pour reconstituer les données de la table absents de la mémoire.
Dans mon cas, une analyse de process CAS montre qu'un des CAS workers n'est pas disponible. le CAS Controller est bien actif, mais sur l'une des CAS workers, aucun process cas n'est actif ( process caslaunch et cas absent). Je n'ai donc qu'un seul CAS worker au lieu de 2.
Mais pourquoi CAS n'a pas réussi à trouver les blocs manquants ?
L'explication est toute simple. Lors du chargement de ma table en mémoire, j'ai fait le choix de ne pas dupliquer les blocs entre les CAS workers :
Avec REPLICATION à 0, l'espace occupé dans le cas disque de
Avec REPLICATION à 1, CAS peut reconstruire sa mémoire à partir des données dans le cache disque.
En affichant les détails de la table en mémoire via le code ci-dessous, on voit que la table n'est maintenant chargé que dans la mémoire d'un seul CAS Worker :
Avant le "crash" d'un de mes deux CAS workers, les blocs actifs était bien répliqués sur les deux CAS worker :
Hors, avec REPLICATION=0, les infomations sur la table montrens l'absence de blocs répliqués :
