Open yohanboniface opened 1 year ago
Est-ce qu'il ne serait pas plus simple d'installer une nouvelle instance avec la dernière Ubuntu ou Debian, et y copier les données après ?
Certainement! L'enjeu est de limiter le downtime. Donc c'est essentiellement les fichiers qui sont longs à migrer.
Dans mon souvenir, la dernière fois, on avait fait une première synchro en faisant un énorme gz, et puis on avait mis en place un rsync régulier qui n'avait plus qu'à faire le diff. Et on avait un script aussi pour migrer la DB (c'est relativement light) je crois.
Donc on pourrait éventuellement refaire plus ou moins ce qu'on avait fait la dernière fois. @cquest ?
Ok, je te créérais une VM sur le cluster TH3 dans la semaine. Toujours avec Ubuntu LTS plutôt que Debian ?
Oui, Ubuntu steup. :)
Trouvé les deux scripts qu'on avait utilisé en 2018:
#! /bin/sh
set -e
DST=/srv/umap/pgdump
sudo -u umap mkdir -p $DST
sudo -u postgres pg_dump umap | bzip2 > /tmp/umap.sql.bz2
sudo chown umap:users /tmp/umap.sql.bz2
sudo -u umap mv /tmp/umap.sql.bz2 $DST/umap.sql.bz2
#! /bin/bash
# WARNING this script is to be used on the SLAVE host.
sudo -u umap rsync --archive --update --verbose --exclude='*.gz' --bwlimit=5000 $${host}:/srv/umap/media_root/ /srv/umap/media_root/
sudo -u umap rsync --archive --update --verbose --bwlimit=5000 $${host}:/srv/umap/pgdump/ /srv/umap/pgdump/
Commande lancée pour la copie initiale des fichiers depuis le volume zfs dispo sur osm32:
ssh osm32.openstreetmap.fr "cd /rpool/backups/umap/srv/umap/media_root/ && sudo tar c pictogram/" | pv | sudo -u umap tar xf - -C /srv/umap/media_root/
ssh osm32.openstreetmap.fr "cd /rpool/backups/umap/srv/umap/media_root/ && sudo tar c datalayer/ --exclude '*.gz'" | pv | sudo -u umap tar xf - -C /srv/umap/media_root/
-> commande tar à modifier en tar --exclude '*.gz' -c datalayer
pour la prochaine fois, pour réellement exclure les *.gz
A priori, la copie initiale a pris 50~55h pour ~1To (je n'ai pas le temps exact, parce la copie a planté au milieu). L'espace pris sur le disque dur n'est que de ~540G, grâce à la compression ZFS.
Je viens de tenter un export/import de la base PostgreSQL. En prenant l'export quotidien (dans /srv/umap/pgdump/
), puis sur la nouvelle machine, en user postgres
:
dropdb umap
createdb umap
psql umap < /path/vers/umap.sql
Et j'ai des erreurs:
ERROR: type "public.pgis_abs" does not exist
ERROR: aggregate public.accum(public.geometry) does not exist
ERROR: type "public.pgis_abs" does not exist
ERROR: aggregate public.makeline(public.geometry) does not exist
ERROR: function public.st_combine_bbox(public.box3d, public.geometry) does not exist
ERROR: aggregate public.st_extent3d(public.geometry) does not exist
ERROR: role "cquest" does not exist
ERROR: value too long for type character varying(30)
CONTEXT: COPY auth_user, line 9181, column first_name: "仏生山まちプランニングルーム"
ERROR: invalid byte sequence for encoding "UTF8": 0xd8 0x2e
ERROR: value too long for type character varying(200)
CONTEXT: COPY umap_map, line 208007, column name: "ОВО № 165 частина міста Тернополя , Бережанський, Зборів..."
ERROR: functions in index expression must be marked IMMUTABLE
ERROR: insert or update on table "django_admin_log" violates foreign key constraint "django_admin_log_user_id_fkey"
DETAIL: Key (user_id)=(1) is not present in table "auth_user".
ERROR: insert or update on table "umap_map_editors" violates foreign key constraint "map_id_refs_id_6d09b0c96789f7ba"
DETAIL: Key (map_id)=(15) is not present in table "umap_map".
ERROR: insert or update on table "social_auth_usersocialauth" violates foreign key constraint "social_auth_usersocialauth_user_id_17d28448_fk_auth_user_id"
DETAIL: Key (user_id)=(4) is not present in table "auth_user".
ERROR: insert or update on table "umap_map_editors" violates foreign key constraint "user_id_refs_id_3126f34faf0482aa"
DETAIL: Key (user_id)=(17) is not present in table "auth_user".
Ce qui empêche la copie des cartes tout au moins.
Possiblement pas le bon encoding de la DB:
umap=# \l
List of databases
Name | Owner | Encoding | Collate | Ctype | Access privileges
-----------+----------+-----------+---------+-------+-----------------------
postgres | postgres | SQL_ASCII | C | C |
template0 | postgres | SQL_ASCII | C | C | =c/postgres +
| | | | | postgres=CTc/postgres
template1 | postgres | SQL_ASCII | C | C | =c/postgres +
| | | | | postgres=CTc/postgres
umap | postgres | SQL_ASCII | C | C |
(4 rows)
Il faudrait plutôt lancer ça pour créer la bdd:
createdb --template=template0 --locale=en_US.UTF-8 --encoding=UTF8 umap
sudo -u umap psql -c "CREATE EXTENSION postgis"
Mieux! Mais j'ai quand même quelques erreurs, dont je ne mesure pas l'impact:
ERROR: type "public.pgis_abs" does not exist
ERROR: aggregate public.accum(public.geometry) does not exist
ERROR: type "public.pgis_abs" does not exist
ERROR: aggregate public.makeline(public.geometry) does not exist
ERROR: function public.st_combine_bbox(public.box3d, public.geometry) does not exist
ERROR: aggregate public.st_extent3d(public.geometry) does not exist
ERROR: role "cquest" does not exist
ERROR: functions in index expression must be marked IMMUTABLE
I guess the last one is related to https://github.com/umap-project/umap/issues/854 and thus must be fixed.
Vu que la solution rsync est trop lente (~4h depuis le clone zfs d'osm32, et 6-8h depuis osm144), on passe à une méthode via zfs:
rpool/data/subvol-199-umapdata-1
, monté sur /mnt/umap-data/
, et avec un lien /mnt/umap-data/srv/umap/media_root/datalayer//
-> /srv/umap/media_root/datalayer/
/usr/local/bin/umap-sync.sh
(sync de quelques secondes si peu de données à copier)Le second volume zfs est configuré dans proxmox, ce qui permet de garder la réplication active, et utilise des options pour que l'uid 1224 du compte umap
soit le même dans les deux volumes.
# /etc/pve/lxc/199.conf
mp0: local-zfs:subvol-199-umapdata-1,mp=/mnt/umap-data/,size=700G
rootfs: local-zfs:subvol-199-disk-0,size=40G
lxc.idmap: u 0 100000 1224
lxc.idmap: g 0 100000 1224
lxc.idmap: u 1224 1224 1
lxc.idmap: g 1224 1224 1
lxc.idmap: u 1225 101225 64310
lxc.idmap: g 1225 101225 64310
# /etc/subuid
root:1224:1
# /etc/subgid
root:1224:1
UMAP_READONLY
dans les settins + restart uwsgi)
Pour pouvoir mettre à jour le code python qui fait tourner uMap, il faut pouvoir faire un upgrade de python lui-même, et donc faire un upgrade de l'OS, et si possible du coup mettre à jour PostgreSQL et PostGIS, bref grosse migration en perspective.
@cquest a commencé à se pencher sur le sujet, en essayant d'utiliser les magies de ZFS, mais pour l'instant sans succès. Je crois qu'il faudrait pouvoir upgrader PostgreSQL (et PostGIS) sur la machine actuelle pour débloquer, mais il confirmera.
Pour mémoire, la dernière migration d'OS: #12
cc @jocelynj @Marc-marc-marc qui pourrait aider ?
Merci d'avance!