Mysqldump got error 2002

I have mysql 5.5 on my ubuntu 12.04 server. This command: mysql -u root -p works perfectly, but this gives me error: mysqldump -u root -p mydb_name > a.sql mysqldump: Got error: 2002: Can't c...

NOTE: serverfault.com may arguably be a better place to ask this question as it is related to server configuration rather than programming.

First, try adding --socket=/home/mysql/mysql.sock to your mysqldump command.

If this works you can make this command line option more persistent and avoid typing it every time by adding it to an option file.

Running mysqldump —help will show you (starting at about line 15 of the output) which option files and groups from which mysqldump will attempt to read options. For example if it reports:

...

Default options are read from the following files in the given order:
/etc/my.cnf /etc/mysql/my.cnf /usr/etc/my.cnf ~/.my.cnf 
The following groups are read: mysqldump client

...

You could add:

[mysqldump]
socket = /home/mysql/mysql.sock

to either /etc/mysql/my.cnf or ~/.my.cnf or any one of the other files listed, and then you would not need the —socket=… option each time you run mysqldump.

NOTE: if mysqldump is not recognizing your socket option from the [client] group in your existing my.cnf file in the same way that your mysql command does, this may mean that your version of mysqldump may not be reading the same group & option file combination that mysql command is reading for whatever reason.

If the —socket option doesn’t work, then it may be some other configuration issue.

  1. Be sure you set socket = /home/mysql/mysql.sock in each of the applicable subsections of your my.cnf file:

    [client]
socket = /home/mysql/mysql.sock

[mysqld_safe]
socket = /home/mysql/mysql.sock

[mysqld]
socket = /home/mysql/mysql.sock

[mysqldump]
socket = /home/mysql/mysql.sock

  2. DO NOT CHANGE APPARMOR SETTINGS UNLESS ABSOLUTELY NECESSARY! Check to see if you are running apparmor using the command sudo apparmor_status and look for «apparmor module is loaded.» near the beginning of the output this command produces. If so, add a line like the following to your /etc/apparmor.d/usr.sbin.mysqld file about 6 lines from the end of the file. The location should be pretty obvious based on similar existing entries for /var/run/mysql/mysqld.sock:

    /home/mysql/mysql.sock rw,

You want to restart apparmor and then mysqld at that point, or just reboot to get a clean restart of everything.

Note that these types of non-standard configuration options that you add to apparmor may open you up for security issues. This may also cause conflicts when you run Update Manager and you may need to hand-edit the changes again in the future if you update or re-install ubuntu.

Источник

I have mysql 5.5 on my ubuntu 12.04 server. This command:

mysql -u root -p

works perfectly, but this gives me error:

mysqldump -u root -p mydb_name > a.sql
mysqldump: Got error: 2002: Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2) when trying to connect

In my.cnf file, the socket is set to:

socket = /home/mysql/mysql.sock

so I have no idea where /var/run/mysqld/mysqld.sock is coming from. Thanks.

asked Jul 12, 2013 at 23:23

AliBZ's user avatar

2

When reading the configuration file, the mysql command line client only reads configuration directives found in the [client] and [mysql] sections, while mysqldump only uses configuration directives found in the [client] and [mysqldump] sections.

If your socket directive in the config file is in the [mysql] section but not the [mysqldump] section then you should move it to the [client] section, and this should solve your problem.

So where does /var/run/mysqld/mysqld.sock come from? I remember very distinctly, once upon a time, beating my head against the wall repeatedly over that one.

It turns out, Ubuntu compiles their MySQL components from source, and when they do that, they compile them to use /var/run/mysqld/mysqld.sock unless the configuration file specifies otherwise or the socket is overridden on the command line… so if your socket directive isn’t in [client] that would be one explanation of this behavior.

answered Jul 13, 2013 at 4:37

Michael - sqlbot's user avatar

Michael — sqlbotMichael — sqlbot

22.3k2 gold badges46 silver badges75 bronze badges

2

Источник

Version: ‘5.1.62’ socket: ‘/var/lib/mysql/mysql.sock’ port: 3306 MySQL Community Server (GPL)
120418 14:52:49 [Note] /usr/sbin/mysqld: Normal shutdown

120418 14:52:49 [Note] Event Scheduler: Purging the queue. 0 events
120418 14:52:51 InnoDB: Starting shutdown…
120418 14:52:55 InnoDB: Shutdown completed; log sequence number 0 1566627868
120418 14:52:55 [Note] /usr/sbin/mysqld: Shutdown complete

120418 14:52:55 mysqld_safe mysqld from pid file /var/lib/mysql/sn1.domainyonlendir.net.pid ended
120418 14:52:56 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
120418 14:52:56 [Warning] ‘—skip-locking’ is deprecated and will be removed in a future release. Pleas e use ‘—skip-external-locking’ instead.
120418 14:52:56 [Warning] ‘record_buffer’ is deprecated and will be removed in a future release. Please use ‘read_buffer_size’ instead.
120418 14:52:56 [Note] Plugin ‘FEDERATED’ is disabled.
120418 14:52:56 InnoDB: Initializing buffer pool, size = 8.0M
120418 14:52:56 InnoDB: Completed initialization of buffer pool
120418 14:52:56 InnoDB: Started; log sequence number 0 1566627868
120418 14:52:56 [Note] Event Scheduler: Loaded 0 events
120418 14:52:56 [Note] /usr/sbin/mysqld: ready for connections.
Version: ‘5.1.62’ socket: ‘/var/lib/mysql/mysql.sock’ port: 3306 MySQL Community Server (GPL)
120418 15:21:54 [Note] /usr/sbin/mysqld: Normal shutdown

