Vor einem Update von WordPress wollte ich wie gewohnt meine Datenbank sichern:

# mysqldump -u username -p wordpress > wordpress.sql
# mysql -u username -p wordpress_bu_20191113 < wordpress.sql

Leider brach der Import mit der Fehlermeldung "ERROR 1118 (42000) at line 2239: Row size too large (> 8126). Changing some columns to TEXT or BLOB may help. In current row format, BLOB prefix of 0 bytes is stored inline." ab.
Nach kurzer Recherche entschied ich mich für folgenden Workaround:
Setzen der Variable innodb_strict_mode auf OFF in der Datei /etc/mysql/mariadb.conf.d/50-server.cnf:

…
# This group is only read by MariaDB servers, not by MySQL.
# If you use the same .cnf file for MySQL and MariaDB,
# you can put MariaDB-only options here
[mariadb]
# Rana
# Kommentarzeichen entfernen wenn der Fehler
# "ERROR 1118 (42000) at line 2239: Row size too large (> 8126). Changing some columns to TEXT or BLOB may help. In
# current row format, BLOB prefix of 0 bytes is stored inline." auftritt:
#
innodb_strict_mode=OFF
…

Nach der Änderung nicht auf den Neustart der Datenbank-Daemon vergessen!

# systemctl restart mysqld.service

Danach funktionierte der Import ohne Probleme.
Ich habe nach dem Import die Variable in der Konfigurationsdatei /etc/mysql/mariadb.conf.d/50-server.cnf wieder auskommentiert und den Daemon neu gestartet.
Weitere Infos zu dem Thema sind in der Knowledgebase zu MariaDB unter Troubleshooting Row Size Too Large Errors with InnoDB zu finden.

Upgrade

Man vollführe die übliche Upgrade-Prozedur, wie sie z.B. unter https://linuxconfig.org/how-to-upgrade-debian-9-stretch-to-debian-10-buster beschrieben ist. Hier die Kurzform:
Test auf Pakete aus anderen Quellen:

# aptitude search '~i(!~ODebian)'

Update von stretch (= Update aller Pakete in stretch auf die aktuellste Version):

# apt-get update
# apt-get upgrade
# apt-get dist-upgrade

Kontrolle, ob irgendetwas aktuell nicht stimmt:

# dpkg -C

Kontrolle, ob Pakete auf hold stehen:

# apt-mark showhold

Falls etwas aus den letzten beiden Befehlen nicht gepasst hat, hilft vielleicht dies noch weiter:

# dpkg --audit

Am besten ein Backup der aktuellen apt-Quellen machen und danach in der Datei etc/apt/sources.list überall stretch mit buster ersetzen:

# cp /etc/apt/sources.list /etc/apt/sources.list_backup

von stretch:
deb http://httpredir.debian.org/debian stretch main
deb http://httpredir.debian.org/debian stretch-updates main
deb http://security.debian.org stretch/updates main

zu buster:
deb http://httpredir.debian.org/debian buster main
deb http://httpredir.debian.org/debian buster-updates main
deb http://security.debian.org buster/updates main

Simulation des Upgrades:

# apt list --upgradable

Der tatsächliche Upgrade:

# apt-get upgrade
# apt-get dist-upgrade

Am Schluss noch einmal eine Kontrolle:

# aptitude search '~i(!~ODebian)'

Nacharbeiten

So, und jetzt zu den Problemen, die bei mir nach dem Upgrade auftraten:

bind9

bind9 im chroot startet nicht!
Man muss jetzt ein wenig mehr in den Käfig verschieben:

# mkdir -p /var/bind9/chroot/run/named
chown bind:bind /var/bind9/chroot/run/named
…
mkdir -p /var/bind9/chroot/usr/share/dns
cp /usr/share/dns/root.hints /var/bind9/chroot/usr/share/dns/
systemctl restart bind9.service

Zusätzlich muss in der Datei /etc/systemd/system/bind9.service/chroot.conf der Type auf simple umgestellt werden:

[Service]
ExecStart=
ExecStart=/usr/sbin/named -f -u bind -t /var/bind9/chroot
Type=simple

Icinga2

dns-Abfragen, bei denen IPv4 und IPv6 konfiguriert sind, habe ich deaktiviert. Das Plugin schrieb: erwarte IPv4 Adresse, bekomme IPv6 Adresse. Muss ich mich erst einlesen, was da geändert wurde.