|
BH, Hi i'm having a problem when trying to use database mirroring on two different machines. I have 2 computers. 1st computer is running server1 and Arbiter. 2nd computer is running server2. I've created 2 services (using sybase central) on computer1 with the following configurations. -x tcpip(port=2640) -n arbiter -xa AUTH=abc;DBN=mtrs16 -xf D:\RMT\arbiter\arbiterstate.txt -su and 2nd service: -n mtrs16a -x tcpip(PORT=2638) -xf d:\RMT\mtrs16\mtrs16astate.txt -su sql d:\RMT\mtrs16\mtrs16.db -sn mirrordemo_test -xp partner=(ENG=mtrs16b;LINKS=tcpip(PORT=2639;TIMEOUT=1));auth=abc;arbiter=(ENG=arbiter;LINKS=tcpip(PORT=2640;TIMEOUT=1));mode=sync On the 2nd computer I have one service running with following commands. -n mtrs16b -x tcpip(PORT=2639) -xf d:\RMT\mtrs16\mtrs16bstate.txt -su sql d:\RMT\mtrs16\mtrs16.db -sn mirrordemo_test -xp partner=(ENG=mtrs16b;LINKS=tcpip(PORT=2638;TIMEOUT=1));auth=abc;arbiter=(ENG=arbiter;LINKS=tcpip(PORT=2640;TIMEOUT=1));mode=sync The strange thing is, that when I have server1, server2, and arbiter all on the same computer, than it works fine. However, when I move server2 to a different computer, it does not connect to arbiter and to server1. I'm sure that the computer2 sees the computer1, because I can ping the ip and connect to computer1 using the ODBC Administrator. What am I doing wrong? |
|
Your -xp parameter on the 2nd computer has the wrong ENG= value - it says mtrs16b and should be mtrs16a. Also check to make sure that you don't have firewalls getting in the way: on your 2nd computer run dbping -c ENG=mtrs16a;LINKS=tcpip(PORT=2638) to test connectivity to your primary server and run dbping -c ENG=arbiter;LINKS=tcpip(PORT=2640) to test connectivity to your arbiter. If the above two dbping commands are successful then ensure that connections in the other direction also work. I.e. run dbping -c ENG=mtrs16b;LINKS=tcpip(PORT=2639) HTH Mark, thanks for your reply. I've tried the dbping and it failed. It says database Server not found. However, my firewalls are off on both machines. Could it be due to the fact that one computer is running windows 2003 server, while the other is running windows 2008 server?
(23 Dec '13, 15:53)
arony
Replies hidden
I highly doubt that the issue is the version of windows. Some virus software also include port blocking features. Are you running virus detection/protection software of either computers? If yes, then you should check the feature settings of the virus software to make sure that the outgoing connection requests and incoming ports are not being blocked. BTW: Did you correct your connection string?
(23 Dec '13, 16:09)
Mark Culp
Mark,
I've checked, and don't have antiviruses installed on either machines.
(23 Dec '13, 16:18)
arony
Replies hidden
In the ODBC data source configuration, under the 'Login' tab, what is 'Action' set to? Is it possible that you are auto-starting the server with the data source (Start and connect to ...) ?
(23 Dec '13, 17:14)
Mikel Rychliski
|
|
I somehow solved the problem. When i connected to a different network, i was able to connect to the servers and arbitrator. I'm not exactly sure why the other network was giving me such a hard time, but the only explanation i can think of is the difference in the 3rd set of the ip addresses. For example: Senario 1. Srv1 ipv4: 192.168.254.18 Srv2 ipv4: 192.168.100.17 DOES NOT WORK. Senario 2. Srv1 ipv4: 192.168.254.18 Srv2 ipv4: 192.168.254.17 WORKS. Could that have been possibly the problem? Ah, I was wondering if you were trying to connect across subnets! Note that when crossing subnets you need to specify the host name of the computer in your connection string. The reason for this is that most (all?) network routers will not broadcast UDP packets across subnets and SQL Anywhere uses UDP broadcasts to find the database server (when you do not specify the host parameter in the connection string). Example: dbping -c "UID=DBA;PWD=sql;ServerName=demo16;Host=my_host:2638" See the documentation for more information: http://dcx.sybase.com/index.html#sa160/en/dbadmin/connect-server.html
(25 Dec '13, 11:09)
Mark Culp
|