Redis: setting ‘maxclients’ on the fly

OK, this is long question. I'll try to answering some part of above question. And maybe draw a summary based on them.

Disclaimer: I haven't used plesk, but I have used postfix. This question age was more than one year, so maybe the plesk has update their config for postfix. But I think this question would be useful for someone who design and implement postfix restriction

Q1: Are these two configs equivalent?

smtpd_sender_restrictions =
    check_sender_access hash:/var/spool/postfix/plesk/blacklists
    permit_sasl_authenticated
    check_client_access pcre:/var/spool/postfix/plesk/non_auth.re

smtpd_client_restrictions =
    permit_mynetworks

smtpd_recipient_restrictions =
    permit_mynetworks
    check_client_access pcre:/var/spool/postfix/plesk/no_relay.re
    permit_sasl_authenticated
    reject_unauth_destination

AND

smtpd_sender_restrictions =

smtpd_client_restrictions =

smtpd_recipient_restrictions =
    permit_mynetworks
    check_sender_access hash:/var/spool/postfix/plesk/blacklists
    permit_sasl_authenticated
    check_client_access pcre:/var/spool/postfix/plesk/non_auth.re
    permit_mynetworks
    check_client_access pcre:/var/spool/postfix/plesk/no_relay.re
    permit_sasl_authenticated
    reject_unauth_destination

If an email comes from mynetworks, then it won't be checked by /var/spool/postfix/plesk/no_relay.re and /var/spool/postfix/plesk/no_relay.re. It means that email will be accepted and not changed. In terms of postfix action (REJECT, ACCEPT), it won't different, but for plesk maybe these two headers is important.

Q2: Does Postfix perform the check again when it's listed multiple times? Or does Postfix know it already did that check? If the checks are performed multiple times, that seems like a waste. If they are not performed multiple times, do the no_auh/no_relay headers actually get added properly in all cases?

Yeah, it's maybe looks like wasteful when two checks repeated. But this repeated checks will be placed in different places/restrictions. And in every checks, there are some logic or algorithm how postfix treated an email. You may concern of repeated check if the check was heavy one such as check_policy_service or DNSBL. For lightweight check like permit_mynetwork, you may ignore it.

Q3: Is it safe to use just smtpd_recipient_restrictions and smtpd_relay_restrictions and ignore the client, helo, sender?

Well, with two smtpd_recipient_restrictions and smtpd_relay_restrictions should be enough for some advanced restriction. But it's for postfix >= 2.10. For user with postfix < 2.10, you can places checks in multiple directive so postfix won't become too permissive.

Q4: Would my proposed configuration accomplish want I want?

Yep, good job for simplifying your current postfix restriction. But beware that postfix was part of plesk. The engineer of plesk may arrange those restriction for some reasons such as modularity or simple maintenance.

Summary:

• Placing all restriction in on of smtpd_*_restriction isn't recommended.
• For this reason, you can use smtpd_relay_restriction for postfix >= 2.10 or other restriction check for postfix < 2.10

You can deploy as many masters as you want, with any number of slaves each, but they will behave like a single separated cluster with their own memory space, and it will be your responsibility at the application layer to spread your keys properly using each of the masters, just as you would do in a Memcached multi-node deployment.

Also, if you have no Redis Sentinel watching your data nodes, your application will have to take care of the failover process in a per-master basis to promote one of the slaves as master and redirect other slaves to use the new master.

Anyway, a single slave is enough for most use cases, unless you intend to use all of the slaves as read replicas for improved read throughput.

And about Redis-Cluster, well... IMHO, Redis Cluster introduces some penalties (No multi-key operations. no pipelining...) that have a big impact in the typical Redis use case, so you should evaluate it carefully before implementing it.