MySql wampserver восстановление базы данных

MySql версия: 5.5.24

ПРИМЕЧАНИЕ. Каждый раз, когда я копировал старую папку "data", службы MySql останавливались и меняли значок Wamp с зеленого на оранжевый.

Решения, которые я пробовал, но не повезло:

так далее..

Раньше я получал ошибку № 2002

Сервер не отвечает (или сокет локального сервера MySQL неправильно настроен)

Я попробовал поискать и применил некоторые решения, но все равно мне не повезло. Я до сих пор не могу получить доступ к PhpMyadmin. Я вижу, что вместо зеленого значок wampserver оранжевый, потому что MySql не работает.

Через пару дней я переустанавливаю свой wampserver (той же версии), и phpmyadmin работает.. но когда я скопировал папку и файлы данных mysql (ibdata1, iblogfile0 и iblogfile1) и перезапустил сервисы, которые я получил, вернувшись к моей проблеме #2002.

Моя проблема:

Я хочу создать дамп sql своей базы данных, но не могу получить доступ к своему phpmyadmin, потому что служба MySql не работает

Вопросы:

  1. Как восстановить базу данных MySql из данных wampserver в новую установку, просто скопировав необходимые папки или файлы?
  2. Если #1 не представляется возможным, есть ли способ создать дамп sql через консоль или что-нибудь, не заходя в phpmyadmin?

Замечания:

  • У меня есть полная резервная копия оригинальной папки wamp перед переустановкой сервера.
  • У меня нет старого дампа sql для восстановления.

MySQL LOG:

141209 21:54:40 [Note] Plugin 'FEDERATED' is disabled.
141209 21:54:40 InnoDB: The InnoDB memory heap is disabled
141209 21:54:40 InnoDB: Mutexes and rw_locks use Windows interlocked functions
141209 21:54:40 InnoDB: Compressed tables use zlib 1.2.3
141209 21:54:40 InnoDB: Initializing buffer pool, size = 128.0M
141209 21:54:40 InnoDB: Completed initialization of buffer pool
141209 21:54:40 InnoDB: highest supported file format is Barracuda.
InnoDB: Log scan progressed past the checkpoint lsn 52664174
141209 21:54:40  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: Doing recovery: scanned up to log sequence number 56879679
141209 21:54:41  InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percents: 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 
InnoDB: Apply batch completed
InnoDB: Last MySQL binlog file position 0 2383366, file name .\mysql-bin.000115
141209 21:54:42  InnoDB: Waiting for the background threads to start
141209 21:54:43  InnoDB: Assertion failure in thread 636 in file fut0lst.ic line 83
InnoDB: Failing assertion: addr.page == FIL_NULL || addr.boffset >= FIL_PAGE_DATA
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.
141209 21:54:43 InnoDB: 1.1.8 started; log sequence number 56879679
InnoDB: Thread 5328 stopped in file ibuf0ibuf.c line 3165
Источник

0 ответов

Другие вопросы по тегам