По очень старым воспоминаниям. Была совершенно аналогичная задача. Рабочее решение было такое - все поля синтетического ключа были сделаны заполняемыми не последовательно, а рандомно (так, как это делается при создании реплик БД). Собственно слизывали решение именно с репликации, которая не работала именно из-за бесконтрольного копирования - не любит она несинхронные копии реплик. В те стародавние времена GUID-поля ещё не прижились, и для снижения вероятности интерференции мы использовали программно генерируемую 64-байтную случайную строку в качестве уникального идентификатора, и CRC32 в качестве первичного ключа. Предполагалось, что в случае коллизии по первичному ключу будет несложно разрешить конфликт за счёт несовпадения уникального идентификатора, а т.к. вероятность коллизии оценивалась как крайне малая, то предполагалось развести всё вручную - но за всё время работы (лет 5 или 6, не помню) так ни разу и не пришлось этим заниматься.