Nowa instalacja supla-docker na rasberry pi4 64 bit i problem po przeniesieniu bazy z rpi2 32 bit

[bob_]

Cześć,

proszę Was o pomoc jak odzyskać swoją konfigurację w sytuacji gdy na nowym własnym serwerze (raspberry pi 4 z systemem lite 64 bit) supla przestaje działać po zaimportowaniu kopii bazy ze starego serwera, tj. raspberry pi 2 32 bit.

Instalację na rpi4, na świeżo, zrobiłem z powodzeniem, wywołanie adresu serwera z przeglądarki bez problemu uruchamiało ekran powitalny z oknem do logowania. Następnie zgodnie z instrukcją migracji:
https://github.com/SUPLA/supla-docker/w ... grade-2025

zrobiłem przywrócenie kopii bazy ze starego serwera i po restarcie kontenera cloud już nie startuje, wpisanie adresu serwera w przeglądarkę już niczego nie otwiera ("serwer niedostępny")

Wywołanie docker ps daje:

Code: Select all

CONTAINER ID   IMAGE                       COMMAND                  CREATED        STATUS                            PORTS                                                             NAMES
019a25b8be38   supla/supla-server:latest   "/usr/bin/server-ent…"   17 hours ago   Up 20 minutes                     0.0.0.0:2015-2016->2015-2016/tcp, [::]:2015-2016->2015-2016/tcp   supla-server
6fe2e373978d   supla/supla-cloud:latest    "docker-php-entrypoi…"   17 hours ago   Restarting (255) 58 seconds ago                                                                     supla-cloud
f175d8553031   mariadb:11.7.2              "docker-entrypoint.s…"   17 hours ago   Up 20 minutes                     3306/tcp                                                          supla-db

z kolei w logach serwera widzę z kolei jakieś błędy związane z niezgodnością wersji bazy, to zapewne jest jakiś trop, ale nie wiem jak to interpretować i co można zrobić dalej:

Code: Select all

2025-08-18 11:54:17,125 WARN received SIGTERM indicating exit request
2025-08-18 11:54:22,122 CRIT Supervisor is running as root.  Privileges were not dropped because no user is specified in the conf                                                                                            ig file.  If you intend to run as root, you can set user=root in the config file to avoid this message.
2025-08-18 11:54:22,131 INFO supervisord started with pid 1
2025-08-18 11:54:23,136 INFO spawned: 'supla-scheduler' with pid 11
2025-08-18 11:54:23,141 INFO spawned: 'supla-server' with pid 12
INFO[11:54:23.161618] Scheduler version 23.05
INFO[11:54:23.161852] Started at Mon Aug 18 11:54:23 2025
ERR[11:54:23.170335] Failed to connect to database: Error: Can't connect to MySQL server on 'supla-db' (115)
INFO[11:54:23.171800] Connecting to database ....
INFO[11:54:23.180548] Server version 25.07 [Protocol v27]
INFO[11:54:23.180725] Started at Mon Aug 18 11:54:23 2025
ERR[11:54:23.184578] Failed to connect to database: Error: Can't connect to MySQL server on 'supla-db' (115)
INFO[11:54:23.184616] Connecting to database ....
ERR[11:54:24.174317] Failed to connect to database: Error: Can't connect to MySQL server on 'supla-db' (115)
2025-08-18 11:54:24,174 INFO success: supla-scheduler entered RUNNING state, process has stayed up for > than 1 seconds (startsec                                                                                            s)
2025-08-18 11:54:24,175 INFO success: supla-server entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
ERR[11:54:24.186102] Failed to connect to database: Error: Can't connect to MySQL server on 'supla-db' (115)
ERR[11:54:25.176128] Failed to connect to database: Error: Can't connect to MySQL server on 'supla-db' (115)
ERR[11:54:25.188566] Failed to connect to database: Error: Can't connect to MySQL server on 'supla-db' (115)
ERR[11:54:26.182893] Failed to connect to database: Error: Can't connect to MySQL server on 'supla-db' (115)
ERR[11:54:26.189914] Failed to connect to database: Error: Can't connect to MySQL server on 'supla-db' (115)
ERR[11:54:27.186765] Failed to connect to database: Error: Can't connect to MySQL server on 'supla-db' (115)
ERR[11:54:27.191058] Failed to connect to database: Error: Can't connect to MySQL server on 'supla-db' (115)
ERR[11:54:28.188126] Failed to connect to database: Error: Can't connect to MySQL server on 'supla-db' (115)
ERR[11:54:28.192218] Failed to connect to database: Error: Can't connect to MySQL server on 'supla-db' (115)
ERR[11:54:29.189245] Failed to connect to database: Error: Can't connect to MySQL server on 'supla-db' (115)
ERR[11:54:29.193503] Failed to connect to database: Error: Can't connect to MySQL server on 'supla-db' (115)
ERR[11:54:30.201156] Incorrect database version! Expected: 20250625101351
ERR[11:54:30.202962] Incorrect database version! Expected: 20250625101351
2025-08-18 11:54:30,206 INFO exited: supla-scheduler (exit status 1; not expected)
2025-08-18 11:54:30,209 INFO spawned: 'supla-scheduler' with pid 13
2025-08-18 11:54:30,211 INFO exited: supla-server (exit status 1; not expected)
INFO[11:54:30.224503] Scheduler version 23.05
INFO[11:54:30.224618] Started at Mon Aug 18 11:54:30 2025
2025-08-18 11:54:30,228 INFO spawned: 'supla-server' with pid 14
ERR[11:54:30.236087] Incorrect database version! Expected: 20250625101351
2025-08-18 11:54:30,237 INFO exited: supla-scheduler (exit status 1; not expected)
INFO[11:54:30.258576] Server version 25.07 [Protocol v27]
INFO[11:54:30.258697] Started at Mon Aug 18 11:54:30 2025
ERR[11:54:30.263419] Incorrect database version! Expected: 20250625101351
2025-08-18 11:54:30,266 INFO exited: supla-server (exit status 1; not expected)

