странные результаты при копировании базы данных вручную на другой сервер [дубликат]

Предположим, у вас есть большой проект, написанный на c ++, который содержит тысячу файлов .cpp и тысячу файлов .h. И давайте предположим, что проект также зависит от десяти статических библиотек. Скажем, мы работаем над Windows, и мы строим наш проект в Visual Studio 20xx. Когда вы нажимаете Ctrl + F7 Visual Studio, чтобы начать компиляцию всего решения (предположим, что у нас есть только один проект в решении)

В чем смысл компиляции?

  • Visual Studio выполните поиск в файле .vcxproj и начните компилировать каждый файл с расширением .cpp. Порядок компиляции не определен. Поэтому вы не должны предполагать, что файл main.cpp скомпилирован сначала
  • . Если файлы .cpp зависят от дополнительных файлов .h, чтобы найти символы, которые могут или не могут быть определены в файл .cpp
  • Если существует один .cpp-файл, в котором компилятор не смог найти один символ, ошибка времени компилятора вызывает сообщение Символ x не может быть найден
  • Для каждого файла с расширением .cpp создается объектный файл .o, а также Visual Studio записывает вывод в файл с именем ProjectName.Cpp.Clean.txt , который содержит все объектные файлы, которые должны обрабатывается компоновщиком.

Второй этап компиляции выполняется Linker.Linker должен объединить весь объектный файл и построить окончательно вывод (который может быть исполняемым или библиотекой)

Шаги при связывании проекта

  • Разберите все объектные файлы и найдите определение, которое было объявлено только в заголовках (например: Код одного метода класса, как указано в p повторные ответы или событие инициализация статической переменной, которая является членом внутри класса)
  • Если один символ не может быть найден в объектных файлах, он также выполняется в дополнительных библиотеках. Для добавления новой библиотеки в project Свойства конфигурации -> Каталоги VC ++ -> Библиотечные каталоги, и здесь вы указали дополнительную папку для поиска библиотек и Свойства конфигурации -> Linker -> Input для указания имени библиотеки. -Если линкер не смог найти символ, который вы пишете в одном .cpp, он вызывает ошибку времени компоновщика, которая может звучать как error LNK2001: unresolved external symbol "void __cdecl foo(void)" (?foo@@YAXXZ)

Наблюдение

  1. После того, как Linker найдет один символ, он не ищет в других библиотеках для него
  2. Порядок ссылок на библиотеки имеет значение.
  3. Если Linker находит внешний символ в одной статической библиотеке, он включает в себя символ на выходе проекта. Однако, если библиотека является общей (динамической), он не включает в себя код (символы) на выходе, но Run-Time могут возникнуть сбои

Как решить эту ошибку

Ошибка времени компилятора:

  • Убедитесь, что вы правильно выполнили синтаксический проект c ++.

Ошибка времени компоновщика

  • Определите все символы, которые вы объявляете в ваших файлах заголовков.
  • Используйте #pragma once, чтобы компилятор не включал один заголовок если он уже был включен в текущий .cpp, который скомпилирован
  • Убедитесь, что ваш exter nal library не содержит символов, которые могут вступать в конфликт с другими символами, которые вы определили в ваших файлах заголовков.
  • Когда вы используете шаблон, чтобы убедиться, что вы включаете определение каждой функции шаблона в файл заголовка для разрешения компилятор для создания соответствующего кода для любых экземпляров.
207
задан rapvelopment 10 December 2013 в 04:45
поделиться

29 ответов

Перейти к: xampp\mysql\data\dbname внутри dbname имеют файл tablename.frm и tablename.ibd. удалите его и перезапустите mysql и повторите попытку.

1
ответ дан Abu Sufian 1 September 2018 в 09:45
поделиться

Была аналогичная проблема с таблицей призраков. К счастью, у меня был дамп SQL перед сбоем.

В моем случае мне пришлось:

  1. Остановить mySQL
  2. Перенести ib * файлы из /var/mysql отключить резервную копию
  3. Удалить /var/mysql/{dbname}
  4. Перезапустить mySQL
  5. Восстановить пустую базу данных
  6. Восстановить файл дампа

ПРИМЕЧАНИЕ. Требуется файл дампа.

5
ответ дан bjb568 1 September 2018 в 09:45
поделиться

Я не знаю причины, но в моем случае я решил просто отключить и включить проверку внешних ключей

SET FOREIGN_KEY_CHECKS=0;
SET FOREIGN_KEY_CHECKS=1;
2
ответ дан Bruno Caponi 1 September 2018 в 09:45
поделиться

Если в названии таблицы есть период, это не сработает для SELECT * FROM poorly_named.table;

Используйте обратные выходы, чтобы найти его в таблице SELECT * FROM `poorly_named.table`;

0
ответ дан Chris 1 September 2018 в 09:45
поделиться

