Schlagwort: mysql

MariaDB Monitoring-Issue nach Upgrade auf Debian 10

In Folge eines Updates von Debian 9 (Stretch) auf 10 (Buster) kam es zu fehlerhaften Check_MK-Checks:

/omd/sites/monitoring/lib/nagios/plugins/check_mysql -H 192.168.23.42 -u user -p password
/omd/sites/monitoring/lib/nagios/plugins/check_mysql: error while loading shared libraries: libmariadbclient.so.18: cannot open shared object file: No such file or directory

Lösung:

aptitude install libmariadbclient-dev
ln -s /usr/lib/x86_64-linux-gnu/libmariadb.so.3 /usr/lib/x86_64-linux-gnu/libmariadbclient.so.18

Quelle

OTRS – Email to big

Nachdem mir vor kurzem OTRS einige E-Mails nicht mehr abgerufen hat, bin ich auf eder Suche danach, auf ein paar mächtige E-Mails mit PDF-Anhang (Einseiter mit 45MB) gestoßen.
Nachdem unsere Gateways bis zu 100MB zulassen, sollten wir die E-Mails auch irgendwann im Ticketsystem finden. Anbei die Settings, welche angepasst werden müssen:

Postfix auf den E-Mail Gateway und dem OTRS
/etc/postfix/main.cf
message_size_limit = 10240000

Auf dem OTRS-Server
/etc/mysql/my.cnf
max_allowed_packet = 100M

In den OTRS Settings
OTRS:
Sysconfig: Core::PostMaster
PostMasterMaxEmailSize 102400

Dienste neu starten nicht vergessen!

mysqldump nach Wechsel auf mariadb-client sichert nicht mehr

Nach einem kurzfristigen Wechsel von mysql-client-5.x auf mariadb-client-10.x (via default-mysql-client) auf Debian Stretch wollte mysqldump keine Daten eines MySQL-Servers (5.1.73-1) mehr sichern:

root@backup:/backup/# mysqldump -h server1 -u backup -p -v database1
Enter password:
-- Connecting to server1...
-- MySQL dump 10.16 Distrib 10.1.23-MariaDB, for debian-linux-gnu (x86_64)
--
-- Host: server1 Database: database1
-- ------------------------------------------------------
-- Server version 5.1.73-1


/*!40101 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */;
/*!40101 SET @OLD_CHARACTER_SET_RESULTS=@@CHARACTER_SET_RESULTS */;
/*!40101 SET @OLD_COLLATION_CONNECTION=@@COLLATION_CONNECTION */;
/*!40101 SET NAMES utf8mb4 */;
/*!40103 SET @OLD_TIME_ZONE=@@TIME_ZONE */;
/*!40103 SET TIME_ZONE='+00:00' */;
/*!40014 SET @OLD_UNIQUE_CHECKS=@@UNIQUE_CHECKS, UNIQUE_CHECKS=0 */;
/*!40014 SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0 */;
/*!40101 SET @OLD_SQL_MODE=@@SQL_MODE, SQL_MODE='NO_AUTO_VALUE_ON_ZERO' */;
/*!40111 SET @OLD_SQL_NOTES=@@SQL_NOTES, SQL_NOTES=0 */;
-- Retrieving table structure for table table1...
-- Skipping dump data for table 'table1', it has no fields

Ursache ist das in /etc/mysql/mariadb.conf.d/50-client.cnf angegebene Character-Set utf8mb4, welches nach dem Paketwechsel standardmäßig verwendet wird und den früheren Standardwert des mysql-client-Paketes (utf8) ablöste:

[client]
# Default is Latin1, if you need UTF-8 set this (also in server section)
default-character-set = utf8mb4

Da der zu sichernde MySQL-Server utf8mb4 nicht unterstützt,  führte die Änderung von default-character-set auf utf8 zur Lösung und nun wieder vollständigen Datenbank-Backups mittels mysqldump.

Der eingangs genante Paketwechsel erwies sich also als recht tückisch, da ab diesem Zeitpunkt keine MySQL-Backups mehr erzeugt wurden, die Sicherung jedoch keinerlei Fehler aufzeigte. Das Backupskript lief erfolgreich durch und es wurden stets neue Backupfiles erzeugt, jedoch alle Tabellen beim Sichern der Inhalte übersprungen („Skipping dump data…“). Nur durch ein manuelles Prüfen der erzeugten Backupfiles fiel auf, dass das Backup nicht mehr funktionsfähig war.