|
|
|
Mysql репликация для деволопмента
|
|||
|---|---|---|---|
|
#18+
Вопрос такой. Имеется база на продакшене. И деволперские машинки. Задача - иметь более-менее актуальную копию базы у девелоперов. Репликация master-slave, конечно. Проблемы - девелоперские машины при запуске проекта, естественно, в среплицированную базу пишут кое-что(логи, например), т.е. обязательно будут дубликаты автоинкримента итд. ров-базед репликация, настройки на игнор, настройки бинлога, список ошибок, которые стоит игнорить, конечно, сильно помогут, но рано или поздно база все равно уходит в отказ реплицироваться далее. Проверено. В данной ситуации. 1) На мастере бинлоги хранить долго, при неустранимой ошибке вернуть бэкап, и снова стартовать репликацию с того же места, что и раньше-пусть накатывает обновления. Проблемы - большой траффик, долго по времени. 2) На слейве периодически останавливать репликацию, делать бэкап, запоминать позицию, сохранять, стартовать репликацию. При отказе в репликации - восстанавливать с последней копии слейва, запускать репликацию с сохраненной позиции. Проблемы - сильно похоже на велосипед. Может есть какие-то решения PS Для шифрования cсоединений при репликации лучше использовать SSL или завернуть все в openvpn? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2013, 16:26:56 |
|
||
|
Mysql репликация для деволопмента
|
|||
|---|---|---|---|
|
#18+
Мы для тестовой базы используем другую механику: - каждую ночь делается бэкап боевого сервера - сразу после грохается тестовая база и заново разворачивается из свежего бэкапа - раз в неделю (в ночь с субботы на воскресенье) предыдущий пункт происходит с другой тестовой базой вместо ежедневной Плюсы решения: - контроль качества бэкапа (если что не так, то будет заметно сразу) - тестовая база с почти актуальными данными (по состоянию на ночь) - полная независимость тестовых баз от боевого сервера (можно как угодно менять данные, структуру таблиц и т.п., не боясь поломать репликацию) - в случае, если ежедневная база необратимо поломана и/или тесты разных программистов мешают друг другу, то можно задействовать еженедельную базу. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2013, 16:39:41 |
|
||
|
Mysql репликация для деволопмента
|
|||
|---|---|---|---|
|
#18+
Схема очевидная, простая и проблемная. У нас сейчас у одного разработчика похожая - не нравится. Во-первых, пофичные релизы отменяются, а это часто бывает нужно. Во-вторых, коммит с накатыванием миграционника сразу все сломает. В третьих, актуальных данным за сегодня не будет, а это очень нужно(специфика). Вот поэтому нужна репликация. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2013, 17:03:57 |
|
||
|
Mysql репликация для деволопмента
|
|||
|---|---|---|---|
|
#18+
АвторhhhПроблемы - девелоперские машины при запуске проекта, естественно, в среплицированную базу пишут кое-что(логи, например), т.е. обязательно будут дубликаты автоинкримента итд. ров-базед репликация, настройки на игнор, настройки бинлога, список ошибок, которые стоит игнорить, конечно, сильно помогут, но рано или поздно база все равно уходит в отказ реплицироваться Здесь надо со структурой бд разбираться. Какие данные нужны, какие нет. А структура таблицы изменяется, если изменяется, то на какой стороне? Я сейчас в божеский вид привожу репликатор, который по внешним ключам правильно "сливает" БД то есть учитывает ид во всех БД. Буду рад представить бесплатно копию для тестирования. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2013, 17:42:01 |
|
||
|
Mysql репликация для деволопмента
|
|||
|---|---|---|---|
|
#18+
АвторhhhСхема очевидная, простая и проблемная. У нас сейчас у одного разработчика похожая - не нравится.Странно, а нам нравится :) АвторhhhВо-первых, пофичные релизы отменяются, а это часто бывает нужно. Во-вторых, коммит с накатыванием миграционника сразу все сломает.Можете расшифровать? что отменяется и что сломает? АвторhhhВ третьих, актуальных данным за сегодня не будет, а это очень нужно(специфика). Вот поэтому нужна репликация.Насколько реально и насколько часто нужно? Иногда, крайне редко, мы позволяем себе отладку и на боевом сервере. Но, естественно, только после того, как на тестовом отлажено и проверено все, что можно. А иногда, когда нужна имитация свежих данных, просто переводим часы назад. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2013, 17:42:20 |
|
||
|
Mysql репликация для деволопмента
|
|||
|---|---|---|---|
|
#18+
Авторhhh, 1. это называется и рыбку сьесть и косточкой не подавиться. Нельзя девелопить (менять схему, добавлять/менять данные) на слейве от продакшена. 2. т.е каждая контора выбирает между актуальностью данных и удобством разработки. У кого раз в день, у кого -- в любой мемент по необходимости. Естествено надо накатывать девелоперские изменения после апдейта -- это обычная задача, ничего сложного нет. 3. Для уменьшения трафика можно посоветовать локальный слейв от продакшена и делать дампы с локальноко слейва по необходимости. У нас все на ssh тунелях, vpn я просто не знаю как там что. На обновление моей девелоперской базы с локального слейва от продакшена уходит минуты на несколько гигов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2013, 21:34:13 |
|
||
|
|

start [/forum/topic.php?fid=47&msg=38396745&tid=1836051]: |
0ms |
get settings: |
8ms |
get forum list: |
14ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
23ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
36ms |
get tp. blocked users: |
1ms |
| others: | 201ms |
| total: | 299ms |

| 0 / 0 |