Похоже, что проблема должна выполняться (по крайней мере, у меня и нескольких других) с недопустимыми (поврежденными?) файлами логов innodb.

Вот решения, большинство из которых требуют перезагрузки mysql.

  • Восстановить ваши файлы журналов ( Удалить и перезагрузите mysql )
  • Измените размер файлов журнала (MySql 5.6+ будет регенерировать файл для вас)
  • Если вы делаете какой-либо тип перенос данных, убедитесь, что вы правильно перенесли нужный файл и дали ему разрешения, как уже указывали другие
  • Проверьте разрешения ваших данных и файлов журналов, что mysql является владельцем обоих
  • Если все остальное не работает, вам, вероятно, придется воссоздать базу данных
2
ответ дан Community 1 September 2018 в 09:45
поделиться
11
ответ дан dev-null-dweller 1 September 2018 в 09:45
поделиться
  1. stop mysqld
  2. backup mysql folder: cp -a /var/lib/mysql /var/lib/mysql-backup
  3. скопировать папку базы данных с старой машины на /var/lib/mysql
  4. переопределить ib * ( ib_logfile *, ibdata) из старой базы данных
  5. start mysqld
  6. dump dabase
  7. mysqldump >dbase.mysql
  8. остановить службу mysql
  9. удалить /var/lib/mysql
  10. переименовать /var/lib/mysql-backup в /var/lib/mysql
  11. запустить mysqld
  12. создать базу данных
  13. mysqldump < dbase.mysql
14
ответ дан Djizeus 1 September 2018 в 09:45
поделиться

Я получаю эту проблему, когда случай для имени таблицы, который я использую, отключен. Таким образом, таблица называется «db», но я использовал «DB» в select statement. Убедитесь, что корпус тот же.

21
ответ дан dkinzer 1 September 2018 в 09:45
поделиться
21
ответ дан golimar 1 September 2018 в 09:45
поделиться

Для меня в Mac OS (MySQL DMG Installation) простая перезагрузка сервера MySQL решила проблему. Я предполагаю, что гибернация вызвала это.

39
ответ дан guaka 1 September 2018 в 09:45
поделиться

У меня была та же проблема, но это произошло не из-за скрытого персонажа или «таблицы schroedinger». Проблема (как указано выше) появилась после восстановления. Я использую администратор MySQL версии 1.2.16. Когда восстановление должно быть выполнено, вы должны снять флажок ORIGINAL в целевой схеме и выбрать имя своей базы данных из раскрывающегося списка. После этого проблема была исправлена. По крайней мере, это было причиной в моей базе данных.

0
ответ дан hims056 1 September 2018 в 09:45
поделиться

Возможно, у вас есть скрытый символ в имени вашей таблицы. Они не отображаются, когда вы показываете таблицы. Можете ли вы сделать «SHOW CREATE TABLE TABLE_ONE» и вкладку заполнить «TABLE_ONE» и посмотреть, содержит ли она какие-либо скрытые символы. Кроме того, вы попытались сбросить и переделать таблицы. Просто чтобы убедиться, что с привилегиями ничего нет, и что скрытых символов нет.

1
ответ дан Hoopdady 1 September 2018 в 09:45
поделиться

Сегодня возникла такая же проблема. Это проблема «Чувствительность регистра идентификатора» mysql.

Пожалуйста, проверьте соответствующий файл данных. Очень вероятно, что имя файла в нижнем регистре файловой системы, но имя таблицы, указанное в команде «show tables», находится в верхнем регистре. Если системная переменная «lower_case_table_names» равна 0, запрос вернет «таблица не существует», потому что сопоставление имен чувствительно к регистру, когда «lower_case_table_names» равно 0.

1
ответ дан Hudson Liang 1 September 2018 в 09:45
поделиться

После переустановки MySQL у меня возникла такая же проблема, кажется, что во время установки некоторые файлы конфигурации, хранящие данные о файлах журнала InnoDB, эти файлы ib_logfile * (они являются файлами журнала справа?), перезаписываются. Чтобы решить эту проблему, я просто удалил файлы ib_logfile *.

5
ответ дан JCM 1 September 2018 в 09:45
поделиться

Я потратил три дня на этот кошмар. В идеале у вас должна быть резервная копия, которую вы можете восстановить, а затем просто опустите поврежденную таблицу. Подобные ошибки могут привести к увеличению вашего ibdata1 огромного (размер 100 ГБ + для скромных таблиц)

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

Итак, в качестве обходного пути перейдите к /var/log/mysql/database_name/ и удалите имя_таблицы. *

Затем немедленно попытайтесь сбросить таблицу; это должно теперь работать. Теперь восстановите базу данных в новой базе данных и перестройте отсутствующие таблицы. Затем выгрузите разбитую базу данных.

