Stanislav Sinyagin wrote:
> --- Cami Sardinha <[EMAIL PROTECTED]> wrote:
>> And what happens when someone requests a 3rd, 4th and 5th MySQL
>> backup option?
>
> nobody would need that :)
> The approach that I suggested would work perfectly for 1+1 redundancy.
> If someone wants a bigger redundancy solution, it would anyway require some
> customization of the code (if not a complete redesign).
>
> I understand that Mysql dual-master setup is not a rocket science - I'll
> most probably go that way myself. But the way I suggested would minimize the
> administrative burden and synchronization efforts. In theory, that could
> even lead to a self-healing redundant solution... but then it really needs
> a redesign and refactoring, so that the storage level is separated from
> the operation logic.
It is not Policyd's job to perform such work. Dual writes increases
latency for each Postfix -> Policyd transaction, introduces another
single point of failure and makes Policyd less robust (especially
when troubleshooting weird problems).
The approach that should be taken is:
1) Set up master -> slave replication
2) Change policyd so that all READS happen from the slave(s)
and WRITES only go to the master.
Such a solution not only makes your environment cleaner and
problems easier to diagnose, but it makes Policyd more robust.
Cami
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
policyd-users mailing list
policyd-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/policyd-users
