Migration en v6.0 sur PostgreSQL

Request description

Bonjour,

J’ai essayé de migrer une application de v5.3.30 à v6.0.3 mais pendant et après la migration je constate plusieurs comportements étranges. J’ai également essayé de faire la migration sur une instance Simplicité vierge avec uniquement le module de Démo et je constate le même comportement.

  • La migration prend beaucoup de temps, 2h dans mon cas pour avoir de nouveau accès à l’IHM.

  • Lors de la migration il y a beaucoup d’erreurs dans les logs.

  • Une fois qu’on a accès à l’IHM, il y a encore beaucoup d’activité dans les logs, des erreurs notamment.

  • Quand je me connecte avec le compte designer, plusieurs domaines et objets ne sont plus accessibles dans le menu. Par exemple, le sous-menu “Objets métier”, “Interface utilisateur” et “Porcessus métier” sont vides.

Est-ce que la migration est toujours en cours même si l’IHM est de nouveau accessible ?
Comment peut-on savoir si la migration est bien terminée ?
Est-ce que la procédure, ci-dessous, que j’ai suivi pour faire la migration est correcte ?

Steps to reproduce

  1. Créer une instance Simplicité v5.3.30 avec le docker-compose suivant :
version: "3"

services:
  db:
    image: postgres:13
    restart: always
    container_name: simplicite_mig_60_2_db
    environment:
      POSTGRES_USER: simplicite60
      POSTGRES_PASSWORD: simplicite60
      POSTGRES_DB: simplicite60
    ports:
      - 6133:5432
    volumes:
      - ./volumes/db:/var/lib/postgresql
      - ./volumes/db/data:/var/lib/postgresql/data

  simplicite:
    image: registry.simplicite.io/platform:5.3.30
    restart: always
    container_name: simplicite_mig_60_2_app
    environment:
      DB_SETUP: "true"
      DB_VENDOR: postgresql
      DB_HOST: db
      DB_USER: simplicite60
      DB_PASSWORD: simplicite60
      DB_NAME: simplicite60
      DB_WAIT: 100
    ports:
      - 8062:8443
    volumes:
      - ./volumes/app/git:/usr/local/tomcat/webapps/ROOT/WEB-INF/git
    depends_on:
      - db

  1. Installer le module Démo depuis l’AppStore + faire un clear cache rouge.

  2. Arrêter l’instance et supprimer les conteneurs avec la commande “docker-compose down”.

  3. Modifier le fichier docker-compose.yml pour utiliser la version 6.0.3.

  4. Exécuter la commande “docker-compose up -d”.

  5. Attendre 2h et garder un oeil sur les logs.
    Remarque : Beaucoup d’erreurs sont présentes.

simplicite_demo_mig_v6_logs.zip (2.4 MB)

  1. Après 2h, l’IHM est de nouveau accessible.

  2. Une fois connecté avec le compte designer on constate que le menu n’est pas complet.

  1. Dans les logs il y a encore beaucoup d’activité, principalement des erreurs.

Technical information

Remarque : J’ai également essayé avec une application utilisant une base de données MariaDB.

Instance /health

[Platform]
Status=OK
Version=6.0.3
BuiltOn=2024-03-07 12:50
Git=6.0/e143635330cda547f9c4fcdfc26f38f9283352d2
Encoding=UTF-8
EndpointIP=
EndpointURL=http://c825f75ae963:8080
TimeZone=UTC
SystemDate=2024-03-15 12:51:28

[Application]
ApplicationVersion=1.0.0
ContextPath=
ContextURL=
ActiveSessions=2
TotalUsers=7
EnabledUsers=5
LastLoginDate=2024-03-15 12:08:14

[Server]
ServerInfo=Apache Tomcat/9.0.86
ServerType=WEB
ServerActiveSessions=2
ServerSessionTimeout=30
CronStarted=true

[OS]
Name=Linux
Architecture=amd64
Version=5.15.0-89-generic
DockerImageName=almalinux9
SystemEncoding=UTF-8

