Problems with ports not working correctly after SQL Server builds a publish subscription

SQL Publishing subscriptions, presumably everyone knows, but generally in the default of 1433 of the case, then 1433 for other ports, the release can still work properly?

I met in a real customer scene.

Well, don't want to write too much today, to simplify the test environment

Publisher Computer name win-01

Distributor Computer name Win-01 (same as the one used for publishing)

Subscriber Computer name win-02

The test library used is YY

In the default port 1433 scenario, we've built a publish subscription,

Made a copy of the two tables.

Let's look at the Replication Monitor.

It is normal to insert, delete, modify in the table of win-01, there is no more introduction.

So, when we win-02 this instance of the default 1433 change to 4111, the subscription is normal?

We then look at the state of the replication timer,

This is the state is already, not even the status of the subscription, at this time we write the data,

Publishing Server win-01

Subscriber win-02

Can be seen, and not synced over. What should we do now?

After testing, it is only possible to map by creating aliases on win-01, which is the distributed server.

Create aliases on win-01

Remember that all two are to be created, and 32 bits are given to create a subscription using the alias, 64 bits for the synchronization program (no need to restart).

This is where we look at the Replication Monitor.

And look at the data in the table on win-02.

It's been synced over.

Problems with ports not working correctly after SQL Server builds a publish subscription