[MDEV-17195] mariabackup is very slow on databases with many tables Created: 2018-09-14  Updated: 2021-09-13  Resolved: 2018-10-31

Status: Closed
Project: MariaDB Server
Component/s: mariabackup
Affects Version/s: 10.2.17
Fix Version/s: 10.2.19

Type: Bug Priority: Major
Reporter: YURII KANTONISTOV Assignee: Vladislav Vaintroub
Resolution: Fixed Votes: 0
Labels: None
Environment:

CentOS Linux release 7.5.1804 (Core)
Linux fies1udb32.tellabs.fi 3.10.0-862.11.6.el7.x86_64 #1 SMP Tue Aug 14 21:49:04 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux


Attachments: Text File mariabackup_slow_mysql_session.txt     PNG File screenshot-1.png    

 Description   

mariabackup becomes very slow if the MariaDB server has many schemes/many tables and using --lock-ddl or --lock-ddl-per-table option.

mariabackup executes per each table information_schema query like below, depending on the server it takes 0.5-1.0+ second time:

MariaDB [(none)]> show profiles;
+----------+------------+-------------------------------------------------------------------------------------------------+
| Query_ID | Duration   | Query                                                                                           |
+----------+------------+-------------------------------------------------------------------------------------------------+
|        1 | 1.10146659 | SELECT NAME FROM INFORMATION_SCHEMA.INNODB_SYS_TABLES WHERE SPACE = 52974 AND NAME LIKE '%%/%%' |

We have servers with as many as 234440 InnoDB tables
=> just querying information schema will last more than 117220 seconds
=> daily backup lasts at least 33 hours, actual time is about 3x days.

Data itself is about 34GB and its copying/archiving lasts only some minutes:

[mysql@fies1udb32 ~]$ du -skh /mysql_data
34G     /mysql_data

Slowness locates in "Filling schema table" phase, see attached mariabackup_slow_mysql_session.txt for details:

MariaDB [(none)]> show profiles;
+----------+------------+-------------------------------------------------------------------------------------------------+
| Query_ID | Duration   | Query                                                                                           |
+----------+------------+-------------------------------------------------------------------------------------------------+
|        1 | 1.10146659 | SELECT NAME FROM INFORMATION_SCHEMA.INNODB_SYS_TABLES WHERE SPACE = 52974 AND NAME LIKE '%%/%%' |
|        2 | 0.94333337 | SELECT NAME FROM INFORMATION_SCHEMA.INNODB_SYS_TABLES WHERE SPACE = 52974 AND NAME LIKE '%%/%%' |
|        3 | 0.85380770 | SELECT NAME FROM INFORMATION_SCHEMA.INNODB_SYS_TABLES WHERE SPACE = 52974 AND NAME LIKE '%%/%%' |
+----------+------------+-------------------------------------------------------------------------------------------------+
...
MariaDB [(none)]> SHOW PROFILE FOR QUERY 3;
...
| Filling schema table           | 0.759816 |
...

I guess mariabackup could make bulk query to information_schema to get all the metadata it needs in one go?



 Comments   
Comment by Lionel Enkaoua [ 2021-09-12 ]

Is there any update on this issue ?
We experiencing the same issue with mysqldump and mariadb 10.5.12.

We have around 350.000 tables, with mariadb 10.1, the backup of all the 200 databases was taking around 30 min. Now it's around 6 hours.

We can see in wait states during regular queries not especially backup, that MariaDB is passing 20% in Statistics. When it was around 1% with MariaDB 10.1

We were able to reproduce this behavior on a local computer, increasing table_open_cache seems to improve by a lot the slow access to information_schema database.
For now we don't have enough RAM in this server to increase TABLE_OPEN_CACHE as much as our tables amount.

With TABLE_OPEN_CACHE set to 131072.

Comment by Daniel Black [ 2021-09-13 ]

This issue was fixed https://github.com/MariaDB/server/commit/f8268f3cce4577c28ab62e53293556d05a74fb1a and relates to the way mariabackup uses information tables. This fix reduces the number of queries and doesn't introduce new queries. The issue you are seeing isn't this one.

Increasing table_open_cache will always improve the querying of information_schema tables that reference ordinary tables. This is why the fix in this bug reduced this to occuring once.

The issue of increased backup time to this large factor is important, however its not this issue.

Generated at Thu Feb 08 08:34:37 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.