120418 15:21:54 [Note] Event Scheduler: Purging the queue. 0 events
120418 15:21:56 InnoDB: Starting shutdown…
120418 15:21:58 InnoDB: Shutdown completed; log sequence number 0 1567110713
120418 15:21:58 [Note] /usr/sbin/mysqld: Shutdown complete

120418 15:21:58 mysqld_safe mysqld from pid file /var/lib/mysql/sn1.domainyonlendir.net.pid ended
120418 15:21:59 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
120418 15:21:59 [Warning] ‘record_buffer’ is deprecated and will be removed in a future release. Please use ‘read_buffer_size’ instead.
120418 15:21:59 [Note] Plugin ‘FEDERATED’ is disabled.
120418 15:21:59 InnoDB: Initializing buffer pool, size = 8.0M
120418 15:21:59 InnoDB: Completed initialization of buffer pool
120418 15:21:59 InnoDB: Started; log sequence number 0 1567110713
120418 15:21:59 [ERROR] /usr/sbin/mysqld: unknown option ‘—-skip-external-locking’
120418 15:21:59 [ERROR] Aborting

120418 15:21:59 InnoDB: Starting shutdown…
120418 15:22:04 InnoDB: Shutdown completed; log sequence number 0 1567110713
120418 15:22:04 [Note] /usr/sbin/mysqld: Shutdown complete

120418 15:22:04 mysqld_safe mysqld from pid file /var/lib/mysql/sn1.domainyonlendir.net.pid ended
120418 15:22:26 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
120418 15:22:26 [Warning] ‘record_buffer’ is deprecated and will be removed in a future release. Please use ‘read_buffer_size’ instead.
120418 15:22:26 [Note] Plugin ‘FEDERATED’ is disabled.
120418 15:22:26 InnoDB: Initializing buffer pool, size = 8.0M
120418 15:22:26 InnoDB: Completed initialization of buffer pool
120418 15:22:26 InnoDB: Started; log sequence number 0 1567110713
120418 15:22:26 [Note] Event Scheduler: Loaded 0 events
120418 15:22:26 [Note] /usr/sbin/mysqld: ready for connections.
Version: ‘5.1.62’ socket: ‘/var/lib/mysql/mysql.sock’ port: 3306 MySQL Community Server (GPL)
[[email protected] custombuild]# tail -n 50 /var/lib/mysql/`hostname`.err
Version: ‘5.1.62’ socket: ‘/var/lib/mysql/mysql.sock’ port: 3306 MySQL Community Server (GPL)
120418 14:52:49 [Note] /usr/sbin/mysqld: Normal shutdown

120418 14:52:49 [Note] Event Scheduler: Purging the queue. 0 events
120418 14:52:51 InnoDB: Starting shutdown…
120418 14:52:55 InnoDB: Shutdown completed; log sequence number 0 1566627868
120418 14:52:55 [Note] /usr/sbin/mysqld: Shutdown complete

120418 14:52:55 mysqld_safe mysqld from pid file /var/lib/mysql/sn1.domainyonlendir.net.pid ended
120418 14:52:56 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
120418 14:52:56 [Warning] ‘—skip-locking’ is deprecated and will be removed in a future release. Please use ‘—skip-external-locking’ instead.
120418 14:52:56 [Warning] ‘record_buffer’ is deprecated and will be removed in a future release. Please use ‘read_buffer_size’ instead.
120418 14:52:56 [Note] Plugin ‘FEDERATED’ is disabled.
120418 14:52:56 InnoDB: Initializing buffer pool, size = 8.0M
120418 14:52:56 InnoDB: Completed initialization of buffer pool
120418 14:52:56 InnoDB: Started; log sequence number 0 1566627868
120418 14:52:56 [Note] Event Scheduler: Loaded 0 events
120418 14:52:56 [Note] /usr/sbin/mysqld: ready for connections.
Version: ‘5.1.62’ socket: ‘/var/lib/mysql/mysql.sock’ port: 3306 MySQL Community Server (GPL)
120418 15:21:54 [Note] /usr/sbin/mysqld: Normal shutdown

120418 15:21:54 [Note] Event Scheduler: Purging the queue. 0 events
120418 15:21:56 InnoDB: Starting shutdown…
120418 15:21:58 InnoDB: Shutdown completed; log sequence number 0 1567110713
120418 15:21:58 [Note] /usr/sbin/mysqld: Shutdown complete

120418 15:21:58 mysqld_safe mysqld from pid file /var/lib/mysql/sn1.domainyonlendir.net.pid ended
120418 15:21:59 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
120418 15:21:59 [Warning] ‘record_buffer’ is deprecated and will be removed in a future release. Please use ‘read_buffer_size’ instead.
120418 15:21:59 [Note] Plugin ‘FEDERATED’ is disabled.
120418 15:21:59 InnoDB: Initializing buffer pool, size = 8.0M
120418 15:21:59 InnoDB: Completed initialization of buffer pool
120418 15:21:59 InnoDB: Started; log sequence number 0 1567110713
120418 15:21:59 [ERROR] /usr/sbin/mysqld: unknown option ‘—-skip-external-locking’
120418 15:21:59 [ERROR] Aborting

120418 15:21:59 InnoDB: Starting shutdown…
120418 15:22:04 InnoDB: Shutdown completed; log sequence number 0 1567110713
120418 15:22:04 [Note] /usr/sbin/mysqld: Shutdown complete

