LXC mysql - jede Nacht defekt

[bforpc]

Hallo,
zum Glück gibts snapshots ;-)
Ich muss jeden morgen ein Snapshot zurückrollen, weil mir die mariadb Datenbank eines LXCV Containers am nächsten Tag nicht mehr brauchbar ist.
Die Fehlermeldungen ranken sich immer wieder um apparmor.
Mein Conf Datei sieht so aus:

arch: amd64
cores: 4
hostname: web
memory: 1024
nameserver: 192.168.5.101
net0: name=eth0,bridge=vmbr1,gw=192.168.5.101,hwaddr=2A:E3:F4:17:B1:A0,ip=192.168.5.205/24,type=veth
onboot: 1
ostype: debian
rootfs: store:subvol-205-disk-1,size=32G
swap: 512
lxc.apparmor.profile=unconfined
lxc.cgroup.devices.allow=a
lxc.mount.auto=proc:rw sys:ro cgroup:ro
#lxc.kmsg=0
lxc.autodev=1

Der container lief bis vor ein paar Wochen problemlos seit mehr als einem Jahr. Ist eventuell mariadb nicht (mehr) Containerfähig?
bfo

 

[tom]

welche fehlermeldungen? geht der ram aus?

 

[foxpalace]

Hi,
vor allen Dingen sind Logs der MariaDB interessant - seit ich mit meiner MariaDB von VMware weg zu Proxmox bin, habe ich keine Probleme mehr - unter VMware war die ständig tot - Stichwort Ballooning. Gerade bei Datenbanken (egal welche) gibt es sehr viele Fallstricke in einer virtuellen Umgebung - hier ist eigentlich Best Practice -> eigenes Blech!
Mir hat mal jemand gesagt, dass er MySQL/MariaDB mit ZFS-Snapshots sichert - bei jeder Mysql/MariaDB muss der Innodb_buffer_pool_pages_dirty leer sein - NUR dann hast du eine funktionierende Sicherung

 

[bforpc]

Hallo,

Hier das Log von heute morgen.
Es wiederholt sich alle paar Sekunden.

tail -f /var/log/mysql/error.log

2017-11-27  8:02:42 140638571270720 [Note] InnoDB: innodb_empty_free_list_algorithm has been changed to legacy because of small buffer pool size. In order to use backoff, increase buffer pool at least up to 20MB.

2017-11-27  8:02:42 140638571270720 [Note] InnoDB: Using mutexes to ref count buffer pool pages
2017-11-27  8:02:42 140638571270720 [Note] InnoDB: The InnoDB memory heap is disabled
2017-11-27  8:02:42 140638571270720 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
2017-11-27  8:02:42 140638571270720 [Note] InnoDB: GCC builtin __atomic_thread_fence() is used for memory barrier
2017-11-27  8:02:42 140638571270720 [Note] InnoDB: Compressed tables use zlib 1.2.8
2017-11-27  8:02:42 140638571270720 [Note] InnoDB: Using Linux native AIO
2017-11-27  8:02:42 140638571270720 [Note] InnoDB: Using SSE crc32 instructions
2017-11-27  8:02:42 140638571270720 [Note] InnoDB: Initializing buffer pool, size = 128.0M
2017-11-27  8:02:42 140638571270720 [Note] InnoDB: Completed initialization of buffer pool
2017-11-27  8:02:42 140638571270720 [Note] InnoDB: Highest supported file format is Barracuda.
2017-11-27  8:02:42 140638571270720 [Note] InnoDB: Starting crash recovery from checkpoint LSN=92475379
2017-11-27  8:02:42 140638571270720 [Note] InnoDB: Restoring possible half-written data pages from the doublewrite buffer...
InnoDB: 2 transaction(s) which must be rolled back or cleaned up
InnoDB: in total 0 row operations to undo
InnoDB: Trx id counter is 140544
2017-11-27  8:02:42 140638571270720 [Note] InnoDB: Starting final batch to recover 10 pages from redo log
InnoDB: Cleaning up trx with id 140121
2017-11-27 08:02:43 7fe8f8151240  InnoDB: Assertion failure in thread 140638571270720 in file trx0trx.cc line 468
InnoDB: Failing assertion: trx->update_undo == NULL
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: http://dev.mysql.com/doc/refman/5.6/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
171127  8:02:43 [ERROR] mysqld got signal 6 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.

