A resposta não é apenas um sim ou um não, é um depende.
As maiores restrições para o uso de um replicador assíncrono de dados são:
- Sua base de dados precisa estar com pelo menos chaves primárias formalmente definidas, e o ideal é que também as chaves estrangeiras estejam formalmente definidas.
- A forma de usar identificadores únicos precisa ser ajustada. Por exemplo se sua aplicação usa sequences (ou colunas tipo identifier, etc) para a atribuição automática de um número para um cliente, um pedido de vendas, etc, será necessário trabalhar no sentido de criar-se um script para o ajuste das sequências em cada servidor de banco de dados que for existir. . Numa situação onde tivessemos 3 servidores, por exemplo, num dos servidores a sequence numeraria na ordem 1, 4, 7, etc, no outro servidor seria 2, 5, 8, etc e no terceiro seria 3, 6, 9, etc.
- Um outro cuidado refere-se ao uso de triggers pela aplicação. Se a aplicação não usa triggers ou a usa apenas para atribuição de IDs, etc, então não tem nenhum problema. Se a aplicação usa triggers então estas triggers precisam ser analisadas, principalmente triggers que façam totalizações, resumos, etc. Exemplificando: Se temos uma trigger num sistema contábil que automaticamente ajusta o saldo de uma conta a partir de um lançamento contábil, então temos que desabilitar esta trigger nos servidores deixando-a ativa apenas em um dos servidores para que não haja concorrência na atualização deste saldo gerando inconsistências. Ficando ativa em apenas um dos servidores ela calculará o saldo corretamente à medida que receba os lançamentos provenientes da replicação dos outros servidores, e depois replica o saldo atualizado para todos.
- Um último cuidado, um pouco relacionado ao item anterior, é quanto à concorrência. Se sua aplicação por exemplo é de controle de estoque, então temos que controlar a aplicação para que um servidor admita transações de estoque apenas relativa à sua filial / site caso contrário teremos saldos de estoque inconsistentes. Se você tem então uma tabela ESTOQUE que contenha o código do produto e o código do local, então o servidor local pode atualizar ESTOQUE apenas para o código do local onde está, se atualizar o saldo de itens de outros servidores isso vai gerar erros nos saldos devido à falta de sincronismo instantâneo entre os servidores. (replicador assíncrono não tem two-phase-commit).
As restrições acima não são exclusivas do replicador ObjectMMRS, é muito importante entender que estas limitações são para QUALQUER replicador assíncrono, não existe meios de se livrar destas limitações sem trabalhar de forma síncrona.