Logan22 добавил(а) новый ресурс:
Скрипт объединение БД серверов - Скрипт слияния баз
Узнать больше об этом ресурсе...
Скрипт объединение БД серверов - Скрипт слияния баз
Узнать больше об этом ресурсе...
-
Новые темы в этом разделе публикуются автоматически при добавлении файла в менеджер ресурсов.
Ручное создание новых тем невозможно.
Скрипт объединение БД серверов 0.1
- Автор темы Logan22
- Дата начала
скинешь инструкцию как им пользоваться?
l2j-database-consolidation
PHP скрипт для слияния базы данных двух серверов в одну.Это может быть полезно, если у Вас есть два сервера, и вы хотите их объединить в один, в результате: персонажи, предметы, кланы (перечисленный вами список) будут объедены.
Для работы скрипта необходимо:
- БД должны быть от одной сборки, либо иметь одинаковую архитектуру.
- PHP (делалось на версии 7.4).
Подключение к БД. Перейдите в файл db/connect.php, найдите массив $firstDBConfig и $twoDBConfig и укажите данные подключения. Эти базы будут слиты в одну, и весь результат будет находится в бд $twoDBConfig. С подключением закончили.
Теперь указываем какие таблицы и колонки объединять!
Как это всё запустить?
Внимание: проверяйте работоспособность не на ЛАЙФСЕРВЕРЕ, а на дампах БД.
спасибо огромное, выручил
Может тогда и не стоит обьединять?)
Или заплатить кому-то деньги.
под l2jeternity кто-то делал ?
Нужно посмотреть, кажется я делал. Только более глобальным самописным скриптом. Точне не помню.
буду благодарен за помощь
Поиск записей
| Без учета регистра | С учетом регистра |
SELECT * FROM characters WHERE LOWER(char_name) = 'gnomka'; | SELECT * FROM characters WHERE char_name LIKE BINARY 'Gnomka'; |
|
|
|
|
З.Ы. Скрипт устарел и не актуален, я давно всё переписал под Go и выполнял платные объединения.
Разница в скорости ощутимейшая, к примеру: нужно было объединять базы, чтоб вы понимали их объем, то на одной бд под 100 млн. предметов в items, и в другой где-то 65 млн. (а там помимо предметов ещё полно толстых таблиц и миллионы и миллионы сравнений). PHP требовалось огромное кол-во времени, больше часа для выполнения задачи, переписанный код на Go справляется за 40-60 сек.
Разница в скорости ощутимейшая, к примеру: нужно было объединять базы, чтоб вы понимали их объем, то на одной бд под 100 млн. предметов в items, и в другой где-то 65 млн. (а там помимо предметов ещё полно толстых таблиц и миллионы и миллионы сравнений). PHP требовалось огромное кол-во времени, больше часа для выполнения задачи, переписанный код на Go справляется за 40-60 сек.
Ну... сравнивать скорость работы интерпретируемого и компилируемого языков...
Ну и на пхп достаточно быструю обработку можно сделать - конечно не равную тому что будет в написанном на го/с++ и т.п., но вполне сопоставимую.
И кстати на кой фиг что-то сравнивать в таблицах items старой и новой базы? там же достаточно например инсертить просто новые записи отсчитывая новые obj_id для них, определив например разово в начале работы максимальный занятый obj_id в новой базе и новые считать уже от него.
Ну и самое медленное тут по сути чтение/запись в базы. Ощутимо сократить время можно если читать и писать данные большими порциями за один цикл.
---
не связано с объединениями баз, но вот чисто для примера вот к примеру у меня объемы базы моей бз
Тут конечно не многие миллионы, но суммарно около миллиона записей во всех таблицах наберется.
И вот если парсерами (на пхп) эти данные заносить в бд в режиме "в одном запросе добавляется одна запись", то парсеры будут работать минут 10-15. А вот если использовать режим пакетной записи, например вставка сразу 100 строк в одном запросе, то это время сразу же сокращается где-то до одной минуты, а то и меньше.
Ну и на пхп достаточно быструю обработку можно сделать - конечно не равную тому что будет в написанном на го/с++ и т.п., но вполне сопоставимую.
И кстати на кой фиг что-то сравнивать в таблицах items старой и новой базы? там же достаточно например инсертить просто новые записи отсчитывая новые obj_id для них, определив например разово в начале работы максимальный занятый obj_id в новой базе и новые считать уже от него.
Ну и самое медленное тут по сути чтение/запись в базы. Ощутимо сократить время можно если читать и писать данные большими порциями за один цикл.
---
не связано с объединениями баз, но вот чисто для примера вот к примеру у меня объемы базы моей бз
И вот если парсерами (на пхп) эти данные заносить в бд в режиме "в одном запросе добавляется одна запись", то парсеры будут работать минут 10-15. А вот если использовать режим пакетной записи, например вставка сразу 100 строк в одном запросе, то это время сразу же сокращается где-то до одной минуты, а то и меньше.
Последнее редактирование:
Это для контр страйка