120418 15:22:04 mysqld_safe mysqld from pid file /var/lib/mysql/sn1.domainyonlendir.net.pid ended
120418 15:22:26 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
120418 15:22:26 [Warning] ‘record_buffer’ is deprecated and will be removed in a future release. Please use ‘read_buffer_size’ instead.
120418 15:22:26 [Note] Plugin ‘FEDERATED’ is disabled.
120418 15:22:26 InnoDB: Initializing buffer pool, size = 8.0M
120418 15:22:26 InnoDB: Completed initialization of buffer pool
120418 15:22:26 InnoDB: Started; log sequence number 0 1567110713
120418 15:22:26 [Note] Event Scheduler: Loaded 0 events
120418 15:22:26 [Note] /usr/sbin/mysqld: ready for connections.
Version: ‘5.1.62’ socket: ‘/var/lib/mysql/mysql.sock’ port: 3306 MySQL Community Server (GPL)

Источник

Let’s resume; I got a bit confused in some previous posts…my bad.

when I asked you

First try: change localhost to 127.0.0.1 if you are on a Mac

you actually changed the local.vhost, not local.database.host

global:
  sql_adapter: "wpcli"

local:
  vhost: "127.0.0.1"
  wordpress_path: "/Users/brettgolding/Google Drive/htdocs/brett-dev-rebuild" # use an absolute path here

  database:
    name: "brettdevrebuild"
    user: "root"
    password: "root"
    host: "localhost"

I meant

database:
    name: "brettdevrebuild"
    user: "root"
    password: "root"
    host: "127.0.0.1"

This can’t return the same error, because you force mysqldump to connect via TCP leaving the socket connection away. This is not how Wordmove works, but just how mysql and mysqldump work.

Do you think it could be related to having multiple instances of mySQL installed?

So: wordmove doctor is not related: you just have an old wordmove version. I hope you upgraded to the latest since I can help supporting only on the latest (non beta) version.

Your problem with MySQL could be related to having multimple MySQL instances installed. But it is not a problem brought by Wordmove it’s just a little mess on the development system ;) Requesting a TCP connection to 127.0.0.1 could bypass some of this confusion.

Where the confusion could be? When using localhost as DB host, mysqldump will search for a socket. Where the socket is is configured by default to /i/dont/know/where. Having multiple MySQL installed?
Ok: both will have their command line tool. Using brew’s mysqldump will use its own defaults, using MAMP’s mysqldump will use its own defaults.

So: which mysqldump is wordmove calling? You should know that with

which mysqldump
which mysql

and you have to consider that the precedence between brew’s commands and MAMP’s commands is controlled by you shell’s $PATH. If you start MAMP’s MySQL server and then use brew’s mysqldump it could work even if they are from different versions, but not if they are searching for different sockets

I hope to have re-ordered ideas a bit and I hope you’ll have the time and the scenario to test these assumptions. If it is no more the case, I’d be glad if you’ll close the issue just to keep things clean ;)

Cheers

Источник

Восстановление работоспособности после падения mysql, разберем специфику восстановления низкоуровневых подсистем InnoDB.

Почему падает бд

Почему mysql не стартует, для этого есть множество причин, в данный момент бы будем разбирать только реальные проблемы работы бд а не программные настройки.

  • Ошибка жёстких дисков, в следствие это невозможность считать файл.
  • Ошибка записи была вызвана невозможность сохранить данные, по русски кончилось место в следствие этого произошла логическая ошибка БД.

Убедимся что проблема действительно есть

df -h

[root@centos-75-64-minimal ~]# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/md2 437G 98G 317G 100% /
devtmpfs 32G 0 32G 0% /dev
tmpfs 32G 0 32G 0% /dev/shm
tmpfs 32G 1.2M 32G 1% /run
tmpfs 32G 0 32G 0% /sys/fs/cgroup
/dev/md1 488M 143M 320M 31% /boot
tmpfs 6.3G 0 6.3G 0% /run/user/600
tmpfs 6.3G 0 6.3G 0% /run/user/0

Место на диске кончилось, и БД не в состояние больше писать, отчистим место и попробуем перезапустить mysql, если же mysql не запускается то первым делом останавливаем mysql, в зависимости от ОС команда моет отличаться.

service mysqld restart
service mysql restart
/etc/init.d/mysqld restart

В нашем случае база не запустилась, по этому полностью останавливаем mysql

service mysqld stop
service mysql stop
/etc/init.d/mysqld stop

И убеждаемся что демон полностью остановлен и все процессы тоже, должен остаться только один процесс

[root@centos-75-64-minimal ~]# ps aux | grep mysql 
root     1903   0.0 0.0 112708 972 pts/3 S+ 19:46 0:00 grep --color=auto mysq

Если mysql все еще есть, то убиваем процесс

 kill -9 "номер процесса"

Запускаем заново mysql

service mysqld start
service mysql start
/etc/init.d/mysqld start

Демон не запускается

service mysql start 
Redirecting to /bin/systemctl start mysql.service 
Job for mysqld.service failed because the control process exited with error code. See "systemctl status mysqld.service" and "journalctl -xe" for details.

В какие логи смотреть

Смотрим логи

journalctl -xe

PageUp и PageDown

Обратите внимание что это не лог mysql и сюда попадает множество другой информации, так что возможно вы не увидите вашу ошибку, поскольку она уже ушла дальше по логу.

Сам демон mysql может сообщить полезную информацию

