David Boreham wrote:
> A limitation on the server side is that a replication agreement's target
> host, port and connection type can't be modified while the server is
> running - DSA unwilling to perform. It has to be recreated or possibly
> edited in offline mode. Maybe this could use some enhancement (followed
> by Console unenhancement), but I'd rank replication StartTLS support
> higher on the nice-to-have list.
>
>
Changing the connection properties while the server is up is likely
to take a long time to completely debug. That's because the
replication connection
management state machine code is rather complicated and hard to modify.
However, adding support for start tls is quite easy.
If you feel like it you can always take the server down and
edit the replication agreement directly. But hey, replication
agreements are created approximately never (like a few times
when you're figuring out how the thing works, then once or
twice when you deploy). So making the process silky-smooth
for some even yet more uncommon corner case like
changing from non-ssl to ssl seems like not a great use
of limited programming and testing time (IMHO).
Oh yeah, I didn't mean to suggest it would be the best investment of
time and effort. It was looked at a couple of years ago with the same
as your conclusion, that's why I grayed-out the fields in the Console
instead.
But it's not as rare as one would think that replication agreement
properties need changing, it happens in some large deployments in
failovers and such. But in that case it wouldn't make sense to perform
it via the Console anyway, it's done by script, and then it's nearly as
simple to just replace the replication agreement as Brian first suggested.