Я использую Debian 6 (Squeeze) в производстве для нескольких веб-сайтов. Я решил использовать postgresql backports, чтобы иметь возможность использовать функции PostgreSQL 9.0. Я думал, что он останется 9.0 и будет получать обновления до этой основной версии.
К сожалению, бэкпорты Squueze были обновлены до PostgreSQL 9.1, поэтому, вероятно, я не получу обновлений до 9.0.
Я планирую обновиться до версии 9.1, но знаю, что это не произойдет автоматически.
Я читал об официальном pg_upgrade и pg_upgradecluster от Debian, но был бы признателен за полное руководство по обновлению.
- Какие шаги нужно сделать (сначала apt-get install postgresql, затем pg_upgradecluster, затем удалить старый кластер)? Список шагов был бы хорош.
- Каковы возможные сценарии отказа?
- Как подготовиться к неудачам и реагировать на них?
Я могу остановить базу данных только на пару часов, поэтому хочу быть готовым
решение1
Довольно сложно дать вам пошаговый процесс обновления, который подходит под вашу ситуацию/среду.
Я попытался охватить некоторые из основных моментов ниже, но вам действительно нужно адаптировать процесс к вашей среде.
Шаг ноль: решите, нужно ли вам обновление. Postgres 9.1 предлагает синхронную репликацию и кучу других интересных вещей, которые полезны, если они вам нужны, но не являются причиной для немедленного обновления, если они вам не нужны.
Шаг 1, ожидайте, что это займет много времени, если ваша база данных большая.
Даже использование pg_upgradeпростого процесса копирования данных для резервного копирования может занять некоторое время: наши 16 ГБ базы данных занимают час или больше для pg_dump/pg_restore или около 10-20 минут для pg_upgrade).
Шаг 2. Предлагаю прочитать9.1 Примечания к выпуску. Убедитесь, что все, что вам нужно, не сломалось и ничего из того, что вы используете, не изменилось.
Нет ничего лучше, чем обновление базы данных, которое разрушает ваши производственные системы, чтобы действительно испортить вам месяц.
Шаг 3,Раздел обновления руководства Postgresобязательна к прочтению.
Шаг 4 (вставьте сюда любые специфичные для Debian вещи, но это не моя тема :-)
Шаг 5. Создайте план обновления.
Шаг 6. Тестирование плана обновления (технически необязательно, носильнорекомендуемые).
Шаг 7. Выполните обновление ваших производственных систем.
Применяются стандартные оговорки:
- Обновление может уничтожить вашу базу данных. Сделайте резервную копию.
- Убедитесь, что вы сможете его восстановить.
- Убедитесь, что вы можете восстановитьдвоичные файлыдля системы баз данных тоже.
(Если можете, сохраните свои старые пакеты Debian — я видел людей, которые не могли отменить неудачное обновление, потому что у них больше не было старых двоичных файлов базы данных, и это действительно очень печальное зрелище.)
Это займет больше времени, чем вы ожидаете. Планируйте это.
Политика обновления БД в моей компании: «Начать в 6 вечера в пятницу. Если не заработает к 9 утра в воскресенье, откатить».Смонтируйте scratch monkey
Если ваши данные действительно важны, восстановите их копию в другом месте и протестируйте свой путь обновления.
Да, я делаю это с базами данных на 16 ГБ. Я все равно сделаю это с базами данных на 160 ГБ, если смогу найти способ заставить это работать :-)
решение2
Это шаг 4 в основном - плюс --checkвозможность убедиться, что ваши пути верны. Моя установка из репозиториев и имеет стандартные пути Debian для файлов.
[email protected]:~$ /usr/lib/postgresql/9.1/bin/pg_upgrade --old-datadir /var/lib/postgresql/9.0/main --new-datadir /var/lib/postgresql/9.1/main --old-bindir /usr/lib/postgresql/9.0/bin/ --new-bindir /usr/lib/postgresql/9.1/bin/ --check
Это не помогло - постоянно говорилось, что оба сервера работают на одном и том же порту.
Похоже, сработало следующее:
pg_dumpall -p 5432 | psql -d postgres -p 6543