Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Оффлайн-тяпничная репликация
|
|||
|---|---|---|---|
|
#18+
hVostt Куда сложнее выглядит задача обеспечения каскадной целостности, так как дифф нужно применить в правильном порядке. И да. Если идти от способа вычисления хеша от ключа, то задача -- не выполнимая. Потому что натуральные ключи могут меняться. Для репликатора изменение ключа, это удаление + создание. А на мастере это ON UPDATE CASCADE. Репликатор тупо встанет раком со своими космическими алгоритмами. Сложные решения -- плохо, уродливо и некрасиво. Простые решения -- хорошо, и красиво. Тоже хорошее замечание. Порядок обновления. Я опишу его ещё пунктом. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.02.2020, 09:04 |
|
||
|
Оффлайн-тяпничная репликация
|
|||
|---|---|---|---|
|
#18+
mayton Я опишу его как ещё один пункт. Еще момент из практики: при репликации для бэкапа есть ненужные данные, т.е. данные которые можно безболезненно терять, но эти данные интенсивно меняются и создают сильную нагрузку на репликатор. Например таблица с логом для логирования всех событий бизнес-логики, также бывают интенсивно меняющиеся поля в справочнике, например в справочнике пользователей может быть поле "дата последнего входа". Для избежания излишней репликации для БД должен быть конфиг где указаны исключения в виде таблицы целиком или только поля таблицы. И еще остается отдельный вопрос что делать при изменении структуры БД. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.02.2020, 09:12 |
|
||
|
Оффлайн-тяпничная репликация
|
|||
|---|---|---|---|
|
#18+
hVostt mayton Ожидаю ваших предложений. Почему не хеш? Потому что хеш медленный и нафиг он тут не упал. Он медленный. Достаточно выбрать подходящую CRC функцию с хорошим распределением. Для нашей задачи (в однопоточном варианте) узким местом будет IO подсистемы БД и Network. Я не вижу смысла тратить время на поиски "хороших" или других распределений. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.02.2020, 09:14 |
|
||
|
Оффлайн-тяпничная репликация
|
|||
|---|---|---|---|
|
#18+
Dima T И еще остается отдельный вопрос что делать при изменении структуры БД. Мы начали с простой утилиты. И хотелось бы сохранить определенную простоту use case и в дальнейшем. Требования касающиеся изменений обьектов схемы (table columns) я опишу отдельным пунктом. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.02.2020, 09:19 |
|
||
|
Оффлайн-тяпничная репликация
|
|||
|---|---|---|---|
|
#18+
mayton Как быть с удалёнными строками? Никак. Удалять не нужно. Сделай флаг deleted и всё. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.02.2020, 09:36 |
|
||
|
Оффлайн-тяпничная репликация
|
|||
|---|---|---|---|
|
#18+
crutchmaster mayton Как быть с удалёнными строками? Никак. Удалять не нужно. Сделай флаг deleted и всё. Как ты себе это представляешь? Логика которая работает с master удаляет строку? Эта (основная) бизнес-логика нам недоступна. Мы ее не меняем. Это конечно моя вина что я не описал и этот пункт. Опишу чуть позже. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.02.2020, 10:31 |
|
||
|
Оффлайн-тяпничная репликация
|
|||
|---|---|---|---|
|
#18+
mayton Изменить его мы не можем. Так надо с этого было начинать. А что с ним можно делать? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.02.2020, 10:34 |
|
||
|
Оффлайн-тяпничная репликация
|
|||
|---|---|---|---|
|
#18+
Добавляю еще дополнения к базовому ТЗ. 14) Репликатор не вносит изменений в логику основных приложений которые работают с master и slave. Однако репликатор (по согласованию с db owner) может добавить дополнительные таблицы. Поля. И триггеры для отслеживания INSERT/DELETE/UPDATE на целевых таблицах ( RDS ). 15) Репликатор обладает сведениями относительно зависимостей таблиц. Зависимости описываются в конфигурационном файле. replicator.conf Код: sql 1. 2. В данном примере описано что таблица emp - дочерняя по отношению к dept. И процесс репликации (sync) должен учитывать направление от дочерних к родительским. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.02.2020, 10:49 |
|
||
|
Оффлайн-тяпничная репликация
|
|||
|---|---|---|---|
|
#18+
16) Репликатор имеет команду полной синхронизации (fullsync) Код: sql 1. По согласованию с владельцем БД для поддержки плановых обновлений версии ПО master/slave (добавление новых колонок) может потребоваться принудительное обновление 100% объема реплицируемых справочников (replicated dictionaries set ( RDS )). Логика расчета hash, lastUpdateTime и прочих служебных полей в этом случае исходит из предположения что 100% datarows обновились и требуется перерасчет всего объема. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.02.2020, 10:55 |
|
||
|
Оффлайн-тяпничная репликация
|
|||
|---|---|---|---|
|
#18+
mayton Опишу чуть позже. Да, я пробежался по треду и не понял ситуацию. То изобретение git'а, то велик для синхронизации двух бд. Что есть вообще? Что может ваш чорный ящик и как вы с ним работаете? Как узнаете, что запись удалена? Надо пройти по всем, найти удаленные и передать? Не понятно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.02.2020, 11:05 |
|
||
|
Оффлайн-тяпничная репликация
|
|||
|---|---|---|---|
|
#18+
mayton Для нашей задачи (в однопоточном варианте) узким местом будет IO подсистемы БД и Network. Я не вижу смысла тратить время на поиски "хороших" или других распределений. IO всегда является узким местом, при его наличии. Не только в этой задаче, а в любой другой в принципе. Насчет хеша, всё же согласиться не могу. У хеша другие задачи. Ваша задача -- это именно CRC. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.02.2020, 11:51 |
|
||
|
Оффлайн-тяпничная репликация
|
|||
|---|---|---|---|
|
#18+
mayton И триггеры для отслеживания INSERT/DELETE/UPDATE на целевых таблицах ( RDS ). Дык если триггер можно добавить, то всё, задача решена like a charm. О чём тогда говорить? :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.02.2020, 11:53 |
|
||
|
Оффлайн-тяпничная репликация
|
|||
|---|---|---|---|
|
#18+
hVostt mayton Для нашей задачи (в однопоточном варианте) узким местом будет IO подсистемы БД и Network. Я не вижу смысла тратить время на поиски "хороших" или других распределений. IO всегда является узким местом, при его наличии. Не только в этой задаче, а в любой другой в принципе. Насчет хеша, всё же согласиться не могу. У хеша другие задачи. Ваша задача -- это именно CRC. Хвост. Я, идя тебе навстречу объявлю настроечный тип хеширования. Какой настроишь - тот и будет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.02.2020, 12:08 |
|
||
|
Оффлайн-тяпничная репликация
|
|||
|---|---|---|---|
|
#18+
hVostt mayton И триггеры для отслеживания INSERT/DELETE/UPDATE на целевых таблицах ( RDS ). Дык если триггер можно добавить, то всё, задача решена like a charm. О чём тогда говорить? :) Отлично. Но где реализация? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.02.2020, 12:09 |
|
||
|
Оффлайн-тяпничная репликация
|
|||
|---|---|---|---|
|
#18+
crutchmaster mayton Опишу чуть позже. Да, я пробежался по треду и не понял ситуацию. То изобретение git'а, то велик для синхронизации двух бд. Что есть вообще? Что может ваш чорный ящик и как вы с ним работаете? Как узнаете, что запись удалена? Надо пройти по всем, найти удаленные и передать? Не понятно. Если вы внимательно читали - я описал только ограничения и требования. Не было ни строчки по самому алгоритму. Но я верю в вашу фантазию и в ваше умение синтезировать алгоритмы. Попробуйте. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.02.2020, 12:10 |
|
||
|
Оффлайн-тяпничная репликация
|
|||
|---|---|---|---|
|
#18+
mayton Отлично. Но где реализация? Создаём триггер на insert/update/delete, для каждой из таблиц или для всех (зависит от возможностей СУБД). Триггер пишет в табличку Changes(Timestamp, TableName,Key,ChangeType), где ChangeType одно из значений C|U|D. Отправляем обновления по Timestamp, фильтруя по времени последнего обновления. Старые записи по какому-то регламенту подчищаем. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.02.2020, 13:04 |
|
||
|
Оффлайн-тяпничная репликация
|
|||
|---|---|---|---|
|
#18+
mayton, Key это конкатенация значений ключа, допустим, через знак |. Можно конечно и хеши, но нафига они тут нужны непонятно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.02.2020, 13:05 |
|
||
|
Оффлайн-тяпничная репликация
|
|||
|---|---|---|---|
|
#18+
Более того, хеш здесь не поможет, так как нам нужно находить записи для C|U из оригинальных таблиц, и там эти хеши вообще не упёрлись. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.02.2020, 13:07 |
|
||
|
Оффлайн-тяпничная репликация
|
|||
|---|---|---|---|
|
#18+
hVostt Насчет хеша, всё же согласиться не могу. У хеша другие задачи. Ваша задача -- это именно CRC. Хэш это альтернативное название для алгоритмов расчета контрольной суммы. https://ru.wikipedia.org/wiki/Контрольная_сумма С точки зрения математики контрольная сумма является результатом хеш-функции , используемой для вычисления контрольного кода — небольшого количества бит внутри большого блока данных И CRC это не контрольная сумма, а один из алгоритмов расчета контрольной суммы https://ru.wikipedia.org/wiki/Циклический_избыточный_код Циклический избыточный код (англ. Cyclic redundancy check, CRC[1]) — алгоритм нахождения контрольной суммы, предназначенный для проверки целостности данных[2]. CRC является практическим приложением помехоустойчивого кодирования, основанным на определённых математических свойствах циклического кода. В общем если хочешь называть хэш контрольной суммой и писать CRC, пусть будет так. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.02.2020, 13:29 |
|
||
|
Оффлайн-тяпничная репликация
|
|||
|---|---|---|---|
|
#18+
mayton Но где реализация? Алгоритм: 1. Получаем из приёмника ts1, время последней удачной репликации. 2. Получаем текущее время ts2 и сохраняем в файл. 3. Для каждой таблицы из списка реплицируемых таблиц выполняем select * where lastModified >= :ts1 и сохраняем результат в файл(ы). 4. Получаем список удалённых записей из таблицы, заполняемой триггерами и сохраняем в файл(ы). 5. Упаковываем все вышеперечисленные файлы и отправляем на приёмник. 6. Спокойно спим до следующего сеанса. На приёмнике полученные файлы распаковываются и применяются, включая значение ts2, которое потом будет выдано как ts1. Кодируется прямолинейно на любом языке, имеющем средства доступа к любой БД. Ява сойдёт. PS: Список таблиц в пункте 3 лучше иметь предварительно отсортированным по зависимостям внешних ключей. Тогда на приёмнике не придётся использовать отложенные ограничения целостности. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.02.2020, 14:46 |
|
||
|
Оффлайн-тяпничная репликация
|
|||
|---|---|---|---|
|
#18+
hVostt mayton, Key это конкатенация значений ключа, допустим, через знак |. Можно конечно и хеши, но нафига они тут нужны непонятно. Если таблица (table1) большая. От 1 млн строк и мы детектируем удалённые - то нам надо чтобы 1 экземпляр приложения репликатор открыл два курсора на master/slave и после merge принял решение об удалённых datarows. Но я до последнего избегаю этого сценария, пытаясь соптимизировать networking. Этот пункт важен и я его включал уже в SR. Если вы считаете что хеши не нужны - ОК выбрасывайте. Но я их пока оставляю как опцию. Если они есть - хорошо. Нету - тоже сойдет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.02.2020, 15:33 |
|
||
|
Оффлайн-тяпничная репликация
|
|||
|---|---|---|---|
|
#18+
Dimitry Sibiryakov 5. Упаковываем все вышеперечисленные файлы и отправляем на приёмник. Пока мы еще не обсуждали нигде способы отправки. Да и нет такого протокола. Есть две базы. Висят где-то в космосе. И есть 1 ваш процесс который поднят либо "тут" либо "там". Никакого другого протокола связи нет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.02.2020, 15:59 |
|
||
|
Оффлайн-тяпничная репликация
|
|||
|---|---|---|---|
|
#18+
mayton Никакого другого протокола связи нет. А разве "доставка любым протоколом" не подпадает под этот случай??? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.02.2020, 16:14 |
|
||
|
Оффлайн-тяпничная репликация
|
|||
|---|---|---|---|
|
#18+
Basil A. Sidorov mayton Никакого другого протокола связи нет. А разве "доставка любым протоколом" не подпадает под этот случай??? Дмитрий писал. 4. Получаем список удалённых записей из таблицы, заполняемой триггерами и сохраняем в файл(ы). 5. Упаковываем все вышеперечисленные файлы и отправляем на приёмник. Это был ответ на предложение по отправке файлов. О файлах я еще не думал. Это - другой уровень репликации. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.02.2020, 16:17 |
|
||
|
Оффлайн-тяпничная репликация
|
|||
|---|---|---|---|
|
#18+
Dimitry Sibiryakov Кодируется прямолинейно на любом языке, имеющем средства доступа к любой БД. Ява сойдёт. 2 All! Давайте - маленкий челлендж. Пускай это будет не требование но Secondary Goal этого топика. Сделаем на языках: - Rust - Go Я очькую только в части сопряжения с БД. Не знаю насколько хорошо Rust укомплектован дровами к PG/ORA/MS/MySQL. На обоих языках я написал аж ПреведМир так што я недалеко ушел в этом смысле от вас, коллеги. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.02.2020, 17:43 |
|
||
|
|

start [/forum/topic.php?fid=16&msg=39924792&tid=1339829]: |
0ms |
get settings: |
9ms |
get forum list: |
13ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
175ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
53ms |
get tp. blocked users: |
1ms |
| others: | 280ms |
| total: | 550ms |

| 0 / 0 |