To report this bug, see https://mariadb.com/kb/en/reporting-bugs

We will try our best to scrape up some info that will hopefully help
diagnose the problem, but since we have already crashed,
something is definitely wrong and this may fail.

Server version: 10.1.26-MariaDB-0+deb9u1
key_buffer_size=16777216
read_buffer_size=131072
max_used_connections=0
max_threads=153
thread_count=0
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 352445 K  bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

Thread pointer: 0x0
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
stack_bottom = 0x0 thread_stack 0x30000
/usr/sbin/mysqld(my_print_stacktrace+0x2e)[0x55566218b36e]
/usr/sbin/mysqld(handle_fatal_signal+0x3bd)[0x555661cd0a4d]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x110c0)[0x7fe8f7dbd0c0]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0xcf)[0x7fe8f66b7fcf]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x16a)[0x7fe8f66b93fa]
/usr/sbin/mysqld(+0x929c12)[0x555662057c12]
/usr/sbin/mysqld(+0x91f1b5)[0x55566204d1b5]
/usr/sbin/mysqld(+0x87c6df)[0x555661faa6df]
/usr/sbin/mysqld(+0x90ae06)[0x555662038e06]
/usr/sbin/mysqld(+0x8214ef)[0x555661f4f4ef]
/usr/sbin/mysqld(_Z24ha_initialize_handlertonP13st_plugin_int+0x66)[0x555661cd2b86]
/usr/sbin/mysqld(+0x422e55)[0x555661b50e55]
/usr/sbin/mysqld(_Z11plugin_initPiPPci+0x7da)[0x555661b5248a]
/usr/sbin/mysqld(+0x37afa3)[0x555661aa8fa3]
/usr/sbin/mysqld(_Z11mysqld_mainiPPc+0x1a0d)[0x555661aac78d]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf1)[0x7fe8f66a52b1]
/usr/sbin/mysqld(_start+0x2a)[0x555661aa0c4a]
The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
information that should help you find out what is causing the crash.

 

[bforpc]

Hat keiner eine Idee?

 

[bforpc]

Ich habe die CT jetzt gelöscht und eine VM angelegt und alle Daten migriert.
Somit ist zwar das Problem der CT nicht gelöst, aber ich kann wieder auf die Datenbank zugreifen ohne angst haben zu müssen, dass sie am nächsten tag nicht mehr antwortet.

Bfo

 

[Oliver R]

Hi bforpc!

Ich kann dir nur Raten den MySQL Server nicht zu virtualisiersen. Es gibt viele Debatten darüber, aber meiner Meinung nach ist es das Beste sich dedizierte Hardware zu organisieren. Notfalls würde ich eine KVM Maschine oder eventuell Docker, welches ich bisher noch nicht ausgiebig getestet habe, nutzen. Mit LXC oder OpenVZ hatte ich immer Probleme, deswegen nutze ich sie nur zu schnellen Testzwecken.

 

[bforpc]

Naja, ... dedizierte HW zu nutzen ist doch (reusper) heute nicht mehr effizient. Mag sein, dass es für große und sehr große Datenbanekn bessere Lösung gibt, aber im kleinen "Massenmarkt" ist das doch Perlen vor die Säue.
Ich kann nicht bestätigen, dass LXC dafür nicht geeignet sei. Ein anderer mysql Server läuft seit 3 Jahren stabil und problemlos unter LXC.
Vielleicht liegts ja auch nur an dem mariaDB - jetzt habe ich wieder mysql im Einsatz.

 

[Oliver R]

Stimmt es ist Geldverschwendung, aber ich kann nicht sagen für welchen Anwendungsbereich du es brauchst. Privat nutze ich eine KVM Maschine, weil die Abfragen auch gering sind. Aber in einem größeren Betrieb mit vielen Abfragen sollte die IO Rate schon ziemlich hoch sein. Von MariaDB halte ich derzeit sowie so nichts, denn für meine Nutzung reicht mir MySQL voll und ganz.