MySQL репликация
MySQL репликация
Всем привет! вопрос не совсем по 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
Собственно рассматриваю два варианта:
1. По крону со sleep 1 - но не очень как то нравится...
2. Использовать репликацию А.master -> B.slave, но тут у меня пробелы в знаниях... не могу найти какова максимальная частота репликаций, а так же есть ли возможность в MySQL 5.6 запускать репликацию в триггере сервера A?
Буду всем весьма признателен, кто даст нужное направление и прольёт свет на мои вопросы.. не исключаю, что есть более изящное решение, однако я его пока не нашёл...
пс: mySQL 5.6
Re: MySQL репликация
В случае MySQL master-slave отставание слэйва от мастера будет зависеть от многих и многих факторов: от железа, от нагрузки на слэйв, от интенсивности нагрузки мастера, от схемы БД, от сети. На деле я ни разу не видел нулевое отставание. Хотя бы пару секунд отставание всегда есть.
Исходя из этого, думаю, что для вашей задачи классический master-slave не подойдёт.
Лучше с кем-то из опытных админов поговорить на эту тему. По мне так MySQL master-slave очень хорошо подходит для теневого бэкапирования данных, но не для моментальной синхронизации.
Исходя из этого, думаю, что для вашей задачи классический master-slave не подойдёт.
Лучше с кем-то из опытных админов поговорить на эту тему. По мне так MySQL master-slave очень хорошо подходит для теневого бэкапирования данных, но не для моментальной синхронизации.
Последний раз редактировалось rugabarbo 2016.09.06, 17:28, всего редактировалось 1 раз.
Re: MySQL репликация
а для какой цели нуждна репликация в вашем случае?
- samdark
- Администратор
- Сообщения: 9489
- Зарегистрирован: 2009.04.02, 13:46
- Откуда: Воронеж
- Контактная информация:
Re: MySQL репликация
rugabarbo, вроде речь об обратном:
со скоростью не более 1 сек/INSERT
Нравится Yii? Давайте сделаем его лучше!.
Re: MySQL репликация
Мне показалось (и до сих пор кажется), что имеется ввиду синхронизация всего в пределах секунды, иначе неясны беспокойства автора о максимизации частоты синхронизаций.
Ждём комментов автора.
Ждём комментов автора.
Re: MySQL репликация
В моём случае это подобие торговой системы (биржа, котировки, ордера... всё очень быстро), есть софт который работает с одной mySQL и есть некий фронтенд который работает с другой MySQL, соответственно каждая БД на своём выделенном сервере (пока для тестов сервера в локальной сети). Есть одна таблица, которая должна дублироваться на фронтенд, потому как перегружать запросами от web-пользователей биржевую БД, считаю, неверным решением. Для фронтенда обновление таблицы допустимо в пределах одной секунды.zelenin писал(а):а для какой цели нуждна репликация в вашем случае?
Re: MySQL репликация
Тогда такой вопрос: а схемы у этих БД совпадают? Или вы надеетесь синхронизировать лишь отдельные таблицы двух баз?
Вы пишете про одну таблицу и при этом упоминаете про репликацию, но репликация - это инструмент уровня всей БД, а не одной отдельной таблицы. Это надо понимать.
Вы пишете про одну таблицу и при этом упоминаете про репликацию, но репликация - это инструмент уровня всей БД, а не одной отдельной таблицы. Это надо понимать.
Re: MySQL репликация
я бы в вашем случае перешел на быструю базу типа тарантул для биржевых дел и любые другие базы для всего остального. Причем тарантул будет обновляться через апдейт снаружи по событиям типа:
Код: Выделить всё
function onEntitySave(EntitySave $event)
{
$this->tarantoolClient->updateEntity($event->getEntity());
}
Re: MySQL репликация
Спасибо, буду иметь ввиду, но пока нет возможности перейти на другую связку...zelenin писал(а):я бы в вашем случае перешел на быструю базу типа тарантул для биржевых дел и любые другие базы для всего остального. Причем тарантул будет обновляться через апдейт снаружи по событиям типа:Код: Выделить всё
function onEntitySave(EntitySave $event) { $this->tarantoolClient->updateEntity($event->getEntity()); }
Re: MySQL репликация
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?!
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 раз.
Re: MySQL репликация
И да, вы не ответили на мой вопрос: viewtopic.php?f=4&t=38299&p=196827#p196822 - если синхронизировать нужно лишь одну/несколько схожих таблиц, а схемы БД в целом разные, то у вас особо выбора уже и нет. По-любому репликация не подойдёт.
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?!
Re: MySQL репликация
На сколько я понимаю, реплицировать только одну или несколько таблиц вполне возможно... поэтому как вариант я его и рассматриваю.rugabarbo писал(а):И да, вы не ответили на мой вопрос: viewtopic.php?f=4&t=38299&p=196827#p196822 - если синхронизировать нужно лишь одну/несколько схожих таблиц, а схемы БД в целом разные, то у вас особо выбора уже и нет. По-любому репликация не подойдёт.
Re: MySQL репликация
Здесь не надо всё проектировать с нуля. Нужно сделать один выделенный сервис для синхронного управления таблицами на известных вам технологиях.mat.twg писал(а):Это в планах на будущее, но пока что есть - то есть... весь проект вырос спонтанно, из более мелких, поэтому спроектировать всё с нуля и сделать по ТЗ не было возможности, так же как и времени... буду думать...
Это возможно через жуткий костыль - MySQL не умеет забирать с мастера в слейв только одну табличку. Он будет лить в бинлог все-все-все изменения БД, а уже слейв будет пытаться их отсекать, выбирая оттуда лишь одну таблицу. Если базы большие, то этот костыль очень быстро даст о себе знать (ударит по производительности репликации).mat.twg писал(а):на сколько я понимаю, реплицировать только одну или несколько таблиц вполне возможно... поэтому как вариант я его и рассматриваю.
Re: MySQL репликация
Как раз софт который работает с биржей надо.. но это детали... и таблицу которую надо передать полностью триггерная...rugabarbo писал(а): Здесь не надо всё проектировать с нуля. Нужно сделать один выделенный сервис для синхронного управления таблицами на известных вам технологиях.
Добро!rugabarbo писал(а):Это возможно через жуткий костыль - MySQL не умеет забирать с мастера в слейв только одну табличку. Он будет лить в бинлог все-все-все изменения БД, а уже слейв будет пытаться их отсекать, выбирая оттуда лишь одну таблицу. Если базы большие, то этот костыль очень быстро даст о себе знать (ударит по производительности репликации).
Re: MySQL репликация
Имхо, костыли уровня БД - самые страшные.