|
|
|
Как быть с 2 БД, разрывом соединения и дальнейшей синхронизацией.
|
|||
|---|---|---|---|
|
#18+
Добрый день, друзья. Скажу сразу, я не DBA, а разработчик на питоне) По-этому, сразу прошу прощения за возможные ляпы. Итак, к делу: Сейчас развиваем инфраструктуру сервиса, который раньше был только внутренний. С недавних пор этим сервисом начали пользоваться клиенты из-за бугра. А так как у нас периодичеки пропадает свет или интернет, то решили выложить копию сервиса в эти ваши интернеты. Собственно со случаем, когда пропадает свет - все понятно. Но проблема возникает, когда пропадает только интернет. Если один инстанс БД разместить только локально - мир не будет видеть БД, если же наоборот в интернете - локально она не будет видна. Дико необходимо иметь живыми обе версии сервиса. Сразу приходит на ум репликация типа МАСТЕР-МАСТЕР, однако как я вижу, это не решает проблемы появления новых записей в одних и тех же таблицах на разных инстансах, во время разрыва соединения. При появлении коннекта гарантированно возникнут конфликты. Плиз, посоветуйте, как это решить? Спасибо) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.09.2014, 10:54:54 |
|
||
|
Как быть с 2 БД, разрывом соединения и дальнейшей синхронизацией.
|
|||
|---|---|---|---|
|
#18+
fynjahэто не решает проблемы появления новых записей в одних и тех же таблицах на разных инстансах, во время разрыва соединения. При появлении коннекта гарантированно возникнут конфликты. Какого именно рода конфликты? Если дублирование синтетических ключей - то это решаемо индивидуализацией начальных значений на серверах, переходом на ГУИДы либо переходом с автоинкрементов на формирование индекнтификаторов внешней логикой (серверной или клиентской). Ну а если это конфликты контента - то только система ручного (обычно с алгоритмизацией получается не очень) арбитража. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.09.2014, 13:19:11 |
|
||
|
Как быть с 2 БД, разрывом соединения и дальнейшей синхронизацией.
|
|||
|---|---|---|---|
|
#18+
AkinaКакого именно рода конфликты? Если дублирование синтетических ключей - то это решаемо индивидуализацией начальных значений на серверах, переходом на ГУИДы либо переходом с автоинкрементов на формирование индекнтификаторов внешней логикой (серверной или клиентской). Ну а если это конфликты контента - то только система ручного (обычно с алгоритмизацией получается не очень) арбитража. Спасибо за ответ! Больше именно дублирование ключей, хотя и данные сами могут изменяться. Насчет индивидуализации - да, уже прочел насчет этого. Хорошая идея, но пока не представляю как это работает и как на это перевести сервис :/ Как жаль, что в начале написания системы, я не пришел к гуидам :( ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.09.2014, 13:52:38 |
|
||
|
Как быть с 2 БД, разрывом соединения и дальнейшей синхронизацией.
|
|||
|---|---|---|---|
|
#18+
fynjahНасчет индивидуализации - да, уже прочел насчет этого. Хорошая идея, но пока не представляю как это работает и как на это перевести сервис Код: sql 1. Для первого сервера не менять, для второго поставить столько, чтобы первый до этого значения ни в жисть не добрался, но и чтобы переполнения не поиметь. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.09.2014, 18:13:47 |
|
||
|
|

start [/forum/topic.php?fid=47&msg=38755708&tid=1834187]: |
0ms |
get settings: |
4ms |
get forum list: |
9ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
44ms |
get topic data: |
5ms |
get forum data: |
1ms |
get page messages: |
33ms |
get tp. blocked users: |
1ms |
| others: | 192ms |
| total: | 293ms |

| 0 / 0 |