service mysqld status
service mysql status
/etc/init.d/mysqld status
Redirecting to /bin/systemctl status mysql.service 
● mysqld.service - MySQL Server
Loaded: loaded (/usr/lib/systemd/system/mysqld.service; enabled; vendor preset: disabled)
Active: failed (Result: start-limit) since Mon 2019-02-18 18:20:59 MSK; 18min ago
Docs: man:mysqld(8)
http://dev.mysql.com/doc/refman/en/using-systemd.html
Process: 25723 ExecStart=/usr/sbin/mysqld --daemonize --pid-file=/var/run/mysqld/mysqld.pid $MYSQL D_OPTS (code=exited, status=1/FAILURE)
Process: 25699 ExecStartPre=/usr/bin/mysqld_pre_systemd (code=exited, status=0/SUCCESS)
Main PID: 14443 (code=killed, signal=KILL)
Feb 18 18:20:59 centos-75-64-minimal systemd[1]: Failed to start MySQL Server.
Feb 18 18:20:59 centos-75-64-minimal systemd[1]: Unit mysqld.service entered failed state.
Feb 18 18:20:59 centos-75-64-minimal systemd[1]: mysqld.service failed.
Feb 18 18:20:59 centos-75-64-minimal systemd[1]: mysqld.service holdoff time over, scheduling ...rt.
Feb 18 18:20:59 centos-75-64-minimal systemd[1]: start request repeated too quickly for mysqld...ice
Feb 18 18:20:59 centos-75-64-minimal systemd[1]: Failed to start MySQL Server.
Feb 18 18:20:59 centos-75-64-minimal systemd[1]: Unit mysqld.service entered failed state.
Feb 18 18:20:59 centos-75-64-minimal systemd[1]: mysqld.service failed.
Hint: Some lines were ellipsized, use -l to show in full.
[root@centos-75-64-minimal mysql]# service mysql status
Redirecting to /bin/systemctl status mysql.service
● mysqld.service - MySQL Server
Loaded: loaded (/usr/lib/systemd/system/mysqld.service; enabled; vendor preset: disabled)
Active: failed (Result: start-limit) since Mon 2019-02-18 18:20:59 MSK; 18min ago
Docs: man:mysqld(8)
http://dev.mysql.com/doc/refman/en/using-systemd.html
Process: 25723 ExecStart=/usr/sbin/mysqld --daemonize --pid-file=/var/run/mysqld/mysqld.pid $MYSQLD_OPTS (code=exited, status=1/FAILURE)
Process: 25699 ExecStartPre=/usr/bin/mysqld_pre_systemd (code=exited, status=0/SUCCESS)
Main PID: 14443 (code=killed, signal=KILL)

Feb 18 18:20:59 centos-75-64-minimal systemd[1]: Failed to start MySQL Server.
Feb 18 18:20:59 centos-75-64-minimal systemd[1]: Unit mysqld.service entered failed state.
Feb 18 18:20:59 centos-75-64-minimal systemd[1]: mysqld.service failed.
Feb 18 18:20:59 centos-75-64-minimal systemd[1]: mysqld.service holdoff time over, scheduling restart.
Feb 18 18:20:59 centos-75-64-minimal systemd[1]: start request repeated too quickly for mysqld.service
Feb 18 18:20:59 centos-75-64-minimal systemd[1]: Failed to start MySQL Server.
Feb 18 18:20:59 centos-75-64-minimal systemd[1]: Unit mysqld.service entered failed state.
Feb 18 18:20:59 centos-75-64-minimal systemd[1]: mysqld.service failed.

Как мы видим в данном случае информативности оно не добавило, просто mysql не желает стартовать.

Можно более подробно посмотреть в error логе mysql

tail -f /var/log/mysql/error.log

Нужно убедиться что логирование включено, для этого в my.cnf должна быть директива

log-error = путь до файла лога

Так же она может быть написана в другом конфиге подключаемом через include, для быстрого поиска воспользоватсья данной командой:

