On 8/21/2018 7:48 PM, Phil Stracchino wrote:
On 8/21/18 4:17 PM, deoren wrote:
Hi all,

We've been using Postfix for years with good results, but in recent
years have moved to a load-balanced HAProxy front-end with multiple
backend relay nodes. I've consulted various sources during that time to
perform the initial setup and light tuning since then.

The health checks are run often and simulate a full email delivery
session in an attempt to exercise the full configuration (including
alias resolution and other related db queries).

This setup works pretty well, but occasionally there is enough of a
delay between one of the steps in the simulated delivery that the health
check fails and the node is marked as down.

When this occurs I have been unable to determine exactly why the issue
occurs. I've adjusted various timeout and timing settings within HAProxy
and Postfix, so I assume that our mostly stock MariaDB 10.0.x
installation is likely to blame.

Do you have any recommendations for guides that cover tuning Postfix and
MySQL? I'd like to start there and work through the steps before turning
back to the configuration as a whole.

Another option I'm considering is replicating the database contents
(where applicable) in MySQL to local SQLite databases that are synced to
the relay nodes, cutting MySQL/MariaDB out of the picture entirely.

Our client node count is currently less than 100.

I wouldn't use SQLite.

May I ask why? Are there performance problems with using it? I've only ever used it for small jobs where I/O and simultaneous access concerns did not apply. Any feedback you have regarding the downsides or better alternatives are welcome.


There is no such thing to my knowledge as a tuning guide for MySQL
specifically to work with Postfix.  The same general MySQL tuning
practices apply to tuning for any load scenario.  You said "mostly
stock" MariaDB - have you done any database tuning *at all*?  (And for
that matter, what are you running it on?  Red Hat, for example, has
historically shipped default MySQL/MariaDB configuration files that are
at best worthless even when they're not actively harmful.)

All three nodes use Ubuntu 16.04 x64 and use stock Ubuntu-provided Postfix 3.1 packages. The database node uses MariaDB 10.0.x from the upstream MariaDB repo. I've done light configuration updates only based on material I read over at the time, but I still consider myself a newbie in regards to configuring MySQL/MariaDB. Any suggestions you have for updating the configuration are welcome.

The load-balancer node uses the HAProxy 1.7 PPA from Vincent Bernat (many thanks to Vincent for providing it). I'm unsure whether the checks being applied are too aggressive, or perhaps are incomplete, but the primary goal of the checks is to exercise the entire stack:

* alias resolution via db lookups
* sender/receiver actions based on lookup table results
* verify connectivity
* etc

These health checks are combined with Nagios mail queue threshold checks that alert us to any mail which is getting hung up on the relays or the sending nodes that we're responsible for.

I've uploaded the configuration files for our frontend (HAProxy), backend (Postfix) and database (MariaDB) roles to a GitHub repo here:

https://github.com/deoren/postfix-examples

Here is a direct link to the config file with comments:
https://github.com/deoren/postfix-examples/blob/master/database-server/mysql/my.cnf

and a direct link to the config file with minimal comments:

https://github.com/deoren/postfix-examples/blob/pruned-comments/database-server/mysql/my.cnf


The HAProxy config file is available here:
https://github.com/deoren/postfix-examples/blob/master/load-balancer/etc/haproxy/haproxy.cfg
https://github.com/deoren/postfix-examples/blob/pruned-comments/load-balancer/etc/haproxy/haproxy.cfg

and the Postfix config files are available here:

https://github.com/deoren/postfix-examples/tree/master/backend-relay/etc/postfix
https://github.com/deoren/postfix-examples/tree/pruned-comments/backend-relay/etc/postfix

Any feedback that you have is welcome!

Reply via email to