|
Перенос данных из таблицы на другой сервер
|
|||
---|---|---|---|
#18+
Проблема следующая. Есть сервер Postgres, на котором остаётся всё меньше и меньше места из-за интенсивного добавления новых данных. Нужно высвобождать место при этом сохраняя данные. Переносить например на другой сервер или как-то архивируя переносимые данные. Есть 2 таблицы с данными, данные которых можно переносить - на данный момент в них около 10млн записей в каждой. Они постоянно пополняются - но любая строка в таких таблицах - это готовые к переносу данные. База данных критична к простою - т.е. прстой сервера невозможен или может быть очень кратковременным. Собственно отюда вопрос - какие есть способы переноса данных - раз и второй (наверное даже более важный) - нужно уменьшать размер БД, после того как данные будут улетать с этого сервера? Приветствуются все возможные способы. ... |
|||
:
Нравится:
Не нравится:
|
|||
16.06.2021, 09:37 |
|
Перенос данных из таблицы на другой сервер
|
|||
---|---|---|---|
#18+
balykovdron, 1. Подключить через FDW внешний архивный сервер. 2. Настроить еженочный\ежечасный перенос данных по условию delete from ... where ... returning * + insert into ... 3. Запускать pg_repack \ pgcompacttable 4. profit p.s при выполнении шагов 2-3 следить за объемом WAL , чтобы не исчерпать всё оставшееся место ... |
|||
:
Нравится:
Не нравится:
|
|||
16.06.2021, 09:53 |
|
Перенос данных из таблицы на другой сервер
|
|||
---|---|---|---|
#18+
gav21 balykovdron, 1. Подключить через FDW внешний архивный сервер. 2. Настроить еженочный\ежечасный перенос данных по условию delete from ... where ... returning * + insert into ... 3. Запускать pg_repack \ pgcompacttable 4. profit p.s при выполнении шагов 2-3 следить за объемом WAL , чтобы не исчерпать всё оставшееся место Да все 100% разумно написано... если версия слишком старая для fdw то тоже самое можно через dblink сделать но сильно менее удобно будет конечно. Начальную архивацию тоже делать по кусочкам разумного размера а не пытаться полтаблицы одним запросов в архив перекинуть. PS: 10 миллионов строк вроде как совсем небольшой размер занимать должны... вы уверены что проблема именно в этой таблице... вряд ли она больше чем 10-40GB занимает в самом плохом случае. -- Maxim Boguk лучшая поддержка PostgreSQL: dataegret.ru ... |
|||
:
Нравится:
Не нравится:
|
|||
16.06.2021, 10:23 |
|
Перенос данных из таблицы на другой сервер
|
|||
---|---|---|---|
#18+
Maxim Boguk если версия слишком старая для fdw то тоже самое можно через dblink сделать но сильно менее удобно будет конечно. Начальную архивацию тоже делать по кусочкам разумного размера а не пытаться полтаблицы одним запросов в архив перекинуть. PS: 10 миллионов строк вроде как совсем небольшой размер занимать должны... вы уверены что проблема именно в этой таблице... вряд ли она больше чем 10-40GB занимает в самом плохом случае. -- Maxim Boguk лучшая поддержка PostgreSQL: dataegret.ru Версия исходного сервера 9.6. По размерам возможно вы правы. На самом деле основное место съедено другими табличками с "грязными" исходными данными. У нас была идея почистить их таким способом: организовать "чистые" таблички (как раз те, что я описал выше) и перелить туда только те данные, которые нужны, при этом удалив соответствующие записи из "грязных" таблиц. И затем уже "чистые данные" безболезненно любым способом убирать на другой сервер. Сейчас глядя на ваше предложение - мне кажется, что "чистые" таблицы не особо то и нужны - выигрыша от них не много, а перенести старые данные из "грязных" таблиц и освободить место можно и через описанное выше предложение с шагами 1,2,3. Я не DBA и поэтому у меня только ряд вопросов. > 1. Подключить через FDW внешний архивный сервер. Не упадет ли исходный сервер, если подключенный сторонний постгрес будет недоступен? Как безопасно настроить пункт 2 - с транзакционностью, чтобы либо все перенеслось и удалилось, либо при ошибках не удалялось из исходных таблиц ? > 3. Запускать pg_repack \ pgcompacttable Если данный подход применять сразу к исходным таблицам с "грязными данными", то не будет ли длительной блокировки этих таблиц при выполнении указанных утилит? ... |
|||
:
Нравится:
Не нравится:
|
|||
16.06.2021, 10:47 |
|
Перенос данных из таблицы на другой сервер
|
|||
---|---|---|---|
#18+
gav21, Кстати напишите мне на mb@dataegret.com может найдется общая точка интересов. -- Maxim Boguk лучшая поддержка PostgreSQL: dataegret.ru ... |
|||
:
Нравится:
Не нравится:
|
|||
16.06.2021, 10:51 |
|
Перенос данных из таблицы на другой сервер
|
|||
---|---|---|---|
#18+
balykovdron > 1. Подключить через FDW внешний архивный сервер. Не упадет ли исходный сервер, если подключенный сторонний постгрес будет недоступен? Как безопасно настроить пункт 2 - с транзакционностью, чтобы либо все перенеслось и удалилось, либо при ошибках не удалялось из исходных таблиц ? > 3. Запускать pg_repack \ pgcompacttable Если данный подход применять сразу к исходным таблицам с "грязными данными", то не будет ли длительной блокировки этих таблиц при выполнении указанных утилит? Не упадет, будет просто ошибка о недоступности внешней таблицы. Если это произойдет во время выполнения транзакции, то как и любая другая транзакция - произойдет откат в исходное состояние. Эти инструменты как раз для выполнения конкурентных операций сжатия без наложения длительных(тяжелых) блокировок. Но документацию к ним, конечно, стоит прочитать(регулировка интенсивности работы, обработка индексов и т.п.) ... |
|||
:
Нравится:
Не нравится:
|
|||
16.06.2021, 11:06 |
|
|
start [/forum/topic.php?fid=53&fpage=10&tid=1993974]: |
0ms |
get settings: |
8ms |
get forum list: |
11ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
41ms |
get topic data: |
10ms |
get forum data: |
3ms |
get page messages: |
41ms |
get tp. blocked users: |
1ms |
others: | 295ms |
total: | 416ms |
0 / 0 |