Skip to main content

!Friendica Support

Wenn ich die Datenbank von Friendica mit mysqldump sichere, krieg ich regelmäßig folgende Fehlermeldung:

mysqldump: Error 1412: Table definition has changed, please retry transaction when dumping table `delivery-queue` at row: 0
]

Den genauen Befehl im Script hab ich so gewählt:

mysqldump -u root --single-transaction --routines --default-character-set=utf8mb4 --triggers  friendica

Das ganze wird dann über gzip gepiped und dann mittels restic in einen S3-Minio-Objektspeicher geschrieben.
Es werden grad mal 1,8GB von 19GB gesichert.

Was kann das sein?

!Friendica Support
This entry was edited (2 years ago)
Michael 🇺🇦
Michael 🇺🇦  
•
Verwende am Besten mariabackup. Das hat diese Probleme nicht.
elrido
elrido  
•

Ich habe kürzlich die Option "Optimiere die Tabellen regelmäßig" (unter Administration, Konfiguration, Seite, Performance) eingeschaltet und diese Meldung während meines dumps erhalten. Habe das nun wieder ausgeschaltet und kriege die Meldung von mysqldump nicht mehr.

Ich nehme an die Option löst ab und an so was wie ein "optimize table" auf diese Tabellen aus, was wohl das laufende mysqldump irritiert?

jakob 🇦🇹 ✅
jakob 🇦🇹 ✅  
•
@elrido
Diese Option hab ich in der Tat auch aktiviert.
Ich schau mir mal maria-backup an.
@elrido
Montag
Montag  
•
@elrido @jakob 🇦🇹 ✅ bei #Uberspace hat diese Option das automatische sichern der Tabellen durch Uberspace verhindert, deshalb habe ich die Option bei mir deaktiviert.
#uberspace @elrido @jakob 🇦🇹 ✅
jakob 🇦🇹 ✅
jakob 🇦🇹 ✅  
•

@Montag

@Michael Vogel hat marua-backup für die mariadb empfohlen.
Ich sichere gerade die ganze DB (da sind noch zwei weitere Services auf der Server) damit und schick es über restic zum minio-server.

Das war zuvor mit mysqldump, gzip und direktes schreiben auf das gempuntete Backup-Laufwerk auch schon langsam.

Momentan stell ich grad auf server-initiated backups und restic/minio um.

Für jeden zu sichernden Server gibts eigene Credentials für Minio (Service Account) mit expiry von wenigen Stunden. Und diese credentials übertrage ich per Umgebungsvariable mit der ssh, wenn sich der Backupserver mit dem zu sichernden Host verbindet.

Angriffsfläche klein halten. ☺️

Schaut bislang ganz gut aus.

@elrido

@Michael 🇺🇦 @Montag @elrido
Michael 🇺🇦
Michael 🇺🇦  
•
Da gehe ich von aus. Aber wenn Du einige der Tabellen nicht regelmäßig optimierst, wird sich die Performance Deines Systems schleichend verschlechtern.
Montag
Montag  
•
@Michael Vogel ich starte eine Optimierenung der Tabellen von Zeit zu Zeit manuell.
@Michael 🇺🇦
jakob 🇦🇹 ✅
jakob 🇦🇹 ✅  
•

@Michael Vogel das ist jetzt der outcome von maria-backup

Files:           1 new,     0 changed,     0 unmodified
Dirs:            2 new,     0 changed,     0 unmodified
Added to the repository: 38.337 GiB (9.509 GiB stored)

processed 1 files, 40.501 GiB in 1:04:20

das versteh ich aber nicht. Ich hab diesen Befehl verwendet
mariadb-backup --user=root --backup --stream=xbstream 2>/data/mariadb-backup.log | restic backup --stdin --stdin-filename mariadb.xb --tag MariaDB
Sind xbstreams wirklich so viel kleiner, als die Datenbank selbst?
Weil komprimiert wurde nix.
Ich versteh das ganze System noch nicht ganz.

@Michael 🇺🇦
jakob 🇦🇹 ✅
jakob 🇦🇹 ✅  
•

@Michael Vogel

Noch spannender...
einmal mit mariadb-dump (das nc.sql file) und einmal mit xbstream (das nc.xb-file) der nextcloud-datenbank (die friendica ist zu groß für einen schnellen schuss)

-rw-r--r--   1 root     root     183M Nov  3 13:47 nc.sql
-rw-r--r--   1 root     root     1.9G Nov  3 13:45 nc.xb

Und in mariadb wird mir angezeigt, dass die nextcloud-datenbank 359MB groß ist...

alles sehr spooky

hab versucht jetzt die friendica-datenbank direkt mit mariadb-dump auf die platte zu dumpen... da geht mir dann der server in die knie und friendica reagiert nicht mehr.

@Michael 🇺🇦
⇧