Вот решил отделить мух от котлет, думаю как с наименьшими затратами и потерями осуществить перенос баз MYSQL в другую базу ничего не поломав.
Перенос баз блога в другую БД MySQL
Вот решил отделить мух от котлет, думаю как с наименьшими затратами и потерями осуществить перенос баз MYSQL в другую базу ничего не поломав.
да вроде бы ничего сложного. сделать дам текущей базы, в текстовом редакторе сменить в дампе название базы, залить обработанный дамп назад на сервер, в wp-config прописать название новой базы. после того как заработает все на новой базе – в старой почистить ненужные таблицы.
вроде ничего не упустил…
Добавить (перепроверить 🙂 ) права доступа для новой БД.
Ищи плагин WordPress Database Backup, кажется он на skippy.net/blog/plugins/ . Меня не раз выручал и я его всегда активирую, чтобы делать бэкап (у каждого своя параноя)
ты будь готов к тому что все таки что-то может поломаться))) JawsIk прав…… воспользуйся бекап плагином. С вордпрессом всегда что-то может пойти не так. Думаю ты разберешься!!!!
Однако я бы советовал бэкапы делать phpMyAdmin
сколько я бекап делал с phpMyAdmin все в конце глючило. Особенно в виджетах. (может просто мне не повезло…)
+1 за phpMyAdmin – самый надежный способ.
phpMyAdmin, бесспорно, классная штука, однако если MySQL сервер "свой", а не у хостера, то я, например, предпочитаю делать бэкап MySQLAdministrator-ом. Ну, а крайний случай – консольная утилита mysqldump, входящая в состав MySQL сервера.
а я дам -1 за phpMyAdmin. Я мучился очень долго с ним, ведь при сохранении вместо русских одни вопросики "???". Какие я там предложенные кодировки не выбирал. Может быть конечно что-то хреново настроено у моего хостера, но однако с предложенным мной плагином я прекрасно всё сохранил и у меня отлично всё потом перенеслось.
А вообще я за виджеты и плагины больше родею, чем за ручные манипуляции, хотя вот "непрограммить" уже не могу 🙂
+ в конце создания таблицы добавлять:
DROP TABLE IF EXISTS `wp_callig_categories`;
CREATE TABLE `wp_callig_categories` (
`cat_ID` bigint(20) NOT NULL auto_increment,
`cat_name` varchar(55) NOT NULL default ”,
`category_nicename` varchar(200) NOT NULL default ”,
`category_description` longtext NOT NULL,
`category_parent` bigint(20) NOT NULL default ‘0’,
`category_count` bigint(20) NOT NULL default ‘0’,
PRIMARY KEY (`cat_ID`),
KEY `category_nicename` (`category_nicename`)
) TYPE=MyISAM DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci;
А если у хостера все нормально?
??? вместо русского текста это повод насторожиться и задать себе вопрос – а все ли в порядке с кодировкой в моих таблицах?
В том то и прикол, что переносятся на новое место не только данные, но и изначальный бардак с кодировкой со старого места.
Ага, и если текстовые данные в бэкапе были в какой-то иной кодировке, отличной от utf8, то после восстановления в таблице будет бардак.
Чем плох Sypex Dumper?
Всем хорошо, но сохранять базу в UTF-8 он не умеет. 5 дней назад проверял. Если у вас получилось, научите нас.
Как оказалось проблема действительно с кодировкой, но вот таблицы тут не причём. Это враньё. Как и у 99% хостеров у моего по умолчанию стояла кодировка latin1. А дело это было больше полу года назад, тогда, когда у Макса не было такой сборки, которая бы устраняла эту проблему. Сейчас я думаю таких проблем не будет.
Снова враньё. Если пользоваться плагином то этого не произойдёт, ведь он действительно сделан для устранения проблем с учётом всяких всевозможных багов, чего не скажешь о phpMyAdmin, где в принципе стандартная процедура. После пользования плагином я мог хоть увидеть русские буквы. Кроме того после переноса я вообще вручную открывал файл базы и менял вручную все параметры latin1 на UTF8. Но русские то буквы были! Да и вообще устрановить плагин и сделать бэкап гораздо быстрее, чем лезть в phpMyAdmin.
p.s. не нужно мне рассказывать про то, что у меня с таблицами бардак. Последний раз я перезжал 8 месяцев назад. Этот блог обновилялся поэтапно с версии 2.0.5 уже до 2.1+ и никаких проблем не было. Кроме того после глюков у хостера блог восстанавливался не раз и делалось это буквально за минуты.
http://sypex.net/encoding/
Там ничего не сказано про UTF и утилита отказывается восстанавлить UTF-базу, выводя ошибку. Только cp1251.
При залитии в пустую базу снятого Сайпексом дампа выводится ошибка? Что пишется?
P.S. Да, в статье не упоминается конкретно UTF-8, но там сказано про принудительное выставление кодировки.
Последняя версия Сайпекса вполне себе работает с UTF.
Ну ё моё… Так и знал что все сведётся к стучанию в грудь. JawsIk, Вы разве не обратили внимание, что я в своём собщении ни чего не утверждал? Там даже вопросительные знаки есть в конце предложений. 🙂 Я лишь говорил, что такое может прозойти. У Вас нет проблем с таблицами – ну и славно.
На прощанье: ни кого, ни в чем не собираюсь переубеждать – имеющий уши да услышит.
Ну извини… видимо не в духе был
Всем, спасибо за ваши советы!
Перенес БД, все работает, как ни странно =)
вопрос.
сделал бэкап через phpadmin, на след. день, на тот же хостинг я импортировал базу обратно (всё прошло успешно) но в админке и на самом сайте грифты представляют собой иэроглифы, как их "отремонтировать", вернуть в нормальный-читаемый текст?
скажем не на хостинге их переконвертировать, а так, на компе.
база- latin1 импорт тоже делал в Latin1
спрашивал у хостер, тот не знает в чём проблема.