Re: Question about replication[with codes]
Posted in 2004
Topics: Error Codes & Troubleshooting, Networking & sqlhosts Configuration
Ken, ER connections are bi-directional in nature. That means that either side can initiate a connection. So what happens during replication server definition is the new server connects to the sync server and requests a sync-up. The sync server then turns arround and attempts to connect to the new server to pass down any necessary metadata. We do this double connect at server definition time to ensure that things are setup correctly. That means that while g_destination might be able to connect to g_source, that g_souce is not able to initiate a connection back to g_destination. So when anyone runs into the error code 5, it means that you need to check both ends, including the message log file. If that doesn't give some insite into the problem, then there is additional tracing that can be done. BTW -- do you have a case open on this problem? If so, could you post the case number? Thanks M.P. "Ken Hu" <kenhu1970@yahoo.com.tw> wrote in message news:cgmqje$ob8$1@netnews.hinet.net... > Madison Pruet wrote: > > We really need to see the exact commands you are executing. > > > Thanks again for your help. > > > The exact commands that I executed are : > > (1)cdr define server -c g_source -I g_source > (2)cdr list server > The result is : > SERVER ID STATE STATUS CONNECTION CHANGED > ------------------------------------------------------------------ > g_source 1 Active Local > (3)cdr define server -c g_destination -I -S g_source g_destination > The result is : > command failed -- unable to connect to server specified (5) > > > The sqlhosts file is : > ------------------------------------------------------------------ > g_source group - - i=1 > MEDIADB_cvsserver onsoctcp cvs-server ediaDB_cvsserver g=g_source > > g_destination group - - i=2 > MEDIADB_kenlinux onsoctcp ken-linux mediaDB_kenlinux g=g_destination > > ------------------------------------------------------------------ > > > Ken >
Thanks , Madison You are right , I forgot to check the log file(online.log). After checking the log message, I found the problem is caused by the machine time are differents on 2 informix database. I used NTPDATE to adjust the time , then , the problem was gone. Thanks for your kindy help . Ken Madison Pruet wrote: > Ken, > So when anyone runs into the error code 5, it means that you need to check > both ends, including the message log file. >