Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Not a Bug
-
10.5.10
-
None
-
CentOS + Windows NAS
Description
mariabackup --backup works well, however it fails on --prepare stage.
[root@XXX XXX]# mariadb-backup --prepare --target-dir=/mnt/backup/XXX/mariadb/$dt |
mariadb-backup based on MariaDB server 10.5.10-7-MariaDB Linux (x86_64) |
[00] 2021-10-06 19:21:30 cd to /mnt/backup/XXX/mariadb/202110061912/ |
[00] 2021-10-06 19:21:30 open files limit requested 0, set to 1024 |
[00] 2021-10-06 19:21:31 This target seems to be not prepared yet. |
[00] 2021-10-06 19:21:31 mariabackup: using the following InnoDB configuration for recovery: |
[00] 2021-10-06 19:21:31 innodb_data_home_dir = . |
[00] 2021-10-06 19:21:31 innodb_data_file_path = ibdata1:12M:autoextend |
[00] 2021-10-06 19:21:31 innodb_log_group_home_dir = . |
[00] 2021-10-06 19:21:31 InnoDB: Using Linux native AIO |
[00] 2021-10-06 19:21:31 Starting InnoDB instance for recovery. |
[00] 2021-10-06 19:21:31 mariabackup: Using 104857600 bytes for buffer pool (set by --use-memory parameter) |
2021-10-06 19:21:31 0 [Note] InnoDB: Uses event mutexes |
2021-10-06 19:21:31 0 [Note] InnoDB: Compressed tables use zlib 1.2.11 |
2021-10-06 19:21:31 0 [Note] InnoDB: Number of pools: 1 |
2021-10-06 19:21:31 0 [Note] InnoDB: Using crc32 + pclmulqdq instructions |
2021-10-06 19:21:31 0 [Note] InnoDB: Using Linux native AIO |
2021-10-06 19:21:31 0 [Note] InnoDB: Initializing buffer pool, total size = 104857600, chunk size = 104857600 |
2021-10-06 19:21:31 0 [Note] InnoDB: Completed initialization of buffer pool |
2021-10-06 19:21:31 0 [Warning] InnoDB: Retry attempts for reading partial data failed. |
2021-10-06 19:21:31 0 [ERROR] InnoDB: Operating system error number 13 in a file operation. |
2021-10-06 19:21:31 0 [ERROR] InnoDB: The error means mysqld does not have the access rights to the directory. |
2021-10-06 19:21:31 0 [ERROR] [FATAL] InnoDB: Tried to read 5120 bytes at offset 2048, but was only able to read 0.Cannot read from file. OS error number 13. |
211006 19:21:31 [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.5.10-7-MariaDB-enterprise |
key_buffer_size=0 |
read_buffer_size=131072 |
max_used_connections=0 |
max_threads=1 |
thread_count=0 |
It is possible that mysqld could use up to
|
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 6057 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 0x49000 |
addr2line: 'mariadb-backup': そのようなファイルはありません |
mariadb-backup(my_print_stacktrace+0x2e)[0x55d5918a29be] |
Printing to addr2line failed
|
mariadb-backup(handle_fatal_signal+0x485)[0x55d5913907d5] |
sigaction.c:0(__restore_rt)[0x7fc2610d7b20] |
:0(__GI_raise)[0x7fc26041c37f] |
:0(__GI_abort)[0x7fc260406db5] |
addr2line: 'mariadb-backup': そのようなファイルはありません |
mariadb-backup(+0x65fc95)[0x55d590fdbc95] |
mariadb-backup(+0x642ef4)[0x55d590fbeef4] |
mariadb-backup(+0xd737c2)[0x55d5916ef7c2] |
mariadb-backup(+0xd5e3c0)[0x55d5916da3c0] |
mariadb-backup(+0xd65e23)[0x55d5916e1e23] |
mariadb-backup(+0xd690ea)[0x55d5916e50ea] |
mariadb-backup(+0xd69654)[0x55d5916e5654] |
mariadb-backup(+0x65828b)[0x55d590fd428b] |
mariadb-backup(+0x6b2b1b)[0x55d59102eb1b] |
mariadb-backup(main+0x181)[0x55d590febdc1] |
??:0(__libc_start_main)[0x7fc260408493] |
addr2line: 'mariadb-backup': そのようなファイルはありません |
mariadb-backup(_start+0x2e)[0x55d59101d9de] |
The manual page at https://mariadb.com/kb/en/how-to-produce-a-full-stack-trace-for-mysqld/ contains |
information that should help you find out what is causing the crash.
|
Writing a core file...
|
Working directory at /mnt/backup/XXX/mariadb/202110061912 |
Resource Limits:
|
Limit Soft Limit Hard Limit Units
|
Max cpu time unlimited unlimited seconds
|
Max file size unlimited unlimited bytes
|
Max data size unlimited unlimited bytes
|
Max stack size 8388608 unlimited bytes |
Max core file size unlimited unlimited bytes
|
Max resident set unlimited unlimited bytes
|
Max processes 158623 158623 processes |
Max open files 1024 262144 files |
Max locked memory 65536 65536 bytes |
Max address space unlimited unlimited bytes
|
Max file locks unlimited unlimited locks
|
Max pending signals 158623 158623 signals |
Max msgqueue size 819200 819200 bytes |
Max nice priority 0 0 |
Max realtime priority 0 0 |
Max realtime timeout unlimited unlimited us
|
Core pattern: |/usr/lib/systemd/systemd-coredump %P %u %g %s %t %c %h %e
|
|
中止 (コアダンプ)
|
[root@XXX ~]# df -h |
....
|
//xxx.xx.xx.xxx/Share 3.7T 86G 3.6T 3% /mnt/data
|
//xxx.xx.xx.xxx/Backup 3.7T 86G 3.6T 3% /mnt/backup
|
tmpfs 3.9G 4.0K 3.9G 1% /run/user/1000 |
|
[root@XXX ~]# cat /etc/selinux/config |
|
# This file controls the state of SELinux on the system.
|
# SELINUX= can take one of these three values:
|
# enforcing - SELinux security policy is enforced.
|
# permissive - SELinux prints warnings instead of enforcing.
|
# disabled - No SELinux policy is loaded.
|
SELINUX=permissive
|
# SELINUXTYPE= can take one of these three values:
|
# targeted - Targeted processes are protected, |
# minimum - Modification of targeted policy. Only selected processes are protected. |
# mls - Multi Level Security protection.
|
SELINUXTYPE=targeted
|
customer noted:
The execution logs for each are attached. |
- NAS
|
- Local Storage
|
|
|
Investigate the cause of the following error that occurs when executing "prepare" in the backup directory on the NAS. |
(When I copy the file to local storage and run "prepare", it terminates normally, so there seems to be no problem with the backup file.) |
|
```
|
2021-10-29 20:18:10 0 [Warning] InnoDB: Retry attempts for reading partial data failed. |
2021-10-29 20:18:10 0 [ERROR] InnoDB: Operating system error number 13 in a file operation. |
2021-10-29 20:18:10 0 [ERROR] InnoDB: The error means mysqld does not have the access rights to the directory. |
2021-10-29 20:18:10 0 [ERROR] [FATAL] InnoDB: Tried to read 65536 bytes at offset 2048, but was only able to read 0.Cannot read from file. OS error number 13. |
```
|
This weren't much information in `/var/log/messages`
Attachments
Issue Links
- relates to
-
MDEV-30266 Preparing a mariabackup on a mounted CIFS / SMB file system fails
-
- Open
-
Activity
Field | Original Value | New Value |
---|---|---|
Fix Version/s | N/A [ 14700 ] | |
Resolution | Not a Bug [ 6 ] | |
Status | Open [ 1 ] | Closed [ 6 ] |
Description |
mariabackup --backup works well, however it fails on --prepare stage.
{code:java} [root@DBSV DBSV]# mariadb-backup --prepare --target-dir=/mnt/backup/DBSV/mariadb/$dt mariadb-backup based on MariaDB server 10.5.10-7-MariaDB Linux (x86_64) [00] 2021-10-06 19:21:30 cd to /mnt/backup/DBSV/mariadb/202110061912/ [00] 2021-10-06 19:21:30 open files limit requested 0, set to 1024 [00] 2021-10-06 19:21:31 This target seems to be not prepared yet. [00] 2021-10-06 19:21:31 mariabackup: using the following InnoDB configuration for recovery: [00] 2021-10-06 19:21:31 innodb_data_home_dir = . [00] 2021-10-06 19:21:31 innodb_data_file_path = ibdata1:12M:autoextend [00] 2021-10-06 19:21:31 innodb_log_group_home_dir = . [00] 2021-10-06 19:21:31 InnoDB: Using Linux native AIO [00] 2021-10-06 19:21:31 Starting InnoDB instance for recovery. [00] 2021-10-06 19:21:31 mariabackup: Using 104857600 bytes for buffer pool (set by --use-memory parameter) 2021-10-06 19:21:31 0 [Note] InnoDB: Uses event mutexes 2021-10-06 19:21:31 0 [Note] InnoDB: Compressed tables use zlib 1.2.11 2021-10-06 19:21:31 0 [Note] InnoDB: Number of pools: 1 2021-10-06 19:21:31 0 [Note] InnoDB: Using crc32 + pclmulqdq instructions 2021-10-06 19:21:31 0 [Note] InnoDB: Using Linux native AIO 2021-10-06 19:21:31 0 [Note] InnoDB: Initializing buffer pool, total size = 104857600, chunk size = 104857600 2021-10-06 19:21:31 0 [Note] InnoDB: Completed initialization of buffer pool 2021-10-06 19:21:31 0 [Warning] InnoDB: Retry attempts for reading partial data failed. 2021-10-06 19:21:31 0 [ERROR] InnoDB: Operating system error number 13 in a file operation. 2021-10-06 19:21:31 0 [ERROR] InnoDB: The error means mysqld does not have the access rights to the directory. 2021-10-06 19:21:31 0 [ERROR] [FATAL] InnoDB: Tried to read 5120 bytes at offset 2048, but was only able to read 0.Cannot read from file. OS error number 13. 211006 19:21:31 [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.5.10-7-MariaDB-enterprise key_buffer_size=0 read_buffer_size=131072 max_used_connections=0 max_threads=1 thread_count=0 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 6057 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 0x49000 addr2line: 'mariadb-backup': そのようなファイルはありません mariadb-backup(my_print_stacktrace+0x2e)[0x55d5918a29be] Printing to addr2line failed mariadb-backup(handle_fatal_signal+0x485)[0x55d5913907d5] sigaction.c:0(__restore_rt)[0x7fc2610d7b20] :0(__GI_raise)[0x7fc26041c37f] :0(__GI_abort)[0x7fc260406db5] addr2line: 'mariadb-backup': そのようなファイルはありません mariadb-backup(+0x65fc95)[0x55d590fdbc95] mariadb-backup(+0x642ef4)[0x55d590fbeef4] mariadb-backup(+0xd737c2)[0x55d5916ef7c2] mariadb-backup(+0xd5e3c0)[0x55d5916da3c0] mariadb-backup(+0xd65e23)[0x55d5916e1e23] mariadb-backup(+0xd690ea)[0x55d5916e50ea] mariadb-backup(+0xd69654)[0x55d5916e5654] mariadb-backup(+0x65828b)[0x55d590fd428b] mariadb-backup(+0x6b2b1b)[0x55d59102eb1b] mariadb-backup(main+0x181)[0x55d590febdc1] ??:0(__libc_start_main)[0x7fc260408493] addr2line: 'mariadb-backup': そのようなファイルはありません mariadb-backup(_start+0x2e)[0x55d59101d9de] The manual page at https://mariadb.com/kb/en/how-to-produce-a-full-stack-trace-for-mysqld/ contains information that should help you find out what is causing the crash. Writing a core file... Working directory at /mnt/backup/DBSV/mariadb/202110061912 Resource Limits: Limit Soft Limit Hard Limit Units Max cpu time unlimited unlimited seconds Max file size unlimited unlimited bytes Max data size unlimited unlimited bytes Max stack size 8388608 unlimited bytes Max core file size unlimited unlimited bytes Max resident set unlimited unlimited bytes Max processes 158623 158623 processes Max open files 1024 262144 files Max locked memory 65536 65536 bytes Max address space unlimited unlimited bytes Max file locks unlimited unlimited locks Max pending signals 158623 158623 signals Max msgqueue size 819200 819200 bytes Max nice priority 0 0 Max realtime priority 0 0 Max realtime timeout unlimited unlimited us Core pattern: |/usr/lib/systemd/systemd-coredump %P %u %g %s %t %c %h %e 中止 (コアダンプ) {code} {code:java} [root@DBSV ~]# df -h ファイルシス サイズ 使用 残り 使用% マウント位置 devtmpfs 20G 0 20G 0% /dev tmpfs 20G 7.3M 20G 1% /dev/shm tmpfs 20G 1.5M 20G 1% /run tmpfs 20G 0 20G 0% /sys/fs/cgroup /dev/mapper/rhel-root 1.1T 18G 1.1T 2% / /dev/sdb2 1006M 236M 771M 24% /boot /dev/sdb1 599M 5.8M 594M 1% /boot/efi //172.16.10.138/Share 3.7T 86G 3.6T 3% /mnt/data //172.16.10.138/Backup 3.7T 86G 3.6T 3% /mnt/backup tmpfs 3.9G 4.0K 3.9G 1% /run/user/1000 [root@DBSV ~]# cat /etc/selinux/config # This file controls the state of SELinux on the system. # SELINUX= can take one of these three values: # enforcing - SELinux security policy is enforced. # permissive - SELinux prints warnings instead of enforcing. # disabled - No SELinux policy is loaded. SELINUX=permissive # SELINUXTYPE= can take one of these three values: # targeted - Targeted processes are protected, # minimum - Modification of targeted policy. Only selected processes are protected. # mls - Multi Level Security protection. SELINUXTYPE=targeted {code} customer noted: {code:java} The execution logs for each are attached. - NAS - Local Storage Investigate the cause of the following error that occurs when executing "prepare" in the backup directory on the NAS. (When I copy the file to local storage and run "prepare", it terminates normally, so there seems to be no problem with the backup file.) ``` 2021-10-29 20:18:10 0 [Warning] InnoDB: Retry attempts for reading partial data failed. 2021-10-29 20:18:10 0 [ERROR] InnoDB: Operating system error number 13 in a file operation. 2021-10-29 20:18:10 0 [ERROR] InnoDB: The error means mysqld does not have the access rights to the directory. 2021-10-29 20:18:10 0 [ERROR] [FATAL] InnoDB: Tried to read 65536 bytes at offset 2048, but was only able to read 0.Cannot read from file. OS error number 13. ``` {code} This weren't much information in `/var/log/messages` |
mariabackup --backup works well, however it fails on --prepare stage.
{code:java} [root@XXX XXX]# mariadb-backup --prepare --target-dir=/mnt/backup/XXX/mariadb/$dt mariadb-backup based on MariaDB server 10.5.10-7-MariaDB Linux (x86_64) [00] 2021-10-06 19:21:30 cd to /mnt/backup/XXX/mariadb/202110061912/ [00] 2021-10-06 19:21:30 open files limit requested 0, set to 1024 [00] 2021-10-06 19:21:31 This target seems to be not prepared yet. [00] 2021-10-06 19:21:31 mariabackup: using the following InnoDB configuration for recovery: [00] 2021-10-06 19:21:31 innodb_data_home_dir = . [00] 2021-10-06 19:21:31 innodb_data_file_path = ibdata1:12M:autoextend [00] 2021-10-06 19:21:31 innodb_log_group_home_dir = . [00] 2021-10-06 19:21:31 InnoDB: Using Linux native AIO [00] 2021-10-06 19:21:31 Starting InnoDB instance for recovery. [00] 2021-10-06 19:21:31 mariabackup: Using 104857600 bytes for buffer pool (set by --use-memory parameter) 2021-10-06 19:21:31 0 [Note] InnoDB: Uses event mutexes 2021-10-06 19:21:31 0 [Note] InnoDB: Compressed tables use zlib 1.2.11 2021-10-06 19:21:31 0 [Note] InnoDB: Number of pools: 1 2021-10-06 19:21:31 0 [Note] InnoDB: Using crc32 + pclmulqdq instructions 2021-10-06 19:21:31 0 [Note] InnoDB: Using Linux native AIO 2021-10-06 19:21:31 0 [Note] InnoDB: Initializing buffer pool, total size = 104857600, chunk size = 104857600 2021-10-06 19:21:31 0 [Note] InnoDB: Completed initialization of buffer pool 2021-10-06 19:21:31 0 [Warning] InnoDB: Retry attempts for reading partial data failed. 2021-10-06 19:21:31 0 [ERROR] InnoDB: Operating system error number 13 in a file operation. 2021-10-06 19:21:31 0 [ERROR] InnoDB: The error means mysqld does not have the access rights to the directory. 2021-10-06 19:21:31 0 [ERROR] [FATAL] InnoDB: Tried to read 5120 bytes at offset 2048, but was only able to read 0.Cannot read from file. OS error number 13. 211006 19:21:31 [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.5.10-7-MariaDB-enterprise key_buffer_size=0 read_buffer_size=131072 max_used_connections=0 max_threads=1 thread_count=0 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 6057 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 0x49000 addr2line: 'mariadb-backup': そのようなファイルはありません mariadb-backup(my_print_stacktrace+0x2e)[0x55d5918a29be] Printing to addr2line failed mariadb-backup(handle_fatal_signal+0x485)[0x55d5913907d5] sigaction.c:0(__restore_rt)[0x7fc2610d7b20] :0(__GI_raise)[0x7fc26041c37f] :0(__GI_abort)[0x7fc260406db5] addr2line: 'mariadb-backup': そのようなファイルはありません mariadb-backup(+0x65fc95)[0x55d590fdbc95] mariadb-backup(+0x642ef4)[0x55d590fbeef4] mariadb-backup(+0xd737c2)[0x55d5916ef7c2] mariadb-backup(+0xd5e3c0)[0x55d5916da3c0] mariadb-backup(+0xd65e23)[0x55d5916e1e23] mariadb-backup(+0xd690ea)[0x55d5916e50ea] mariadb-backup(+0xd69654)[0x55d5916e5654] mariadb-backup(+0x65828b)[0x55d590fd428b] mariadb-backup(+0x6b2b1b)[0x55d59102eb1b] mariadb-backup(main+0x181)[0x55d590febdc1] ??:0(__libc_start_main)[0x7fc260408493] addr2line: 'mariadb-backup': そのようなファイルはありません mariadb-backup(_start+0x2e)[0x55d59101d9de] The manual page at https://mariadb.com/kb/en/how-to-produce-a-full-stack-trace-for-mysqld/ contains information that should help you find out what is causing the crash. Writing a core file... Working directory at /mnt/backup/XXX/mariadb/202110061912 Resource Limits: Limit Soft Limit Hard Limit Units Max cpu time unlimited unlimited seconds Max file size unlimited unlimited bytes Max data size unlimited unlimited bytes Max stack size 8388608 unlimited bytes Max core file size unlimited unlimited bytes Max resident set unlimited unlimited bytes Max processes 158623 158623 processes Max open files 1024 262144 files Max locked memory 65536 65536 bytes Max address space unlimited unlimited bytes Max file locks unlimited unlimited locks Max pending signals 158623 158623 signals Max msgqueue size 819200 819200 bytes Max nice priority 0 0 Max realtime priority 0 0 Max realtime timeout unlimited unlimited us Core pattern: |/usr/lib/systemd/systemd-coredump %P %u %g %s %t %c %h %e 中止 (コアダンプ) {code} {code:java} [root@XXX ~]# df -h .... //xxx.xx.xx.xxx/Share 3.7T 86G 3.6T 3% /mnt/data //xxx.xx.xx.xxx/Backup 3.7T 86G 3.6T 3% /mnt/backup tmpfs 3.9G 4.0K 3.9G 1% /run/user/1000 [root@XXX ~]# cat /etc/selinux/config # This file controls the state of SELinux on the system. # SELINUX= can take one of these three values: # enforcing - SELinux security policy is enforced. # permissive - SELinux prints warnings instead of enforcing. # disabled - No SELinux policy is loaded. SELINUX=permissive # SELINUXTYPE= can take one of these three values: # targeted - Targeted processes are protected, # minimum - Modification of targeted policy. Only selected processes are protected. # mls - Multi Level Security protection. SELINUXTYPE=targeted {code} customer noted: {code:java} The execution logs for each are attached. - NAS - Local Storage Investigate the cause of the following error that occurs when executing "prepare" in the backup directory on the NAS. (When I copy the file to local storage and run "prepare", it terminates normally, so there seems to be no problem with the backup file.) ``` 2021-10-29 20:18:10 0 [Warning] InnoDB: Retry attempts for reading partial data failed. 2021-10-29 20:18:10 0 [ERROR] InnoDB: Operating system error number 13 in a file operation. 2021-10-29 20:18:10 0 [ERROR] InnoDB: The error means mysqld does not have the access rights to the directory. 2021-10-29 20:18:10 0 [ERROR] [FATAL] InnoDB: Tried to read 65536 bytes at offset 2048, but was only able to read 0.Cannot read from file. OS error number 13. ``` {code} This weren't much information in `/var/log/messages` |
Workflow | MariaDB v3 [ 127113 ] | MariaDB v4 [ 159830 ] |
Link | This issue relates to MDEV-30266 [ MDEV-30266 ] |
Zendesk Related Tickets | 128050 |
Since I do not have Windows based NAS server, I tested this with windows file sharing with SMB.
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.
diagnose the problem, but since we have already crashed,
It is possible that mysqld could use up to
Attempting backtrace. You can use the following information to find out
terribly wrong...
Printing to addr2line failed
information that should help you find out what is causing the crash.
Writing a core file...
Working directory at /data/cifs/windows/backup
Resource Limits:
Limit Soft Limit Hard Limit Units
Max cpu time unlimited unlimited seconds
Max file size unlimited unlimited bytes
Max data size unlimited unlimited bytes
Max resident set unlimited unlimited bytes
Max address space unlimited unlimited bytes
Max file locks unlimited unlimited locks
Max realtime timeout unlimited unlimited us
Core pattern: |/usr/libexec/abrt-hook-ccpp %s %c %p %u %g %t e %P %I %h
Aborted (core dumped)
I was hitting the same signal 6.