Il s'agit de la commande queue_splitter3 qui peut être exécutée dans le fournisseur d'hébergement gratuit OnWorks en utilisant l'un de nos multiples postes de travail en ligne gratuits tels que Ubuntu Online, Fedora Online, l'émulateur en ligne Windows ou l'émulateur en ligne MAC OS
PROGRAMME:
Nom
queue_splitter3 - consommateur PgQ qui transporte les événements d'une file d'attente vers plusieurs cibles
files d'attente
SYNOPSIS
queue_splitter3 [commutateurs] config.ini
DESCRIPTION
queue_spliter est un consommateur PgQ qui transporte les événements de la file d'attente source vers plusieurs cibles
files d'attente. Le champ ev_extra1 de chaque événement indique dans quelle file d'attente cible il doit aller.
(pgq.logutriga() y met le nom de la table.)
Un cas d'utilisation consiste à déplacer des événements de la base de données OLTP vers le serveur de traitement par lots. En utilisant
séparateur de file d'attente, il est possible de déplacer toutes sortes d'événements pour le traitement par lots avec un seul
consommateur gardant ainsi la base de données OLTP moins encombrée.
DÉMARRAGE RAPIDE
La configuration et l'utilisation de base de queue_splitter peuvent être résumées par les étapes suivantes :
1. pgq doit être installé à la fois dans les bases de données source et cible. Voir la page de manuel pgqadm pour
des détails. La base de données cible doit également avoir le schéma pgq_ext installé.
2. éditez un fichier de configuration queue_splitter, disons
queue_splitter_sourcedb_sourceq_targetdb.ini
3. créer des files d'attente source et cible
$ pgqadm.py ticker.ini créer
4. lancer le séparateur de file d'attente en mode démon
$ queue_splitter3 queue_splitter_sourcedb_sourceq_targetdb.ini -d
5. commencer à produire et à consommer des événements
CONFIG
Commun paramétrage paramètres
nom du travail
Nom du travail particulier effectué par le script. Le script se connectera sous ce nom à
logdb/logserver. Le nom est également utilisé par défaut pour le nom du consommateur PgQ. Ça devrait être
unique.
fichier pid
Emplacement du fichier pid. S'il n'est pas fourni, le script n'est pas autorisé à être démonisé.
fichier journal
Emplacement du fichier journal.
boucle_delay
Si le processus est en cours d'exécution, combien de temps dormir après chaque boucle de travail, en secondes.
Par défaut: 1.
connexion_vietime
Fermez et reconnectez les anciennes connexions de base de données.
use_skylog
fou.
Commun PgQ consommateur paramètres
nom_file_attente
Nom de la file d'attente à laquelle s'attacher. Aucun défaut.
nom_consommateur
Identifiant du consommateur à utiliser lors de l'inscription. Par défaut : %(job_name)s
queue_splitter paramètres
src_db
Base de données sources.
dst_db
Base de données cible.
Exemple config filet
[queue_splitter3]
nom_travail = queue_splitter_sourcedb_sourceq_targetdb
src_db = nom de base de données = base de données source
dst_db = nom de base de données = base de données cible
pgq_queue_name = sourceq
fichier journal = ~/journal/%(nom_travail)s.log
fichier pid = ~/pid/%(nom_travail)s.pid
COMMAND LINE INTERRUPTEURS
Les commutateurs suivants sont communs à tous les programmes Python basés sur skytools.DBScript.
-h, --aide
afficher le message d'aide et quitter
-q, --calme
rendre le programme silencieux
-v, --verbeux
rendre le programme plus verbeux
-d, --démon
faire passer le programme en arrière-plan
--ini
afficher le fichier de configuration de modèle commenté.
Les commutateurs suivants sont utilisés pour contrôler le processus en cours d'exécution. Le pidfile est lu depuis
config, puis le signal est envoyé à l'ID de processus spécifié ici.
-r, --recharger
recharger la configuration (envoyer SIGHUP)
-s, --stop
arrêter le programme en toute sécurité (envoyer SIGINT)
-k, --kill
tuer le programme immédiatement (envoyer SIGTERM)
CAS D'UTILISATION
Comment traiter les événements créés dans la base de données secondaire avec plusieurs files d'attente mais n'ayant que
une file d'attente dans la base de données primaire. Cela montre également comment insérer des événements dans des files d'attente avec
SQL régulier facilement.
CRÉER la file d'attente SCHEMA ;
CREATE TABLE queue.événement1 (
-- cela doit correspondre à la structure interne de l'événement
-- ici, vous pouvez vérifier que les données correctes sont mises en file d'attente
identifiant int4,
texte du nom,
-- pas nécessaire, mais bon d'avoir :
clé primaire (id)
);
-- mettre les données dans la file d'attente au format urlencoded, ignorer l'insertion réelle
CRÉER LE DÉCLENCHEUR redirect_queue1_trg AVANT D'INSÉRER SUR queue.event1
POUR CHAQUE LIGNE EXÉCUTER LA PROCÉDURE pgq.logutriga('singlequeue', 'SKIP');
-- répéter ce qui précède pour l'événement2
-- maintenant les données peuvent être insérées :
INSERT INTO queue.event1 (id, name) VALUES (1, 'user');
Si queue_splitter est mis sur "singlequeue", il propage l'événement sur la cible aux files d'attente
nommé "queue.event1", "queue.event2", etc. Cela maintient la charge PgQ sur la base de données primaire minimale
à la fois du point de vue du processeur et de la maintenance.
01/15/2016 QUEUE_SPLITTER3(1)
Utilisez queue_splitter3 en ligne à l'aide des services onworks.net
