MySQL репликация

Темы, не касающиеся фреймворка, но относящиеся к программированию в целом.
Ответить
Аватара пользователя
mat.twg
Сообщения: 222
Зарегистрирован: 2012.02.22, 20:44
Откуда: Санкт-Петербург

MySQL репликация

Сообщение mat.twg »

Всем привет! вопрос не совсем по yii2 однако спрошу, есть два сервера A и B и две одинаковых по структуре таблицы A.t и B.t. Все изменения происходят с таблицей A.t и с очень большой скоростью обновления 100-200ms/INSERT, необходимо эту таблицу копировать в B.t со скоростью не более 1 сек/INSERT.

Собственно рассматриваю два варианта:

1. По крону со sleep 1 - но не очень как то нравится...
2. Использовать репликацию А.master -> B.slave, но тут у меня пробелы в знаниях... не могу найти какова максимальная частота репликаций, а так же есть ли возможность в MySQL 5.6 запускать репликацию в триггере сервера A?

Буду всем весьма признателен, кто даст нужное направление и прольёт свет на мои вопросы.. не исключаю, что есть более изящное решение, однако я его пока не нашёл...

пс: mySQL 5.6
Аватара пользователя
rugabarbo
Сообщения: 1063
Зарегистрирован: 2015.06.21, 16:21
Контактная информация:

Re: MySQL репликация

Сообщение rugabarbo »

В случае MySQL master-slave отставание слэйва от мастера будет зависеть от многих и многих факторов: от железа, от нагрузки на слэйв, от интенсивности нагрузки мастера, от схемы БД, от сети. На деле я ни разу не видел нулевое отставание. Хотя бы пару секунд отставание всегда есть.

Исходя из этого, думаю, что для вашей задачи классический master-slave не подойдёт.

Лучше с кем-то из опытных админов поговорить на эту тему. По мне так MySQL master-slave очень хорошо подходит для теневого бэкапирования данных, но не для моментальной синхронизации.
Последний раз редактировалось rugabarbo 2016.09.06, 17:28, всего редактировалось 1 раз.
zelenin
Сообщения: 10596
Зарегистрирован: 2013.04.20, 11:30

Re: MySQL репликация

Сообщение zelenin »

а для какой цели нуждна репликация в вашем случае?
Аватара пользователя
samdark
Администратор
Сообщения: 9489
Зарегистрирован: 2009.04.02, 13:46
Откуда: Воронеж
Контактная информация:

Re: MySQL репликация

Сообщение samdark »

rugabarbo, вроде речь об обратном:
со скоростью не более 1 сек/INSERT
Аватара пользователя
rugabarbo
Сообщения: 1063
Зарегистрирован: 2015.06.21, 16:21
Контактная информация:

Re: MySQL репликация

Сообщение rugabarbo »

Мне показалось (и до сих пор кажется), что имеется ввиду синхронизация всего в пределах секунды, иначе неясны беспокойства автора о максимизации частоты синхронизаций.

Ждём комментов автора.
Аватара пользователя
mat.twg
Сообщения: 222
Зарегистрирован: 2012.02.22, 20:44
Откуда: Санкт-Петербург

Re: MySQL репликация

Сообщение mat.twg »

zelenin писал(а):а для какой цели нуждна репликация в вашем случае?
В моём случае это подобие торговой системы (биржа, котировки, ордера... всё очень быстро), есть софт который работает с одной mySQL и есть некий фронтенд который работает с другой MySQL, соответственно каждая БД на своём выделенном сервере (пока для тестов сервера в локальной сети). Есть одна таблица, которая должна дублироваться на фронтенд, потому как перегружать запросами от web-пользователей биржевую БД, считаю, неверным решением. Для фронтенда обновление таблицы допустимо в пределах одной секунды.
Аватара пользователя
rugabarbo
Сообщения: 1063
Зарегистрирован: 2015.06.21, 16:21
Контактная информация:

Re: MySQL репликация

Сообщение rugabarbo »

Тогда такой вопрос: а схемы у этих БД совпадают? Или вы надеетесь синхронизировать лишь отдельные таблицы двух баз?

Вы пишете про одну таблицу и при этом упоминаете про репликацию, но репликация - это инструмент уровня всей БД, а не одной отдельной таблицы. Это надо понимать.
zelenin
Сообщения: 10596
Зарегистрирован: 2013.04.20, 11:30

Re: MySQL репликация

Сообщение zelenin »

я бы в вашем случае перешел на быструю базу типа тарантул для биржевых дел и любые другие базы для всего остального. Причем тарантул будет обновляться через апдейт снаружи по событиям типа:

Код: Выделить всё

function onEntitySave(EntitySave $event)
{
$this->tarantoolClient->updateEntity($event->getEntity());
}
Аватара пользователя
mat.twg
Сообщения: 222
Зарегистрирован: 2012.02.22, 20:44
Откуда: Санкт-Петербург

Re: MySQL репликация

Сообщение mat.twg »

zelenin писал(а):я бы в вашем случае перешел на быструю базу типа тарантул для биржевых дел и любые другие базы для всего остального. Причем тарантул будет обновляться через апдейт снаружи по событиям типа:

Код: Выделить всё

function onEntitySave(EntitySave $event)
{
$this->tarantoolClient->updateEntity($event->getEntity());
}
 
Спасибо, буду иметь ввиду, но пока нет возможности перейти на другую связку...
Аватара пользователя
rugabarbo
Сообщения: 1063
Зарегистрирован: 2015.06.21, 16:21
Контактная информация:

Re: MySQL репликация

Сообщение rugabarbo »

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