[bob_]

Widzę, że temat został przeniesiony - dziękuję i przepraszam za umieszczenie w złym dziale.
Ktoś może coś podpowie? Zastanawia mnie szczególnie ten wpis:


supla-server | ERR[19:01:25.346626] MySQL - stmt prepare error - Table 'supla.migration_versions' doesn't exist
supla-server | ERR[19:01:25.346832] The version of the database can not be determined!
supla-server | 2025-08-17 19:01:25,348 INFO exited: supla-scheduler (exit status 1; not expected)

oraz

supla-server | INFO[11:54:36.384623] Scheduler version 23.05
supla-server | INFO[11:54:36.384746] Started at Mon Aug 18 11:54:36 2025
supla-server | ERR[11:54:36.395914] Incorrect database version! Expected: 20250625101351
supla-server | INFO[11:54:33.352921] Server version 25.07 [Protocol v27]



Oznaczenie daty i godziny w jakiej serwer spodziewa się bazy (20250625101351), nie odpowiada dacie, w której faktycznie robiłem kopię.

[lesny8]

Ta data nie dotyczy Twojej kopii zapasowej tylko wersji bazy danych. Jak coś się pojawia w nowszych wersjach Cloud-a, jakieś funkcjonalności, które potrzebują przechowywać coś w bazie, to robiona jest migracja, poprzez dodanie nowych tabel, pól itp.

Przy takim przenoszeniu trzeba zadbać o te samą wersję bazy na obu serwerach, ja zawsze tak robiłem. Czyli jeśli nie możesz zaktualizować na starym Pi2 do aktualnej wersji i masz tam np. v25.03 , to na nowym sprzęcie zainstaluj dokładnie tą samą wersje co masz na starej, czyli v25.03, a po przywróceniu bazy z backupu, jak wszystko już wstanie, zrób update nowej instancji.
Wszystkie dockery wcześniejszych wersji są dostępne, wystarczy zamiast tagu 'latest' lub jego braku, wskazać odpowiedni tag dla wersji.

https://hub.docker.com/r/supla/supla-cloud/tags
https://hub.docker.com/r/supla/supla-server/tags

No chyba, że można jeszcze puścić tą migrację z konsoli i to przejdzie, ale osobiście nigdy nie sprawdzałem.

[bob_]

No i dokładnie w tym był cały szkopuł. Na nowym sprzęcie postępowałem ściśle zgodnie z instrukcją, a zatem zainstalowała mi się najwyższa dostępna wersja (25.07), z kolei na starym serwerze miałem wersję 25.03. Nie wiem skąd mi się to wzięło, ale czytając informację odejściu od platform 32bit uznałem, że tej starej już nie da się zaktualizować.
Ostatecznie tak jak radzi lesny puściłem aktualizację na starej wersji, poszło bez problemów za wyjątkiem komunikatów o rychłym braku wsparcia. Potem kopia bazy i przywrócenie na nowym serwerze i wszystko hula!

Dziękuję!

ps.
wytłumacz mi proszę tylko jedno - skoro przy "normalnych" aktualizacjach tworzymy nowe wersje clouda (i serwera też?) to co się dzieje w trakcie automatycznego tworzenia kopii bazy i nią samą skoro wszystko potem działa? Cały ten proces "nadpsuje" nowe tagi, tak?
W takiej sytuacji przywrócenie bazy zrobionej np. 2 wersje wcześniej poskutkowałoby tymi samymi błędami, które tu opisuję?

[lesny8]

Nowe wersje Clouda i serwera nie koniecznie muszą wprowadzać zmiany w bazie danych, wtedy nie będzie migracji, ale jeśli to robią, to wersja bazy się nie będzie zgadzać po odtworzeniu ze starszej kopii.

Domyślnie przy pierwszym uruchomieniu aplikacji, Cloud łączy się z silnikiem bazodanowym, tworzy i inicjuje bazę danych, a potem przeprowadza szereg migracji, które od początku istnienia projektu zostały wprowadzone.
https://github.com/SUPLA/supla-cloud/tr ... /Migration

Tu masz np. tą ostatnią
https://github.com/SUPLA/supla-cloud/bl ... 101351.php

Jak już Cloud wykona jakąś migrację, to to zapamiętuje i aplikacja wie jakiej wersji bazy danych oczekuje, więc podając jej starszą kopię zapasową, napotyka na błędy przy uruchamianiu i w logu to widać bo sypie stosownym komunikatem.

Automatyczny backup, który odbywa się chwilę przed upgradem, jest do wersji z której podnosisz aplikację. Skrypt następnie zatrzymuje kontenery, pobiera nowe obrazy i uruchamia ponownie całą aplikację w oparciu o obrazy z tagiem 'latest'. Stare pobrane obrazy, które miały do tej pory tag 'latest', mają już wtedy tag wersji np. 'v25.03'. Taki rename ogarnia sobie docker.

Następnie kontenery są przebudowywane w oparciu o nowe obrazy i jak przypuszczam przy pierwszym takim starcie sprawdzane są migracje. Pewnie da się je jakoś uruchomić z terminala, ale nigdy tego nie sprawdzałem i nie szukałem tego pod kątem Supli, bo nie miałem takiej potrzeby.
Powiem nawet, że na pewno się da, ale że mi to nie było nigdy potrzebne to na tą chwilę nie wiem jak

[bob_]

Piękne dzięki za wytłumaczenie.