Импорт базы данных |
Здравствуйте, гость ( Вход | Регистрация )
Импорт базы данных |
23.4.2017, 21:20
Сообщение
#1
|
|
Пресмертн. Проф. Патологич. Библиомансии Возраст: 50 Группа: Пользователи Сообщений: 24 683 Регистрация: 13.1.2005 Из: Владимир Пользователь №: 8 330 Вставить ник Цитата |
Пытаюсь импортировать базу данных сайта на новый хостинг через phpMyAdmin.
Но размер моей базы данных превышает допустимый. Даже в архивированном виде (.zip) вдвое больше допустимого. Данная проблема имеет какое-нибудь решение? Ну в смысле, можно ли обойти данное ограничение по размеру? --------------------
На каждого, кто пляшет русалочьи пляски, есть Finnegan, который умеет ходить по воде.
|
|
|
| |
24.4.2017, 16:46
Сообщение
#21
|
||
Пресмертн. Проф. Патологич. Библиомансии Возраст: 50 Группа: Пользователи Сообщений: 24 683 Регистрация: 13.1.2005 Из: Владимир Пользователь №: 8 330 Вставить ник Цитата |
Настроил редирект по найденному старому .htacess
Вроде все заработало. Но есть досадные ошибки. 1. При первом заходе на сайт на страницах сбита кодировка, текст отображается знаками вопроса. Хотя в меню текст отображается правильно. При перезагрузке страницы кодировка устаканивается и все буквы отображаются как надо. Нужно что-то еще прописать в файл .htacess, чтоб отладить кодировку? 2. Статические страницы отображаются без ошибок. А вот страницы с новостями с ошибкой Цитата Warning: Call-time pass-by-reference has been deprecated; If you would like to pass it by reference, modify the declaration of exec_acts(). If you would like to enable call-time pass-by-reference, you can set allow_call_time_pass_reference to true in your INI file in /storage/h7/113/1450113/public_html/engine/includes/news.php on line 158 Warning: Call-time pass-by-reference has been deprecated; If you would like to pass it by reference, modify the declaration of exec_acts(). If you would like to enable call-time pass-by-reference, you can set allow_call_time_pass_reference to true in your INI file in /storage/h7/113/1450113/public_html/engine/includes/news.php on line 449 Я правильно понимаю, что мне нужно в файле news.php изменить значение на true в строчках 158 и 449? 3. Я импортировал базу данных от июля 2016. Но у меня в папке с бекапами есть файл backup_2017_04_18_10_57 Могу я через этот файл восстановить базу данных до состояния на апрель 2017? И если да, то как технически это сделать? В админ панели сайта не могу найти такую опцию. --------------------
На каждого, кто пляшет русалочьи пляски, есть Finnegan, который умеет ходить по воде.
|
|
|
||
24.4.2017, 17:22
Сообщение
#22
|
|
Новенький Возраст: 48 Группа: Пользователи Сообщений: 9 643 Регистрация: 21.4.2003 Из: Владимир Пользователь №: 2 702 Вставить ник Цитата |
Нужно что-то еще прописать в файл .htacess, чтоб отладить кодировку? Если сайт в виндовской кодировке, то Код AddDefaultCharset windows-1251 Я правильно понимаю, что мне нужно в файле news.php изменить значение на true в строчках 158 и 449? Нет. У вас выводятся предупреждения, их надо отключить. Например, в том же .htaccess Код php_flag display_errors off Если, конечно, движок сайта не перенастраивает этот флаг сам. --------------------
Ну, допустим, про кипятильник я наврал... Но факт остается фактом!
|
|
|
24.4.2017, 18:40
Сообщение
#23
|
|
Пресмертн. Проф. Патологич. Библиомансии Возраст: 50 Группа: Пользователи Сообщений: 24 683 Регистрация: 13.1.2005 Из: Владимир Пользователь №: 8 330 Вставить ник Цитата |
Нет. У вас выводятся предупреждения, их надо отключить. Например, в том же .htaccess Предупреждения исчезли. Если сайт в виндовской кодировке, то Код AddDefaultCharset windows-1251 А вот знаки вопроса периодически появляются на некоторых страницах. И пропадают после перезагрузки. Кроме изменения .htacess, прописал cp_1251 general ci в кодировке базы данных (в phpMyAdmin) Но проблема по-прежнему имеет место быть. Поправка. в базе данных в phpMyAdmin опять кодировка utf8mb4_unicode_ci Видимо там исправления только на текущую сессию сохраняются. Странно. Сообщение отредактировал Finnegan - 24.4.2017, 18:46 --------------------
На каждого, кто пляшет русалочьи пляски, есть Finnegan, который умеет ходить по воде.
|
|
|
25.4.2017, 0:04
Сообщение
#24
|
|
Новенький Группа: Пользователи Сообщений: 9 614 Регистрация: 9.9.2002 Пользователь №: 1 805 Вставить ник Цитата |
Предупреждения исчезли. А вот знаки вопроса периодически появляются на некоторых страницах. И пропадают после перезагрузки. Кроме изменения .htacess, прописал cp_1251 general ci в кодировке базы данных (в phpMyAdmin) Но проблема по-прежнему имеет место быть. Поправка. в базе данных в phpMyAdmin опять кодировка utf8mb4_unicode_ci Видимо там исправления только на текущую сессию сохраняются. Странно. ничего странного: php файл в другой кодировке надо все в порядок приводить |
|
|
25.4.2017, 12:25
Сообщение
#25
|
||
Пресмертн. Проф. Патологич. Библиомансии Возраст: 50 Группа: Пользователи Сообщений: 24 683 Регистрация: 13.1.2005 Из: Владимир Пользователь №: 8 330 Вставить ник Цитата |
ничего странного: php файл в другой кодировке надо все в порядок приводить А как это сделать? Изменил в .htacess запись о кодировке на такую: DefaultLanguage ru AddDefaultCharset windows-1251 php_value default_charset "cp1251" Но проблема остается. Вроде сайт отображается нормально, а как зайдешь в раздел с тестами, сразу весь текст на сайте превращается в знаки вопросов Кстати. И у меня появилась идея: что если обнулить базу данных (удалить таблицы и их содержимое), оставить только пустую оболочку с именем БД и юзернеймом пользователя; и запустить через админ панель файл backup_2017_04_18_10_57 чистая база данных восстановится из этого файла? Или нужно, чтоб в БД были хоть какие-то данные и таблицы? --------------------
На каждого, кто пляшет русалочьи пляски, есть Finnegan, который умеет ходить по воде.
|
|
|
||
25.4.2017, 12:29
Сообщение
#26
|
|
Новенький Возраст: 48 Группа: Пользователи Сообщений: 9 643 Регистрация: 21.4.2003 Из: Владимир Пользователь №: 2 702 Вставить ник Цитата |
Есть старинная админская мудрость: перед восстановлением базы из бэкапа сделай бэкап того, что есть.
Позволяет сохранить волосяной покров на ягодицах, если что-то пошло не так. --------------------
Ну, допустим, про кипятильник я наврал... Но факт остается фактом!
|
|
|
25.4.2017, 12:40
Сообщение
#27
|
|
Пресмертн. Проф. Патологич. Библиомансии Возраст: 50 Группа: Пользователи Сообщений: 24 683 Регистрация: 13.1.2005 Из: Владимир Пользователь №: 8 330 Вставить ник Цитата |
Есть старинная админская мудрость: перед восстановлением базы из бэкапа сделай бэкап того, что есть. Позволяет сохранить волосяной покров на ягодицах, если что-то пошло не так. Т.е. восстановление чистой БД из backup_2017_04_18_10_57 может прокатить? Задница-то за два последних дня уже почти и так облысела, так что терять особо нечего. --------------------
На каждого, кто пляшет русалочьи пляски, есть Finnegan, который умеет ходить по воде.
|
|
|
25.4.2017, 13:59
Сообщение
#28
|
|
Новенький Возраст: 48 Группа: Пользователи Сообщений: 9 643 Регистрация: 21.4.2003 Из: Владимир Пользователь №: 2 702 Вставить ник Цитата |
Может, конечно. В бэкап пишутся все команды создания таблиц и их наполнения.
В том числе - и кодировка, кстати. Но вам нужно перед этим настроить правильную кодировку базы, чтобы запрос к ней шел в правильной кодировке. --------------------
Ну, допустим, про кипятильник я наврал... Но факт остается фактом!
|
|
|
25.4.2017, 14:08
Сообщение
#29
|
|
Пресмертн. Проф. Патологич. Библиомансии Возраст: 50 Группа: Пользователи Сообщений: 24 683 Регистрация: 13.1.2005 Из: Владимир Пользователь №: 8 330 Вставить ник Цитата |
Может, конечно. В бэкап пишутся все команды создания таблиц и их наполнения. В том числе - и кодировка, кстати. Но вам нужно перед этим настроить правильную кодировку базы, чтобы запрос к ней шел в правильной кодировке. Кодировку я настроил. В phpMyAdmin нашел, где зафиксировать кодировку базы как cp_1251_general_ci, чтоб она не сбрасывалась. Но возникла другая проблема. Я очистил содержимое базы данных и теперь не могу войти в админ панель сайта. Видимо логин/пароль админа как раз в таблице с юзерами был:) --------------------
На каждого, кто пляшет русалочьи пляски, есть Finnegan, который умеет ходить по воде.
|
|
|
25.4.2017, 14:51
Сообщение
#30
|
|
Пресмертн. Проф. Патологич. Библиомансии Возраст: 50 Группа: Пользователи Сообщений: 24 683 Регистрация: 13.1.2005 Из: Владимир Пользователь №: 8 330 Вставить ник Цитата |
В общем очистил все, кроме папки с юзерами в базе данных.
Восстановил базу данных из бэкапа backup_2017_04_18_10_57. Теперь весь сайт в знаках вопроса. Ни одного слова на кириллице. В .htacess запись о кодировке windows-1251 на месте. Но это не помогает. --------------------
На каждого, кто пляшет русалочьи пляски, есть Finnegan, который умеет ходить по воде.
|
|
|
25.4.2017, 15:10
Сообщение
#31
|
|
Новенький Возраст: 48 Группа: Пользователи Сообщений: 9 643 Регистрация: 21.4.2003 Из: Владимир Пользователь №: 2 702 Вставить ник Цитата |
Вопрос в том, откуда берется "весь текст на сайте".
У текста, прописанного в самих PHP-файлах, база ни при чем - он выводится кракозябрами, если сервер неверно отдает в заголовках кодировку. В принципе, та строчка в .htaccess должна от этого помогать, но бывают нюансы. Если же текст берется из БД, то проблема в кодировке соединения. Нет, это не сравнение cp_1251_general_ci, это другая настройка. Не уверен, что в PMA ее вообще можно решить, если у вас нет доступа к его localhost - у хостеров обычно пользователь имеет доступ только к конкретной базе. Тут решают либо костыли типа выставления "SET NAMES cp1251" / mysqli_set_charset в потрохах сайта, либо перекодировка всей базы. --------------------
Ну, допустим, про кипятильник я наврал... Но факт остается фактом!
|
|
|
25.4.2017, 16:26
Сообщение
#32
|
||
Пресмертн. Проф. Патологич. Библиомансии Возраст: 50 Группа: Пользователи Сообщений: 24 683 Регистрация: 13.1.2005 Из: Владимир Пользователь №: 8 330 Вставить ник Цитата |
Вопрос в том, откуда берется "весь текст на сайте". У текста, прописанного в самих PHP-файлах, база ни при чем - он выводится кракозябрами, если сервер неверно отдает в заголовках кодировку. В принципе, та строчка в .htaccess должна от этого помогать, но бывают нюансы. Если же текст берется из БД, то проблема в кодировке соединения. Нет, это не сравнение cp_1251_general_ci, это другая настройка. Не уверен, что в PMA ее вообще можно решить, если у вас нет доступа к его localhost - у хостеров обычно пользователь имеет доступ только к конкретной базе. Тут решают либо костыли типа выставления "SET NAMES cp1251" / mysqli_set_charset в потрохах сайта, либо перекодировка всей базы. Текст меню берется из файла main.tpl - и там все отражается нормально. Весь остальной текст на сайте - со статических страниц (их около 900) и "новостей" (около 30). Так что все завязано на БД. В самой базе данных это выглядит так: --------------------
На каждого, кто пляшет русалочьи пляски, есть Finnegan, который умеет ходить по воде.
|
|
|
||
25.4.2017, 16:42
Сообщение
#33
|
||
специалист Возраст: 46 Группа: Пользователи Сообщений: 3 311 Регистрация: 10.10.2001 Пользователь №: 612 Вставить ник Цитата |
Текст меню берется из файла main.tpl - и там все отражается нормально. Весь остальной текст на сайте - со статических страниц (их около 900) и "новостей" (около 30). Так что все завязано на БД. В самой базе данных это выглядит так: Проблема 99.9% в несовпадении кодировки текстового файла дампа БД с кодировкой базы. Причем надо понимать что у mysql несколько разных кодировок - кодировка соединения, кодировка самой базы, кодировка сервера. Ещё в самом SQL дампе могут быть команды на изменение кодировки причем не факт что правильные. Что бы сделал я 1) Открыл дамп базы в текстовом редакторе, поддерживающем работу с разными кодировками и автоопределением (какой нибудь Notepad++). Посмотрел какая там кодировка у текста. 2) Поискал бы в дампе команды на изменение кодировки типа SET NAMES utf-8 + нет ли явного указания кодировки для самих таблиц и текстовых полей в запросах CREATE TABLE . Если в пункте 2 есть явное указание кодировки в дампе - для таблиц и полей и это нормальная кодировка (utf-8, cp1251_generai_ci и т.п.), то это хорошо. Эта кодировка должна совпадать с кодировкой самого файла! То есть если в дампе команды на создание таблиц в utf-8 но сам файл в 1251 - это не очень хорошо . Тут поможет текстовый редактор который позволит сохранить дамп в соответствующей кодировке. Самое плохое если в дампе есть явное указание кодировки, но эта кодировка некириллическая - к примеру latin1. Тогда придется долго и мучительно менять везде глобальным поиском и заменой на ту же 1251 , потом пересохранить файл в такой же кодировке. 3) На этом этапе если всё сделано корректно у нас есть правильный дамп. Правильный - это значит его внутреннее содержимое соответствует тем командам которые этот дамп дает mysql серверу. Собственно останется его импортировать. PhpMydmin можно указать кодировку, в которой находится дамп при импорте. Естественно нужно выбрать ту, у который мы приводили дамп двумя пунктами ранее. --------------------
{ cli; jmp $-2 }
-
|
|
|
||
25.4.2017, 16:46
Сообщение
#34
|
|
Пресмертн. Проф. Патологич. Библиомансии Возраст: 50 Группа: Пользователи Сообщений: 24 683 Регистрация: 13.1.2005 Из: Владимир Пользователь №: 8 330 Вставить ник Цитата |
Дамп базы - это файл .sql?
--------------------
На каждого, кто пляшет русалочьи пляски, есть Finnegan, который умеет ходить по воде.
|
|
|
25.4.2017, 17:14
Сообщение
#35
|
|
специалист Возраст: 46 Группа: Пользователи Сообщений: 3 311 Регистрация: 10.10.2001 Пользователь №: 612 Вставить ник Цитата |
Дамп базы - это файл .sql? Ага. Вот к примеру: -- MySQL dump 10.13 Distrib 5.5.47, for Linux (x86_64) -- -- ------------------------------------------------------ -- Server version 5.0.95 /*!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 */; -- -- Not dumping tablespaces as no INFORMATION_SCHEMA.FILES table on this server -- -- -- Table structure for table `BANNER` -- DROP TABLE IF EXISTS `BANNER`; /*!40101 SET @saved_cs_client = @@character_set_client */; /*!40101 SET character_set_client = utf8 */; CREATE TABLE `BANNER` ( `ID_BANNER` int(11) unsigned NOT NULL auto_increment, `ID_RAZDEL` int(11) default NULL, `ALT` varchar(255) default NULL, `GIF` varchar(255) default NULL, `URL` varchar(255) default NULL, PRIMARY KEY (`ID_BANNER`) ) ENGINE=MyISAM AUTO_INCREMENT=36 DEFAULT CHARSET=utf8; /*!40101 SET character_set_client = @saved_cs_client */; Я выделил на примере на что обратить внимание. В дампе во первых в самом начале дампа и перед импортом каждой таблицы стоят команды "забыть" какая там кодировка была и установить свою - utf8 . Вот файл обязан быть этой же кодировки по содержимому. И созданная база данных крайне желательно чтобы была в этой же кодировке. --------------------
{ cli; jmp $-2 }
-
|
|
|
25.4.2017, 18:06
Сообщение
#36
|
|
Пресмертн. Проф. Патологич. Библиомансии Возраст: 50 Группа: Пользователи Сообщений: 24 683 Регистрация: 13.1.2005 Из: Владимир Пользователь №: 8 330 Вставить ник Цитата |
1) Открыл дамп базы в текстовом редакторе, поддерживающем работу с разными кодировками и автоопределением (какой нибудь Notepad++). Посмотрел какая там кодировка у текста. 2) Поискал бы в дампе команды на изменение кодировки типа SET NAMES utf-8 + нет ли явного указания кодировки для самих таблиц и текстовых полей в запросах CREATE TABLE . Открыл NPP три файла .sql 1. в файле .sql, который я не мог загрузить (от апрель 2017), кодировка "UTF8 без BOM" 2. в файле .sql, который я загружал (от июль 2016), кодировка "UTF8 без BOM" 3. в файле .sql из восстановленого бэкапа, кодировка "ANSI" Строчки SET NAMES нет ни в одном из дампов. Записи о кодировках есть: 1.-2. в CREATE TABLE записи типа ) ENGINE=MyISAM DEFAULT CHARSET=cp1251 AUTO_INCREMENT=[xxx] ; 3. Много записей типа ) ENGINE=MyISAM DEFAULT CHARSET=cp1251 ; # TD`ng_flood`cp1251_general_ci ; Я выделил на примере на что обратить внимание. В дампе во первых в самом начале дампа и перед импортом каждой таблицы стоят команды "забыть" какая там кодировка была и установить свою - utf8 . Вот файл обязан быть этой же кодировки по содержимому. И созданная база данных крайне желательно чтобы была в этой же кодировке. У меня перед началом таблиц в 1-2 .sql есть только одна запись: SET SQL_MODE="NO_AUTO_VALUE_ON_ZERO"; а в 3. /sql вообще никаких записей перед таблицами нет, Получается мне нужно в ручную прописать SET NAMES utf8 и сохранить файл в этой кодировке? --------------------
На каждого, кто пляшет русалочьи пляски, есть Finnegan, который умеет ходить по воде.
|
|
|
25.4.2017, 18:20
Сообщение
#37
|
|
Новенький Возраст: 48 Группа: Пользователи Сообщений: 9 643 Регистрация: 21.4.2003 Из: Владимир Пользователь №: 2 702 Вставить ник Цитата |
Нет, у вас вполне типичный дамп базы, работающей в cp1251. PMA сохраняет этот дамп в UTF-8 по умолчанию, вне зависимости от кодировки базы.
При импорте файла тоже нужно выбрать кодировку UTF-8. --------------------
Ну, допустим, про кипятильник я наврал... Но факт остается фактом!
|
|
|
25.4.2017, 19:15
Сообщение
#38
|
|
Пресмертн. Проф. Патологич. Библиомансии Возраст: 50 Группа: Пользователи Сообщений: 24 683 Регистрация: 13.1.2005 Из: Владимир Пользователь №: 8 330 Вставить ник Цитата |
Нет, у вас вполне типичный дамп базы, работающей в cp1251. PMA сохраняет этот дамп в UTF-8 по умолчанию, вне зависимости от кодировки базы. При импорте файла тоже нужно выбрать кодировку UTF-8. В том-то и дело, что - в phpMyAdmin ограничение размера <2 Mb, так что не могу загрузить ни один .msql - в sxd могу загрузить созданный им же дамп.sql #3 в кодировке utf8, но текст на сайте все равно со знаками вопроса - в adminer могу загрузить только .sql #2, но без указания кодировки (там только кнопка выбрать и выполнить) и если поверх выполнить бэкап, то все снова становится со знаками вопроса. Получается замкнутый круг. --------------------
На каждого, кто пляшет русалочьи пляски, есть Finnegan, который умеет ходить по воде.
|
|
|
25.4.2017, 20:46
Сообщение
#39
|
|
Новенький Группа: Пользователи Сообщений: 9 614 Регистрация: 9.9.2002 Пользователь №: 1 805 Вставить ник Цитата |
Получается замкнутый круг. пора доверить решение этого вопроса профессионалам тут уже сто раз все обмылили как и что делать все проблемы с sql файлом решаются в ultraedit и с кодировкой и с размером да и еще у нормального хостера должны быть архивы сайта их можно попросить в тех поддержке Сообщение отредактировал baseq3 - 25.4.2017, 20:46 |
|
|
25.4.2017, 21:31
Сообщение
#40
|
|
специалист Возраст: 46 Группа: Пользователи Сообщений: 3 311 Регистрация: 10.10.2001 Пользователь №: 612 Вставить ник Цитата |
В том-то и дело, что - в phpMyAdmin ограничение размера <2 Mb, так что не могу загрузить ни один .msql - в sxd могу загрузить созданный им же дамп.sql #3 в кодировке utf8, но текст на сайте все равно со знаками вопроса - в adminer могу загрузить только .sql #2, но без указания кодировки (там только кнопка выбрать и выполнить) и если поверх выполнить бэкап, то все снова становится со знаками вопроса. Получается замкнутый круг. Сложно вслепую что то советовать. Я бы сохранил файл дампа в кодировке 1251 через редактор так как сайт судя по всему работает именно с ней и попробовал бы импортировать через консольный mysql , запустив его через php. То есть написал бы простой php скрипт <?php system("/usr/bin/mysql -uпользователь -pпароль -Dбаза -hхост --default_character_set=cp1251 < /путь_к_сайту/дамп.sql"); ?> Залил бы на сайт и запустил бы в браузере. Скорее всего таким образом, если сделать все правильно, удастся корректно импортировать любой из дампов. --------------------
{ cli; jmp $-2 }
-
|
|
|
Политика конфиденциальности | Легкая версия |