1) Поднял отдельное обычное HTTP-API (обычные GET-запросы с JSON-ответами, например)
2) Под это API положил PHP-сервис, который будет заниматься вставкой/обновлением/удалением данных в обеих таблицах одновременно (эдакая ручная синхронизация)
4) Далее стал бы HTTP-API использовать везде, где нужны операции записи над этими таблицами (и в приложении A, и в приложении B)
5) Для использования API можно написать компонент обёртку (клиент)
6) Операции чтения по-прежнему делаются напрямую из таблиц и приложением A, и приложением B

Таким образом:
1) синхронным изменением данных в таблицах будет заниматься выделенный PHP-сервис, доступный по API
2) чтением данных из таблиц каждое приложение (A и B) будет заниматься самостоятельно
3) не придётся мутить никаких скриптов/триггеров и прочих доработок уровня БД
4) сохранится привычный вам стэк (MySQL, PHP, HTTP-API, JSON)
5) ...
6) PROFIT?!
Последний раз редактировалось rugabarbo 2016.09.06, 18:51, всего редактировалось 1 раз.
Аватара пользователя
rugabarbo
Сообщения: 1063
Зарегистрирован: 2015.06.21, 16:21
Контактная информация:

Re: MySQL репликация

Сообщение rugabarbo »

И да, вы не ответили на мой вопрос: viewtopic.php?f=4&t=38299&p=196827#p196822 - если синхронизировать нужно лишь одну/несколько схожих таблиц, а схемы БД в целом разные, то у вас особо выбора уже и нет. По-любому репликация не подойдёт.
Аватара пользователя
mat.twg
Сообщения: 222
Зарегистрирован: 2012.02.22, 20:44
Откуда: Санкт-Петербург

Re: MySQL репликация

Сообщение mat.twg »

rugabarbo писал(а):mat.twg, если на другую связку перейти нельзя, то я бы сделал следующее:

1) Поднял отдельное обычное HTTP-API (обычные GET-запросы с JSON-ответами, например)
2) Под это API положил PHP-сервис, который будет заниматься вставкой/обновлением/удалением данных в обеих таблицах одновременно (эдакая ручная синхронизация)
4) Далее стал бы HTTP-API использовать везде, где нужны операции записи над этими таблицами (и в приложении A, и в приложении B)
5) Для использования API можно написать компонент обёртку (клиент)
6) Операции чтения по-прежнему делаются напрямую из таблиц и приложением A, и приложением B

Таким образом:
1) синхронным изменением данных в таблицах будет заниматься выделенный PHP-сервис, доступный по API
2) чтением данных из таблиц каждое приложение (A и B) будет заниматься самостоятельно
3) не придётся мутить никаких скриптов/триггеров и прочих доработок уровня БД
4) сохранится привычный вам стэк (MySQL, PHP, HTTP-API, JSON)
5) ...
6) PROFIT?!
Это в планах на будущее, но пока что есть - то есть... весь проект вырос спонтанно, из более мелких, поэтому спроектировать всё с нуля и сделать по ТЗ не было возможности, так же как и времени... буду думать...
Аватара пользователя
mat.twg
Сообщения: 222
Зарегистрирован: 2012.02.22, 20:44
Откуда: Санкт-Петербург

Re: MySQL репликация

Сообщение mat.twg »

rugabarbo писал(а):И да, вы не ответили на мой вопрос: viewtopic.php?f=4&t=38299&p=196827#p196822 - если синхронизировать нужно лишь одну/несколько схожих таблиц, а схемы БД в целом разные, то у вас особо выбора уже и нет. По-любому репликация не подойдёт.
На сколько я понимаю, реплицировать только одну или несколько таблиц вполне возможно... поэтому как вариант я его и рассматриваю.
Аватара пользователя
rugabarbo
Сообщения: 1063
Зарегистрирован: 2015.06.21, 16:21
Контактная информация:

Re: MySQL репликация

Сообщение rugabarbo »

mat.twg писал(а):Это в планах на будущее, но пока что есть - то есть... весь проект вырос спонтанно, из более мелких, поэтому спроектировать всё с нуля и сделать по ТЗ не было возможности, так же как и времени... буду думать...
Здесь не надо всё проектировать с нуля. Нужно сделать один выделенный сервис для синхронного управления таблицами на известных вам технологиях.
mat.twg писал(а):на сколько я понимаю, реплицировать только одну или несколько таблиц вполне возможно... поэтому как вариант я его и рассматриваю.
Это возможно через жуткий костыль - MySQL не умеет забирать с мастера в слейв только одну табличку. Он будет лить в бинлог все-все-все изменения БД, а уже слейв будет пытаться их отсекать, выбирая оттуда лишь одну таблицу. Если базы большие, то этот костыль очень быстро даст о себе знать (ударит по производительности репликации).
Аватара пользователя
mat.twg
Сообщения: 222
Зарегистрирован: 2012.02.22, 20:44
Откуда: Санкт-Петербург

Re: MySQL репликация

Сообщение mat.twg »

rugabarbo писал(а): Здесь не надо всё проектировать с нуля. Нужно сделать один выделенный сервис для синхронного управления таблицами на известных вам технологиях.
Как раз софт который работает с биржей надо.. но это детали... и таблицу которую надо передать полностью триггерная...
rugabarbo писал(а):Это возможно через жуткий костыль - MySQL не умеет забирать с мастера в слейв только одну табличку. Он будет лить в бинлог все-все-все изменения БД, а уже слейв будет пытаться их отсекать, выбирая оттуда лишь одну таблицу. Если базы большие, то этот костыль очень быстро даст о себе знать (ударит по производительности репликации).
Добро!
Аватара пользователя
rugabarbo
Сообщения: 1063
Зарегистрирован: 2015.06.21, 16:21
Контактная информация:

Re: MySQL репликация

Сообщение rugabarbo »

Имхо, костыли уровня БД - самые страшные.
Ответить