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