|
pg_dump таблицы с одного сервера на другой
|
|||
---|---|---|---|
#18+
Есть два сервера. Нужно скопировать очень большую таблицу (~800ГБ) на другой сервер, но в таблицу с другим именем, так как с таким именем уже таблица существует и такая конструкция не работает pg_dump -t "table_name" -h SERVER1 -U USER DB | psql -h SERVER2 -U USER DB можно ли это как-то сделать? переименовывать на время копирования таблицы другую таблицу не хочется Заранее благодарен ... |
|||
:
Нравится:
Не нравится:
|
|||
06.07.2018, 12:03 |
|
pg_dump таблицы с одного сервера на другой
|
|||
---|---|---|---|
#18+
mumuskul, перенесите структуру вручную. Затем уже данные COPY запросом, на источнике to stdout, на приёмнике from stdin. pg_dump данные тоже через copy тягает, потому никакой разницы. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.07.2018, 12:55 |
|
pg_dump таблицы с одного сервера на другой
|
|||
---|---|---|---|
#18+
Спасибо, то что надо! ... |
|||
:
Нравится:
Не нравится:
|
|||
06.07.2018, 15:52 |
|
pg_dump таблицы с одного сервера на другой
|
|||
---|---|---|---|
#18+
А в архивном (-F c) формате pg_dump|pg_restore работает быстрее чем COPY? ... |
|||
:
Нравится:
Не нравится:
|
|||
07.07.2018, 17:08 |
|
pg_dump таблицы с одного сервера на другой
|
|||
---|---|---|---|
#18+
Бумбараш, Зависит от того, во что вы упираетесь. custom формат дефотно сжимается. Поэтому будет быстрее если упёрлись в сеть и медленнее - если в CPU. На уровне чтения-записи в саму базу - это всё так же copy. ... |
|||
:
Нравится:
Не нравится:
|
|||
07.07.2018, 18:39 |
|
pg_dump таблицы с одного сервера на другой
|
|||
---|---|---|---|
#18+
MelkijБумбараш, Зависит от того, во что вы упираетесь. custom формат дефотно сжимается. Поэтому будет быстрее если упёрлись в сеть и медленнее - если в CPU. На уровне чтения-записи в саму базу - это всё так же copy. Hm справедливости ради - с сжатием все будет непросто потому что: host1:db1 -> не сжатый поток данных -> pg_dump + сжатие | pg_restore + разжатие -> не сжатый поток данных -> host2:db2 в итоге как (и где) не пускай в таком виде по сети будет идти несжатый поток данных (сжатый только через | будет передаваться). Если надо по сети сжатое передавать - это будет несколько сложнее но реально сделать конечно через ssh. Но ssh и сам сжимать налету умеет. В общем для переноса данных 1 таблицы скорее всего pg_dump -Fc будет медленнее чем copy | copy или тоже самое через ssh с сжатием на удаленный хост. Maxim Boguk лучшая поддержка PostgreSQL: dataegret.ru ... |
|||
:
Нравится:
Не нравится:
|
|||
09.07.2018, 12:05 |
|
pg_dump таблицы с одного сервера на другой
|
|||
---|---|---|---|
#18+
Maxim Boguk, мм, логично. Я что-то автоматически подумал про ssh ... 'pg_dump -Fc ...' | pg_restore или около того. Верно, pg_dump -Fc -h ... | pg_restore ... - будет сжимать и распаковывать данные на одном и том же хосте, просто потребляя CPU и замедляя процесс. А по сети при этом пойдут всё так же несжатые данные обычного copy запроса. ... |
|||
:
Нравится:
Не нравится:
|
|||
09.07.2018, 13:32 |
|
pg_dump таблицы с одного сервера на другой
|
|||
---|---|---|---|
#18+
Но у pg_restore для архивного формата есть опция с параллелями --jobs=number-of-jobs Вроде как файл оно должно быстрее закачивать? Работает ли это на одной таблице? Естественно, тут уже без конвейра будет |. ... |
|||
:
Нравится:
Не нравится:
|
|||
09.07.2018, 15:49 |
|
pg_dump таблицы с одного сервера на другой
|
|||
---|---|---|---|
#18+
БумбарашНо у pg_restore для архивного формата есть опция с параллелями --jobs=number-of-jobs Вроде как файл оно должно быстрее закачивать? Работает ли это на одной таблице? Естественно, тут уже без конвейра будет |. Нет --jobs (что для pg_dump что для pg_restore) только между таблицами параллелит, одна таблица всегда dump и restore в один поток. -- Maxim Boguk лучшая поддержка PostgreSQL: dataegret.ru ... |
|||
:
Нравится:
Не нравится:
|
|||
09.07.2018, 17:38 |
|
|
start [/forum/moderation_log.php?user_name=Goodyear]: |
0ms |
get settings: |
10ms |
get forum list: |
16ms |
get settings: |
8ms |
get forum list: |
15ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
39ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
41ms |
get tp. blocked users: |
2ms |
others: | 711ms |
total: | 859ms |
0 / 0 |