В нашем случае мы также постоянно получали mysql has gone away сообщения в случайные интервалы во всех базах данных; как только поврежденная база данных была удалена, все стало нормальным.

9
ответ дан Krythic 1 September 2018 в 09:45
поделиться

Попробуйте запустить sql-запрос, чтобы отбросить табличное пространство перед тем, как выполнить idb-файл:

ALTER TABLE mydatabase.mytable DISCARD TABLESPACE;

Копировать idb-файл

ALTER TABLE mydatabase.mytable IMPORT TABLESPACE;

Перезапустить MySql

7
ответ дан l0pan 1 September 2018 в 09:45
поделиться
1
ответ дан Onur Kucukkece 1 September 2018 в 09:45
поделиться

Скопировать только файл ibdata1 из старого каталога данных. Не копируйте файлы ib_logfile1 или ib_logfile0. Это заставит MySQL больше не запускаться.

1
ответ дан Plabon Dutta 1 September 2018 в 09:45
поделиться

O.k. это будет звучать довольно абсурдно, но я буду юмором. Для меня проблема решена, когда я изменил свое заявление на следующее:

SELECT * FROM `table`

Я сделал два изменения 1.) Сделал нижний регистр имени таблицы - я знаю !! 2.) Используется специальный символ цитаты = `: Это ключ над вашей TAB

. Решение звучит абсурдно, но это сработало, и это субботний вечер, и я работаю с 9 утра. Итак, возьмем:)

Удачи.

7
ответ дан PlanetUnknown 1 September 2018 в 09:45
поделиться

У меня возникла эта проблема после обновления WAMP, но без резервного копирования базы данных.

Это сработало для меня:

  1. Остановить новый WAMP
  2. Скопировать поверх требуемые каталоги базы данных и файл ibdata1 из старой установки WAMP
  3. Удалить ib_logfile0 и ib_logfile1
  4. Запустить WAMP

Теперь вы должны быть в состоянии сделать резервные копии ваших баз данных. Однако после перезагрузки сервера у вас все еще будут проблемы. Теперь переустановите WAMP и импортируйте свои базы данных.

4
ответ дан Rohan Khude 1 September 2018 в 09:45
поделиться

В моем случае это был параметр SQLCA.DBParm.

Я использовал

SQLCA.DBParm = "Databse = "sle_database.text""

, но он должен быть

SQLCA.DBParm = "Database='" +sle_database.text+ "'"

Объяснение:

Вы собираетесь объединить три строки:

 1. Database='              -  "Database='"

 2. (name of the database)  - +sle_database.text+

 3. '                       - "'" (means " ' "  without space)

Не используйте пробелы в quatermarks. Спасибо моему коллеге Ян.

1
ответ дан Rohit Jindal 1 September 2018 в 09:45
поделиться
2
ответ дан Roman Kutlak 1 September 2018 в 09:45
поделиться

У меня была та же проблема, и я искал 2-3 дня, но решение для меня было действительно глупо.

Перезапустить mysql

$ sudo service mysql restart

Теперь таблицы становятся доступными.

7
ответ дан Siraj 1 September 2018 в 09:45
поделиться
  1. Выполнить mysqldump для базы данных:
    mysqldump -u user -ppass dbname > D:\Back-ups\dbname.sql
    
  2. Восстановить базу данных
    mysql -u user -ppass dbname < D:\Back-ups\dbname.sql
    

Теперь все таблицы в базе данных были полностью восстановлены. Попробуйте ..

SELECT * FROM dbname.tablename;
1
ответ дан Stephen Rauch 1 September 2018 в 09:45
поделиться

Я установил MariaDB на новый компьютер, остановил службу службы Mysql, переименовал папку данных в данные - я решил проблему с копированием только Mysql \ data \ table_folders и ibdata1 из разбитого файла данных HD MySql. Папка в новую установленную папку данных mysql.

Я пропустил ib_logfile0 и ib_logfile1 (в противном случае сервер не запустил службу)

Запустил службу mysql.

Затем сервер работает.

2
ответ дан Tony 1 September 2018 в 09:45
поделиться
1
ответ дан user3415481 1 September 2018 в 09:45
поделиться

Еще один ответ, который, я думаю, стоит здесь подняться (потому что я пришел сюда с той же проблемой, и это оказалось для меня ответом):

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

Вид очевидной новички, но такие вещи, как «пользователь» и «пользователи», могут отключать людей, и я подумал, что это будет полезный ответ иметь в списке здесь. :)

1
ответ дан vazor 1 September 2018 в 09:45
поделиться
1
ответ дан Yogesh Kumar Gupta 1 September 2018 в 09:45
поделиться
3
ответ дан Zoobra McFly 1 September 2018 в 09:45
поделиться
Другие вопросы по тегам:

Похожие вопросы: