ERREUR: connexion Segment a échoué: allocateWriterGang a tenté de retourner une mauvaise bande. (Cdbgang.c: 2591)

Question

En utilisant la version de base de données Greenplum 3.2.3 sur Solaris.

Étape 1. Créez une table.

CREATE TABLE ivdb.OPTION_PRICE (
    SecurityID integer NOT NULL,
    Date timestamp NOT NULL,
    Root char(5) NOT NULL,
    Suffix char(2) NOT NULL,
    Strike integer NOT NULL,
    Expiration timestamp NOT NULL,
    CallPut char(1),
    BestBid real NOT NULL,
    BestOffer real NOT NULL,
    LastTradeDate timestamp NULL,
    Volume integer NOT NULL,
    OpenInterest integer NOT NULL,
    SpecialSettlement char(1) DEFAULT '0',
    ImpliedVolatility real NOT NULL,
    Delta real NOT NULL,
    Gamma real NOT NULL,
    Vega real NOT NULL,
    Theta real NOT NULL,
    OptionID integer NOT NULL,
    Adjustmentfactor integer DEFAULT 1 NOT NULL,

    CONSTRAINT PK_OPTION_PRICE PRIMARY KEY (Date, Root, Suffix))

    PARTITION BY RANGE (Date) (
        START (timestamp '01/01/1996') INCLUSIVE
        END (timestamp '01/01/2020') EXCLUSIVE
        EVERY (INTERVAL '1 month')); 

Étape 2: Insérez les données d'une autre table. (Celui-ci est la vanille simple, non cloisonné, pas de contraintes. Il a 564,392,723 lignes.)

INSERT INTO OPTION_PRICE SELECT * FROM casey_option_price;

Résultats:

-- Executing query:

INSERT INTO OPTION_PRICE SELECT * FROM casey_option_price;
NOTICE: Releasing gangs to finish aborting the transaction.


ERROR: Segment connection failed: allocateWriterGang attempted to return a bad gang. (cdbgang.c:2591)

********** Error **********

ERROR: Segment connection failed: allocateWriterGang attempted to return a bad gang. (cdbgang.c:2591)
SQL state: XX000

Les mauvaises choses de gangs apporte tout le spectacle à un arrêt, besoin de base de données redémarrer pour faire avancer les choses nettoyé à nouveau.

Je n'ai pas trouvé beaucoup sur le web, ont un billet d'assistance ouvert avec Greenplum, je pensais le faire flotter ici aussi. Est-ce que revenir avec une solution si je reçois un avant de vous faire.

Désolé, pas assez représentant pour marquer avec "Greenplum".

Answer 1

Cette erreur est due à un problème matériel. Un disque dur a échoué et pour quelque raison que le RAID ne nous a pas couvrir correctement.

« mauvaise bande » signifie « vérifier votre matériel » maintenant pour moi.

A lié (ou peut-être le vrai) problème: Vérifiez votre réglage gp_vmem_protect_limit. La nôtre était trop élevé, et j'utiliser tous l'espace d'échange de la machine dans ma requête.

Answer 2

La « bande a été déconnecté » est un symptôme qui indique un ou plusieurs des processus de travail de segments primaires avorter anormalement. Les causes possibles varient. EG, max_connections sont atteintes sur un segment; segments principaux vers le bas en raison de délai d'attente; Les processus Postgresql sont tués; le segment serveur question NIC; Le système de fichiers est plein sur les segments; etc.

Je vous suggère de cas ouverts au GP équipe de soutien avec ci-dessous info:

1. journaux maître
2. logs de segments liés
3. Sortie gp_segment_configuration
4. select * de l'ordre gp_configuration_history par 1 desc;
5. / var / log / messages sur les serveurs de segments connexes
6. df -h sur les segments
7. Tout changement que vous pouvez penser associés.