Предлагаю вам ознакомиться с расшифровкой доклада Андрея Сальникова за 2018 год «Практика обновления версий PostgreSQL» В большинстве своем системные администраторы и менеджеры баз данных чертовски боятся делать серьезные обновления версий баз данных (СУБД), особенно если эта база данных работает и имеет достаточно высокую нагрузку.
Основная причина этого – некоторый простой базы данных, который всегда подразумевается при планировании подобных работ. На практике такого рода обновление занимает достаточно много времени и зачастую администраторам с небольшим опытом подобных операций приходится откатываться к старой версии баз из-за достаточно тривиальных ошибок, которых можно было избежать на этапе подготовки.
В Data Egret мы накопили большой опыт проведения крупных обновлений PostgreSQL в проектах, где нет права на ошибку.
Поделюсь своим опытом и расскажу о следующих шагах процесса: как правильно подготовиться к обновлению PostgreSQL? что необходимо сделать на этапе подготовки? как спланировать последовательность действий по самой модернизации? Как провести процедуру обновления успешно, не возвращаясь к предыдущей версии базы данных? как минимизировать или даже избежать простоя всей системы во время обновления? какие действия необходимо выполнить после успешного обновления PostgreSQL? Также я расскажу о двух самых популярных процедурах обновления PostgreSQL — pg_upgrade и pg_dump/pg_restore, о плюсах и минусах каждого метода и расскажу обо всех типичных проблемах на всех этапах этой процедуры и о том, как их избежать.
Доклад будет интересен как новичкам, так и тем администраторам баз данных, которые давно работают с PostgreSQL, но хотят узнать больше о том, как правильно спланировать и провести обновление максимально безболезненно.
Привет! Я работаю в Data Egret. Мы поддерживаем серверы PostgreSQL и предоставляем консультационные услуги по PostgreSQL. И практика показала, что базы данных мало кто обновляет. Запустили проект, установили актуальную на тот момент версию, которая работает до сих пор.
Доклад будет состоять из трех частей.
Первый – вводный, предназначенный для выработки общей терминологии.
Второе — о мелких обновлениях.
И третий будет о мажорах.
Цель доклада – ответить на вопросы.
- Почему вам нужно обновиться? Обновления необходимы, потому что Postgres не стоит на месте.
Они постоянно добавляют новые функции и исправляют некоторые ошибки.
И чтобы не скакать все время с одними и теми же проблемами, лучше обновиться.
И у вас все будет работать быстрее, и проблем будет меньше.
Это основная цель обновления.
- Расскажу, какие методы обновления существуют в процессе отчета.
- Я затрону темы, где у вас могут возникнуть проблемы с тем или иным методом, и расскажу, как их избежать.
- Очень важный вопрос, который волнует многих: «Можно ли обновиться без простоев и как их сделатьЭ» Давайте поговорим об этом.
- Если у вас нет опыта обновления, вы можете использовать этот отчет, чтобы попробовать его самостоятельно.
Можно сначала потренироваться на кошках, а потом обновлять производственную базу.
Немного вводной информации о том, как нумеруются версии, чтобы было общее понимание.
До 10 версии наша нумерация состоит из трёх цифр.
Первые две цифры, разделенные точкой, отвечают за основную версию, последняя цифра – за младшую версию.
Начиная с 10-й версии сообщество решило изменить стиль нумерации.
Теперь у нас есть два числа, разделенные точкой.
Первое число — это основной номер версии, последнее число — это дополнительный номер версии.
Какие типы обновлений могут быть? Незначительные обновления.
Здесь важно понимать, что минорные обновления — это обновления в рамках одной мажорной версии.
Если вы работаете с версией 9.6 и обновления между этими небольшими патчами очень важны, то будут и минорные обновления.
Это по последней цифре.
Они самые легкие.
В версии 10 начинается новый стиль нумерации.
Ничего не меняется, последняя цифра отвечает за минорную версию.
Основные обновления.
Здесь все довольно интересно.
В крупных обновлениях мы переключаемся между версиями и стремимся к новым функциям и возможностям базы данных, а также к разным вкусностям.
Здесь минорные версии базы данных уже не играют роли.
Во время крупного обновления мы постараемся обновиться до последней доступной версии выпуска.
Текущие версии на сегодняшний день — это те, которые получили исправления и незначительные обновления.
Их 6. Но один отмечен красным.
И отмечено оно по той причине, что сообщество больше не поддерживает эту версию.
То есть пропатчили в 9.2. Это был последний патч, больше не будет, про 9.2 можно забыть.
Если у вас установлена версия 9.2, значит пришло время обновиться.
Любая процедура обновления будет состоять из двух вещей: готовим и делаем обновление.
Есть общие рекомендации.
Перед любым обновлением, независимо от того, является ли оно минорной или основной версией, вам необходимо будет сделать следующее перед обновлением до рабочей версии:
- Очень важно прочитать примечания к выпуску полностью.
Что я имею в виду под этим? Обычно, если люди читают примечания к выпуску, они читают примечания к выпуску основной основной версии, потому что там много написано.
Там написано о вкусностях, которые там сделали разработчики.
А мелкие как-то упускаются.
А мелкие обновления несут в себе серьезные исправления ошибок, ведь мы все люди и разработчики тоже люди, и когда выкатывается новый релиз, он еще достаточно сырой и патчей очень много.
Например, мы пока не очень хотим устанавливать 10 клиентам, потому что ждем второй набор патчей.
Только после этого, скорее всего, мы займемся этим серьезно.
- Зачем вам нужно обновляться в тестовой среде? Причина проста.
Вам необходимо проверить, как ваша система будет работать с новой версией базы данных.
Если вы не читали примечания к выпуску, вас могут ожидать сюрпризы.
Например, приложение не будет работать с какой-либо конкретной функцией.
В целом Postgres обратно совместим и проблемы возникают редко, но случаются.
Поэтому запуск вашего приложения в тестовой среде всегда полезен не только с точки зрения обновления Postgres, но и для разработки.
- Если у вас возникнут какие-либо проблемы, то вам нужно будет подойти к разработчикам, написавшим приложение, и рассказать им, что и как нужно изменить, иначе в продакшене вас ждут сюрпризы.
- И то, что нужно всегда и везде и о чем мы не перестаем вам напоминать, это то, что резервное копирование нужно везде и всегда.
А настоящий бэкап — это когда ты встаешь из бэкапа, подключаешь свое приложение к базе и все у тебя работает, и проблем нет. Все данные совпадают и все в порядке.
Теперь перейдем к самим обновлениям.
И начнем от простого к более сложному по количеству действий и пониманию.
Небольшое обновление хорошо тем, что оно вносит исправления в код самой базы данных.
Мы не вносим никаких изменений в структуру данных, во внутреннее представление системного каталога Postgres. Есть исправления ошибок для самого движка Postgres. Как это произошло:
- Установите пакеты с новой версией PostgreSQL. Но здесь важно понимать, что если вы используете какие-то стандартные репозитории, то у вас, скорее всего, Postgres работает как сервис.
А установка пакетов перезапустит эту службу.
И вы создадите небольшую аварию с установкой базы данных и вашего приложения.
Поэтому сосредоточьтесь на этом и установите пакет, чтобы он не перезагружался.
Например, в Ubuntu имеется стандартный файл конфигурации для каждого создаваемого кластера.
Он называется start.conf. И там можно поправить режим перезапуска службы конкретного кластера.
Вы можете запретить службе автоматически перезапускать ее.
- Вам необходимо установить другие пакеты, связанные с PostgreSQL. Если мы обновляем только серверный пакет, то автоматически ни клиентская часть, ни общий пакет не будут обновляться по вашим подключениям, а пакет расширения тоже может не обновляться.
Будьте осторожны здесь.
- Следующий - КПП.
Зачем нам КПП? Когда у нас работает база данных, все изменения происходят в нашей памяти.
И когда мы начнем останавливать базу данных для перезапуска, база данных начнет активно сбрасывать на диск все, что накопила в памяти.
И это создаст для нас небольшой коллапс, потому что если у нас будет очень огромная оперативная память, скажем 250 ГБ, то мы не сможем моментально сбросить их на диск.
Поэтому нам нужно в первую очередь позаботиться об этом и запустить контрольную точку, которая сбросит все данные из памяти на диск и облегчит нам дальнейшую жизнь при перезапуске Postgres.
- Как избежать простоя? Если вы используете pgbouncer, то в этом случае он поможет приложениям прозрачно оставаться подключенными к базе данных, поскольку это прослойка между базой данных и приложением.
Приложение переходит в pgbouncer, а pgbouncer — в базу данных.
И мы можем указать pgbouncer приостановить работу приложения, а мы спокойно перезапустим базу данных с новой версией двоичного файла.
Для приложения это будет похоже на большую задержку при ответе на запросы.
То есть они зависнут на время перезапуска, потом мы возобновим работу pgbouncer, и приложение снова начнет работать.
Если вы сначала сделаете чекпоинт или паузу в pgbouncer, то перезапуск займет у вас, в зависимости от активности в базе, от секунды до полминуты.
- И перезапускаем базу данных, чтобы она работала с новыми бинарниками.
В настоящее время в данных наших файлов нет изменений.
Мы просто запускаем новые бинарники, которые работают с теми же данными.
- Некоторые исправления ошибок и обновления могут повлиять на расширения, если вы используете определенные расширения.
И поэтому я рекомендую вам потратить время на просмотр всех баз данных и обновить все расширения в каждой базе данных.
Это очень полезно.
Это будет особенно полезно для крупных обновлений.
Там это очень очевидная проблема.
У несовершеннолетних я такого еще не встречал.
Но я всегда их обновляю.
- А также мелкие обновления (возврат к тому, что очень важно читать примечания к выпуску) иногда требуют дополнительных процедур из примечаний к выпуску.
Каждый раз от минора к минору — это могут быть какие-то конкретные вещи.
Допустим, если вы обновляетесь с 9.6.1 до 9.6.6, которая актуальна на данный момент, вам необходимо прочитать примечания к выпуску для 9.6.2 – 9.6.6. А если у вас возникнут какие-то проблемы, то изолируйте оттуда то, что вам нужно будет делать после перезапуска базы данных с новыми бинарниками.
- Если вы работаете со резервными серверами, с потоковой репликацией, то лучше и правильнее обновлять реплики до обновления Мастера Сервера.
Недавно у нас была ситуация, когда у клиента был Мастер 14 минорной версии, а реплика была 2.3 и у нас была репликация.
Он начал миграцию схемы данных.
Синтаксисы были перестроены и в репликации произошла ошибка, она перестала работать.
Вращение в бесконечном цикле.
Эта конкретная вырезка взята с официального сайта Postgres.org. Релиз для версии 9.6.2. А тут черным по белому написано, что в этом релизе исправлено создание конкурентных индексов для всех желающих.
В чем была суть бага? Если вы ранее создали конкурентный индекс для поля, которое никогда раньше не имело индекса и не было включено ни в один другой индекс, то у вас может получиться неработающий индекс, и вы бы об этом не узнали.
Потому что в базе данных это выглядело бы валидно, но на самом деле в индексе были бы пропущенные значения или ссылки были бы на неправильные строки таблицы.
Что в итоге приводит к неожиданным результатам при выполнении запросов.
И таких интересных вещей в каждой минорной версии очень много.
Сообщество не просто выпускает минорные версии.
Будь осторожен.
Пожалуйста, прочтите примечания к выпуску.
Это очень важно.
А вот иллюстрация, которой не следуют пакеты зависимостей.
В данном случае я обновил версию сервера.
Как видите, у меня сервер 9.6.5. Но клиент по зависимостям не догнал 9.6.1. Это тоже не очень хорошо, поскольку обратная совместимость не гарантируется.
И могут быть некоторые проблемы с клиентом.
В минорной версии это маловероятно, но в мажорной версии это может быть более вероятно.
Поэтому мы обновили серверную часть — обновили другие пакеты.
И пример как пройти расширения.
То есть для каждой базы данных напишите bash-скрипт, который обращается к каждой базе данных и извлекает имя расширения.
И просто сгенерируйте расширение, обновите его и запустите для своего спокойствия.
Какие выводы можно сделать?
- Это легко сделать.
Мы просто устанавливаем новый пакет. Мы предпринимаем простые шаги для выполнения перезапуска базы данных, который является достаточно безопасным и прозрачным для приложения, чтобы оно никоим образом не участвовало и никоим образом не влияло на него.
- Каждое незначительное обновление содержит существенные исправления ошибок.
Да, возможно, сейчас у вас не такая ситуация, но в следующем миноре эта проблема может возникнуть, поэтому читайте примечания к выпуску.
- В качестве дополнительного эффекта исправления ошибок повышают производительность.
Допустим, при параллельном сканировании есть какой-то баг, добавляющий пару лишних цифр.
Ребята выкатили минорное обновление.
Удалены ненужные циклы.
И параллельное сканирование происходит быстрее.
- И минимальный простой системы, т.е.
ваша база данных недоступна сразу после перезагрузки.
Вы это остановили, если правильно сделали с чекпоинтом, то перезапуск базы занимает от миллисекунды до 30 секунд максимум.
Самая большая и интересная часть отчета — это основные обновления.
Существует несколько методов крупных обновлений.
Кто ему подходит, тот выбирает того.
Моя цель — рассказать о каждом из них.
- Pg_dump и восстановление — самые старые и лучшие методы.
Мы до сих пор иногда им пользуемся, потому что нет ничего надежнее него.
Но у него очень много недостатков для современного мира.
- Pg_upgrade — наша любимая утилита, которую мы используем, вероятно, в 95% случаев при выполнении крупных обновлений базы данных.
И мы проводим их точно еженедельно.
- А также обновления на основе репликации.
Как будет выглядеть процедура обновления при использовании pg_dump?
- Установите пакет с новой основной версией.
Здесь не стоит волноваться, потому что это разные пакеты.
Один пакет 9.5, например, другой пакет 10. В Ubuntu нужно быть осторожным, в ветке RedHat можно не волноваться — Постгрес не перезапустится.
Но помним, чтобы случайно не перезапустить текущую рабочую базу данных.
- Мы создаем пустой кластер в той же локали, в которой существует текущая работающая база данных.
- Пробежимся по конфигам Postgres, ведь если вы его используете, то, скорее всего, вы их подправили и некоторые параметры по умолчанию вам не нужны.
- А затем возникает то, что не устраивает большинство людей при обновлении базы данных с помощью pg_dumop. Нам нужно остановить модификацию данных в PostgreSQL. Почему нам нужно это делать? Если мы используем pg_dump для снятия дампа, то мы делаем снимок в тот момент, когда он стартовал, но база данных может продолжать записывать изменения в себя в этот момент. Нам не нужны изменения, потому что мы хотим перенести весь объём данных из старой базы данных в новую, чтобы они были актуальными и актуальными.
И сделать это можно только одним способом.
Остановив запись в PostgreSQL, т.е.
остановив приложение закрытием порта.
Есть много разных путей, выбирайте тот, который вам удобен.
- Время простоя начинается, когда прекращается модификация данных.
И это главный недостаток pg_dump, ведь после этого мы создаем дамп базы данных.
И здесь время совершенно прямо пропорционально размеру вашей базы данных.
Чем больше база данных, тем дольше вы будете ждать создания дампа.
- А потом еще и восстановление дампа на новую версию.
Но дамп гарантированно восстановит вашу базу данных до новой версии с некоторыми оговорками.
- И после того, как мы восстановили дамп на новой версии, запускаем приложение, чтобы оно писало в новую версию PostgreSQL.
Некоторые особенности pg_dump:
- Некоторые трудности с обновлением загруженных баз.
Есть только одна сложность — время простоя.
Большой и неприемлемый в современном мире.
- Останавливаем приложение.
Это тоже следствие простоя.
- Требуется дополнительное дисковое пространство.
Здесь есть варианты: два раза, три раза, а может и больше.
Все зависит от того, как вы возьмете дамп.
- Если вы снимаете промежуточный дамп на диск, то в утилите есть хорошая опция, позволяющая при снятии дампа сразу заархивировать его и положить запакованным на диск.
Это позволит вам сэкономить место.
- Вы также можете снимать это одновременно.
Если ваша дисковая система позволяет, то вы можете распараллелить удаление дампа.
И это позволит вам быстрее обрабатывать данные.
Но это касается SSD-систем, где используются хорошие SSD-накопители.
Но если вы хотите перенести дамп из старой базы в новую без промежуточного хранения на диске, то параллельно это, к сожалению, не получится.
И это тоже недостаток достаточно большого дампа.
- И это очень важно.
Перед обновлением мы всегда удаляем схему базы данных из старых версий и накатываем ее в новую версию.
И эта процедура позволяет нам поймать большую часть граблей, с которыми мы можем столкнуться.
Например, несовместимые версии расширений, отсутствующие типы.
А удаление только схемы восстановления, только схемы данных позволяет наловить все эти грабли до того, как реально запустить дамп с даунтаймом.
Это позволит избежать многих проблем.
Теперь перейдем к нашей любимой утилите pg_upgrade.
- Pg_upgrade гораздо сложнее с точки зрения подготовки к обновлению.
Но если вы будете с ним близки, т. е.
будете практиковаться, то вы его полюбите.
Предварительная подготовка затруднена.
- При определенных обстоятельствах вы можете испортить свою базу данных.
Я расскажу вам, как это происходит, и надеюсь, вы этого не сделаете.
- Это самый быстрый способ обновления PostgreSQL. И самый дешевый по ресурсам и человеко-часам, а это самый ценный ресурс в нашей жизни.
- После обновления могут возникнуть проблемы.
О них я расскажу чуть позже.
Немного информации о том, как работает pg_upgrade. На входе у нас должно быть две базы данных: старая, которая у нас есть с данными, и новый пустой кластер, который мы создали.
Соответственно, когда мы запускаем pg_upgrade и он начинает хорошо работать, в первую очередь он очищает в новом кластере информацию о счетчиках транзакций, потому что нам нужно перенести счетчик транзакций из старой базы данных в новую.
И когда мы начнем, мы начнем именно с того места, на котором остановились в старой версии базы данных.
Сюда переносится этот счетчик транзакций.
И последняя, самая масштабная, но самая веселая вещь — pg_upgrade делает дамп и восстановление схемы, он запускает pg_dump,restore с некоторыми флагами, чтобы восстановить в новую базу всю схему данных, которая была в старой базе, но не не передавать данные.
Это именно та схема.
А передача данных может осуществляться двумя способами.
Мы можем скопировать файлы с данными, а можем сделать жесткую ссылку на существующие данные, ведь наш блок данных не меняется с версии 8.4. В Postgres мы можем себе позволить такой трюк с ушами.
И когда мы делаем жесткую ссылку, в этот момент у вас есть две версии базы данных (например, 9.0 и 10), просматривающие одни и те же файлы данных.
А если вы запустите и то и другое одновременно, то ваша база данных превратится в тыкву, с которой вы потом ничего не будете делать.
Поэтому будьте очень осторожны со ссылкой.
Но мы всегда делаем это через ссылку, руки не трясутся.
Это именно та процедура подготовки, которую мы всегда делаем перед реальным обновлением производства.
То есть, прежде чем устраивать простой и коллапс, мы сначала проверяем, действительно ли мы можем это сделать.
- Устанавливаем новые пакеты для новой версии PostgreSQL.
- Создаем новую базу данных в правильном месте.
Это общие шаги.
- Давайте сделаем pg_upgrade. Запускаем клавишей «проверка».
Проверка делает почти все, что в реальности может сделать обновление.
И в то же время, если у вас какая-то несовместимость с типами данных, со схемой и все это вылезет, то оно будет ругаться, отваливаться, но при этом вы не повредили старую базу и не сделали никаких ошибок.
изменяется на пустой кластер.
И можно сразу прекратить процедуру обновления, плановые простои и общую суету.
И вернитесь к тесту, посмотрите, что с вами не так, и исправьте это.
- Pg_dumpall — только схема.
К сожалению, обновление с проверки не все показывает. И дополнительно проверяем себя через pg_dumpall — Schema-only, и выкатываем новую базу.
Недостаток этой процедуры в том, что вам придется заново создавать пустой кластер.
Но оно того стоит, ведь бывали ситуации, когда проверка не улавливала нашу проблему с обновлением, а дамп - ловил.
- Наряду с некоторыми расширениями существуют особые ситуации.
Особенно примечательным примером является PostGIS, поскольку PostGIS обновляется раньше, чем обновляется Postgres. Это расширение всегда следует обновлять перед обновлением Postgres, а затем обновлять сам Postgres. Вам нужно прочитать журнал изменений и узнать, можно ли обновить его просто так, используя pg_upgrade, потому что на старых версиях это сделать было невозможно.
Там надо было это делать через восстановление дампа.
Сама процедура обновления, если вы подготовились, довольно проста.
- Создаем базу данных в новой локали, если использовали только pg_dumpall, восстанавливаем.
- Остановка старой базы данных.
При этом не забываем, что pgbouncer поможет нам приостановить соединение с базой данных, т.е.
приложение не потеряет соединение, а просто зависнет.
- Не забываем про контрольные точки, которые помогают нам очищать память и сбрасывать ее на диск, чтобы быстро остановить базу данных.
- И следующий шаг — запуск обновления pg_upgrade. Процедура передачи счетчика транзакций, схемы данных и привязки происходит достаточно быстро.
Время обновления зависит от размера вашей базы данных, а именно от количества объектов в базе данных.
Может занять от минуты до 45 минут. У меня однажды был критический момент, когда обновление заняло 45 минут, но это уже другая история.
Чаще всего обновление занимает от минуты до 15 минут вне зависимости от размера базы.
Это зависит от количества объектов, созданных в базе данных.
- Если скопируем файл, будет зависимость от размера базы.
Мы делаем это через жесткие ссылки.
А создание ссылок в обычной ситуации занимает секунды.
- И мы запускаем новую версию PostgreSQL. Но мы пока не разрешаем приложению туда попадать.
Почему мы не разрешаем приложению перейти на новую версию PostgreSQL? Потому что статистики там нет. К сожалению, pg_upgrade теряет статистику при обновлении.
- И нам необходимо собрать эту статистику.
- И после этого разрешаем подключения к базе данных.
Наше время простоя, в зависимости от ситуации, колеблется от одной до 10 минут. А еще это зависит от опыта человека, который проводит этот даунтайм.
- По умолчанию pg_upgrade генерирует скрипт для сбора статистики.
Суть его в том, что по всем базам данных запускается вакуум в три этапа: одна цель, 10 целей и полный сбор статистики.
- Если ваша база данных небольшая или в ней мало объектов, то вы можете сразу запустить полный сбор статистики, игнорируя автогенерируемый скрипт.
- Начиная с версии 9.5 этот скрипт можно немного редактировать.
В зависимости от того, сколько у вас ядер и насколько позволяют ваши диски, вы можете распараллелить сбор в статистику.
- Обычно мы используем стандартный сценарий.
И делаем это следующим образом.
Без статистики наш планировщик сойдет с ума; он не будет знать, как правильно строить планы.
Поэтому ждем, пока вакуумдб соберет статистику по 1, 10 целям.
И когда оно начнет собирать полную статистику, мы разрешаем приложению подключиться к базе данных.
Работа с базой данных теперь более-менее адекватна.
Планировщик более-менее адекватный.
Хотя могут быть странности, но это не так страшно, как ждать полного сбора статистики.
- Но здесь есть один фактор.
Если приложение активно начнет менять записи в базе данных, то произойдет блокировка.
В какой-то момент у вас будет автовакуум.
И будет блокировка между вакуумом, который мы запустили после обновления, и автовакуумом.
В это время нужно сидеть и следить за блокировками, прибивая автовакуум, чтобы он не мешал полному сбору статистики после обновления.
Кратко о процедуре обновления на слайде.
- Pg_upgrade не обновляет расширения.
Это тот же недостаток, что и отсутствие статистики.
- Не забудьте прочитать примечания к выпуску расширений.
- После обновления вам придется просмотреть все расширения, обновить их вручную и сказать: «Изменить расширение EXTENSION_NAME, обновить».
Это необходимо.
Если вы используете pg_stat_statements, то в какой-то версии поменяли количество столбцов.
Если вы обновились через pg_upgrade, вы не увидите новых столбцов со статистикой из pg_stat_statements. То же самое касается и других расширений.
Вам обязательно нужно пройти через все.
Очень часто задаваемый вопрос – как обновить реплики? Это делается просто:
- Сначала мы обновляем главный сервер, используя некоторую процедуру.
- Дальше мы видим, что у нас все хорошо, приложение работает с мастером, мы нигде не накосячили, все довольны, все работает. И тогда реплика нам не нужна.
Потому что если мы облажаемся, нам будет куда откатиться и раскрутить старую реплику старой версии.
- Как мы это проверим? Мы просто просматриваем журнал Postgres. И мы ищем ошибки и нештатные ситуации.
Это занимает разное количество времени.
Иногда смотрим день, иногда смотрим 10 минут.
- После этого устанавливаем новую версию PostgreSQL на сервера с репликами.
- И pg_basebackup копируем базу данных с обновленного мастера на реплику.
Старая версия реплики нам не нужна.
- Запускаем реплику на новой версии PostgreSQL.
- А если у вас нет опыта, то мы не рекомендуем вам использовать rsync, поскольку это сложный и трудоемкий процесс.
Обновиться таким способом можно, но скорее всего вы допустите ошибку и ваша реплика превратится в бесполезный набор файлов.
Поэтому добирайтесь до rsync только тогда, когда наберетесь опыта.
Нам это не очень нравится.
Есть несколько причин:
- Во-первых, потоковая репликация не работает между разными версиями PostgreSQL.
- Работают только логические типы репликации.
Их существует несколько видов.
Он развивается с каждой версией.
И я думаю, что с ее помощью с 10 версии на 11 можно довольно легко мигрировать.
Также существуют сторонние репликации, появившиеся ранее.
Это Slony-l, Londiste, Bucardo и т. д. Их можно использовать.
Теги: #Системное администрирование #Администрирование сервера #Администрирование баз данных #postgresql #sql #postgesql
-
Элея Школа
19 Oct, 24 -
Невероятные Наркосубы Из Колумбии
19 Oct, 24 -
Глубокое Обучение Теперь На Java
19 Oct, 24 -
Усталый
19 Oct, 24 -
Google Не Будет Платить Только За Клики
19 Oct, 24
