|
выбор модели репликации
|
|||
---|---|---|---|
#18+
Я знаю 2 модели репликации 1- на тригерах. После каждого изменения БД, триггер собирает запрос для второй БД 2- добавляется поле 'ismodifed' которое ставится в 1 после каждого изменения , и переносятся те поля которые изменились. Какие есть плюсы и минусы у этих решений? На вскидку у 2 проблемы с удалением и последовательностью вставки. У 1 лишнее разбухание БД ... |
|||
:
Нравится:
Не нравится:
|
|||
17.06.2015, 11:27 |
|
выбор модели репликации
|
|||
---|---|---|---|
#18+
Первая неэффективна при редкой репликации, когда между сессиями успевает обновиться большая часть БД, причём некоторые записи - по несколько раз. Вторая неэффективна при большом количестве записей, когда между сессиями обновляется только малый процент от них. Вторая может нарваться на конфликт обновлений, когда репликационная транзакция сбрасывает флаг, а кто-то другой как раз запись опять меняет. Первая бесконфликтна. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
17.06.2015, 11:35 |
|
выбор модели репликации
|
|||
---|---|---|---|
#18+
Видел на прошлой работе вариант 2: с увеличением БД увеличивается время выгрузки реплики, т.к. приходится перечитывать все таблицы. Уж лучше было бы писать инфу о модификации записи в отдельный журнал вида ид таблицы, ид записи, тип модификации, но там этого почему-то сделано не было. Реплика выгружалась по 30-40 минут при БД в 30Гб. У себя сделал вариант 1. Имхо лучше, чем 2, т.к. позволяет грузить данные в хронологическом порядке. Совет: не нужно собирать запрос в триггере, лучше передавать в реплике инфу о типе изменения данных и сами данные, а запросы с параметрами собирать уже при импорте реплики. Если к этому еще прикрутить повторное использование одинаковых по тексту запросов, можно добиться заметного прироста производительности, сэкономишь ресурсы проца и время на препарирование. ... |
|||
:
Нравится:
Не нравится:
|
|||
17.06.2015, 16:52 |
|
выбор модели репликации
|
|||
---|---|---|---|
#18+
файрбердд, у меня по неопытности был сначала вариант 2. Просуществовал пару лет, затем задолбали конфликты. Да и перебор всех таблиц всегда - тоже плохо. Переделал лет 10 назад на вариант 1: при изменении в таблицу логов добавляется запись (если такой не было) с ID таблицы и ID записи и тип изменения (I или D). Когда запускается репликатор он в снапшоте работает с этой таблицей, после работы - очищает ее. Да, нужна таблица со списком участвующих в репликации таблиц. Для присвоения им ID. По этой же таблице создаются автоматически триггера для таблиц. После этого проблем нет. ... |
|||
:
Нравится:
Не нравится:
|
|||
17.06.2015, 17:05 |
|
выбор модели репликации
|
|||
---|---|---|---|
#18+
MikeDD Совет: не нужно собирать запрос в триггере, лучше передавать в реплике инфу о типе изменения данных и сами данные, а запросы с параметрами собирать уже при импорте реплики. Если к этому еще прикрутить повторное использование одинаковых по тексту запросов, можно добиться заметного прироста производительности, сэкономишь ресурсы проца и время на препарирование. Да что ты говоришь? Тоесть запрос вида Код: sql 1.
будет работать медленнее, чем серия препарированных запросов вида Код: sql 1.
да еще и по разным таблицам? Ню-ню. ... |
|||
:
Нравится:
Не нравится:
|
|||
17.06.2015, 17:06 |
|
выбор модели репликации
|
|||
---|---|---|---|
#18+
miwaonlineMikeDD Совет: не нужно собирать запрос в триггере, лучше передавать в реплике инфу о типе изменения данных и сами данные, а запросы с параметрами собирать уже при импорте реплики. Если к этому еще прикрутить повторное использование одинаковых по тексту запросов, можно добиться заметного прироста производительности, сэкономишь ресурсы проца и время на препарирование. Да что ты говоришь? Тоесть запрос вида Код: sql 1.
будет работать медленнее, чем серия препарированных запросов вида Код: sql 1.
да еще и по разным таблицам? Ню-ню.А откуда берется last_replication_id ? ... |
|||
:
Нравится:
Не нравится:
|
|||
17.06.2015, 17:10 |
|
выбор модели репликации
|
|||
---|---|---|---|
#18+
Секретное имя пользователяА откуда берется last_replication_id ? В моем варианте: Храню в отдельной таблице 1) последний_подтвержденный_принятый_мой_id 2) последний_принятый_их_id Передаю этот id вместе с пакетом репликации. Для каждого получателя генерирую пакет с "where id > :последний_подтвержденный_принятый_мой_id" При получении игнорирую данные в которых ID <= последний_принятый_их_id ... |
|||
:
Нравится:
Не нравится:
|
|||
17.06.2015, 17:22 |
|
выбор модели репликации
|
|||
---|---|---|---|
#18+
miwaonlineзапрос вида Накроется весьма забавным медным тазом на таблице с блобами. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
17.06.2015, 17:36 |
|
выбор модели репликации
|
|||
---|---|---|---|
#18+
у меня сейчас запросы собираются и хранятся , в принципе все отлично но если ковычки затеряются в тексте то может встать запись. но это бывает редко и с не критичными таблицами. хотя вариант в таблице "реплики" хранить ИД таблицы и ИД измененной записи и Тип изменения звучит интересно. ... |
|||
:
Нравится:
Не нравится:
|
|||
17.06.2015, 18:19 |
|
выбор модели репликации
|
|||
---|---|---|---|
#18+
Attidзвучит интересно Особенно это интересно в случае, когда запись вставили и поменяли пару раз ещё перед запуском репликации. А уж когда изменения включают в себя ПК, то интересность вырастает до захватывающих размеров. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
17.06.2015, 18:26 |
|
выбор модели репликации
|
|||
---|---|---|---|
#18+
Dimitry Sibiryakov, ну изменении ПК это смертный грех и такого безобразия у меня нет, я ведь не универсальную реп машину делаю. а изменение несколько раз записи перед репликаций ничего плохого не сделает, сэкономит передачу. а в первом варианте возможно что одну запись поменяют в двух БД одновременно(между синхронизациями) на разные значения, после репликации значения поменяются, но будут разные. и бд не будут идентичны. ... |
|||
:
Нравится:
Не нравится:
|
|||
17.06.2015, 18:41 |
|
выбор модели репликации
|
|||
---|---|---|---|
#18+
Attidизменение несколько раз записи перед репликаций ничего плохого не сделает, сэкономит передачу. "Эт вряд ли..." (с) Сухов. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
17.06.2015, 18:45 |
|
выбор модели репликации
|
|||
---|---|---|---|
#18+
Dimitry SibiryakovОсобенно это интересно в случае, когда запись вставили и поменяли пару раз ещё перед запуском репликации. В данном случае под "репликация" я подразумеваю процесс, после которого "не основная" база становится такой же, как "основная", на данный момент. Всё, что бывает в промежутках между этими "репликациями" - меня не интересует. Меня такой подход вполне устраивает. Да, и ещё, я соврал (забыл, что я так начинал делать, но потом убрал). Я не проверяю, есть ли запись в таблице логов, просто всегда INSERT. Во-первых, так намного быстрее, во-вторых - не бывает проблем, когда при обработке логов в снапшоте добавится еще один лог по обрабатываемой записи, логи по которой будут удалены после обработки. Вот, а в "не основную" базу уходит запись с MAX(ID) лога этой записи. Dimitry SibiryakovА уж когда изменения включают в себя ПК, Такие изменения запрещены доп. триггером, конечно. ... |
|||
:
Нравится:
Не нравится:
|
|||
17.06.2015, 20:02 |
|
выбор модели репликации
|
|||
---|---|---|---|
#18+
Dimitry Sibiryakovmiwaonlineзапрос вида Накроется весьма забавным медным тазом на таблице с блобами. Естесственно. Это, как по мне, главная проблема первого варианта. Не удивлен, что ты об этом в курсе. Вообще есть что-то в репликации, о чем ты не в курсе? Секретное имя пользователяА откуда берется last_replication_id ? Сохраняется из предыдущего сеанса связи. Изначально инициализируется тем, кто настраивает репликацию или нулем. Attidа в первом варианте возможно что одну запись поменяют в двух БД одновременно(между синхронизациями) на разные значения, после репликации значения поменяются, но будут разные. и бд не будут идентичны. От этого не застрахованы оба предложенных варианта. ... |
|||
:
Нравится:
Не нравится:
|
|||
17.06.2015, 22:16 |
|
выбор модели репликации
|
|||
---|---|---|---|
#18+
miwaonlineесть что-то в репликации, о чем ты не в курсе? Да. Когда я был на докладе по работе Галеры, там упоминались какие-то академические работы и изыскания в которых я не понял ни слова. Но говорилось о них с таким придыханием, что это должен быть полный переворот в данной области. С другой стороны, с тех пор прошло шесть лет, а Галера ещё не захватила мир... Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
17.06.2015, 22:29 |
|
выбор модели репликации
|
|||
---|---|---|---|
#18+
miwaonlineMikeDD Совет: не нужно собирать запрос в триггере, лучше передавать в реплике инфу о типе изменения данных и сами данные, а запросы с параметрами собирать уже при импорте реплики. Если к этому еще прикрутить повторное использование одинаковых по тексту запросов, можно добиться заметного прироста производительности, сэкономишь ресурсы проца и время на препарирование. Да что ты говоришь? Тоесть запрос вида Код: sql 1.
будет работать медленнее, чем серия препарированных запросов вида Код: sql 1.
да еще и по разным таблицам? Ню-ню. А нафига ТСу генерить селективные запросы в триггерах, если в них и так ясно что и как меняли? Ты читать умеешь? Я говорил про запросы insert/delete/update, которые ТС собирается генерить в виде текста в триггерах. И таки да, влияет, подробнее тут: http://www.sql.ru/forum/836300/tyazhelaya-procedura-v-triggere ... |
|||
:
Нравится:
Не нравится:
|
|||
17.06.2015, 23:06 |
|
выбор модели репликации
|
|||
---|---|---|---|
#18+
miwaonlineСекретное имя пользователяА откуда берется last_replication_id ? Сохраняется из предыдущего сеанса связи. Изначально инициализируется тем, кто настраивает репликацию или нулем. Шавлюк ЕвгенийСекретное имя пользователяА откуда берется last_replication_id ? В моем варианте: Храню в отдельной таблице 1) последний_подтвержденный_принятый_мой_id 2) последний_принятый_их_id Передаю этот id вместе с пакетом репликации. Для каждого получателя генерирую пакет с "where id > :последний_подтвержденный_принятый_мой_id" При получении игнорирую данные в которых ID <= последний_принятый_их_id а кто ид генерит и в какой момент ? длинные транзакции нормально реплицируются ? меня смущает сравнение ид на больше-меньше ... |
|||
:
Нравится:
Не нравится:
|
|||
17.06.2015, 23:29 |
|
выбор модели репликации
|
|||
---|---|---|---|
#18+
Структура таблиц Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. 80. 81. 82. 83. 84. 85. 86. 87. 88. 89. 90. 91. 92. 93. 94. 95. 96. 97. 98. 99. 100. 101. 102. 103. 104. 105. 106. 107. 108. 109. 110. 111. 112. 113. 114. 115. 116. 117. 118. 119. 120. 121. 122. 123. 124. 125. 126. 127. 128. 129. 130. 131. 132. 133. 134. 135. 136. 137. 138. 139. 140. 141. 142. 143. 144. 145. 146. 147. 148. 149. 150. 151. 152. 153. 154. 155. 156. 157. 158. 159. 160. 161. 162. 163. 164. 165. 166. 167. 168. 169. 170. 171. 172. 173. 174. 175. 176. 177. 178. 179. 180. 181. 182. 183. 184. 185. 186. 187. 188. 189. 190. 191. 192. 193. 194. 195. 196. 197. 198. 199. 200. 201. 202. 203. 204. 205. 206. 207. 208. 209. 210. 211. 212. 213. 214. 215. 216. 217. 218. 219. 220. 221. 222. 223. 224. 225. 226. 227. 228. 229. 230. 231. 232. 233. 234. 235. 236. 237. 238. 239. 240. 241. 242. 243. 244. 245. 246. 247. 248. 249. 250. 251. 252. 253. 254. 255. 256. 257. 258. 259. 260. 261. 262. 263. 264. 265. 266. 267. 268. 269. 270. 271. 272. 273. 274. 275. 276. 277. 278. 279. 280. 281. 282. 283. 284. 285. 286. 287. 288. 289. 290. 291. 292. 293. 294. 295. 296. 297. 298. 299. 300. 301. 302. 303. 304. 305. 306. 307. 308.
Триггер на каждую таблицу выглядит так (текст формируется автоматически в триггере UPDATE_TABLES_BIU0) Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15.
Коротко как работает: таблица UPDATE_TRANSACTIONS Содержит список БД с которыми эта БД обменивается. Для основной base_id=1 ID_TRANSACTION соответствует последнему подтвержденному значению UPDATE_LOG.ID_TRANSACTION на текущей БД В пакете обновления содержится информация о последнем полученном обновлении ID_LASTRECEIVE последнее получение от удаленной БД. Соответствует UPDATE_LOG.ID_TRANSACTION удаленной БД. При приеме информации игнорируются все данные в пакете с ID_TRANSACTION < ID_LASTRECEIVE Секретное имя пользователяа кто ид генерит и в какой момент ? длинные транзакции нормально реплицируются ? меня смущает сравнение ид на больше-меньше 1) ID генерится в триггере UPDATE_LOG_BI0 2) Длинные транзакции: есть процедура get_mintime_connections, которая возвращает дату старта самой старой не RO-транзакции. Отправляю только те данные, которые старше этой транзакции. За это отвечает процедура BEFORE_SAVEDELTA Описывать много, если интересно отвечу. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.06.2015, 01:10 |
|
выбор модели репликации
|
|||
---|---|---|---|
#18+
MikeDDА нафига ТСу генерить селективные запросы в триггерах, если в них и так ясно что и как меняли? Ты читать умеешь? Я говорил про запросы insert/delete/update, которые ТС собирается генерить в виде текста в триггерах. И таки да, влияет, подробнее тут: http://www.sql.ru/forum/836300/tyazhelaya-procedura-v-triggere В тригерах никто ничего селектить не будет, само собой. Выборки будет делать репликатор и я продемонстрировал, в каком случае они будут значительно быстрее. О том что долгоиграющая процедура будет тормозить триггер никто не спорит, но генерация запроса в тригере... Скажем так, лично я не мерял, но говорить можно о единицах миллисекунд. Секретное имя пользователяа кто ид генерит и в какой момент ? длинные транзакции нормально реплицируются ? меня смущает сравнение ид на больше-меньше ID генерирует реплицируемая база в момент вставки очередного сгенерированного запроса в replication_log. Длительность транзакции не принципиальна. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.06.2015, 08:16 |
|
выбор модели репликации
|
|||
---|---|---|---|
#18+
Dimitry Sibiryakovmiwaonlineесть что-то в репликации, о чем ты не в курсе? Да. Когда я был на докладе по работе Галеры, там упоминались какие-то академические работы и изыскания в которых я не понял ни слова. Но говорилось о них с таким придыханием, что это должен быть полный переворот в данной области. С другой стороны, с тех пор прошло шесть лет, а Галера ещё не захватила мир... Ты об этом ? Ну, нам, рабоче-крестьянскому классу кластеры не интересны. С другой стороны нормально, что человек, рассказывающий о своем проекте, говорит о нем с воодушевлением. И нормально, что другие не видят причин для такого воодушевления :) ... |
|||
:
Нравится:
Не нравится:
|
|||
18.06.2015, 08:23 |
|
|
start [/forum/topic.php?fid=40&fpage=75&tid=1562770]: |
0ms |
get settings: |
8ms |
get forum list: |
12ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
29ms |
get topic data: |
32ms |
get forum data: |
4ms |
get page messages: |
55ms |
get tp. blocked users: |
1ms |
others: | 14ms |
total: | 161ms |
0 / 0 |