find  /etc/mysql/ -type f -exec grep -l "log-error" {} ; 
2019-02-12T17:10:41.002325Z 0 [Warning] Could not increase number of max_open_files to more than 5000 (request: 80192)
2019-02-12T17:10:41.002565Z 0 [Warning] Changed limits: table_open_cache: 2392 (requested 18432)
2019-02-12T17:10:41.147060Z 0 [Warning] 'NO_AUTO_CREATE_USER' sql mode was not set.
2019-02-12T17:10:41.148006Z 0 [Note] /usr/sbin/mysqld (mysqld 5.7.23-25) starting as process 3314 ..
2019-02-12T17:10:41.153630Z 0 [Warning] InnoDB: Using innodb_file_format is deprecated and the parameter may be removed in future releases. See http://dev.mysql.com/doc/refman/5.7/en/innodb-file-format.html
2019-02-12T17:10:41.153694Z 0 [Note] InnoDB: PUNCH HOLE support available
2019-02-12T17:10:41.153702Z 0 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
2019-02-12T17:10:41.153705Z 0 [Note] InnoDB: Uses event mutexes
2019-02-12T17:10:41.153708Z 0 [Note] InnoDB: GCC builtin __atomic_thread_fence() is used for memory barrier
2019-02-12T17:10:41.153711Z 0 [Note] InnoDB: Compressed tables use zlib 1.2.7
2019-02-12T17:10:41.153715Z 0 [Note] InnoDB: Using Linux native AIO
2019-02-12T17:10:41.153902Z 0 [Note] InnoDB: Number of pools: 1
2019-02-12T17:10:41.153973Z 0 [Note] InnoDB: Using CPU crc32 instructions
2019-02-12T17:10:41.174468Z 0 [Note] InnoDB: Initializing buffer pool, total size = 18G, instances = 8, chunk size = 128M
2019-02-12T17:10:41.371813Z 0 [Note] InnoDB: Completed initialization of buffer pool
2019-02-12T17:10:41.401599Z 0 [Note] InnoDB: If the mysqld execution user is authorized, page cleaner thread priority can be changed. See the man page of setpriority().
2019-02-12T17:10:41.414873Z 0 [Note] InnoDB: Recovering partial pages from the parallel doublewrite buffer at /var/lib/mysql/xb_doublewrite
2019-02-12T17:10:41.425080Z 0 [Note] InnoDB: Highest supported file format is Barracuda.
2019-02-12T17:10:41.444212Z 0 [Note] InnoDB: Log scan progressed past the checkpoint lsn 21193390186
2019-02-12T17:10:41.444235Z 0 [Note] InnoDB: Doing recovery: scanned up to log sequence number 21193394424
2019-02-12T17:10:41.444432Z 0 [Note] InnoDB: Database was not shutdown normally!
2019-02-12T17:10:41.444436Z 0 [Note] InnoDB: Starting crash recovery.
2019-02-12T17:10:41.546953Z 0 [Note] InnoDB: Created parallel doublewrite buffer at /var/lib/mysql/xb_doublewrite, size 31457280 bytes
2019-02-12T17:10:41.576387Z 0 [ERROR] InnoDB: Page [page id: space=0, page number=3] log sequence number 108677477433 is in the future! Current system log sequence number 21193394506.
2019-02-12T17:10:41.576432Z 0 [ERROR] InnoDB: Your database may be corrupt or you may have copied the InnoDB tablespace but not the InnoDB log files. Please refer to http://dev.mysql.com/doc/refman/5.7/en/
forcing-innodb-recovery.html for information about forcing recovery.
2019-02-12T17:10:41.576647Z 0 [ERROR] InnoDB: Page [page id: space=0, page number=2] log sequence number 132140291279 is in the future! Current system log sequence number 21193394506.
2019-02-12T17:10:41.576670Z 0 [ERROR] InnoDB: Your database may be corrupt or you may have copied the InnoDB tablespace but not the InnoDB log files. Please refer to http://dev.mysql.com/doc/refman/5.7/en/
forcing-innodb-recovery.html for information about forcing recovery.
2019-02-12T17:10:41.576922Z 0 [ERROR] InnoDB: Page [page id: space=0, page number=4] log sequence number 21194400206 is in the future! Current system log sequence number 21193394506.
2019-02-12T17:10:41.576948Z 0 [ERROR] InnoDB: Your database may be corrupt or you may have copied the InnoDB tablespace but not the InnoDB log files. Please refer to http://dev.mysql.com/doc/refman/5.7/en/
forcing-innodb-recovery.html for information about forcing recovery.
2019-02-12T17:10:41.577209Z 0 [ERROR] InnoDB: Page [page id: space=0, page number=11] log sequence number 132140749179 is in the future! Current system log sequence number 21193394506.
2019-02-12T17:10:41.577226Z 0 [ERROR] InnoDB: Your database may be corrupt or you may have copied the InnoDB tablespace but not the InnoDB log files. Please refer to http://dev.mysql.com/doc/refman/5.7/en/
forcing-innodb-recovery.html for information about forcing recovery.
2019-02-12T17:10:41.577858Z 0 [ERROR] InnoDB: Page [page id: space=0, page number=6] log sequence number 132140702919 is in the future! Current system log sequence number 21193394506.
2019-02-12T17:10:41.577877Z 0 [ERROR] InnoDB: Your database may be corrupt or you may have copied the InnoDB tablespace but not the InnoDB log files. Please refer to http://dev.mysql.com/doc/refman/5.7/en/
forcing-innodb-recovery.html for information about forcing recovery.
2019-02-12T17:10:41.578094Z 0 [ERROR] InnoDB: Page [page id: space=0, page number=330] log sequence number 132140702919 is in the future! Current system log sequence number 21193394506.
2019-02-12T17:10:41.578112Z 0 [ERROR] InnoDB: Your database may be corrupt or you may have copied the InnoDB tablespace but not the InnoDB log files. Please refer to http://dev.mysql.com/doc/refman/5.7/en/
forcing-innodb-recovery.html for information about forcing recovery.
2019-02-12T17:10:41.578328Z 0 [ERROR] InnoDB: Page [page id: space=0, page number=790] log sequence number 21193512754 is in the future! Current system log sequence number 21193394506.
2019-02-12T17:10:41.578344Z 0 [ERROR] InnoDB: Your database may be corrupt or you may have copied the InnoDB tablespace but not the InnoDB log files. Please refer to http://dev.mysql.com/doc/refman/5.7/en/
forcing-innodb-recovery.html for information about forcing recovery.
2019-02-12T17:10:41.578555Z 0 [ERROR] InnoDB: Page [page id: space=0, page number=45] log sequence number 21194412806 is in the future! Current system log sequence number 21193394506.

Что происходит

Была повреждена одна или более таблиц бд, особенно это относится к InnoDB

Как правило если исправить эту ошибку то работоспособность БД восстановится.

В противном случае нам прийдётся делать дамп всех БД и переустанавливать mysql

Востанавливаем базы данных

Когда innodb вообще не запускается, нам прийдутся зайти в защитный режим, для этого добавим в /etc/my.cnf

innodb_force_recovery = 1

Место положение файла зависит от ОС

И попробуем заново запустить mysql.

Если старт не происходит, увеличиваем цифру с шагом в единицу и пытаемся запустить бд.

innodb_force_recovery = 2