[JavaVM]
Version=21.0.2
Vendor=Eclipse Adoptium
VMName=OpenJDK 64-Bit Server VM
VMVersion=21.0.2+13-LTS
ScriptEngine=rhino
ScriptEngineVersion=Rhino 1.7.13 2020 09 02
HeapFree=80337
HeapSize=313344
HeapMaxSize=2033664
TotalFreeSize=1800657

[Cache]
ObjectCache=322
ObjectCacheMax=10000
ObjectCacheRatio=3
ProcessCache=322
ProcessCacheMax=10000
ProcessCacheRatio=3
APIGrantCache=0
APIGrantCacheMax=1000
APIGrantRatio=0

[Database]
Vendor=3
VendorName=postgresql
ProductName=PostgreSQL
ProductVersion=13.14 (Debian 13.14-1.pgdg120+2)
DriverName=PostgreSQL JDBC Driver
DriverVersion=42.7.2
DBDate=2024-03-15 12:51:28
DBDateOffset=0
DBPatchLevel=6;P00;670c794129f408f5bf771ff357b38321
UsingBLOBs=true

[Healthcheck]
Date=2024-03-15 12:51:28
ElapsedTime=20

Bonjour @FlorentGN ,

En dehors du temps de migration qui peut effectivement être long, ce que tu décris n’est effectivement pas normal. L’IHM ne devrait pas être accessible pendant la migration, et la procédure que tu as suivi est correcte. On reproduit sur nos environnements et on te fait un retour rapidement.

Avant de prendre le temps de faire ça cependant, est-on d’accord que les volumes ont été purgés pour ce test, et que la base était bien vierge?

