Not sure what the timeout is before LB_FAILED is triggered, anybody else know?
The connection and persistence table relationships are not cleared if a selected node that looks UP fails to respond (thus triggering LB_FAILED). Only a monitor marking the node DOWN clears the related server-side table entries.
So with OneConnect, LB::detach is necessary before a re-select to clear the connection table relationship of the client to the backend server, otherwise the same node will be re-selected. (might not be specific to OneConnect, but I think I'm remembering that correctly, somebody will straighten me out I'm sure)
Same idea re: removing the persistence record in LB_FAILED when re-selecting. Not sure if it's as necessary, but it would ensure the old persistence table relationship is cleared, then a new one would be created when the connection is re load balanced.
(LB::down isn't well integrated with monitors yet, so I would recommend against using it in this situation, preferring instead good monitoring with appropriate intervals configured.)
HTH
/deb