Чем больше цифра, тем больше будет ограничений при старте, так что имеет смысл постепенно повышать значение, подобрав минимально подходящую, максимальное значение innodb_force_recovery = 8

В моем случае старт пошёл на =2, но одна из бд падала при обращение к ней и заработала только на 6.

Во многих мануалах встречается так же рекомендация по смене порта, и тут все просто, если обратиться к битой таблице то может упасть вся бд, а если с сайта обращение к ней то, некому будет мешать восстанавливать данные. Так что мы меняем порт, тем самым делаем невозможным подключиться к БД сайтам.

Внимание! Обязательно сделайте резервную копию БД перед началом работы. Остановите mysql и полностью скопируйте папку /var/lib/mysql, любые изменения в текущей бд могут привести к потере даных!

Делаем дамп всех БД, обычно рекомендуют сделать mysqldump -u root -p —all-databases —skip-lock-tables > alldb.sql с вариациями, но нам нужно понять кто не корректно и где дамптися так что я делаю по другому.

В начале посмотрим можем ли мы прочитать названия БД

mysql -uroot -p******** -e'show databases;'
[root@centos-75-64-minimal mysql]# mysql -uroot -p******s -e’show databases;'
±--------±
| Database |
±--------±
| information_schema |
| dbami-com |
| dbhikvisionpro |
| performance_schema |
| sitemanager |
| sys |
±--------±

У нас есть список БД и мы можем сделать дамп каждой по отдельности.

Создадим директорию для бэкапов, я делаю это не в /tmp поскольку может понадобиться перезагрузиться а в зависимости от способа монтирования, она может перетереться при загрузке

 mkdir -p /var/backup/mysql

Возьмём список бд в цикл и будем дампить каждую из них по отдельности, в купе с этим возвращать код завершения, за одно уберём системные БД из списка.

for i in `mysql -uroot -p******** -e'show databases;' | grep -v information_schema | grep -v performance_schema | grep -v Database`; do mysqldump -uroot -p******** $i > /var/backup/mysql/$i.sql || echo "$i $?";done

Если дамп прошёл успешно, то можно запускать

mysqlcheck --auto-repair -o --all-databases

Если и он справился удачно то можно попробовать удалить innodb_force_recovery из my.cnf и перезагрузить mysql

Но мы будем разбирать менее оптимистичный сценарий.

[root@centos-75-64-minimal mysql]# for i in `mysql -uroot -e’show databases;' | grep -v information_schema | grep -v performance_schema | grep -v Database`; do mysqldump -uroot -no-create-info $i > /var/backup/mysql/$i.sql || echo «$i $?«;done
mysqldump: Error: 'Lost connection to MySQL server during query' when trying to dump tablespaces
mysqldump: Couldn’t execute 'SHOW VARIABLES LIKE 'ndbinfo_version'': MySQL server has gone away (2006)
dbhikvisionpro 2
mysqldump: Got error: 2002: Can’t connect to local MySQL server through socket '/var/lib/mysqld/mysqld.sock' (111) when trying to connect
sitemanager 2
mysqldump: Got error: 2002: Can’t connect to local MySQL server through socket '/var/lib/mysqld/mysqld.sock' (111) when trying to connect

Как мы видим что-то пошло не так, при обращение к одной из бд произошла ошибка, и она привела к падению всего mysql, дальше дамп был не возможен. В данном случае mysql пришлось снимать kill −9 поскольку другим способом демон не желал ни работать ни корректно останавливаться.

Посмотрим что нам удалось выгрузить:

root@centos-75-64-minimal mysql]# ls -la
total 597616
drwxr-xr-x 2 root root 4096 Feb 18 19:43 .
drwxr-xr-x 3 root root 4096 Feb 18 19:37 ..
-rw-r—r— 1 root root 611926379 Feb 18 19:43 dbami-com.sql
-rw-r—r— 1 root root 1563 Feb 18 19:43 dbhikvisionpro.sql
-rw-r—r— 1 root root 0 Feb 18 19:43 sitemanager.sql

