Ответ 1
Пара мыслей. Во-первых, мы избегаем SPOF для таких вещей, как PGPool, используя Heartbeat, Pacemaker и ElasticIP. Выполните два (или более) экземпляра, посвященных PGPool. Назначьте ElasticIP одному из них. Установите Heartbeat и кардиостимулятор для мониторинга PGPool. В случае отказа от работы, Pacemaker запускает script, который назначает ElasticIP новому хозяину (DC в условиях кардиостимулятора). Если вы используете только два узла, убедитесь, что вы отключили функцию кворума в Pacemaker, потому что вы не можете иметь кворум, если один из node выходит из общего числа двух узлов.
Чтобы воспользоваться преимуществами ElasticIP, выполните обратный поиск DNS на вашем ElasticIP вне Amazon. Это даст вам имя DNS, которое будет отображаться в ElasticIP, которое должно заканчиваться на amazonaws.com. Поиск DNS из экземпляра EC2 для имени домена, заканчивающегося на amazonaws.com, фактически разрешит внутренний IP-адрес для экземпляра, которому был назначен ElasticIP. Вы можете либо указать свои серверы приложений непосредственно в DNS для ElasticIP, либо, предположив, что вы используете свой собственный DNS, вы можете создать CNAME, который ссылается на ElasticIP DNS.
Тем не менее, есть один большой улов для использования ElasticIPs для перехода на другой ресурс. Повторное назначение ElasticIP занимает до 120 секунд, чтобы вступить в силу. Большую часть времени тратится на ожидание этого изменения для распространения через DNS-серверы Amazon.
Кроме того, хотя я не пытался запускать PGPool-ii на каждом сервере приложений, я не уверен, что это сработает. Если основная база данных терпит неудачу, я думаю, что каждый из экземпляров PGPool будет конкурировать за обработку отказа. Может быть, я просто недостаточно знаком с PGPool-ii, чтобы понять, как лучше справиться с этим.
Что касается человека, который упомянул plproxy, я думаю, что он путается с PGBouncer, который рекомендуется для использования с plproxy. plproxy - это система разбиения, а не балансировка нагрузки. Тем не менее, PGBouncer не является балансировщиком нагрузки - это система объединения соединений. PGBouncer не обеспечивает функциональность балансировки нагрузки. На самом деле в FAQ для PGBouncer явно рекомендуется использовать балансировщик нагрузки TCP, например HAProxy.
Кроме того, утверждения об Amazon, имеющие проблемы вертикальной масштабируемости, которые решаются Rackspace, неверны. С экземплярами Amazon EC2 вы всегда можете остановить экземпляр и обновить его до более крупного типа экземпляра. Ни Amazon, ни Rackspace не поддерживают изменение типов экземпляров на лету.