1. Возможность потери данных (гибель реплики в пути). Все ситуации, когда с точки зрения сервера А запись отправлена, с точки зрения Б - не доехала и уже не доедет.

2. Целостность данных; все ситуации, когда изменения, выполненные на сервере А в одной транзакции, на сервере Б выполняются в разных транзакциях.

3. Порядок выполнения изменений. Зависит от ТЗ, но в общем случае изменения на сервере Б должны выполняться в том же порядке, что и на сервере А.

4. Согласованность данных; все ситуации, когда на сервере Б в результате приема реплик образуется состояние данных, которого никогда не было на сервере А (например, таблица T1 соответствует состоянию на 18:00, а таблица T2 - состоянию на 18:10).

5. Изменения, [не] происходящие на Б при приеме реплик с А. На таблицах могут висеть триггера, срабатывание которых приведет к нежелательным последствиям.

6. Проверка и реакция на всевозможные ошибочные ситуации в пути (повреждение данных; исчезновение либо нарушение порядка следования файлов при файловом протоколе итд). Правильная в общем случае реакция - торможение обработки ошибочных и следующих за ними данных вплоть до исправления ситуации.

7. Проверка и реакция на всевозможные ошибочные ситуации при накате данных на целевой сервер (например - пришло обновление отсутствующей записи). Правильная логика поведения в таких ситуациях различна, но главное - они должны быть четко прописаны, однозначно определяться и обрабатываться.

8. Логика обработки неожиданных ошибок (начиная от "закончилось место на диске" и до "данные, успешно введенные на А, не принимаются на Б из-за ограничения целостности").

9. Возможность конфликтов (конфликтующих изменений); средства их обнаружения и разрешения.

Список наверняка неполный, но что вспомнилось сходу.

Да, еще вспомнилось:

10. Поведение при накате патчей (возможность того, что данные, посланные из старой версии, приезжают на новую либо наоборот).

11. Влияние репликации на работу БД (глобальные блокировки и прочие неприятности).