Skip site navigation (1) Skip section navigation (2)

Re: Command prompt replication.

From: Theo Galanakis <Theo(dot)Galanakis(at)lonelyplanet(dot)com(dot)au>
To: pgsql-admin(at)postgresql(dot)org
Subject: Re: Command prompt replication.
Date: 2005-01-20 04:23:23
Message-ID: D1444817B78AB546BF2896C2B70E7F04371E7F@ganesh.au.lpint.net (view raw or flat)
Thread:
Lists: pgsql-admin
I also should add....
 
This is the results of slave_stat when running on the slave, this looks
peculiar:
 
 /usr/local/pgsql/bin/slave_stat  /usr/local/pgsql/mcp_data 0
Sync: DESYNC
First record in queue: 0
Last received record: 0
Last restored record: 0

-----Original Message-----
From: Theo Galanakis 
Sent: Thursday, 20 January 2005 2:09 PM
To: pgsql-admin(at)postgresql(dot)org
Subject: [ADMIN] Command prompt replication.



Hi, 
        I'm evaluating command prompts replication server and have an issue
I need help to resolve. 

        I have install the master and slave from the postgres code supplied
from command prompt. Have created a benchpg database which is automatically
created by the contrib program, pg_bench. Then proceeded to copy that
database to the slave via pg_dump, etc...

        Im currently running both databases on separate servers. And I have
started up : 

 /usr/local/pgsql/bin/mcp_server -c /usr/local/pgsql/etc/mcp_server.conf -l
/var/log/mcp_server.log & 

        Based on the output both pg servers connect to the mcp server
successfully.. 

        Ok.. 

        Not testing the replication by inserting a record into the master
database table branches. 

        As soon as I enter this record /var/log/mcp_server.log is populated
with : 
  

DEBUG_MSG:  MCP-M-Recv| recno: 16003065  txnid:    85  datalen:    25
flags: TABLE_BEGIN TABLE_LIST TABLE_END 

DEBUG:  Store master tables list in
/usr/local/pgsql/mcp_data/txlog_mcp_master_table_list 
DEBUG_MSG:  MCP-M-Recv| recno: 16003066  txnid:    86  datalen:     4
flags: TXBEGIN DATA 

DEBUG_MSG:  MCP-M-Recv| recno: 16003067  txnid:    86  datalen:     4
flags: DATA 

DEBUG_MSG:  MCP-M-Recv| recno: 16003068  txnid:    86  datalen:    44
flags: DATA 

DEBUG_MSG:  MCP-M-Recv| recno: 16003069  txnid:    86  datalen:    12
flags: DATA 

DEBUG_MSG:  MCP-M-Recv| recno: 16003070  txnid:    86  datalen:    16
flags: DATA 

DEBUG_MSG:  MCP-M-Recv| recno: 16003071  txnid:    86  datalen:     4
flags: DATA TXEND 

DEBUG_MASTER:  MCP Receive TXEND => mcp_ack_recno: 16003071 
DEBUG_MASTER:  MCP Send ACK to Master => ACK reco: 16003071, mcp_ack_recno =
0 
DEBUG_MSG:  MCP-M-Send| recno: 16003071  txnid:     0  datalen:     0
flags: !ACK 

DEBUG_SLAVE:  0: TABLE_LIST => SKIP recno: 16003065 
DEBUG_SLAVE:  MCP Send TXBEGIN to Slave(0) 
DEBUG_SLAVE:  MCP send TXEND to Slave(0) 
DEBUG_SLAVE:  0, Send INCSKIP 
DEBUG_MSG:  MCP-S(0)-Send| recno: 16003071  txnid:    86  datalen:     4
flags: DATA TXEND 

DEBUG_MSG:  MCP-S(0)-Recv| recno: 16003071  txnid:     0  datalen:     0
flags: !ACK 

DEBUG_SLAVE:  0: Recv ACK from Slave(0) => Slave(0).vrecno = 16003071 


On the slave server the /var/log/postgresql.log is polutated with this: 

LOG:  INCSKIP to 16003071 
LOG:  SET mcp_ack_recno: 16003071 

Based on my limited knowledge and little documentation provided by command
prompt, all looks well??? However the record I added to the master has not
been copied to the slave. 

Regards, 
        Theo 

______________________________________________________________________
This email, including attachments, is intended only for the addressee
and may be confidential, privileged and subject to copyright. If you
have received this email in error, please advise the sender and delete
it. If you are not the intended recipient of this email, you must not
use, copy or disclose its content to anyone. You must not copy or 
communicate to others content that is confidential or subject to 
copyright, unless you have the consent of the content owner.
	

Responses

pgsql-admin by date

Next:From: Troyston CampanoDate: 2005-01-20 05:03:28
Subject: Oracle and Postgresql Play Nice Together on Same Computer?
Previous:From: Michael FuhrDate: 2005-01-20 04:07:07
Subject: Re: Privileges where not restored

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group