Feed Aggregator

Sources:

• RSyslog Documentation
• How to Configure Remote Logging with Rsyslog on Ubuntu 18.04

This notes are intended for Ubuntu 18.04!

Install and Configure Rsyslog Server

dpkg -l | grep rsyslogd
apt-get update && apt-get install rsyslog

systemctl start rsyslog
systemctl enable rsyslog
systemctl status rsyslog

Check rsyslog version (v7 vs. v8!):

rsyslogd -v

General configuration

#
# /etc/rsyslog.conf
#

# provides UDP syslog reception
module(load="imudp")
input(type="imudp" port="514")

and/or

# provides TCP syslog reception
module(load="imtcp")
# RPC service is using this port as well.
input(type="imtcp" port="50514")

Restrictions:

# GLOBAL DIRECTIVES

$AllowedSender UDP, 192.168.1.0/24, [::1]/128, *.fromdual.com
$AllowedSender UDP, 192.168.56.0/24, [::1]/128, *.fromdual.com

$AllowedSender TCP, 192.168.1.0/24, [::1]/128, *.fromdual.com
$AllowedSender TCP, 192.168.56.0/24, [::1]/128, *.fromdual.com

Specific configuration:

#
# …

FromDual has the pleasure to announce the release of the new version 1.2.0 of its popular Database Performance Monitor for MariaDB and Galera Cluster fpmmm.

The FromDual Performance Monitor for MariaDB (fpmmm) enables DBAs and System Administrators to monitor and understand what is going on inside their MariaDB database instances and on the machines where the databases reside.

More detailed information you can find in the fpmmm Installation Guide.

Download

The new FromDual Performance Monitor for MariaDB (fpmmm) can be downloaded from here or you can use our FromDual repositories. How to install and use fpmmm is documented in the fpmmm Installation Guide.

In the inconceivable case that you find a bug in the FromDual Performance Monitor for MariaDB please report it to the FromDual Bug-tracker or just send us an [email](mailto:contact@fromdual.com?Subject=Bug report for fpmmm).

