Смена СУБД форума

Вопроситель · 2015-12-28 00:20:37

Уважаемые, возникли мысли поменять СУБД форума. Сейчас форум работает с sqlite, а менять планируется на mysql (расположенную на другом физическом сервере).

Есть ли у кого опыт подобного? Имеются ли какие-то подводные камни? Возможно ли проделать указанное без переустановки форума?

Visman · 2015-12-28 06:16:09

Опыта нет, но как я этот процесс вижу:
1. Делается дамп базы SQLite
2. Дамп базы SQLite конвертируется в дамп базы MySQL (гугл дает такие ссылки по запросу https://www.google.ru/search?q=Convert+ … lr=lang_ru)
3. В MySQL создается база, куда импортируются данные из дампа полученного во 2 пункте
4. В файле настроек форума config.php меняются настройки относящиеся к подключению к базе:

$db_type = 'mysqli';
$db_host = ... // имя сервера MySQL, обычно localhost
$db_name = ... // имя новой базы данных
$db_username = ... // имя юзера для доступа к базе
$db_password = ... // пароль юзера для доступа к базе
$db_prefix = ... // префикс, если есть, таблиц базы данных форума
$p_connect = false;

Visman · 2015-12-28 06:16:45

P.S.

Возможно ли проделать указанное без переустановки форума?

Переустановка форума не нужна.

Вопроситель · 2015-12-28 20:46:03

Спасибо @Visman.

Я хоть и дилетант, но в целом так себе процесс и представлял. Однако про то, что дампы нужно конвертировать по невежеству не знал. Это очень по делу.

Ну и главная информация - это то, что достаточно config поменять.

В общем на днях, а может на праздниках, буду пробовать. Об успехах напишу.

Еще раз спасибо.

Вопроситель · 2015-12-30 00:08:40

В общем операция проходит с переменным успехом.

Сделал дамп, но при попытке грузить его в новую базу, программа стала ругаться на таблицы поиска, после их вычистки импорт прошел без ошибок.

Форум заработал на новой базе, но добавка сообщений ломала тему в которую они добавлялись, а добавка новой темы вообще сбивала список тем.

Беглый анализ показал, что новое сообщение было добавлено в базу с id=0, с топиком аналогично. Ручное удаление поста и топика восстановило правильное отображение форума, а ручная добавка свойства "автоикремент" к соответствующим полям позволило добиться корректного добавления постов и топиков на форум.

Однако проблема, видимо, в том, что в дампе по какой-то причине не оказалось автоинкрементов в нужных полях.

Например описание таблицы постов:

CREATE TABLE posts (
id INTEGER NOT NULL,
poster VARCHAR(200) NOT NULL DEFAULT '',
poster_id INTEGER NOT NULL DEFAULT 1,
poster_ip VARCHAR(39),
poster_email VARCHAR(80),
message TEXT,
hide_smilies INTEGER NOT NULL DEFAULT 0,
posted INTEGER NOT NULL DEFAULT 0,
edited INTEGER,
edited_by VARCHAR(200),
topic_id INTEGER NOT NULL DEFAULT 0,
PRIMARY KEY (id)
);

Верны ли мои предположения? И как нужно делать дамп, что бы поля были описаны правильно? Это мой косяк или sqlite?
Я делал так:

#sqlite имя-базы .dump .quit >> export.sql

Редактировался Вопроситель (2015-12-30 00:12:42)

Visman · 2015-12-30 09:09:38

@Вопроситель, поля на которых автоинкремент должен быть можно найти в файле install.php. Они все имеют такое свойство в описании таблиц

'datatype'		=> 'SERIAL'

Вот, например, как у меня выглядит создание таблицы в бэкапе:

CREATE TABLE `flux_categories` (
  `id` int(10) unsigned NOT NULL AUTO_INCREMENT,
  `cat_name` varchar(80) NOT NULL DEFAULT 'New Category',
  `disp_position` int(10) NOT NULL DEFAULT '0',
  PRIMARY KEY (`id`)
) ENGINE=MyISAM AUTO_INCREMENT=5 DEFAULT CHARSET=utf8;

Вопроситель · 2015-12-30 23:49:20

Разбираясь кто виноват, пришел к выводу что это sqlite. В базе соответствующие поля не объявлены со свойством autoincrement. Нашел такую информацию:

Согласно FAQ SQLite INTEGER PRIMARY KEY можно не объявлять как AUTOINCREMENT.
Цитата:
How do I create an AUTOINCREMENT field.
Short answer: A column declared INTEGER PRIMARY KEY will autoincrement.

Дальше разбираюсь - что делать.
Предложенный подход: смотреть в install.php у меня не прошел. Этот файл ссылается на файлы для каждой конкретной базы, но и там я не разобрался, код для меня замысловатый быстро въехать не получилось.

Поэтому пока просто прошелся по всем таблицам и где есть id обозначенный как PRIMARY KEY поставил в ручную AUTOINCREMENT. Однако, возможно, не буду останавливаться на этом решении.

Тут я немного отвлекусь и спрошу такую вещь: когда лазил по install.php и дальше, нашел следующие файлы. Вопрос в чем разница этих вариантов подключения к mysql?

mysql.php
mysql_innodb.php
mysqli.php
mysqli_innodb.php

Возвращаясь к решению задачи, мне сейчас видится такой подход:
1. Поставить свежий форум с подключением к mysql.
2. Снять от туда (mysql) дамп только со структурой без данных.
3. Снять дамп только с данными без структуры из старой базы sqlite.
4. Вычистить базу.
5. Залить структурный дамп mysql в новую базу.
6. Залить дамп данных sqlite в новую базу.

Целесообразен ли такой алгоритм?

Visman · 2015-12-31 08:34:31

Дамп данных из sqlite можно залить в базу из пункта 1 без всякой чистки, поверх имеющихся данных. Но значения автоинкрементов все равно надо прописать в таблицах где они считаются.

Предложенный подход: смотреть в install.php у меня не прошел. Этот файл ссылается на файлы для каждой конкретной базы, но и там я не разобрался, код для меня замысловатый быстро въехать не получилось.

Надо было просто сделать поиск по слову SERIAL, чтобы найти поля с автоинкрементом.

mysql.php
mysql_innodb.php
mysqli.php
mysqli_innodb.php

Ни mysql, ни mysql_innodb выбирать не следует, они устарели.

mysqli - это улучшенное расширение для работы с MySQL, mysqli_innodb - тоже самое, но с поддержкой транзакций.

Вопроситель · 2015-12-31 11:41:42

Дамп данных из sqlite можно залить в базу из пункта 1 без всякой чистки, поверх имеющихся данных. Но значения автоинкрементов все равно надо прописать в таблицах где они считаются.

Я потому предполагаю чистить, что по невежеству боюсь, будто при записи новых данных поверх старых, могут вылезти ошибки с которыми мне не разобраться. А что касается автоинкрементов, то ведь вся идея как раз в том, что при свежей установке форума на базу mysql структура базы будет правильно прописана в том числе по части автоикрементов. Разве нет?

Надо было просто сделать поиск по слову SERIAL, чтобы найти поля с автоинкрементом.

До этого я догадался. Но только искал AUTO и нашел его (как впрочем и SERIAL) лишь в одном месте (mysqli.php):

class DBLayer
{
      * * * * *
	var $datatype_transformations = array(
		'%^SERIAL$%'	=>	'INT(10) UNSIGNED AUTO_INCREMENT'
	);

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

Про варианты подключений к базе понял, спасибо еще раз.

Visman · 2015-12-31 13:51:31

@Вопроситель, я про поиск в install.php писал выше.

Вопроситель · 2015-12-31 16:41:08

я про поиск в install.php писал выше.

Теперь понял, я поначалу искал и там, но по запросу AUTO. По запросу SERIAL действительно все находится и все понятно.

Однако, я все же сделал по тому алгоритму который описал. Побоялся, сделать что-то неправильно или вдруг какие-то разночтения.

Вроде все прошло более или менее гладко, только когда подгружал дамп данных, система заругалась на строки
CREATE INDEX. Ну я их убрал и все прошло без ошибок. Создание таблиц я вручную убрал из дампа, а эти индексы по-началу не стал убирать т.к. не знаю их смысла.

Что это за индексы? Не повредит ли это результату?

CREATE INDEX bans_username_idx ON bans(username);
CREATE INDEX online_ident_idx ON online(ident);
CREATE INDEX online_logged_idx ON online(logged);
CREATE INDEX posts_multi_idx ON posts(poster_id,topic_id);
CREATE INDEX posts_topic_id_idx ON posts(topic_id);
CREATE INDEX reports_zapped_idx ON reports(zapped);
CREATE INDEX search_cache_ident_idx ON search_cache(ident);
CREATE INDEX search_matches_post_id_idx ON search_matches(post_id);
CREATE INDEX search_matches_word_id_idx ON search_matches(word_id);
CREATE INDEX search_words_id_idx ON search_words(id);
CREATE INDEX topics_first_post_id_idx ON topics(first_post_id);
CREATE INDEX topics_forum_id_idx ON topics(forum_id);
CREATE INDEX topics_last_post_idx ON topics(last_post);
CREATE INDEX topics_moved_to_idx ON topics(moved_to);
CREATE INDEX users_registered_idx ON users(registered);

Visman · 2015-12-31 19:23:00

Что это за индексы? Не повредит ли это результату?

Это индексы с не уникальным содержимым, кажется.
Вот пример из бэкапа

CREATE TABLE `flux_online` (
  `user_id` int(10) unsigned NOT NULL DEFAULT '1',
  `ident` varchar(200) NOT NULL DEFAULT '',
  `logged` int(10) unsigned NOT NULL DEFAULT '0',
  `idle` tinyint(1) NOT NULL DEFAULT '0',
  `last_post` int(10) unsigned DEFAULT NULL,
  `last_search` int(10) unsigned DEFAULT NULL,
  `witt_data` varchar(255) NOT NULL DEFAULT '',
  UNIQUE KEY `flux_online_user_id_ident_idx` (`user_id`,`ident`(25)),
  KEY `flux_online_ident_idx` (`ident`(25)),
  KEY `flux_online_logged_idx` (`logged`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8;

Их отсутствие резко негативно скажется на быстродействии запросов.

Вопроситель · 2015-12-31 20:29:08

В вашем фрагменте индексы это те что идут за командой KEY?

Если так, то у меня с этим должен быть порядок т.к. дамп структуры снимал с mysql и там все как у вас (исключая префикс flux_). А дамп данных я делал на основе дампа sqlite и там эти индексы указывались не при создании таблицы, а в конце файла в том виде как я приводил.

В общем, большое спасибо за ваши ответы. С наступающим Новым Годом!

Visman · 2015-12-31 21:27:19

В вашем фрагменте индексы это те что идут за командой KEY?

Да. Если они есть в конечной базе, значит все хорошо.

исключая префикс flux_

Префикс таблиц в моей базе. Можно не обращать внимание.

Русское сообщество fluxbb

Объявление

#1 2015-12-28 00:20:37

Смена СУБД форума

#2 2015-12-28 06:16:09

Re: Смена СУБД форума

#3 2015-12-28 06:16:45

Re: Смена СУБД форума

#4 2015-12-28 20:46:03

Re: Смена СУБД форума

#5 2015-12-30 00:08:40

Re: Смена СУБД форума

#6 2015-12-30 09:09:38

Re: Смена СУБД форума

#7 2015-12-30 23:49:20

Re: Смена СУБД форума

#8 2015-12-31 08:34:31

Re: Смена СУБД форума

#9 2015-12-31 11:41:42

Re: Смена СУБД форума

#10 2015-12-31 13:51:31

Re: Смена СУБД форума

#11 2015-12-31 16:41:08

Re: Смена СУБД форума

#12 2015-12-31 19:23:00

Re: Смена СУБД форума

#13 2015-12-31 20:29:08

Re: Смена СУБД форума

#14 2015-12-31 21:27:19

Re: Смена СУБД форума

Подвал доски