проблема бэкапа mysql

MySQL/PostgreSQL/SQLite/Oracle/M$SQL/....

Модератор: terminus

Правила форума
Убедительная просьба юзать теги [code] при оформлении листингов.
Сообщения не оформленные должным образом имеют все шансы быть незамеченными.
basov
рядовой
Сообщения: 39
Зарегистрирован: 2013-06-24 16:18:01

проблема бэкапа mysql

Непрочитанное сообщение basov » 2015-07-14 16:30:50

Здравствуйте!
Делаю бэкап базы mysql в freebsd

Код: Выделить всё

mysqldump -u User -pPassword database > /path/to/backup 
База бэкапится минут 10, копирует 3021Мб и далее вылетает с ошибкой:

Код: Выделить всё

Error 2013: Lost connection to MySQL server during query when dumping table `def_table` at row: 27959
errorlog пишет:

Код: Выделить всё

150714 15:16:49  InnoDB: Page checksum 515083236, prior-to-4.0.14-form checksum 3527469123
InnoDB: stored checksum 2105647215, prior-to-4.0.14-form stored checksum 3527469123
InnoDB: Page lsn 2 4023965291, low 4 bytes of lsn at page end 4023965291
InnoDB: Page number (if stored to page already) 305017,
InnoDB: space id (if created with >= MySQL-4.1.1 and stored already) 0
InnoDB: Page may be a BLOB page
InnoDB: Database page corruption on disk or a failed
InnoDB: file read of page 305017.
InnoDB: You may have to recover from a backup.
InnoDB: It is also possible that your operating
InnoDB: system has corrupted its own file cache
InnoDB: and rebooting your computer removes the
InnoDB: error.
InnoDB: If the corrupt page is an index page
InnoDB: you can also try to fix the corruption
InnoDB: by dumping, dropping, and reimporting
InnoDB: the corrupt table. You can use CHECK
InnoDB: TABLE to scan your table for corruption.
InnoDB: See also http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
InnoDB: Ending processing because of a corrupt database page.
150714 15:16:49  InnoDB: Assertion failure in thread 683718656 in file buf0buf.c line 3660
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
150714 15:16:49 - 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.
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.

key_buffer_size=16777216
read_buffer_size=262144
max_used_connections=9
max_threads=151
thread_count=9
connection_count=9
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 133414 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

150714 15:16:50 mysqld_safe mysqld restarted
150714 15:16:52 [Warning] You need to use --log-bin to make --binlog-format work.
150714 15:16:52 InnoDB: The InnoDB memory heap is disabled
150714 15:16:52 InnoDB: Mutexes and rw_locks use GCC atomic builtins
150714 15:16:52 InnoDB: Compressed tables use zlib 1.2.5
150714 15:16:52 InnoDB: Initializing buffer pool, size = 16.0M
150714 15:16:52 InnoDB: Completed initialization of buffer pool
150714 15:16:52 InnoDB: highest supported file format is Barracuda.
InnoDB: The log sequence number in ibdata files does not match
InnoDB: the log sequence number in the ib_logfiles!
150714 15:16:52  InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Restoring possible half-written data pages from the doublewrite
InnoDB: buffer...
InnoDB: Last MySQL binlog file position 0 16099, file name ./mysql-bin.000001
150714 15:16:59  InnoDB: Waiting for the background threads to start
150714 15:17:00 InnoDB: 1.1.8 started; log sequence number 91653199455
150714 15:17:01 [Note] Event Scheduler: Loaded 0 events
150714 15:17:01 [Note] /usr/local/libexec/mysqld: ready for connections.
Version: '5.5.17'  socket: '/tmp/mysql.sock'  port: 3306  Source distribution
В чем может быть проблема?
версия mysql 5.5.17

Отправлено спустя 56 минут 51 секунду:
Вопрос решился.
Нашел его в статье http://bsdadmin.ru/index.php/database/242-restore-mysql

Хостинговая компания Host-Food.ru
Хостинг HostFood.ru
 

Услуги хостинговой компании Host-Food.ru

Хостинг HostFood.ru

Тарифы на хостинг в России, от 12 рублей: https://www.host-food.ru/tariffs/hosting/
Тарифы на виртуальные сервера (VPS/VDS/KVM) в РФ, от 189 руб.: https://www.host-food.ru/tariffs/virtualny-server-vps/
Выделенные сервера, Россия, Москва, от 2000 рублей (HP Proliant G5, Intel Xeon E5430 (2.66GHz, Quad-Core, 12Mb), 8Gb RAM, 2x300Gb SAS HDD, P400i, 512Mb, BBU):
https://www.host-food.ru/tariffs/vydelennyi-server-ds/
Недорогие домены в популярных зонах: https://www.host-food.ru/domains/

Аватара пользователя
Alex Keda
стреляли...
Сообщения: 35454
Зарегистрирован: 2004-10-18 14:25:19
Откуда: Made in USSR
Контактная информация:

проблема бэкапа mysql

Непрочитанное сообщение Alex Keda » 2015-07-17 16:59:00

InnoDB вообще без нужды лучше не юзать....

Или, хоть бы, innodb_per_file или как там оно....
Убей их всех! Бог потом рассортирует...

FiL
ст. лейтенант
Сообщения: 1374
Зарегистрирован: 2010-02-05 0:21:40

проблема бэкапа mysql

Непрочитанное сообщение FiL » 2015-07-17 18:05:36

innodb_file_per_table

юзать или не юзать innodb - это очень зависит. как по мне, так таки часто лучше юзать.
А поломаться база может независимо от того она в одном файле или во многих.

Аватара пользователя
Alex Keda
стреляли...
Сообщения: 35454
Зарегистрирован: 2004-10-18 14:25:19
Откуда: Made in USSR
Контактная информация:

проблема бэкапа mysql

Непрочитанное сообщение Alex Keda » 2015-08-04 12:28:19

Когда их много - часть таблиц целая остаётся....
Всё легче....

--
Поверь наслово администратору хостинга ;)
Убей их всех! Бог потом рассортирует...