oro*_*aki 3 database django postgresql database-replication
我注意到Postgres现在具有内置复制功能,包括同步复制,流复制和其他一些变体.它甚至可以为应用程序级别的特定操作提供控制同步的能力(例如,对于诸如汇款等重要事项使用同步,但可能不会用于诸如用户评论之类的不太重要的事情等)
我正在使用Django 1.5(即dev)开发软件,并且可能需要同步复制(将继续进行与商业相关的事务).
您是否认为内置工具在大多数情况下最适合工作,您是否对内置复制的一种变体与另一种变体,易用性,质量等有任何想法？
最后一件事; Slony和PGPool II似乎非常流行(特别是Slony)用于复制.有没有A)特定的技术原因,因为它们比内置复制更受欢迎,或者B)是因为很多人使用的是没有内置复制的版本,或者C)我是否曾经在岩石下和PG内置复制已经非常流行？
我只有2台物理服务器,它们位于同一个机架中.我的目的是提供一个可以自动变成主机的从机,如果在一台机器上发生了某些特定的错误(或者甚至是像双电源故障那样简单的事情等).我不介意我的客户在自动故障转移期间遇到停机时间,只要停机时间是几分钟左右,而不是一小时或者其他什么.
我希望零数据丢失,并愿意在故障转移过程中牺牲更多时间.有没有办法在不进行同步复制的情况下进行这种交易(例如,没有回写确认的流式传输日志)？
您会推荐什么策略或复制变体？
我认为你误解了同步提交复制的好处和成本.在PostgreSQL中,复制的工作原理是使用PostgreSQL的标准崩溃恢复功能将从属服务器恢复到主服务器.例如,如果电源耗尽,您可以确保预写日志段将在主服务器和从服务器上运行.使用异步提交,将提交写入WAL,通知应用程序,并且根据网络特征等,或多或少地同时通知从属设备.
同步提交派上用场的地方有两件事:
使用同步提交,数据库会等待,直到它从可配置数量的从服务器回来,告诉应用程序提交已发生.这在异步提交无法工作的少数情况下提供了持久性保证.
例如,假设您的主服务器通过raid阵列获取子弹并立即崩溃(抱歉,我想不出任何有更好硬件的更好示例).或者假设某人使用电源线绊倒,不仅关闭了服务器电源,还破坏了软件RAID设备.在这种情况下,可能没有复制一些事务并且您的WAL无法恢复,因此这些事务将丢失.使用同步提交,应用程序将等待,直到满足耐久性保证.
这意味着,如果您只使用一个从站执行同步提交,则您的可用性不会超过主服务器或从服务器上的崩溃,因此您的可用性将比仅使用一台服务器时更糟糕.这也意味着如果您的slave在地理位置上被删除,那么您在应用程序提交事务的请求中会引入显着的延迟.
从异步切换到同步提交它并不是一个很大的改变,但一般来说,我认为当你已经完成了尽可能多的保证和硬件可用性时,你得到了最多的同步提交.当您无法将设置进一步优化为异步时,请从异步开始并向上移动.