на 2 публикации. Но как избежать волны инконсистенси в самых свежих данных, если мы джойним таблицы из двух разных подписок?
На подписчике вообще не хранится оффсет в вал, и похоже нельзя просто отсечь слишком новые туплы после xid самой старой подписки, во время чтения.
Нужно что-то свое костылить?
А почему две репликации будут быстрее одной? Если правильно помню, работа с wal однопоточная
Если таблицы логически не связаны, то есть знаем что одна трансакция тронет лишь набор таблиц в одной подписке. А быстрее будет, потому что уже два ядра будут работать и больше ио потоков.
Но wal пишется в один поток, откуда ускорение?
Записывать не медленно ж, медленно их на реплике применять если большой поток
Так оно и на реплике тоже в один поток... Может кто поопытнее в этой части подскажет, имхо выигрыш сомнительный будет
Я про логическую репликацию :) Тут и правда все в один процесс, но не все так просто как с бинарной репликацией: нужно квери планы заново строить, искать какие индексы обновлять, проверять unique constraints и тому подобное.
Я прочитал. Эти расходы что в одной что в двух репликах будут, и не факт что в двух репликах их будет меньше
С одной подпиской уже одно ядро запинено на 100% и расти некуда. С двумя подписками будут 2 ядра работать на 50%, но минус в том что таблицы нужно осторожно распределять между публикациями чтоб не дай б-г одна трансакция записала сразу в 2 публикации на мастере.
Обсуждают сегодня