Hi Eduardo, On Thu, May 23, 2019 at 10:09:55AM -0300, Eduardo Doria Lima wrote: > Hi Aleks, > > I don't understand what you means with "local host". But could be nice if > new process get data of old process.
That's exatly the principle. A peers section contains a number of peers, including the local one. Example, let's say you have 4 haproxy nodes, all of them will have the exact same section : peers my-cluster peer node1 10.0.0.1:1200 peer node2 10.0.0.2:1200 peer node3 10.0.0.3:1200 peer node4 10.0.0.4:1200 When you start haproxy it checks if there is a peer with the same name as the local machine, if so it considers it as the local peer and will try to synchronize the full tables with it. Normally what this means is that the old process connects to the new one to teach it everything. When your peers don't hold the same name, you can force it on the command line using -H to give the local peer name, e.g. "-H node3". Also, be sure to properly reload, not restart! The restart (-st) will kill the old process without leaving it a chance to resychronize! The reload (-sf) will tell it to finish its work then quit, and among its work there's the resync job ;-) > As I said to João Morais, we "solve" this problem adding a sidecar HAProxy > (another container in same pod) only to store the sticky-table of main > HAProxy. In my opinion it's a resource waste, but this is best solution now. That's a shame because the peers naturally support not losing tables on reload, so indeed your solution is way more complex! Hoping this helps, Willy