Как мы видим, дамп корректно был завершена только для одной dbami-com.sql (не нулевой размер, dbhikvisionpro, это или часть некорректного дампа, или в нашем случае, ошибка была в первой же таблице по этому дамп содержал только общий заголовок и не имел внутри вообще никакой информации. Все последующие БД не имели размера поскольку sql уже не отвечал.

[root@centos-75-64-minimal mysql]# cat dbhikvisionpro.sql
— MySQL dump 10.13 Distrib 5.7.23–25, for Linux (x86_64)
-
— Host: localhost Database: dbhikvisionpro
— --------------------------
— Server version 5.7.23–25
/*!40101 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */;
/*!40101 SET @OLD_CHARACTER_SET_RESULTS=@@CHARACTER_SET_RESULTS */;
/*!40101 SET @OLD_COLLATION_CONNECTION=@@COLLATION_CONNECTION */;
/*!40101 SET NAMES utf8 */;
/*!40103 SET @OLD_TIME_ZONE=@@TIME_ZONE */;
/*!40103 SET TIME_ZONE='+00:00' */;
/*!40014 SET @OLD_UNIQUE_CHECKS=@@UNIQUE_CHECKS, UNIQUE_CHECKS=0 */;
/*!40014 SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0 */;
/*!40101 SET @OLD_SQL_MODE=@@SQL_MODE, SQL_MODE='NO_AUTO_VALUE_ON_ZERO' */;
/*!40111 SET @OLD_SQL_NOTES=@@SQL_NOTES, SQL_NOTES=0 */;
/*!50717 SELECT COUNT(*) INTO @rocksdb_has_p_s_session_variables FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_SCHEMA = 'performance_schema' AND TABLE_NAME = 'session_variables' */;
/*!50717 SET @rocksdb_get_is_supported = IF (@rocksdb_has_p_s_session_variables, 'SELECT COUNT(*) INTO @rocksdb_is_supported FROM performance_schema.session_variables WHERE VARIABLE_NAME='rocksdb_bulk_load'', 'SELECT 0') */;
/*!50717 PREPARE s FROM @rocksdb_get_is_supported */;
/*!50717 EXECUTE s */;
/*!50717 DEALLOCATE PREPARE s */;
/*!50717 SET @rocksdb_enable_bulk_load = IF (@rocksdb_is_supported, 'SET SESSION rocksdb_bulk_load = 1', 'SET @rocksdb_dummy_bulk_load = 0') */;
/*!50717 PREPARE s FROM @rocksdb_enable_bulk_load */;
/*!50717 EXECUTE s */;
/*!50717 DEALLOCATE PREPARE s */;

Проверим догадку, так ли это, зайдем в mysql и попробуем посмотреть список таблиц.

mysql> use dbhikvisionpro
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with
Databases changed~
Mysql>
show tables;
mysql> show tables;
No connection. Trying to reconnect…
ERROR 2002 (HY000): Can’t connect to local MySQL server through socket '/var/lib/mysqld/mysqld.sock' (111)
ERROR:

SQL не могла вернуть даже список таблиц, мало того от этого запроса упала вся БД и не отвечала до полной отчистки памяти, принудительно через 

 ps aux | grep mysql

и 

kill -9 ***

Убедившись что mysql полностью остановлен мы заново его запускаем.

Следующий вопрос, как сделать дамб базы данных не имея возможности посмотреть список таблиц, ответ достаточно очевиден нам нужно сделать этот список самим.

cd /var/lib/mysql/ваша бд/

Получаем список таблиц

Внимание! Такой способ возможен только при условии что innodb_file_per_table=1

ls *.ibd | grep -v "FTS"| cut -d '.' -f 1
[root@centos-75-64-minimal dbhikvisionpro]# ls *.ibd | grep -v «FTS»| cut -d '.' -f 1
b_abtest
b_admin_notify
b_admin_notify_lang
b_adv_banner_2_country
b_adv_banner_2_day
b_adv_banner_2_group
b_adv_banner_2_page
b_adv_banner_2_site
b_adv_banner_2_stat_adv
b_adv_banner_2_weekday
b_adv_banner
b_adv_contract_2_page
b_adv_contract_2_site
b_adv_contract_2_type
b_adv_contract_2_user
b_adv_contract_2_weekday
b_adv_contract
b_adv_type
b_agent
b_app_password
b_b24connector_buttons
b_bitrixcloud_option
b_blog_category
b_blog_comment
b_blog_group
b_blog
b_blog_image
b_blog_post_category
...

Имея список таблиц сделаем дамп каждой таблицы по отдельности и и будем смотреть что у нас с ними.

Создаем папку для дампа таблиц

mkdir /tmp/dbhikvisionpro

И делаем дамп таблиц. Поскольку мы делаем дамп каждой таблицы по отдельности, мы можем следить за кодом завершения каждой из них.

for i in `ls *.ibd | grep -v "FTS"| cut -d '.' -f 1`; do mysqldump -uroot dbhikvisionpro $i > /tmp/dbhikvisionpro/$i.sql || echo "$i $?";done 
# for i in `ls *.ibd | grep -v «FTS»| cut -d '.' -f 1`; do mysqldump -uroot dbhikvisionpro $i > /tmp/dbhikvisionpro/$i.sql || echo «$i $?«;done
mysqldump: Error: 'Lost connection to MySQL server during query' when trying to dump tablespaces
mysqldump: Couldn’t execute 'SHOW VARIABLES LIKE 'ndbinfo_version'': MySQL server has gone away (2006)
b_xml_tree_import_1c 2
mysqldump: Got error: 2002: Can’t connect to local MySQL server through socket '/var/lib/mysqld/mysqld.sock' (111) when trying to connect

И видим что при обращение к таблице b_xml_tree_import_1c , код ответа 2, и опять упала бд, все последующие так же не читаются.

Все что нам остается, это пропустить данную таблицы и делать дамп дальше, постепенно исключая убитые таблицы, как правило это 1-2 таблицы, в моем случае это била таблица импорта из 1с и таблица сессий, обе не важные так что я их удалил, а структуру таблицы взял стандартную для дижка.

Делаем исключение битых таблиц grep -v исключает таблицу

for i in `ls *.ibd | grep -v "FTS"| grep -v "b_xml_tree_import_1c" | grep -v "b_session" | cut -d '.' -f 1`; do mysqldump -uroot dbhikvisionpro $i > /tmp/dbhikvisionpro/$i.sql || echo "$i $?";done 
drwxrwxrwt. 18 root 4096 Feb 18 21:36.
-rw-r-r- 1 root 7459 Feb 18 21:35 b_abtest.sql
-rw-r-r- 1 root 3166 Feb 18 21:35 b_admin_notify_lang.sql
-rw-r-r- 1 root 3318 Feb 18 21:35 b_admin_notify.sql
-rw-r-r- 1 root 3301 Feb 18 21:35 b_adv_banner_2_country.sql
-rw-r-r- 1 root 3140 Feb 18 21:35 b_adv_banner_2_day.sql
-rw-r-r- 1 root 3028 Feb 18 21:35 b_adv_banner_2_group.sql
-rw-r-r- 1 root 3163 Feb 18 21:35 b_adv_banner_2_page.sql
-rw-r-r- 1 root 3031 Feb 18 21:35 b_adv_banner_2_site.sql
-rw-r-r- 1 root 3055 Feb 18 21:35 b_adv_banner_2_stat_adv.sql
-rw-r-r- 1 root 3109 Feb 18 21:35 b_adv_banner_2_weekday.sql
-rw-r-r- 1 root 5759 Feb 18 21:35 b_adv_banner.sql
-rw-r-r- 1 root 3183 Feb 18 21:35 b_adv_contract_2_page.sql
-rw-r-r- 1 root 3102 Feb 18 21:35 b_adv_contract_2_site.sql
-rw-r-r- 1 root 3110 Feb 18 21:35 b_adv_contract_2_type.sql
-rw-r-r- 1 root 3160 Feb 18 21:36 b_adv_contract_2_user.sql
-rw-r-r- 1 root 5984 Feb 18 21:36 b_adv_contract_2_weekday.sql
-rw-r-r- 1 root 4099 Feb 18 21:36 b_adv_contract.sql
-rw-r-r- 1 root 3274 Feb 18 21:36 b_adv_type.sql
-rw-r-r- 1 root 11749 Feb 18 21:36 b_agent.sql
-rw-r-r- 1 root 3515 Feb 18 21:36 b_app_password.sql
-rw-r-r- 1 root 3153 Feb 18 21:36 b_b24connector_buttons.sql
-rw-r-r- 1 root 3424 Feb 18 21:36 b_bitrixcloud_option.sql
-rw-r-r- 1 root 3063 Feb 18 21:36 b_blog_category.sql
-rw-r-r- 1 root 3934 Feb 18 21:36 b_blog_comment.sql
-rw-r-r- 1 root 3054 Feb 18 21:36 b_blog_group.sql
-rw-r-r- 1 root 3402 Feb 18 21:36 b_blog_image.sql
-rw-r-r- 1 root 3175 Feb 18 21:36 b_blog_post_category.sql
-rw-r-r- 1 root 3200 Feb 18 21:36 b_blog_post_param.sql
-rw-r-r- 1 root 5096 Feb 18 21:36 b_blog_post.sql
-rw-r-r- 1 root 3155 Feb 18 21:36 b_blog_site_path.sql
-rw-r-r- 1 root 3178 Feb 18 21:36 b_blog_socnet_rights.sql
-rw-r-r- 1 root 2987 Feb 18 21:36 b_blog_socnet.sql
-rw-r-r- 1 root 4513 Feb 18 21:36 b_blog.sql
-rw-r-r- 1 root 3343 Feb 18 21:36 b_blog_trackback.sql
-rw-r-r- 1 root 3054 Feb 18 21:36 b_blog_user2blog.sql
……

Теперь у нас есть все таблицы и мы можем смотреть каждую по отдельности. Убедившись что все с ними хорошо, поэтому нам больше не нужны таблицы по отдельности, нам нужен один файл.

for i in `ls *.ibd | grep -v "FTS"| grep -v "b_xml_tree_import_1c" | grep -v "b_session" | cut -d '.' -f 1`; do mysqldump -uroot dbhikvisionpro $i >> /tmp/dbhikvisionpro/dbhikvisiononpro.sql || echo "$i $?";done

В результате получаем полноценный дамб за исключением двух таблиц. Как вариант в mysqldump есть —ignore-table=DATABASE.table1 но там нужно писать баш скрипт и многие жалуются что он не работает корректно, в моем же случае цикл у меня уже был сделал и не принципиально как он будет делаться.

Все что нам остаётся удалить проблемные БД, если не получается их удалить то проверяем диск на вероятные сбои как физические так и логические, если же все хорошо но база не удаляется, остаётся только полностью переустановить mysql.

Заново инициализируем mysql

Поскольку все БД мы уже получили, нам нужно восстановить работоспособность mysql, DROP TABLES не помогает, в связи с этим, мы удалим физически все БД и инициализируем чистый mysql

Остановим mysql

systemctl stop mysqld

Удалим полностью папку mysql

rm -rf /var/lib/mysqld

Инициализируем новую БД

mysqld --initialize-insecure --basedir=/usr --datadir=/var/lib/mysql

Создаем сокет

mkfifo /var/lib/mysqld/mysqld.sock

Права

chown -R mysql /var/lib/mysqld/mysqld.sock

Нам нужно установить root пароль, устанавливаем environment

systemctl set-environment MYSQLD_OPTS="--skip-grant-tables"

Заходим в mysql без пароля

systemctl start mysqld	mysql -u root

Обновляем пароль root

mysql> UPDATE mysql.user SET authentication_string = PASSWORD('MyNewPassword')
-> WHERE User = 'root' AND Host = 'localhost';
mysql> FLUSH PRIVILEGES;
mysql> quit

новый вариант, просто делаем и тот и тот

mysql> ALTER USER 'root'@'localhost' IDENTIFIED BY 'MyNewPass';

Останавливаем sql и возвращаемся в нормальный режим

systemctl stop mysqld
systemctl unset-environment MYSQLD_OPTS
systemctl start mysqld

Проверяем

mysql -u root -p

Источник

Like this post? Please share to your friends:
  • Mysql clear error log
  • Myriwell 3d ручка error
  • Myisamchk error 140 when opening myisam table
  • Myheritage произошла ошибка пожалуйста попытайтесь еще раз позже
  • My friend pedro blood bullets bananas has encountered an error and must close