[Pgpool-general] "kind does not match between backends" errors :(

[Paul Lee]

Hi

> to expect SELECT to be sent to master only. What you are missing is
turning on load_balance_mode.
> Please let me know if you stil have the problem after setting
load_balance_mode to true.
I am only wanting SELECT queries to be sent to the master but seemed that
they were being sent to both the master and the secondary and producing the
error when they shouldn't have been sent to the secondary at all.

If load_balance_mode is set to false, the SELECT statements are only suppose
to go to the master right?


Thanks for your time guys, seems the error has gone now but replication
still isnt working, bit of a strange one, will keep chugging along at it.

Thanks again. 


Cheers
Paul
sitesonline
-------------
Email: paul at soa.net
Web: www.soa.net
-------------
Dante and Entertainz are members of:
The sitesonline Group

-----Original Message-----
From: Tatsuo Ishii [mailto:t-ishii at sra.co.jp] 
Sent: Thursday, 24 February 2005 2:06 p.m.
To: support at soa.net; paul at soa.net
Cc: pgpool-general at pgfoundry.org
Subject: Re: [Pgpool-general] "kind does not match between backends" errors
:(

> Trying to set-up pgpool, have been trying all morning but still cant 
> get it to run.

As Pablo has already pointed out, probably it's due to OID differences.
Another possiblity would be row ordering differences. Can you enable
debugging mode (add -d option to pgpool when starting up) and see what kind
of query trigger the error?

> I'm also curious to know in replication-only mode does pgpool still 
> send SELECT queries to the secondary server?

I find that you set:
> weight_master = 10
> weight_secondary = 0

to expect SELECT to be sent to master only. What you are missing is turning
on load_balance_mode. Please let me know if you stil have the problem after
setting load_balance_mode to true.
--
Tatsuo Ishii

> Anyhow here is my pgpool.conf:
>  
> #
> # pgpool configuration file sample
> # $Header: /home/t-ishii/repository/pgpool/pgpool.conf.sample,v 1.19
> 2005/02/02 14:33:38 t-ishii Exp $
>  
> # host name or IP address to listen on: '*' for all, '' for no TCP/IP 
> connections listen_addresses = '*'
>  
> # port number for pgpool
> port = 9999
>  
> # Unix domain socket path. Debian package default to /var/run/postgresql!
> socket_dir = '/tmp'
>  
> # host name where PostgreSQL server is running on. '' means localhost 
> using UNIX # domain socket backend_host_name = ''
>  
> # port number PostgreSQL server is running on.
> backend_port = 5432
>  
> # Unix domain socket path for the backend. Debian package default to 
> /var/run/postgresql!
> backend_socket_dir = '/tmp'
>  
> # host name where secondary PostgreSQL server is running on. '' means 
> localhost using UNIX # domain socket secondary_backend_host_name = 
> '[hidden]'
>  
> # port number secondary PostgreSQL server is running on.
> # 0 means no secondrary PostgreSQL
> secondary_backend_port = 5432
>  
> # number of pre-forked child process
> num_init_children = 32
>  
> # numer of connection pool allowed for a child process.
> max_pool = 4
>  
> # if idle for this seconds, child exits. 0 means no timeout.
> child_life_time = 300
>  
> # if idle for this seconds, connection to PostgreSQL closes. 0 means # 
> no timeout connection_life_time = 0
>  
> # logging directory
> logdir = '/tmp'
>  
> # replication mode
> replication_mode = true
>  
> # set this to true if you want to avoid deadlock situation when # 
> replication enabled.
> # there will be noticable performance degration, however.
> # a work around is set this to false and insert /*STRICT*/ comment # 
> at the beginning of the SQL command.
> replication_strict = true
>  
> # when replication_strict is set to false, there will be a chance for 
> # deadlocks. set this to non 0 (in milli seconds) to detect this # 
> situation and resolve the deadlock aborting current session.
> replication_timeout = 10000
>  
> # load balancing mode. i.e. all SELECT except in a transaction block # 
> are load balanced. This is ignored if replication_mode is false.
> load_balance_mode = false
>  
> # load balance weight for master and secondary. actual weight is # 
> calculated by weight_master:weight_secondary. For example both # # 
> weight_master = 10 and weight_secondary = 5 # weight_master = 4 and 
> weight_secondary = 2 # # are regarded as master has double the weight 
> comparing with secondary.
> # master and secondary have same weight in the default.
> weight_master = 10
> weight_secondary = 0
>  
> # if there's a data mismatch between master and secondary # start 
> degenration to stop replication mode replication_stop_on_mismatch = 
> false
>  
> # semicolon separated list of quries to be issued at the end of 
> session reset_query_list = 'ABORT; RESET ALL; SET SESSION AUTHORIZATION
DEFAULT'
>  
> # if true print time stamp to each log line print_timestamp = true
>  
> # if true, operate in master/slave mode master_slave_mode = false
>  
> # if true, cache connection pool
> connection_cache = true
>  
> # health check timeout. 0 means no timeout; health_check_timeout = 20
>  
> # health check period. 0 means no health check health_check_period = 0
>  
> # health check user
> health_check_user = 'nobody'
>  
> and here is my /tmp/pgpool.log:
>  
> 2005-02-24 02:51:00 ERROR: pid 1415: pool_process_query: kind does not 
> match between backends master(D) secondary(C)
> 2005-02-24 02:51:00 LOG: pid 1415: do_child: exits with status 1 due 
> to error
> 2005-02-24 02:51:37 ERROR: pid 1414: pool_process_query: kind does not 
> match between backends master(D) secondary(C)
> 2005-02-24 02:51:37 LOG: pid 1414: do_child: exits with status 1 due 
> to error
>  
> The plan is to have synchronous replication running on these 2 
> servers, but all I get is errors at this stage.
>  
> Server #1:
>     Postgres 8.0.0 on RHEL WS 3 port 5432
>     Pgpool 2.5 port 9999
>  
> Server #2:
>     Postgres 8.0.0 on RHEL WS 3 port 5432
>  
>  
> I have done a pg_dump on both servers and an md5sum and both databases 
> are currently identical, same usernames, same passwords, both super 
> users just in case.
>  
>  
> Any ideas?
>  
> Regards
> Paul Lee
>