Can we upgrade the mariadb of zimbra mailstore - running on 10.1.5

[zimuzer]

Hi, is it possible to upgrade the mariadb version, current is "Server version: 10.1.25-MariaDB". Reason for asking is, we encountered some issue when we created a trigger insert on the mboxgroup database, but it keeps crashing the db, on 10.1.5, but we have no issue on older zimbra like 8.8.x. Found some suggestion on mariadb forum to upgrade. How can we upgrade in case it's possible.



Version: '10.1.25-MariaDB' socket: '/opt/zimbra/data/tmp/mysql/mysql.sock' port: 7306 Zimbra MariaDB binary distribution
250303 5:37:27 [ERROR] mysqld got signal 11 ;
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.25-MariaDB
key_buffer_size=134217728
read_buffer_size=31997952
max_used_connections=1
max_threads=112
thread_count=1
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 7133133 K bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

Thread pointer: 0x55c68edee008
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 = 0x7ff264a60138 thread_stack 0x48400
*** buffer overflow detected ***: terminated
Fatal signal 6 while backtracing
250303 05:37:28 mysqld_safe Number of processes running now: 0
250303 05:37:28 mysqld_safe mysqld restarted
2025-03-03 5:37:28 140582914166464 [Note] /opt/zimbra/common/sbin/mysqld (mysqld 10.1.25-MariaDB) starting as process 3415906 ...
2025-03-03 5:37:28 140582914166464 [Note] InnoDB: Using mutexes to ref count buffer pool pages
2025-03-03 5:37:28 140582914166464 [Note] InnoDB: The InnoDB memory heap is disabled
2025-03-03 5:37:28 140582914166464 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
2025-03-03 5:37:28 140582914166464 [Note] InnoDB: GCC builtin __atomic_thread_fence() is used for memory barrier
2025-03-03 5:37:28 140582914166464 [Note] InnoDB: Compressed tables use zlib 1.2.3
2025-03-03 5:37:28 140582914166464 [Note] InnoDB: Using Linux native AIO
2025-03-03 5:37:28 140582914166464 [Note] InnoDB: Using SSE crc32 instructions
2025-03-03 5:37:28 140582914166464 [Note] InnoDB: Initializing buffer pool, size = 3.2G
2025-03-03 5:37:28 140582914166464 [Note] InnoDB: Completed initialization of buffer pool
2025-03-03 5:37:28 140582914166464 [Note] InnoDB: Highest supported file format is Barracuda.
2025-03-03 5:37:28 140582914166464 [Note] InnoDB: The log sequence number 64012642 in ibdata file do not match the log sequence number 69135189 in the ib_logfiles!
2025-03-03 5:37:29 140582914166464 [Note] InnoDB: Restoring possible half-written data pages from the doublewrite buffer...
2025-03-03 5:37:30 140582914166464 [Note] InnoDB: 128 rollback segment(s) are active.
2025-03-03 5:37:30 140582914166464 [Note] InnoDB: Waiting for purge to start
2025-03-03 5:37:30 140582914166464 [Note] InnoDB: Percona XtraDB (http://www.percona.com) 5.6.36-82.0 started; log sequence number 69135189
2025-03-03 5:37:30 140579148187200 [Note] InnoDB: Dumping buffer pool(s) not yet started
2025-03-03 5:37:30 140582914166464 [Note] Plugin 'FEEDBACK' is disabled.
2025-03-03 5:37:30 140582914166464 [Note] Recovering after a crash using tc.log
2025-03-03 5:37:30 140582914166464 [Note] Starting crash recovery...
2025-03-03 5:37:30 140582914166464 [Note] Crash recovery finished.
2025-03-03 5:37:30 140582914166464 [Note] Server socket created on IP: '127.0.0.1'.
2025-03-03 5:37:30 140582914166464 [Note] /opt/zimbra/common/sbin/mysqld: ready for connections.
Version: '10.1.25-MariaDB' socket: '/opt/zimbra/data/tmp/mysql/mysql.sock' port: 7306 Zimbra MariaDB binary distribution
250303 5:38:28 [ERROR] mysqld got signal 11 ;
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.

[umashankar.avagadda]

Could you please provide more details about the issue you encountered when creating an insert trigger on the mboxgroup database? It would be helpful if you could share the steps to reproduce the problem and the operating system details you're using.

[zimuzer]

Ok, we created a trigger on all of the mboxgroup (1 to 100) database of specific mstore. (multi server setup)

# Trigger 1 - prevent_deleteMail < this prevents user from deleting the message. (deletion will be done by the zimbra retention policy)

DELIMITER //
CREATE TRIGGER prevent_deleteMail
BEFORE UPDATE
ON mail_item
FOR EACH ROW
BEGIN
IF (NEW.folder_id = 3) THEN
SIGNAL SQLSTATE '23000' SET MESSAGE_TEXT = 'Cannot Delete Mail';
END IF;
END//
DELIMITER ;


#Trigger 2 - prevent_draft_and_newFolder < this prevent user on the modified mstore to create new folder and save to draft, or attach file.

DELIMITER //
Create trigger prevent_draft_and_newFolder
AFTER insert
on mail_item
FOR EACH ROW BEGIN
if (new.folder_id = 6) Then
delete from mail_item where folder_id = 6 and mailbox_id = new.mailbox_id;
end if;
if (new.type = 1 and new.mod_metadata <> 1) then
delete from mail_item where type=1 and mod_metadata<>1 and mailbox_id=new.mailbox_id;
end if;
end//
DELIMITER ;


So these functions well on 8.8.x, no issue, mysql does not crash, but on the latest zimbra 10.1.5 (zextras build) Ubuntu 22.04, there are instances that it crashed, and to the point that zimbra user webmail cannot be loaded, every time it attempt to load, mysql crashed. The work around is to find the mboxgroup assigned to the user and issue the command 'delimiter ;' or simply restoring the default delimiter, and the database will normalize. Odd, but, im not a DB expert, so maybe someone here can replicate and fix.. the function of the trigger works only on webmail, so its useful for specific requirement on a zimbra admin perspective.

[lauralordelaure]

Is it feasible to deploy the trigger only on another MariaDB replica (not the primary mailstore) for non-critical processes like analytics or logging?

[miloz]

Looks like the trigger crash is tied to Zimbra’s patched MariaDB build. I’d test on a staging box before touching production, just to see if the issue repeats.youtube vanced