# Mysqldump - -- Connecting to localhost **URL:** \ **Category:** Percona Server for MySQL 8.0\ **Tags:** percona\ **Created:** [December 29, 2022, 9:42am UTC](https://forums.percona.com/t/mysqldump-connecting-to-localhost/19380 "2022-12-29T09:42:29Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![khaledhu](https://avatars.discourse-cdn.com/v4/letter/k/ac91a4/32.png) [@khaledhu](https://forums.percona.com/u/khaledhu)\ **Post date:** [December 29, 2022, 9:42am UTC](https://forums.percona.com/t/mysqldump-connecting-to-localhost/19380/1 "2022-12-29T09:42:29Z")
I am using mysqldump to dump my databases, but I face a problem, the dump freeze for around 30-40 seconds on – Connecting to localhost…, then the process continue normally I did not face this issue with my other server that still running MySQL 5.7 ---
**Author:** ![matthewb](https://sea1.discourse-cdn.com/flex019/user_avatar/forums.percona.com/matthewb/32/34_2.png) [@matthewb](https://forums.percona.com/u/matthewb)\ **Post date:** [December 29, 2022, 1:53pm UTC](https://forums.percona.com/t/mysqldump-connecting-to-localhost/19380/2 "2022-12-29T13:53:14Z")
When mysqldump freezes, what does the output say right before this happens? ---
**Author:** ![khaledhu](https://avatars.discourse-cdn.com/v4/letter/k/ac91a4/32.png) [@khaledhu](https://forums.percona.com/u/khaledhu)\ **Post date:** [January 1, 2023, 7:47am UTC](https://forums.percona.com/t/mysqldump-connecting-to-localhost/19380/3 "2023-01-01T07:47:51Z")
> [@matthewb](#): > > es, what does the output say right bef if you mean mysql error log file, nothing written there before start the dump, it just freeze for around 30 seconds then continue the dump ---
**Author:** ![yunus\_shaikh](https://sea1.discourse-cdn.com/flex019/user_avatar/forums.percona.com/yunus_shaikh/32/3512_2.png) [@yunus\_shaikh](https://forums.percona.com/u/yunus_shaikh)\ **Post date:** [January 2, 2023, 9:20am UTC](https://forums.percona.com/t/mysqldump-connecting-to-localhost/19380/4 "2023-01-02T09:20:25Z")
Can you post the command that you use for mysqldump? Also, when you say that the mysqldump is stuck in connecting to localhost for 30-40 seconds, is it possible for you to check the processlist of mysql in another session during that time? That would let us know what is happening with the server when it is trying to authenticate. ---
**Author:** ![khaledhu](https://avatars.discourse-cdn.com/v4/letter/k/ac91a4/32.png) [@khaledhu](https://forums.percona.com/u/khaledhu)\ **Post date:** [January 2, 2023, 12:33pm UTC](https://forums.percona.com/t/mysqldump-connecting-to-localhost/19380/5 "2023-01-02T12:33:37Z")
backup command I am using is **mysqldump --login-path=local --opt --set-gtid-purged=OFF -v DATABASE | gzip \> DATABASE.gz** and I found this in the full processlist command output | 314393 | root | localhost | NULL | Query | 13 | checking permissions | **SELECT LOGFILE\_GROUP\_NAME, FILE\_NAME, TOTAL\_EXTENTS, INITIAL\_SIZE, ENGINE, EXTRA FROM INFORMATION\_SCHEMA.FILES WHERE FILE\_TYPE = ‘UNDO LOG’ AND FILE\_NAME IS NOT NULL AND LOGFILE\_GROUP\_NAME IS NOT NULL AND LOGFILE\_GROUP\_NAME IN (SELECT DISTINCT LOGFILE\_GROUP\_NAME FROM INFORMATION\_SCHEMA.FILES WHERE FILE\_TYPE = ‘DATAFILE’ AND TABLESPACE\_NAME IN (SELECT DISTINCT TABLESPACE\_NAME FROM INFORMATION\_SCHEMA.PARTITIONS WHERE TABLE\_SCHEMA IN (‘asp\_tirehc\_2160642’))) GROUP BY LOGFILE\_GROUP\_NAME, FILE\_NAME, ENGINE, TOTAL\_EXTENTS, INITIAL\_SIZE ORDER BY LOGFILE\_GROUP\_NAME** | 12763 | 0 | 0 | ---
**Author:** ![yunus\_shaikh](https://sea1.discourse-cdn.com/flex019/user_avatar/forums.percona.com/yunus_shaikh/32/3512_2.png) [@yunus\_shaikh](https://forums.percona.com/u/yunus_shaikh)\ **Post date:** [January 2, 2023, 2:11pm UTC](https://forums.percona.com/t/mysqldump-connecting-to-localhost/19380/6 "2023-01-02T14:11:16Z")
It seems like you are hitting this bug, [https://bugs.mysql.com/bug.php?id=93875](https://bugs.mysql.com/bug.php?id=93875) So it seems like this problem occurs where the tables are more than your other instance where you don’t see this problem. The bug is that the query scans many rows when there are a lot of tables in the database. It is not indexed so the query performance is bad. This was fixed in 8.0 by improving the query to not scan all the rows. Other alternative would be to use mydumper which is more advanced version of mysqldump, If you want to take a look here, > **[GitHub - mydumper/mydumper: Official MyDumper project](https://github.com/mydumper/mydumper)** > > Official MyDumper project. Contribute to mydumper/mydumper development by creating an account on GitHub. ---
**Author:** ![khaledhu](https://avatars.discourse-cdn.com/v4/letter/k/ac91a4/32.png) [@khaledhu](https://forums.percona.com/u/khaledhu)\ **Post date:** [January 3, 2023, 12:07pm UTC](https://forums.percona.com/t/mysqldump-connecting-to-localhost/19380/7 "2023-01-03T12:07:47Z")
Thanks for your reply, but I am using this version of Percona 8.0.27-18 Percona Server (GPL), Release ‘18’, Revision ‘24801e21b45’ and the problem still exist, I am discovering mydumper and it seems it is perfect ---
**Author:** ![yunus\_shaikh](https://sea1.discourse-cdn.com/flex019/user_avatar/forums.percona.com/yunus_shaikh/32/3512_2.png) [@yunus\_shaikh](https://forums.percona.com/u/yunus_shaikh)\ **Post date:** [January 3, 2023, 1:40pm UTC](https://forums.percona.com/t/mysqldump-connecting-to-localhost/19380/8 "2023-01-03T13:40:05Z")
Oh, I though you mentioned that you were on 5.7. > [@khaledhu](#): > > I did not face this issue with my other server that still running MySQL 5.7 Can you check your mydumper version? mysqldump --version And yes, mydumper is a better option than mysqldump. It allows you to back up in multiple threads. Restore is faster as well with myloader.