Работа PostgreSQL на EC2/EBS

Здесь есть некоторая связанная информация. Основной вывод - это сообщение от Bryan Murphy:

Работаю с очень загруженной базой данных OLTP postgres объемом 170+ гб на Amazon уже 1 год. уже 1,5 года. Я не могу сказать, что я "счастлив", но я заставил ее работать и все еще предпочитаю это, чем бежать в центр города в colo в 3 часа ночи, когда что-то что-то идет не так.

Есть две основные вещи, которых следует опасаться:

1) Физический ввод-вывод не очень хорош, поэтому в первой системе использовался RAID0.

Давайте проясним, физический ввод/вывод временами ужасен. :)

Если у вас большая база данных, то тома EBS станут настоящим узким местом. Нашей основной базе данных требуется 8 томов EBS в RAID-массиве. и мы используем slony для разгрузки запросов на две ведомые машины, и она все равно не справляется.

Мы никак не можем запустить эту базу данных на одном томе EBS.

Я также рекомендую вам использовать RAID10, а не RAID0. Тома EBS не работают. Более чаще одиночные тома будут испытывать очень длительные периоды низкой производительности. Чем больше дисков у вас в рейде, тем больше вы сгладить ситуацию. Тем не менее, бывали случаи, когда нам приходилось менять плохо работающий том на новый и перестраивать RAID-массив. RAID, чтобы вернуть все на свои места. Вы не можете сделать это с массивом RAID0 массивом.

2) Надежность EBS ужасна по стандартам баз данных; я уже комментировал это немного на http://archives.postgresql.org/pgsql-general/2009-06/msg00762.php The end результатом является то, что вы должны быть внимательны к тому, как вы создаете резервные копии ваших данных, с рекомендуется непрерывное потоковое резервное копирование с помощью WAL-доставки. Я бы не стал внедрять эту среду в ситуации, когда потеряна минуту или две транзакций в случае сбоя EC2/EBS была бы неприемлемой, потому что вероятность того, что это произойдет, несколько выше. чем на большинстве аппаратных средств баз данных.

Согласен. У нас есть три запасных WAL-хранилища. Один транслирует наши WAL файлы на один том EBS, который мы используем для моментальных снимков в худшем случае. резервного копирования. Два других являются точными копиями нашей основной базы данных. (одна в центре обработки данных на западном побережье, а другая в центре обработки данных на восточном побережье). центр обработки данных), которые мы используем для резервного копирования.

Если в худшем случае нам придется восстанавливаться из одного из наших EBS мы будем работать шесть часов, потому что нам придется передавать потоком данные с нашего снимка EBS обратно на рейд-массив EBS. 170гб при 20мб/сек (если вам повезет) займет очень много времени. Это занимает от 30 до 60 минут, чтобы один из этих снимков стал "пригодным для использования" после того, как мы создадим из него диск из него, а затем нам все еще нужно поднять базу данных и ждать мучительно долго, пока горячие данные вернутся в память.

За последние 1,5 года нам пришлось дважды переходить на один из резервных дисков. Невесело. Оба раза из-за отказа экземпляра.

Можно запустить большую базу данных на EC2, но для этого требуется много работы, тщательное планирование и толстая кожа. работы, тщательного планирования и толстой кожи.

Bryan