(c) Yandex.Photos
Tous les personnages sont fictifs, les marques appartiennent à leurs propriétaires, toutes les coïncidences sont aléatoires et en général, c'est mon "jugement de valeur subjective, s'il vous plaît ne pas casser la porte ...".
Nous avons une expérience considérable dans la traduction de systèmes d'information avec logique dans la base de données d'un SGBD à un autre. Dans le cadre du décret gouvernemental n ° 1236 du 16/11/2016, il s'agit souvent d'un transfert d'Oracle vers Postgresql. Comment organiser le processus de la manière la plus efficace et la plus indolore possible - nous pouvons vous dire séparément, nous parlerons aujourd'hui des caractéristiques de l'utilisation d'un cluster et des problèmes que vous pouvez rencontrer lors de la construction de systèmes distribués très chargés avec une logique complexe dans les procédures et les fonctions.
Spoiler - oui cap, RAC et pg multimaster sont des solutions très différentes.
Supposons que vous ayez déjà transféré toute la logique de pl \ sql vers pg \ sql. Et vos tests de régression sont tout à fait OK, maintenant vous pensez bien sûr à l'échelle, car les tests de charge ne vous plaisent pas beaucoup, surtout sur le matériel initialement prévu dans le projet, sous ce SGBD très différent. Supposons que vous ayez trouvé une solution du fournisseur national «Postgres Professional» avec une option appelée «multimaster», qui n'est disponible que dans la version «maximale» de «Postgres Pro Enterprise» et selon la description - elle est très similaire à ce dont vous avez besoin, et lors de la première étude de surface, elle viendra dans ma tête la pensée: "Oh! Au lieu de RAC, alors! Oui, et avec le pipeline technique dans le pays d'origine! ”
Mais ne vous précipitez pas pour vous réjouir, et nous décrirons plus loin pourquoi vous devez connaître ces nuances, car ils sont difficiles à envisager même après avoir bien lu la documentation produit. Évaluez si vous serez prêt à mettre à jour fréquemment la version du SGBD directement sur le site industriel, comme certains défauts ne sont pas compatibles avec un fonctionnement industriel et sont difficiles à détecter lors des tests.
Commencez par lire attentivement la section «multimaître» - «restriction» sur le site Web du fabricant.
La première chose que vous pouvez rencontrer est les caractéristiques du fonctionnement des transactions, dites Mode "biphasé", et parfois, sauf en réécrivant toute la logique de votre procédure, cela ne peut pas être corrigé. Voici un exemple simple:
create table test1 (id integer, id1 integer); insert into test1 values (1, 1),(1, 2); ALTER TABLE test1 ADD CONSTRAINT test1_uk UNIQUE (id,id1) DEFERRABLE INITIALLY DEFERRED; update test1 set id1 = case id1 when 1 then 2 else id1 - sign(2 - 1) end where id1 between 1 and 2;
Une erreur se produit:
: [MTM] Transaction MTM-1-2435-10-605783555137701 (10654) is aborted on node 3. Check its log to see error details.
Ensuite, vous pouvez lutter contre le blocage mort pendant une longue période dans les versions 10.5, 10.6 et le seul salut connu qui tue toute l'essence du cluster est de supprimer les tables de "problèmes" du cluster, c'est-à-dire faites make_table_local, mais au moins cela vous permettra de travailler, et ne "jouera" pas tout à cause des attentes suspendues de commettre des transactions. Eh bien, ou mettez une mise à jour de la version 11.2, qui devrait aider, ou peut-être pas, n'oubliez pas de vérifier.
Dans certaines versions, vous pouvez obtenir un verrou encore plus mystérieux:
username= mtm backend_type = background worker
Et dans cette situation, seule la mise à jour de la version du SGBD vers 11.2 et plus vous aidera, ou cela ne vous aidera pas.
Certaines opérations avec des index peuvent entraîner des erreurs où il est clairement indiqué que le problème est dans la réplication bidirectionnelle, dans les journaux MTM, vous verrez directement BDR. Vraiment 2ndQuadrant? Oh non ... nous avons acheté un multimaître, c'est juste une coïncidence, c'est le nom de la technologie.
[MTM] bdr doesn't support index rechecks [MTM] 12124: REMOTE begin abort transaction 4083 [MTM] 12124: send ABORT notification for transaction (5467) local xid=4083 to coordinator 3 [MTM] Receive ABORT_PREPARED logical message for transaction MTM-3-25030-83-605694076627780 from node 3 [MTM] Abort prepared transaction MTM-3-25030-83-605694076627780 status InProgress from node 3 originId=3 [MTM] MtmLogAbortLogicalMessage node=3 transaction=MTM-3-25030-83-605694076627780 lsn=9fff448
Si vous utilisez des tables temporaires, malgré les assurances: «L'extension multimaître réplique les données de manière complètement automatique. "Vous pouvez simultanément écrire des transactions et travailler avec des tables temporaires sur n'importe quel nœud du cluster."
Ensuite, en fait, vous obtiendrez que la réplication ne fonctionne pas pour toutes les tables utilisées dans la procédure, si le code contient la création d'une table temporaire, et même si l'utilisation de multimaster.remote_functions n'aide pas, vous devrez mettre à jour ou réécrire votre logique dans la procédure. Si vous devez utiliser deux extensions multimaster et pg_pathman en même temps dans le cadre de Postgres Pro Enterprise v 10.5, vérifiez cela avec cet exemple simple:
CREATE TABLE measurement ( city_id int not null, logdate date not null, peaktemp int, unitsales int ) PARTITION BY RANGE (logdate); CREATE TABLE measurement_y2019m06 PARTITION OF measurement FOR VALUES FROM ('2019-06-01') TO ('2019-07-01'); insert into measurement values (1, to_date('27.06.2019', 'dd.mm.yyyy'), 1, 1); insert into measurement values (2, to_date('28.06.2019', 'dd.mm.yyyy'), 1, 1); insert into measurement values (3, to_date('29.06.2019', 'dd.mm.yyyy'), 1, 1); insert into measurement values (4, to_date('30.06.2019', 'dd.mm.yyyy'), 1, 1);
Les erreurs suivantes commencent à verser les journaux sur les nœuds du SGBD:
… PATHMAN_CONFIG doesn't contain relation 23245 > find_in_dynamic_libpath: trying "/opt/…/ent-10/lib/pg_pathman" > find_in_dynamic_libpath: trying "/opt//…/ent-10/lib/pg_pathman.so" > : find_in_dynamic_libpath: trying "/opt/…/ent-10/lib/pg_pathman" > find_in_dynamic_libpath: trying "/opt/…/ent-10/lib/pg_pathman.so" > PrepareTransaction(1) name: unnamed; blockState: PREPARE; state: INPROGR, xid/subid/cid: 6919/1/40 > StartTransaction(1) name: unnamed; blockState: DEFAULT; state: INPROGR, xid/subid/cid: 0/1/0 > switched to timeline 1 valid until 0/0 … Transaction MTM-1-13604-7-612438856339841 (6919) is aborted on node 2. Check its log to see error details. ... [MTM] 28295: REMOTE begin abort transaction 7017 … [MTM] 28295: send ABORT notification for transaction (6919) local xid=7017 to coordinator 1
Vous pouvez découvrir quelles sont ces erreurs dans le support technique, ce n'est pas pour rien que vous l'avez acheté.
Que faire Ok! Mise à niveau vers Postgres Pro Enterprise vers la version 11.2
Vous devez savoir séparément que, étant un objet d'une base de données répliquée, il n'a pas de valeur transversale dans le cluster, chaque séquence est locale à chaque nœud et si vous avez des champs avec des restrictions uniques et utilisez une séquence, vous ne pouvez incrémenter le numéro de nœud que dans cluster, car combien de nœuds dans le cluster sont tellement plus rapides que la séquence va grandir, et int se terminera plus vite que prévu. Pour simplifier le travail avec la séquence dans le produit, vous trouverez même la fonction alter_sequences, qui effectuera les incréments nécessaires pour chaque séquence sur tous les nœuds, mais soyez prêt à ce que la fonction ne fonctionne pas dans toutes les versions. Bien sûr, vous pouvez l'écrire vous-même, en prenant le code de github comme base ou en vous corrigeant directement dans le SGBD. Dans le même temps, les champs de type serial \ bigserial fonctionneront plus correctement, mais pour les utiliser, vous devrez probablement réécrire le code de vos procédures et fonctions. Peut-être que quelqu'un trouvera la fonction monotonic_sequences utile.
Avant la version 11.2 de Postgres Pro Enterprise, la réplication ne fonctionne que s'il existe des clés primaires uniques, gardez cela à l'esprit lors de la conception.
Je voudrais également mentionner les fonctionnalités de npgsql dans une solution de cluster, ces problèmes ne se produisent pas sur un seul nœud, mais ils sont assez présents dans le multimaître.
Dans certaines versions, vous pouvez rencontrer une erreur:
Exception Details: Npgsql.PostgresException: 25001: SET TRANSACTION ISOLATION LEVEL Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.
Que peut-on faire? N'utilisez simplement pas certaines versions. Vous devez les connaître, car l'erreur n'apparaît pas dans une version, et même après sa première correction, vous pouvez la rencontrer plus tard. Vous devez également vous y préparer et il est préférable d'identifier tous les défauts du SGBD qui sont corrigés par le fabricant et de les couvrir avec des tests de régression distincts. Faites confiance, pour ainsi dire, mais vérifiez.
Si l'application utilise npgsql et bascule entre les nœuds en pensant qu'ils sont tous identiques, vous pouvez obtenir une erreur:
EXCEPTION:Npgsql.PostgresException (0x80004005): XX000: cache lookup failed for type ...
Une telle erreur se produira du fait que la liaison
(NpgsqlConnection.GlobalTypeMapper.MapComposite<SomeType>("some_composite_type");)
types composites au démarrage de l'application pour toutes les connexions. En conséquence, nous obtenons l'identifiant de l'un des nœuds, et lorsqu'il est demandé sur un autre nœud, il ne correspond pas, à la suite de quoi une erreur est retournée, c'est-à-dire un travail transparent avec des types composites dans un cluster pour certaines applications sera impossible sans réécritures supplémentaires côté application (si vous réussissez à le faire).
Comme nous le savons tous, une évaluation générale de l'état du cluster est très importante pour les diagnostics et les mesures opérationnelles lorsque vous travaillez, dans le produit, vous pouvez trouver certaines fonctions qui devraient vous faciliter la vie, mais parfois elles peuvent ne pas produire du tout ce que vous et même le fabricant eux-mêmes à partir d'eux attendre.
Par exemple:
select mtm.collect_cluster_info(); : (1,Online,0,0,0,2,3,0,0,0,1,0,0,1,1,3,7,0,0,0,"2018-10-31 05:33:06") (2,Online,0,0,0,2,3,0,0,0,1,0,0,1,1,3,7,0,0,0,"2018-10-31 05:33:06") (3,Online,0,0,0,2,3,0,0,0,1,0,0,1,1,3,7,0,0,0,"2018-10-31 05:33:09")
Mais pourquoi le nombre 2 est-il partout dans le champ LiveNodes, bien que selon la description du travail du multimaître, il devrait correspondre au nombre AllNodes = 3? Réponse: vous devez mettre à jour la version du SGBD.
Et soyez prêt à collecter des journaux sur tous les nœuds, comme généralement, vous verrez "l'erreur se trouve dans le journal d'un autre nœud". TechSupport acceptera tous les défauts identifiés et vous informera que la prochaine version est prête, qui devra être installée tantôt avec le service arrêté, tantôt pendant longtemps (selon le volume de votre SGBD). Il ne vaut pas la peine d'espérer que les problèmes de fonctionnement perturberont grandement le fournisseur, et la mise à jour en raison de défauts identifiés sera effectuée avec la participation des représentants du fournisseur, ou plutôt, il n'est même pas nécessaire d'impliquer les représentants du fournisseur, car au final, vous pouvez obtenir un cluster démonté sans sauvegarde sur le produit.
En fait, dans la licence d'un produit commercial, le fabricant avertit honnêtement: «Ce logiciel est fourni« tel quel »et la société à responsabilité limitée Postgres Professional n'est pas tenue de fournir une assistance, une assistance, des mises à jour, des extensions ou des modifications.»
Si vous n'avez pas deviné de quel type de produit nous parlons, alors toute cette expérience a été acquise grâce au fonctionnement annuel de la base Postgres Pro Enterprise. Vous pouvez vous-même tirer une conclusion, une telle humidité que les champignons poussent.
Mais ce serait la moitié du problème, si elle était effectuée en temps opportun et éliminait rapidement les problèmes qui se posaient.
Mais cela ne se produit tout simplement pas. Apparemment, les ressources du fabricant ne sont pas suffisantes pour corriger rapidement les bogues identifiés.