Дата создания БД или уникальный идентификатор

Есть много баз данных, все связываются с центральной, чтоб не запутаться в них даже в случае восстановления из бекапов

Я, скорее всего, вопрос не понял, но попробуй это

select oid, * from pg_database

rovan,

когда у клиента разворачиваешь базу с нуля, у почти всех oid будет 16385 +- 1

хотелось бы уникальный идентификатор кластера, который создается случайно в момент установки(например время установки), тогда его можно было бы использовать в паре с OID базы данных.

У меня просто так получается, сделал бэкап бд у клиента, принес куда ни будь, развернул, а он возьми и подключись к центру...

svd85,

Во всей литературе по дизайну реляционной модели говориться "никогда не привязывайтесь к особенностям физической реализации СУБД". Если вам нужен идентификатор, то генерируйте и храните его самостоятельно.

svd85
хотелось бы уникальный идентификатор кластера, который создается случайно в момент установки(например время установки), тогда его можно было бы использовать в паре с OID базы данных. У меня просто так получается, сделал бэкап бд у клиента, принес куда ни будь, развернул, а он возьми и подключись к центру...

Можно использовать uuid

svd85
хотелось бы уникальный идентификатор кластера, который создается случайно в момент установки(например время установки), тогда его можно было бы использовать в паре с OID базы данных.

Что и в какой момент должен идентифицировать ваш идентификатор?

svd85
У меня просто так получается, сделал бэкап бд у клиента, принес куда ни будь, развернул, а он возьми и подключись к центру...

Я правильно понимаю, что развернутая из бэкапа база должна получить отличный от оригинала идентификатор?

Ы

svd85 хотелось бы уникальный идентификатор кластера, который создается случайно в момент установки(например время установки), тогда его можно было бы использовать в паре с OID базы данных. Что и в какой момент должен идентифицировать ваш идентификатор? svd85 У меня просто так получается, сделал бэкап бд у клиента, принес куда ни будь, развернул, а он возьми и подключись к центру... Я правильно понимаю, что развернутая из бэкапа база должна получить отличный от оригинала идентификатор?

наверное в бекапе должна лежать непроинициализированнная БД -- тогда концы сойдутся -- развернутая из бекапа БД, к которой было совершено [инициализирующее] обращение -- далее по тексту.

гарантий тут не будет никаких, но гарантия сверхмалой вероятности может дать генерация гуид при первом обращении инициирующей процедурки.
(есть вроде набор утилит в виде http://www.postgresql.org/docs/9.4/static/uuid-ossp.html )

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


а чтобы не подключаться куда не надо, если такой забывачивый, -- надо все обращения завернуть в WHERE client_inet_addr() blahblahblah UND server_inet_addr() blahblahblah , ну и усложнить жизнь жесткими ограничениями listen_addresses [postgres.conf]и hosts in pg_hba.conf

но дешевле -- не забывать

Ы
Что и в какой момент должен идентифицировать ваш идентификатор?

идентифицировать надо конкретный экземпляр базы данных, чтобы центр мог определить случайные и посторонние копии

Ы
Я правильно понимаю, что развернутая из бэкапа база должна получить отличный от оригинала идентификатор?

правильно

лопата

наверное в бекапе должна лежать непроинициализированнная БД -- тогда концы сойдутся -- развернутая из бекапа БД, к которой было совершено [инициализирующее] обращение -- далее по тексту. гарантий тут не будет никаких, но гарантия сверхмалой вероятности может дать генерация гуид при первом обращении инициирующей процедурки. (есть вроде набор утилит в виде http://www.postgresql.org/docs/9.4/static/uuid-ossp.html ) вариант реализации -- любое обращение читает из некоторой таблички запись констант, а если ее (записи) нет -- создает с опорой на сгенерированный гуид (и вешает блокирующий триггер на все события записи и таблицы). работает, если в бекапе этой записи гарантированно не будет. если кто-то обратится к бд--шаблону по пользовательским интерфейсам -- то проинициализирует её -- и придётся чистить перед бекапированием "шаблона"

такой гуид есть, а ели его нет то при первом обращении создается, но и в бекап он тоже попадает, на этом как раз я и прокололся, и решил заморочится

лопата
а чтобы не подключаться куда не надо, если такой забывачивый, -- надо все обращения завернуть в WHERE client_inet_addr() blahblahblah UND server_inet_addr() blahblahblah , ну и усложнить жизнь жесткими ограничениями listen_addresses [postgres.conf]и hosts in pg_hba.conf

базы географически разнесены, ip динамические, к каждой базе подключаются несколько клиентов, без ограничений, любой клиент может подключатся к центру.

лопата
но дешевле -- не забывать

цена ошибки очень велика, минимум день реставрации БД

надеялся что есть что ни будь штатное