Why do I understand that so well .. :-)Hi Jogchum, Sorry, I did not notice that you had a question for me.
<...>Yes, the steps look roughly correct, possibly except for the part of shutting down the 10.6.10 server. As far as the server is concerned, SIGTERM (signal 15) or SIGQUIT should initiate a shutdown. I would think that on systemd, the preferred way to start and stop services would be the following: systemctl start mariadb systemctl stop mariadb Systemd could actually take the role of mysqld_safe. It could be simplest to start the server directly as "mariadbd" so that nothing will keep restarting it after you initiated the shutdown. If you run the process in the foreground, then ctrl-\ should be SIGQUIT and it should initiate a shutdown. You'd better check with "pgrep mariadbd" or "pgrep mysqld" that nothing is running, both before starting and after shutting down the server. I will clarify the error message. For 10.3 and 10.4, it will look like this: https://github.com/MariaDB/server/commit/9ac8be4e2980aa995117147e39ae5b7ad79fc980 Starting with 10.5, it may additionally suggest to use a version not later than MariaDB 10.4. Starting with 10.8, it may additionally suggest to use a version not later than MariaDB 10.7. With best regards, Marko Mäkelä
Hi Marko,
Thanks a lot!
What happened so far:
On first start of the server by executing "/usr/local/mariadb-10.6.10-linux-systemd-x86_64/bin/mariadbd"as non-root from the command line,
it complained "Can't read dir of '/etc/my.cnf.d"; indeed that dir did not exist.
So I created it as root, and copied /etc/my.cnf to it.
Restarting mariadbd the same way, I got
################################################################################
/usr/local/mariadb-10.6.10-linux-systemd-x86_64/bin/mariadbd
Warning: skipping '!includedir /etc/my.cnf.d' directive as
maximum includerecursion level was reached in file
/etc/my.cnf.d/my.cnf at line 124
2022-11-08 12:06:16 0 [Note]
/usr/local/mariadb-10.6.10-linux-systemd-x86_64/bin/mariadbd
(server 10.6.10-MariaDB-log) starting as process 93785 ...
/usr/local/mariadb-10.6.10-linux-systemd-x86_64/bin/mariadbd:
Can't create file '/var/log/mysql/mysqld.log' (errno: 13
"Permission denied")
2022-11-08 12:06:16 0 [Note] InnoDB: Compressed tables use zlib
1.2.12
2022-11-08 12:06:16 0 [Note] InnoDB: Number of pools: 1
2022-11-08 12:06:16 0 [Note] InnoDB: Using crc32 + pclmulqdq
instructions
2022-11-08 12:06:16 0 [Note] InnoDB: Using Linux native AIO
2022-11-08 12:06:16 0 [Note] InnoDB: Initializing buffer pool,
total size = 134217728, chunk size = 134217728
2022-11-08 12:06:16 0 [Note] InnoDB: Completed initialization of
buffer pool
2022-11-08 12:06:16 0 [Note] InnoDB: Starting crash recovery
from checkpoint LSN=578191755,578191755
2022-11-08 12:06:17 0 [Note] InnoDB: Last binlog file
'./mysql-bin.000067', position 8811365
2022-11-08 12:06:17 0 [Note] InnoDB: 128 rollback segments are
active.
2022-11-08 12:06:17 0 [Note] InnoDB: Removed temporary
tablespace data file: "./ibtmp1"
2022-11-08 12:06:17 0 [Note] InnoDB: Creating shared tablespace
for temporary tables
2022-11-08 12:06:17 0 [Note] InnoDB: Setting file './ibtmp1'
size to 12 MB. Physically writing the file full; Please wait ...
2022-11-08 12:06:17 0 [Note] InnoDB: File './ibtmp1' size is now
12 MB.
2022-11-08 12:06:17 0 [Note] InnoDB: 10.6.10 started; log
sequence number 578191767; transaction id 2935782
2022-11-08 12:06:17 0 [Note] Plugin 'FEEDBACK' is disabled.
2022-11-08 12:06:17 0 [Note] InnoDB: Loading buffer pool(s) from
/home/jogchum/mysql/ib_buffer_pool
2022-11-08 12:06:17 0 [Warning] 'innodb-file-format' was
removed. It does nothing now and exists only for compatibility
with old my.cnf files.
(repeated several times)
2022-11-08 12:06:17 0 [ERROR]
/usr/local/mariadb-10.6.10-linux-systemd-x86_64/bin/mariadbd:
unknown option '--skip-locking'
2022-11-08 12:06:17 0 [ERROR] Aborting
################################################################################
I'm not quite sure if this
would be enough to do the final steps (i.e. remove the 10.6.10
version, and install the Tumbleweed version).
From the fact that innodb reports a crash recovery, I would say
yes
But the last errors make me somewhat unsure?
regards, Jogchum