WARNING: ... already exists
│2024-03-15 10:25:16,047|SIMPLICITE|WARN|Database patch SQL request = CREATE TABLE m_permission ( row_id integer NOT NULL, row_module_id integer, created_dt timestamp NOT NULL, created_by varchar(100) NOT NULL, updated_dt timestamp NOT NU│
│2024-03-15 10:25:16,050|SIMPLICITE|WARN|Database patch SQL request = CREATE INDEX m_permission_fk0 ON m_permission (row_module_id) / warning = ERROR: relation "m_permission_fk0" already exists                                             │
│2024-03-15 10:25:16,053|SIMPLICITE|WARN|Database patch SQL request = CREATE INDEX m_permission_fk1 ON m_permission (prm_group_id) / warning = ERROR: relation "m_permission_fk1" already exists                                              │
│2024-03-15 10:25:16,060|SIMPLICITE|WARN|Database patch SQL request = CREATE INDEX m_permission_fk2 ON m_permission (prm_object) / warning = ERROR: relation "m_permission_fk2" already exists                                                │
│2024-03-15 10:25:16,152|SIMPLICITE|WARN|Database patch SQL request = ALTER TABLE m_licensekey ADD COLUMN lky_max_obj integer / warning = ERROR: column "lky_max_obj" of relation "m_licensekey" already exists                               │
│2024-03-15 10:25:16,156|SIMPLICITE|WARN|Database patch SQL request = CREATE TABLE m_action_group ( row_id integer NOT NULL, row_module_id integer, created_dt timestamp NOT NULL, created_by varchar(100) NOT NULL, updated_dt timestamp NOT │
│2024-03-15 10:25:16,158|SIMPLICITE|WARN|Database patch SQL request = CREATE UNIQUE INDEX m_action_group_uk ON m_action_group (acg_name) / warning = ERROR: relation "m_action_group_uk" already exists                                       │
│2024-03-15 10:25:16,161|SIMPLICITE|WARN|Database patch SQL request = CREATE INDEX m_action_group_fk0 ON m_action_group (row_module_id) / warning = ERROR: relation "m_action_group_fk0" already exists                                       │
│2024-03-15 10:25:16,164|SIMPLICITE|WARN|Database patch SQL request = ALTER TABLE m_action_group ADD COLUMN acg_label char(1) / warning = ERROR: column "acg_label" of relation "m_action_group" already exists                               │
│2024-03-15 10:25:16,229|SIMPLICITE|WARN|Database patch SQL request = CREATE TABLE m_action_queue ( row_id integer NOT NULL, row_module_id integer, created_dt timestamp NOT NULL, created_by varchar(100) NOT NULL, updated_dt timestamp NOT │
│2024-03-15 10:25:16,232|SIMPLICITE|WARN|Database patch SQL request = CREATE UNIQUE INDEX m_action_queue_uk ON m_action_queue (acq_name) / warning = ERROR: relation "m_action_queue_uk" already exists                                       │
│2024-03-15 10:25:16,273|SIMPLICITE|WARN|Database patch SQL request = ALTER TABLE m_theme ADD COLUMN thm_code_editor_theme varchar(50) / warning = ERROR: column "thm_code_editor_theme" of relation "m_theme" already exists                 │
│2024-03-15 10:25:16,275|SIMPLICITE|WARN|Database patch SQL request = ALTER TABLE m_theme ADD COLUMN thm_html_editor_theme varchar(10) / warning = ERROR: column "thm_html_editor_theme" of relation "m_theme" already exists                 │
│2024-03-15 10:25:16,300|SIMPLICITE|WARN|Database patch SQL request = ALTER TABLE m_objfield ADD COLUMN obf_filters text / warning = ERROR: column "obf_filters" of relation "m_objfield" already exists                                      │
│2024-03-15 10:25:16,504|SIMPLICITE|WARN|Database patch SQL request = ALTER TABLE m_user ADD COLUMN usr_numformat varchar(2) / warning = ERROR: column "usr_numformat" of relation "m_user" already exists  
ERROR: duplicate key value / Key already exists
│2024-03-15 12:04:20,053|SIMPLICITE|ERROR||http://c825f75ae963:8080||ECOREDB001|system|com.simplicite.util.engine.ObjectManager|create||Error SQL query: Create failed for object ObjectIndex and row ID =                                    │
│org.postgresql.util.PSQLException: ERROR: duplicate key value violates unique constraint "m_index_pkey"                                                                                                                                      │
│  Detail: Key (idx_key)=(TranslateField:52629) already exists.   

En filtrant ces erreurs, tes logs n’ont plus que l’erreur Git Unable to create Git base dir: /usr/local/tomcat/webapps/ROOT/WEB-INF/git (Not writeable) qui doit être traîtée à part, et les warnings des patchs SQLs.

Oui, j’ai installé une instance 5.3.30 toute neuve dédiée à ce test avec son propre conteneur PostgreSQL. Les volumes étaient vides ou inexistants avant le premier docker-compose up.

L’upgrade en lui-même prend normalement quelques minutes.

Ce qui est long c’est la ré-indexation de la table m_index pour les recherches fulltext. Ca aurait dû être lancé à la fin en asynchrone, les accès UI pouvant se faire dès que l’upgrade est terminé / l’instance démarrée.

Effectivement, sur PG il y a des problèmes de mises à jour concurrentielles. On va revoir le process pour ne pas tout faire en même temps.

Ce sera corrigé sur PostgreSQL en 6.0.5.

ok, merci François par contre j’ai constaté le même comportement avec une base de données MariaDB. Est-ce que la correction réalisée pour PostgreSQL corrigera également le problème avec MariaDB ?

Bonjour,

Oui nous allons retester chaque base aujourd’hui en repartant d’une 5.3 à jour : Maria/MySQL, Oracle et aussi Microsoft MSSQL.

Le problème venait surtout de rebuilds de séquence surabondants sur les PK qui provoquaient des duplicate key lors des imports en //. Il venait aussi de patchs XML backportés avec une syntaxe 6.1 incompatible qui générait pas mal d’erreurs au 1er passage des patchs.

1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.