Варианты решения uniqid от лучшего к худшему:
1) Если 64bitный bigint то вообще проблем никаких: в старшие 32 бита засовываем заведомо уникальный идентификатор машины (например ip-адрес, или crc32/adler32 от hostname). а младшие 32 крутим как обычный сиквенс.
Достоинства: для любого идентификатора можно в случае «жесткого дебага» найти «откуда ноги растут» — т.е. однозначно идентифицировать тачку на которой возникла запись с исследуемым id.
2) Если есть желание убраться в 32bit (разумное желание, ведь не все хорошо работает даже в наш 64разрядный век с большими числами) лучше применять кешированый сиквенс. При запросе сиквенс увеличивается не на 1 а сразу на большое значение, например на 1000 или на 10000. Соотвественно, нода, получив от сиквенса диапазон 320000..329999 спокойно может не обращатся снова к сиквенсу, пока не израсходует этот диапазон. Плюсы: опять-таки возможно логировать. Минусы (правда устранимые резервным сиквенсом с резервным диапазоном): придется выбирать порцию отдачи.
3) Экстремальный вариант. Еще расширяем integer до 128 бит и используем хеши или что-нибудь uuid-подобное. Минус очевиден — 99.9% софта не сможет работать с таким значением как с числом.
4) Hardcode-вариант. Если вам известно, что нод будет не более чем N, каждая нода просто крутит сиквенс S а id получает по ф-ле id=S*N+n; где n-номер ноды. Плохой вариант, очень чреват нехорошими последствиями, если вдруг вы ошиблись в смелых оценках.
5) Метод проб и повторов. еще хуже, поскольку сработает если у вас записей мало и добавляются они редко и вообще надежно будет работать если источник добавления записей только один.