o_v_aА как использовать копию в случае отказа мастера и как потом восстановить штатную репликацию - не нашёл.
копия - это прямо копия, с которой можно работать, она в read-only. Отвязываешь от read-only, и делай что хочешь.
Восстановить штатную репликацию - все с самого начала, иначе никак. Т.е. берем базу, копируем, заряжаем репликацию, и т.д.

o_v_aТо есть на реплика-сервере отвязываем базы от репликации и начинаем работать с ней вместо боевой базы, ессессно, предусматривая настройки в ПО какой-то регламент под это со сменой путей доступа к базам и т.п.
ну, нет в жизни счастья, увы.
Вот тут сейчас самая полная дока (пока на английском, на русском тоже будет обязательно)
http://ib-aid.com/download/docs/hqbird2016r1userguide.pdf
там расписано что делать в случае "шеф, все пропало, спасайся кто может!". Но в случае любой репликации если мастер издох, то нужно взять реплику, превратить ее в "мастера", и зарядить все по новой. Тут любая репликация, триггерная, страничная, или еще какая - абсолютно одинакова в отношении восстановления после сбоя.
FAQ по этому делу в процессе написания, как для синхронной, так и для асинхронной репликации.
o_v_aСобственно, а пар баз мастер-реплика неограниченное количество в спарке двух HQbird?
Ну, поскольку репликация состоит из мастера и реплики, а конфигурируется только через DataGuard, получается, что 2 DataGuard должно быть.

o_v_a,

в смысле, 1 лицензия HQBird Enterprise включает 1 мастер и 1 реплику.

o_v_a,

"переводить" ничего не надо, ODS никак не затрагивается, так что все работает мгновенно. Раз сервер один, значит HQBird Ent тоже один. Сюда входит мастер и второй сервер реплики. Т.е. одна лицензия за 59к руб.

так только с триггерной репликации получится. Потому что эти две базы фактически независимые, и могут быть разной структуры.
KreatorXXIКлассика, в общем. Так работает?
это классика только в том смысле, что такое прикладное (!) решение массово классически хотят. Хотя оно не поддерживается никакой СУБД, и не может поддерживаться вообще по определению. Работает так только в Lotus Notes (если он еще жив) - там сложная система репликации, где даже только отдельные столбцы могут передаваться.

Со стороны СУБД под репликацией обычно имеют в виду "тиражирование" мастера в реплику, и делается это либо для распределения нагрузки, либо для High Availability. Пока мастер жив, реплику, разумеется, модифицировать "со стороны" невозможно. И обычно реплицируется именно журнал транзакций (хотя репликация через нбэкап в ФБ4 это опровергает).

Gallemar,

а она где-нибудь есть? Репликация master-slave предполагает отсутствие конфликтов на уровне данных. Репликация master-master предполагает наличие разных конфликтов, некоторые из которых решаются только вручную. Иначе запись на уровне sql-операторов должна синхронно идти в обе БД. Выигрыш по производительности тут получить нельзя, а значит это дело с успехом заменит синхронная или асинхронная репликация мастер-слейв.
Так что определись терминологически, что ты имеешь в виду. СУБД не может обеспечивать репликацию мастер-мастер на отдельных серверах. Такое решение может быть только программным (триггерным, дублирование потока команд из клиента, и т.д.), о чем я и сказал выше.

Gallemar,

да понятно, что multi-master write-scalable cluster. Но про запись я как раз и говорил
"More than 3× scalability performance speedup with five servers, compared with pure PostgreSQL".
То есть, либо мы берем 5 адски дорогих серверов, и получаем трехкратную адскую производительность,
или мы берем 5 дешевых серверов, и получаем ... производительность как у одного дорогого сервера.

KreatorXXIПолучается аналог бэкап-рестор на другом сервере. Только поумнее. В 4.0 планируется такая?
это не бэкап-рестор. База копируется на реплику, стартует мастер, затем реплика, после чего с мастера данные передаются в реплику. Это асинхронное. С синхронной репликацией сначала стартует реплика.

Тут уже несколько раз говорили, что эта репликация и будет в 4.0. И якобы уже есть - репликация через nbackup -b guid. В этом случае репликация асинхронная, изменения накатываются через регулярный инкремент.

KreatorXXIНеужели на рынке востребована реплика read-only?
вы не читаете, что я пишу про мастер-мастер. Такую репликацию можно сделать хоть сейчас через IBPhoenix Replicator, триггерно.
Но вы понимаете, как ваши данные будут ходить из одного мастера в другой и обратно? Если же вы хотите чтобы мастеры были вообще синхронными - то для чего вы этого хотите? Как у вас будет происходить параллельное оформление заказов в обоих мастерах?
А... Идентификаторы надо разнести? А как этим будет сам сервер заниматься? Типа, в мастер1 генераторы одни, в мастер2 другие?
И что будет при падении одного из мастеров, как будет продолжаться работа? Каков будет процесс восстановления?
Неточная терминология плюс собственные фантазии (неподкрепленные технологически) приводят к неверному обозначению проблемы, или неверным попыткам решения проблемы.

Сколько я слышу про репликацию, так все хотят чтобы "из всех баз везде чтобы волшебно синхронизировалось". При этом, казалось бы, дофига статей про специфику репликации, конфликты обновлений, и прочее. Может, мне просто повезло, что я эту репликацию мастер-мастер в Lotus Notes увидел еще в 90х? :-)

KreatorXXIНеужели на рынке востребована реплика read-only?
и еще про это добавлю. На рынке масштабирование производительности отчетов, например, востребовано давно, только все его делают по разному. Кто-то простым бэкап-рестором, кто-то через нбэкап, кто-то через on external, через сервера отчетов, и т.д.
Но больше востребована надежность после сбоя. А read-only реплика этому соответствует, да еще и позволяет масштабирование. И легко превращается в read-write в случае сбоя мастера.
В результате простой сильно сокращается, что и требовалось.
А чего вы хотите от полной репликации мастер-мастер, я не знаю.
Это как в 2008-2009, вдруг внезапно людям захотелось кластер на Firebird. Когда началась разработка, выяснилось, что решение дорогое, и клиенты не особо горят желанием за кластер платить. Соответственно заглохло, по крайней мере на 8 лет.

Я не говорю что мастер-мастер не нужен. Он нужен, вопрос только зачем, и кому.

Dimitry Sibiryakovи обойти которое можно только шардингом.
А шардинг это не мастер-мастер, а по факту или тэйблспэйс на разных серверах, или партиционирование на разных серверах.
Я может утрирую, но опять же, это вопрос терминологии.

KreatorXXI,

я как раз в начале 2000 видел, как люди сами сделали мульти-мастер репликацию на IB - триггеры плюс их софт. Но они это все делали к своей базе. Т.е. база была разработана с учетом репликации. И таких решений - полно. Но чтобы вот прямо master-master на любой базе взял и заработал - я не верю именно в это.

Когда начинаешь тыкать пальцем всякие серверные решения, на поверку оно так и оказывается - там недоделано, тут ограничения, это не работает, и т.д.
https://en.wikipedia.org/wiki/Multi-master_replication

sql anywhere? не вижу. Но да, у него есть SQL Replication, транслируются логи транзакций. PostgreSQL? про него тут уже упоминали.
MySQL? только сегодня специально на хабре нашел описание, там...

Gallemar https://habrahabr.ru/company/oleg-bunin/blog/312494/
в основном маркетинговая чешуя и адский трэш про 2PC.