Re: Strategy for moving a large DB to another machine with least possible down-time
Вложения
В списке pgsql-general по дате отправления:
| От | Andreas Joseph Krogh |
|---|---|
| Тема | Re: Strategy for moving a large DB to another machine with least possible down-time |
| Дата | |
| Msg-id | VisenaEmail.6f.9316bc28db203d21.1489879daba@tc7-visena обсуждение исходный текст |
| Ответ на | Re: Strategy for moving a large DB to another machine with least possible down-time (Adrian Klaver <adrian.klaver@aklaver.com>) |
| Ответы |
Re: Strategy for moving a large DB to another machine with
least possible down-time
|
| Список | pgsql-general |
On 09/21/2014 05:44 AM, Andreas Joseph Krogh wrote:
> På søndag 21. september 2014 kl. 13:51:00, skrev Bill Moran
> <wmoran@potentialtech.com <mailto:wmoran@potentialtech.com>>:
>
>
> I see this limitation in Slyny:
> http://slony.info/documentation/2.2/limitations.html
>
> Slony-I does not automatically replicate
>
> *
>
> Changes to large objects (BLOBS)
>
> *
>
> Changes made by DDL commands
>
> *
>
> Changes to users and roles
>
> Not being able to replicate BLOBS is a show-stopper for me as we have
> lots of them.
Well I would say it depends on where you are storing the binary data, in
large objects or in a bytea column? If you are using bytea columns then
you would be okay. If it is large objects then you have a problem.
В списке pgsql-general по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера
