Hi
Thanks for the reply. We were not planning to use pgPools connection
pool mode, but its replication mode.
Our tests with pgPool allow us to install a backup db via pgPool to each
node, and tests loads overnight of 10+GB of inserts/updates/deletes all
work fine, with only a slight loss of performance vs a standalone DB.
I was wondering if there is another option that will allow me to spool
all ALTER|CREATE|DELETE|DROP|INSERT|UPDATE commands to all nodes, and
SELECTs to any of the connected nodes. The apllication can actually
handle separate READ|WRITE nodes from how it was written for Oracle.
Simon
On 21/01/2017 20:09, Stephen Frost wrote:
Simon,
* Simon Windsor (simon.windsor@xxxxxxxxxxxxxxx) wrote:
My employer wants to move from an in house Oracle solution to a
cloud based Postgres system. The system will involve a number of
data loaders running 24x7 feeding several Postgres Databases that
will be used by internal applications and external customer
applications.
For the record, internal and external applications make heavy use of
Temporary tables, that are session related. This requirement means I
cannot consider normal replication methods.
Is PgPool the only viable that will allow the system the data
loaders to feed [n] databases that will be functional identical?
I'm not sure what you mean by 'functional identical', but I wouldn't
generally consider that to be a property of pgpool (or pgbouncer, or any
other connection pooler, really).
That said, my general feeling is that pgbouncer tends to be simpler,
faster, and less likely to introduce oddities that you don't expect.
The 'session' mode might work for you, though it might be debatable if
that really helps you all that much. 'transaction' mode is what I
usually recommend as it allows idle connections to be handled by
pgbouncer (unlike 'session' mode), but there are caveats to using that
mode, of course.
I'm a bit curious where you're thinking of using the connection pooler
also though. If you have data loaders running 24x7 feeding data
constantly to PG, do you really need a connection pooler for those?
Connection poolers make a lot of sense for environments where there's
lots of down-time on the connection, but the less down-time, the less
they make sense.
Thanks!
Stephen
--
Simon Windsor
Eml: simon.windsor@xxxxxxxxxxxxxxx
Tel: 01454 617689
Mob: 0755 197 9733
“There is nothing in the world that some man cannot make a little worse and sell a little cheaper, and he who considers price only is that man's lawful prey.”
--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