Any feedback, statements and testimonials are welcome as well! Please send them [to us](mailto:feedback@fromdual.com?Subject=Feedback …

Trx # 86153878218 exists in both Galera Cluster conflics which are 46 seconds apart (= long running transaction?). Table `rt3`.`Tickets` seems to be involved in both cases. One should investigate also in this query or transaction we cannot see here...

MySQL thread id 6147, OS thread handle 0x7f5af77fe700, query id 5394536 192.168.1.42 node1
*** WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 67799 page no 2924419 n bits 136 index `PRIMARY` of table `rt3`.`Tickets` trx id 86153787673 lock_mode X locks rec but not gap
2020-06-09 08:27:24 9737 [Note] WSREP: cluster conflict due to high priority abort for threads:
2020-06-09 08:27:24 9737 [Note] WSREP: Winning thread:
   THD: 26, mode: applier, state: executing, conflict: no conflict, seqno: 1297074501
   SQL: (null)
2020-06-09 08:27:24 9737 [Note] WSREP: Victim thread:
   THD: 6147, mode: local, state: executing, conflict: no conflict, seqno: -1
   SQL: SELECT main.* FROM Attributes main  WHERE (main.ObjectId = 3137700935) AND …

Very often I see some stupid error messages as a (power-)user. I do not know if this is because of lazy developers or managers not having enough focus on more useful error messages.

If the error messages would be more clear it would help me as a power-user to fix my problems faster and fix it possibly myself instead of asking questions or even open support cases.

That would also safe costs on the support service side if end-users would be enabled to fix their problems themself. If this is what software vendors really want…

Sometimes strace helps to understand the problem. But why do I need external tools to do the job?

Some examples

Bad: Could not add A-record.

Better: Could not add A-record lamp-database.org because it already exists.

Bad: Error 2.

OK I can help myself with:

perror 2
OS error code   2:  No such file or directory

but still bad.

Better: No such file or directory. File I was looking for: /tmp/doesnotexist.txt

Unique Error Code Policy

FromDual has introduced a unique error code policy: …

FromDual has the pleasure to announce the release of the new version 1.0.0 of its popular FromDual Ops Center focmm, a Graphical User Interface (GUI) for MySQL and compatible databases.

The FromDual Ops Center for MySQL and compatible databases (focmm) helps DBA’s and System Administrators to better manage their MySQL and compatible databases farms. Ops Center makes DBA and Admins life easier!

The main task of Ops Center is to support you in your daily MySQL and compatible databases operation tasks. More information about FromDual Ops Center you can find here.

Download

The new FromDual Ops Center for MySQL and compatible databases (focmm) can be downloaded from here. How to install and use focmm is documented in the Ops Center User Guide.

In the inconceivable case that you find a bug in the FromDual Ops Center for MySQL and compatible databases please report it to the FromDual bug tracker or just send us an [email](mailto:contact@fromdual.com?Subject=Bug report for focmm).

Any feedback, statements and …

cd /var/log
ll -d -Z mysql* mysql/*
mkdir mysql
chown mysql: mysql
semanage fcontext -a -t mysqld_db_t "/var/log/mysql/(/.*)?"
restorecon -Rv /var/log/mysql
ll -d -Z mysql* mysql/*

And Non-standard database set up with SELinux

/usr/sbin/logrotate /etc/logrotate.conf

On StackExchange for Database Administrators I recently have seen a question which attracted my interest.

The question puzzled me a bit because the answer seems too easy. Further the question was not so clear. An all theses factors smell dangerous…

About time - was, is and will be

How can I find out if the database “was” shutdown slowly? This is quite easy: Look into your MySQL Error Log and there you will find a log sequence similar to the following:

2020-03-30T08:03:36.928017Z 0 [System] [MY-010910] [Server] /home/mysql/product/mysql-8.0.19-linux-glibc2.12-x86_64/bin/mysqld: Shutdown complete (mysqld 8.0.19)  MySQL Community Server - GPL.

Ups! There are no more “shutting down …” messages like in MySQL 5.7:

2020-03-30T08:04:49.898254Z 0 [Note] Giving 1 client threads a chance to die gracefully
2020-03-30T08:04:49.898266Z 0 [Note] Shutting down slave threads
2020-03-30T08:04:51.898389Z 0 [Note] Forcefully disconnecting 1 remaining clients
2020-03-30T08:04:51.898433Z 0 …

The InnoDB deadlock detector was rewritten in MySQL 5.7.1, in a merge commit that does not mention any WL or bug number, nor any reviewer. I did not review those changes, and I cannot say whether the algorithmic complexity of the deadlock checker was reduced. Possibly the rewrite replaced procedural recursion with iteration over a data structure that explicitly represents a stack.

I think that the InnoDB locking performance could be significantly improved by extending the use of implicit locking to UPDATE and DELETE operations, as noted in MDEV-16232. It could also be helpful to merge multiple record log bitmaps into a single bitmap per page, with 4 bits per record, as noted in MDEV-16406.

Marko Mäkelä, Lead Developer InnoDB
MariaDB Corporation

• fpmmm 2.2.1 Release Notes, Release Date: 13 February 2026
• fpmmm 2.2.0 Release Notes, Release Date: 4 September 2025 → see v2.2.1
• fpmmm 2.1.0 Release Notes, Release Date: 5 December 2023
• fpmmm 2.0.0 Release Notes, Release Date: 18 May 2022
• fpmmm 1.2.0 Release Notes, Release Date: 11 June 2020
• fpmmm 1.1.0 Release Notes, Release Date: 17 December 2019
• fpmmm 1.0.2 Release Notes, Release Date: 7 March 2019
• fpmmm 1.0.1 Release Notes, Release Date: 9 February 2017
• fpmmm 1.0.0 Release Notes, Release Date: 2 October 2016
• fpmmm 0.10.9 Release Notes, Release Date: 17 August 2016
• fpmmm 0.10.6 Release Notes, Release Date: 2 August 2016
• fpmmm 0.10.5 Release Notes, Release Date: 31 July 2015
• fpmmm 0.10.4 Release Notes, Release Date: 16 May 2015
• fpmmm 0.10.3 Release Notes, Release Date: 1 May 2015
• fpmmm 0.10.2 Release Notes, Release Date: 30 April 2015
• fpmmm 0.10.1 Release Notes, Release Date: 19 April 2015
• fpmmm 0.10.0 Release Notes, Release Date: 16 April 2015
• fpmmm 0.9.3 Release Notes, Release Date: 24 May 2014
• fpmmm …

Recently we had a new customer who has had from time to time massive database problems which he did not understand. When we reviewed the MySQL configuration file (my.cnf) we found, that this customer had disabled the InnoDB Deadlock detection (innodb_deadlock_detect).

Because we have advised against doing this so far, but I never stumbled upon this problem in practice, I have investigated a bit more about the MySQL variable innodb_deadlock_detect.

The MySQL documentation tells us the following
[1
]:

Disabling Deadlock Detection On high concurrency systems, deadlock detection can cause a slowdown when numerous threads wait for the same lock. At times, it may be more efficient to disable deadlock detection and rely on the innodb_lock_wait_timeout setting for transaction rollback when a deadlock occurs. Deadlock detection can be disabled using the innodb_deadlock_detect configuration option.

And about the parameter innodb_deadlock_detect itself
[2
] itself:

This option is used to disable deadlock detection. On …

MariaDB/MySQL Stored Language is called SQL/PSM.
There are 4 different types of Stored Language: Stored Procedures, Stored Functions, Triggers and Events.

Stored Procedures

Stored Procedure with a Cursor:

DELIMITER //
CREATE PROCEDURE cleanup(IN pData VARCHAR(48))
BEGIN
  DECLARE vId INTEGER;
  DECLARE vNotFound INTEGER;

  DECLARE cCleanUp CURSOR FOR
    SELECT id FROM test WHERE data = pData;

  DECLARE CONTINUE HANDLER FOR NOT FOUND
    SET vNotFound = 1;
  
  OPEN cCleanUp;
  lGetRecord: LOOP
  
    FETCH cCleanUp INTO vId;
    IF vNotFound = 1 THEN 
      LEAVE lGetRecord;
    END IF;
  
    DELETE FROM test WHERE id = vId;
  END LOOP lGetRecord;
  CLOSE cCleanUp;
END //
DELIMITER ;

CALL cleanup('Bla1Trx');

Stored Procedure with SUPER PRIVILEGE

Disabling binary log on a per session base requires the SUPER privilege:

SQL> SET SESSION sql_log_bin = off;
ERROR 1227 (42000): Access denied; you need (at least one of) the SUPER privilege(s) for this operation

If you do NOT want to GRANT the SUPER …

On 1 March 2020 FromDual became 10 years old! Sincere thanks are given to all our customers, partners and interested person for their support and good cooperation in the last 10 years. And we would be pleased to advise and support you again competently in the coming 10 years.

Your FromDual Team

Picture by kalhh on Pixabay

Recently we migrated a database system from MySQL 5.7 to MariaDB 10.3. Everything went fine so far just the following message started to pop-up in the MariaDB Error Log File with the severity Note:

InnoDB: page_cleaner: 1000ms intended loop took 4674ms. The settings might not be optimal. (flushed=102 and evicted=0, during the time.)

I remember that this message also appeared in earlier MySQL 5.7 releases but somehow disappeared in later releases. I assume MySQL has just disabled the Note?

You can find various advices in the Internet about how to get rid of this Note:

innodb_lru_scan_depth        = 1024, 256
innodb_buffer_pool_instances = 1, 8
innodb_io_capcity            = 100, 200 or 1000
innodb_page_cleaners         = 1, 4 or 8

But non of these changes made the Note go away in our case. I only found one voice claiming it could be an external reason which makes this message appear. Because we are actually running on a Cloud-Machine the appearance of this message could really be an effect of the Cloud and …

FromDual has the pleasure to announce the release of the new version 0.9.3 of its popular FromDual Ops Center focmm, a Graphical User Interface (GUI) for MariaDB and MySQL.

The FromDual Ops Center for MariaDB and MySQL (focmm) helps DBA’s and System Administrators to better manage their MariaDB and MySQL database farms. Ops Center makes DBA and Admins life easier!

The main task of Ops Center is to support you in your daily MySQL and MariaDB operation tasks. More information about FromDual Ops Center you can find here.

Download

The new FromDual Ops Center for MariaDB and MySQL (focmm) can be downloaded from here. How to install and use focmm is documented in the Ops Center User Guide.

In the inconceivable case that you find a bug in the FromDual Ops Center for MariaDB and MySQL please report it to the FromDual bug tracker or just send us an [email](mailto:contact@fromdual.com?Subject=Bug report for focmm).

Any feedback, statements and testimonials are welcome as well! Please send them to …

When it comes to MariaDB/MySQL Database consulting engagements we often see, that our customers are very confused by many different technologies advertised to them.

Below you will find some simple concepts and ideas we use during our consulting engagements to solve some issues and answer some questions.

General problem solving approach

• 1
  . Written description of the problem to solve. This helps to learn about your problem and better understand your problem.
• 2
  . Searching for a suitable method, technology or architecture solving the described problem.
• 3
  . Evaluating a product or solution which is specialised solving the described problem. Check if the product/solution matches your problem.
  Caution: In this topic we are strongly MariaDB/MySQL biased!
• 4
  . Do a Proof of Concept (PoC) to verify the chosen solution will fix your described problem (or not).

Splitting Database Tables (BLOB/TEXT)

Sometimes it might be useful to split 1 entity (table) into 2 separate tables. This makes sense when you have either:

• hot …

FromDual has the pleasure to announce the release of the new version 1.1.0 of its popular Database Performance Monitor for MariaDB, MySQL and Galera Cluster fpmmm.

The FromDual Performance Monitor for MariaDB and MySQL (fpmmm) enables DBAs and System Administrators to monitor what is going on inside their MariaDB and MySQL databases and on their machines where the databases reside.

More detailed information your can find in the fpmmm Installation Guide.

Download

The new FromDual Performance Monitor for MariaDB and MySQL (fpmmm) can be downloaded from here. How to install and use fpmmm is documented in the fpmmm Installation Guide.

In case you find a bug in the FromDual Performance Monitor for MariaDB and MySQL please report it to the FromDual Bugtracker or just send us an [email](mailto:contact@fromdual.com?Subject=Bug report for fpmmm).

Any feedback, statements and testimonials are welcome as well! Please send them [to us](mailto:feedback@fromdual.com?Subject=Feedback for fpmmm “Feedback for …

You are using an old version of the FromDual Performance Monitor for MariaDB and MySQL (fpmmm). Please consider using a more recent version.

Your InnoDB Redo Log Buffer is too small for large transactions. Make the InnoDB Redo Log Buffer (innodb_log_buffer_size) bigger if you have enough RAM available to avoid additional I/O.
1 Mibyte is good for databases with small transactions. 8 Mibyte is good for medium size transactions. 64 MiByte is good for large transactions.

See also for MariaDB MySQL.