prestogres 0.1.0
Sign up to get free protection for your applications and to get access to all the features.
- data/.gitignore +4 -0
- data/Gemfile +2 -0
- data/Gemfile.lock +20 -0
- data/LICENSE +202 -0
- data/NOTICE +22 -0
- data/README.md +217 -0
- data/Rakefile +13 -0
- data/VERSION +1 -0
- data/bin/prestogres +254 -0
- data/config/pcp.conf.sample +28 -0
- data/config/pgpool.conf +678 -0
- data/config/pool_hba.conf +84 -0
- data/config/pool_passwd +0 -0
- data/config/postgresql.conf +2 -0
- data/ext/.gitignore +6 -0
- data/ext/depend +26 -0
- data/ext/extconf.rb +4 -0
- data/ext/prestogres_config.c +12 -0
- data/pgpool2/.gitignore +36 -0
- data/pgpool2/AUTHORS +4 -0
- data/pgpool2/COPYING +12 -0
- data/pgpool2/ChangeLog +1 -0
- data/pgpool2/INSTALL +1 -0
- data/pgpool2/Makefile.am +159 -0
- data/pgpool2/Makefile.in +1187 -0
- data/pgpool2/NEWS +4960 -0
- data/pgpool2/README +1 -0
- data/pgpool2/README.euc_jp +1 -0
- data/pgpool2/README.online-recovery +62 -0
- data/pgpool2/TODO +103 -0
- data/pgpool2/ac_func_accept_argtypes.m4 +85 -0
- data/pgpool2/aclocal.m4 +1088 -0
- data/pgpool2/c-compiler.m4 +134 -0
- data/pgpool2/c-library.m4 +325 -0
- data/pgpool2/child.c +2097 -0
- data/pgpool2/config.guess +1532 -0
- data/pgpool2/config.h.in +332 -0
- data/pgpool2/config.sub +1640 -0
- data/pgpool2/configure +15752 -0
- data/pgpool2/configure.in +392 -0
- data/pgpool2/depcomp +522 -0
- data/pgpool2/doc/basebackup.sh +17 -0
- data/pgpool2/doc/pgpool-de.html +4220 -0
- data/pgpool2/doc/pgpool-en.html +5738 -0
- data/pgpool2/doc/pgpool-fr.html +4118 -0
- data/pgpool2/doc/pgpool-ja.css +198 -0
- data/pgpool2/doc/pgpool-ja.html +11279 -0
- data/pgpool2/doc/pgpool-zh_cn.html +4445 -0
- data/pgpool2/doc/pgpool.css +280 -0
- data/pgpool2/doc/pgpool_remote_start +13 -0
- data/pgpool2/doc/recovery.conf.sample +117 -0
- data/pgpool2/doc/tutorial-en.html +707 -0
- data/pgpool2/doc/tutorial-ja.html +422 -0
- data/pgpool2/doc/tutorial-memqcache-en.html +325 -0
- data/pgpool2/doc/tutorial-memqcache-ja.html +370 -0
- data/pgpool2/doc/tutorial-memqcache-zh_cn.html +322 -0
- data/pgpool2/doc/tutorial-watchdog-en.html +306 -0
- data/pgpool2/doc/tutorial-watchdog-ja.html +343 -0
- data/pgpool2/doc/tutorial-watchdog-zh_cn.html +301 -0
- data/pgpool2/doc/tutorial-zh_cn.html +537 -0
- data/pgpool2/doc/watchdog.png +0 -0
- data/pgpool2/doc/wd-en.html +236 -0
- data/pgpool2/doc/wd-en.jpg +0 -0
- data/pgpool2/doc/wd-ja.html +219 -0
- data/pgpool2/doc/wd-ja.jpg +0 -0
- data/pgpool2/doc/wd-zh_cn.html +201 -0
- data/pgpool2/doc/where_to_send_queries.odg +0 -0
- data/pgpool2/doc/where_to_send_queries.pdf +0 -0
- data/pgpool2/general.m4 +166 -0
- data/pgpool2/getopt_long.c +200 -0
- data/pgpool2/getopt_long.h +44 -0
- data/pgpool2/install-sh +251 -0
- data/pgpool2/ltmain.sh +8406 -0
- data/pgpool2/m4/libtool.m4 +7360 -0
- data/pgpool2/m4/ltoptions.m4 +368 -0
- data/pgpool2/m4/ltsugar.m4 +123 -0
- data/pgpool2/m4/ltversion.m4 +23 -0
- data/pgpool2/m4/lt~obsolete.m4 +92 -0
- data/pgpool2/main.c +2971 -0
- data/pgpool2/md5.c +444 -0
- data/pgpool2/md5.h +28 -0
- data/pgpool2/missing +360 -0
- data/pgpool2/mkinstalldirs +40 -0
- data/pgpool2/parser/Makefile.am +50 -0
- data/pgpool2/parser/Makefile.in +559 -0
- data/pgpool2/parser/copyfuncs.c +3310 -0
- data/pgpool2/parser/gram.c +39100 -0
- data/pgpool2/parser/gram.h +940 -0
- data/pgpool2/parser/gram.y +13408 -0
- data/pgpool2/parser/gramparse.h +74 -0
- data/pgpool2/parser/keywords.c +32 -0
- data/pgpool2/parser/keywords.h +39 -0
- data/pgpool2/parser/kwlist.h +425 -0
- data/pgpool2/parser/kwlookup.c +88 -0
- data/pgpool2/parser/list.c +1156 -0
- data/pgpool2/parser/makefuncs.c +518 -0
- data/pgpool2/parser/makefuncs.h +83 -0
- data/pgpool2/parser/memnodes.h +79 -0
- data/pgpool2/parser/nodes.c +29 -0
- data/pgpool2/parser/nodes.h +609 -0
- data/pgpool2/parser/outfuncs.c +5790 -0
- data/pgpool2/parser/parsenodes.h +2615 -0
- data/pgpool2/parser/parser.c +262 -0
- data/pgpool2/parser/parser.h +46 -0
- data/pgpool2/parser/pg_class.h +158 -0
- data/pgpool2/parser/pg_config_manual.h +273 -0
- data/pgpool2/parser/pg_list.h +352 -0
- data/pgpool2/parser/pg_trigger.h +147 -0
- data/pgpool2/parser/pg_wchar.h +492 -0
- data/pgpool2/parser/pool_memory.c +342 -0
- data/pgpool2/parser/pool_memory.h +77 -0
- data/pgpool2/parser/pool_parser.h +222 -0
- data/pgpool2/parser/pool_string.c +121 -0
- data/pgpool2/parser/pool_string.h +37 -0
- data/pgpool2/parser/primnodes.h +1280 -0
- data/pgpool2/parser/scan.c +4094 -0
- data/pgpool2/parser/scan.l +1451 -0
- data/pgpool2/parser/scanner.h +120 -0
- data/pgpool2/parser/scansup.c +221 -0
- data/pgpool2/parser/scansup.h +28 -0
- data/pgpool2/parser/snprintf.c +1102 -0
- data/pgpool2/parser/stringinfo.c +294 -0
- data/pgpool2/parser/stringinfo.h +178 -0
- data/pgpool2/parser/value.c +78 -0
- data/pgpool2/parser/value.h +62 -0
- data/pgpool2/parser/wchar.c +2048 -0
- data/pgpool2/pcp.conf.sample +28 -0
- data/pgpool2/pcp/Makefile.am +40 -0
- data/pgpool2/pcp/Makefile.in +771 -0
- data/pgpool2/pcp/libpcp_ext.h +250 -0
- data/pgpool2/pcp/md5.c +444 -0
- data/pgpool2/pcp/md5.h +28 -0
- data/pgpool2/pcp/pcp.c +1652 -0
- data/pgpool2/pcp/pcp.h +61 -0
- data/pgpool2/pcp/pcp_attach_node.c +172 -0
- data/pgpool2/pcp/pcp_detach_node.c +185 -0
- data/pgpool2/pcp/pcp_error.c +87 -0
- data/pgpool2/pcp/pcp_node_count.c +160 -0
- data/pgpool2/pcp/pcp_node_info.c +198 -0
- data/pgpool2/pcp/pcp_pool_status.c +166 -0
- data/pgpool2/pcp/pcp_proc_count.c +166 -0
- data/pgpool2/pcp/pcp_proc_info.c +261 -0
- data/pgpool2/pcp/pcp_promote_node.c +185 -0
- data/pgpool2/pcp/pcp_recovery_node.c +172 -0
- data/pgpool2/pcp/pcp_stop_pgpool.c +179 -0
- data/pgpool2/pcp/pcp_stream.c +385 -0
- data/pgpool2/pcp/pcp_stream.h +52 -0
- data/pgpool2/pcp/pcp_systemdb_info.c +194 -0
- data/pgpool2/pcp/pcp_watchdog_info.c +211 -0
- data/pgpool2/pcp_child.c +1493 -0
- data/pgpool2/pg_md5.c +305 -0
- data/pgpool2/pgpool.8.in +121 -0
- data/pgpool2/pgpool.conf +553 -0
- data/pgpool2/pgpool.conf.sample +666 -0
- data/pgpool2/pgpool.conf.sample-master-slave +665 -0
- data/pgpool2/pgpool.conf.sample-replication +664 -0
- data/pgpool2/pgpool.conf.sample-stream +664 -0
- data/pgpool2/pgpool.spec +264 -0
- data/pgpool2/pgpool_adm/TODO +7 -0
- data/pgpool2/pgpool_adm/pgpool_adm--1.0.sql +85 -0
- data/pgpool2/pgpool_adm/pgpool_adm.c +558 -0
- data/pgpool2/pgpool_adm/pgpool_adm.control +5 -0
- data/pgpool2/pgpool_adm/pgpool_adm.h +46 -0
- data/pgpool2/pgpool_adm/pgpool_adm.sql.in +85 -0
- data/pgpool2/pool.h +655 -0
- data/pgpool2/pool_auth.c +1390 -0
- data/pgpool2/pool_config.c +5007 -0
- data/pgpool2/pool_config.h +284 -0
- data/pgpool2/pool_config.l +3281 -0
- data/pgpool2/pool_config_md5.c +29 -0
- data/pgpool2/pool_connection_pool.c +812 -0
- data/pgpool2/pool_error.c +242 -0
- data/pgpool2/pool_globals.c +27 -0
- data/pgpool2/pool_hba.c +1723 -0
- data/pgpool2/pool_hba.conf.sample +67 -0
- data/pgpool2/pool_ip.c +567 -0
- data/pgpool2/pool_ip.h +65 -0
- data/pgpool2/pool_ipc.h +38 -0
- data/pgpool2/pool_lobj.c +242 -0
- data/pgpool2/pool_lobj.h +32 -0
- data/pgpool2/pool_memqcache.c +3818 -0
- data/pgpool2/pool_memqcache.h +268 -0
- data/pgpool2/pool_params.c +163 -0
- data/pgpool2/pool_passwd.c +249 -0
- data/pgpool2/pool_passwd.h +41 -0
- data/pgpool2/pool_path.c +193 -0
- data/pgpool2/pool_path.h +81 -0
- data/pgpool2/pool_process_context.c +247 -0
- data/pgpool2/pool_process_context.h +62 -0
- data/pgpool2/pool_process_query.c +5001 -0
- data/pgpool2/pool_process_reporting.c +1671 -0
- data/pgpool2/pool_process_reporting.h +44 -0
- data/pgpool2/pool_proto2.c +671 -0
- data/pgpool2/pool_proto_modules.c +3524 -0
- data/pgpool2/pool_proto_modules.h +185 -0
- data/pgpool2/pool_query_cache.c +1020 -0
- data/pgpool2/pool_query_context.c +1871 -0
- data/pgpool2/pool_query_context.h +105 -0
- data/pgpool2/pool_relcache.c +284 -0
- data/pgpool2/pool_relcache.h +78 -0
- data/pgpool2/pool_rewrite_outfuncs.c +9060 -0
- data/pgpool2/pool_rewrite_query.c +715 -0
- data/pgpool2/pool_rewrite_query.h +192 -0
- data/pgpool2/pool_select_walker.c +1150 -0
- data/pgpool2/pool_select_walker.h +68 -0
- data/pgpool2/pool_sema.c +161 -0
- data/pgpool2/pool_session_context.c +952 -0
- data/pgpool2/pool_session_context.h +203 -0
- data/pgpool2/pool_shmem.c +185 -0
- data/pgpool2/pool_signal.c +158 -0
- data/pgpool2/pool_signal.h +61 -0
- data/pgpool2/pool_ssl.c +339 -0
- data/pgpool2/pool_stream.c +962 -0
- data/pgpool2/pool_stream.h +61 -0
- data/pgpool2/pool_system.c +659 -0
- data/pgpool2/pool_timestamp.c +1215 -0
- data/pgpool2/pool_timestamp.h +38 -0
- data/pgpool2/pool_type.h +171 -0
- data/pgpool2/pool_worker_child.c +384 -0
- data/pgpool2/ps_status.c +404 -0
- data/pgpool2/recovery.c +435 -0
- data/pgpool2/redhat/pgpool.conf.sample.patch +52 -0
- data/pgpool2/redhat/pgpool.init +201 -0
- data/pgpool2/redhat/pgpool.sysconfig +7 -0
- data/pgpool2/redhat/rpm_installer/basebackup-replication.sh +53 -0
- data/pgpool2/redhat/rpm_installer/basebackup-stream.sh +55 -0
- data/pgpool2/redhat/rpm_installer/config_for_script +17 -0
- data/pgpool2/redhat/rpm_installer/failover.sh +64 -0
- data/pgpool2/redhat/rpm_installer/getsources.sh +141 -0
- data/pgpool2/redhat/rpm_installer/install.sh +1363 -0
- data/pgpool2/redhat/rpm_installer/pgpool_recovery_pitr +47 -0
- data/pgpool2/redhat/rpm_installer/pgpool_remote_start +15 -0
- data/pgpool2/redhat/rpm_installer/recovery.conf +4 -0
- data/pgpool2/redhat/rpm_installer/uninstall.sh +57 -0
- data/pgpool2/sample/dist_def_pgbench.sql +73 -0
- data/pgpool2/sample/pgpool.pam +3 -0
- data/pgpool2/sample/pgpool_recovery +20 -0
- data/pgpool2/sample/pgpool_recovery_pitr +19 -0
- data/pgpool2/sample/pgpool_remote_start +13 -0
- data/pgpool2/sample/replicate_def_pgbench.sql +18 -0
- data/pgpool2/sql/insert_lock.sql +15 -0
- data/pgpool2/sql/pgpool-recovery/pgpool-recovery.c +280 -0
- data/pgpool2/sql/pgpool-recovery/pgpool-recovery.sql.in +19 -0
- data/pgpool2/sql/pgpool-recovery/pgpool_recovery--1.0.sql +24 -0
- data/pgpool2/sql/pgpool-recovery/pgpool_recovery.control +5 -0
- data/pgpool2/sql/pgpool-recovery/uninstall_pgpool-recovery.sql +3 -0
- data/pgpool2/sql/pgpool-regclass/pgpool-regclass.c +206 -0
- data/pgpool2/sql/pgpool-regclass/pgpool-regclass.sql.in +4 -0
- data/pgpool2/sql/pgpool-regclass/pgpool_regclass--1.0.sql +7 -0
- data/pgpool2/sql/pgpool-regclass/pgpool_regclass.control +5 -0
- data/pgpool2/sql/pgpool-regclass/uninstall_pgpool-regclass.sql +1 -0
- data/pgpool2/sql/system_db.sql +38 -0
- data/pgpool2/strlcpy.c +85 -0
- data/pgpool2/test/C/test_extended.c +98 -0
- data/pgpool2/test/jdbc/.cvsignore +2 -0
- data/pgpool2/test/jdbc/AutoCommitTest.java +45 -0
- data/pgpool2/test/jdbc/BatchTest.java +55 -0
- data/pgpool2/test/jdbc/ColumnTest.java +60 -0
- data/pgpool2/test/jdbc/CreateTempTableTest.java +48 -0
- data/pgpool2/test/jdbc/InsertTest.java +34 -0
- data/pgpool2/test/jdbc/LockTest.java +36 -0
- data/pgpool2/test/jdbc/PgpoolTest.java +75 -0
- data/pgpool2/test/jdbc/README.euc_jp +73 -0
- data/pgpool2/test/jdbc/RunTest.java +83 -0
- data/pgpool2/test/jdbc/SelectTest.java +37 -0
- data/pgpool2/test/jdbc/UpdateTest.java +32 -0
- data/pgpool2/test/jdbc/expected/CreateTempTable +1 -0
- data/pgpool2/test/jdbc/expected/autocommit +10 -0
- data/pgpool2/test/jdbc/expected/batch +1 -0
- data/pgpool2/test/jdbc/expected/column +100 -0
- data/pgpool2/test/jdbc/expected/insert +1 -0
- data/pgpool2/test/jdbc/expected/lock +100 -0
- data/pgpool2/test/jdbc/expected/select +2 -0
- data/pgpool2/test/jdbc/expected/update +1 -0
- data/pgpool2/test/jdbc/pgpool.properties +7 -0
- data/pgpool2/test/jdbc/prepare.sql +54 -0
- data/pgpool2/test/jdbc/run.sh +6 -0
- data/pgpool2/test/parser/.cvsignore +6 -0
- data/pgpool2/test/parser/README +32 -0
- data/pgpool2/test/parser/expected/copy.out +17 -0
- data/pgpool2/test/parser/expected/create.out +64 -0
- data/pgpool2/test/parser/expected/cursor.out +37 -0
- data/pgpool2/test/parser/expected/delete.out +10 -0
- data/pgpool2/test/parser/expected/drop.out +12 -0
- data/pgpool2/test/parser/expected/insert.out +13 -0
- data/pgpool2/test/parser/expected/misc.out +28 -0
- data/pgpool2/test/parser/expected/prepare.out +4 -0
- data/pgpool2/test/parser/expected/privileges.out +31 -0
- data/pgpool2/test/parser/expected/scanner.out +30 -0
- data/pgpool2/test/parser/expected/select.out +89 -0
- data/pgpool2/test/parser/expected/transaction.out +38 -0
- data/pgpool2/test/parser/expected/update.out +11 -0
- data/pgpool2/test/parser/expected/v84.out +37 -0
- data/pgpool2/test/parser/expected/v90.out +25 -0
- data/pgpool2/test/parser/expected/var.out +22 -0
- data/pgpool2/test/parser/input/alter.sql +2 -0
- data/pgpool2/test/parser/input/copy.sql +17 -0
- data/pgpool2/test/parser/input/create.sql +64 -0
- data/pgpool2/test/parser/input/cursor.sql +37 -0
- data/pgpool2/test/parser/input/delete.sql +10 -0
- data/pgpool2/test/parser/input/drop.sql +12 -0
- data/pgpool2/test/parser/input/insert.sql +13 -0
- data/pgpool2/test/parser/input/misc.sql +28 -0
- data/pgpool2/test/parser/input/prepare.sql +4 -0
- data/pgpool2/test/parser/input/privileges.sql +31 -0
- data/pgpool2/test/parser/input/scanner.sql +34 -0
- data/pgpool2/test/parser/input/select.sql +89 -0
- data/pgpool2/test/parser/input/transaction.sql +38 -0
- data/pgpool2/test/parser/input/update.sql +11 -0
- data/pgpool2/test/parser/input/v84.sql +37 -0
- data/pgpool2/test/parser/input/v90.sql +38 -0
- data/pgpool2/test/parser/input/var.sql +22 -0
- data/pgpool2/test/parser/main.c +96 -0
- data/pgpool2/test/parser/parse_schedule +16 -0
- data/pgpool2/test/parser/pool.h +13 -0
- data/pgpool2/test/parser/run-test +62 -0
- data/pgpool2/test/pdo-test/README.euc_jp +58 -0
- data/pgpool2/test/pdo-test/SQLlist/test1.sql +3 -0
- data/pgpool2/test/pdo-test/SQLlist/test2.sql +3 -0
- data/pgpool2/test/pdo-test/collections.inc +11 -0
- data/pgpool2/test/pdo-test/def.inc +7 -0
- data/pgpool2/test/pdo-test/log.txt +0 -0
- data/pgpool2/test/pdo-test/mod/database.inc +36 -0
- data/pgpool2/test/pdo-test/mod/def.inc +0 -0
- data/pgpool2/test/pdo-test/mod/errorhandler.inc +27 -0
- data/pgpool2/test/pdo-test/pdotest.php +11 -0
- data/pgpool2/test/pdo-test/regsql.inc +56 -0
- data/pgpool2/test/pgpool_setup +898 -0
- data/pgpool2/test/regression/README +39 -0
- data/pgpool2/test/regression/clean.sh +21 -0
- data/pgpool2/test/regression/libs.sh +16 -0
- data/pgpool2/test/regression/regress.sh +166 -0
- data/pgpool2/test/regression/tests/001.load_balance/test.sh +128 -0
- data/pgpool2/test/regression/tests/002.native_replication/PgTester.java +47 -0
- data/pgpool2/test/regression/tests/002.native_replication/create.sql +6 -0
- data/pgpool2/test/regression/tests/002.native_replication/test.sh +71 -0
- data/pgpool2/test/regression/tests/003.failover/expected.r +6 -0
- data/pgpool2/test/regression/tests/003.failover/expected.s +6 -0
- data/pgpool2/test/regression/tests/003.failover/test.sh +45 -0
- data/pgpool2/test/regression/tests/004.watchdog/master.conf +12 -0
- data/pgpool2/test/regression/tests/004.watchdog/standby.conf +19 -0
- data/pgpool2/test/regression/tests/004.watchdog/test.sh +52 -0
- data/pgpool2/test/regression/tests/050.bug58/test.sh +50 -0
- data/pgpool2/test/regression/tests/051.bug60/bug.sql +12 -0
- data/pgpool2/test/regression/tests/051.bug60/database-clean.sql +6 -0
- data/pgpool2/test/regression/tests/051.bug60/database-setup.sql +28 -0
- data/pgpool2/test/regression/tests/051.bug60/test.sh +79 -0
- data/pgpool2/test/regression/tests/052.do_query/test.sh +44 -0
- data/pgpool2/test/regression/tests/053.insert_lock_hangs/test.sh +81 -0
- data/pgpool2/test/regression/tests/054.postgres_fdw/test.sh +67 -0
- data/pgpool2/test/regression/tests/055.backend_all_down/test.sh +52 -0
- data/pgpool2/test/regression/tests/056.bug63/jdbctest2.java +66 -0
- data/pgpool2/test/regression/tests/056.bug63/test.sh +47 -0
- data/pgpool2/test/regression/tests/057.bug61/test.sh +40 -0
- data/pgpool2/test/regression/tests/058.bug68/jdbctest3.java +45 -0
- data/pgpool2/test/regression/tests/058.bug68/test.sh +47 -0
- data/pgpool2/test/timestamp/expected/insert.out +16 -0
- data/pgpool2/test/timestamp/expected/misc.out +3 -0
- data/pgpool2/test/timestamp/expected/update.out +6 -0
- data/pgpool2/test/timestamp/input/insert.sql +16 -0
- data/pgpool2/test/timestamp/input/misc.sql +3 -0
- data/pgpool2/test/timestamp/input/update.sql +6 -0
- data/pgpool2/test/timestamp/main.c +129 -0
- data/pgpool2/test/timestamp/parse_schedule +3 -0
- data/pgpool2/test/timestamp/run-test +69 -0
- data/pgpool2/version.h +1 -0
- data/pgpool2/watchdog/Makefile.am +17 -0
- data/pgpool2/watchdog/Makefile.in +505 -0
- data/pgpool2/watchdog/test/stab.c +266 -0
- data/pgpool2/watchdog/test/test.c +85 -0
- data/pgpool2/watchdog/test/wd_child_t.c +87 -0
- data/pgpool2/watchdog/test/wd_lifecheck_t.c +87 -0
- data/pgpool2/watchdog/test/wd_packet_t.c +87 -0
- data/pgpool2/watchdog/test/wd_ping_t.c +20 -0
- data/pgpool2/watchdog/watchdog.c +408 -0
- data/pgpool2/watchdog/watchdog.h +209 -0
- data/pgpool2/watchdog/wd_child.c +444 -0
- data/pgpool2/watchdog/wd_ext.h +123 -0
- data/pgpool2/watchdog/wd_heartbeat.c +577 -0
- data/pgpool2/watchdog/wd_if.c +216 -0
- data/pgpool2/watchdog/wd_init.c +126 -0
- data/pgpool2/watchdog/wd_interlock.c +347 -0
- data/pgpool2/watchdog/wd_lifecheck.c +512 -0
- data/pgpool2/watchdog/wd_list.c +429 -0
- data/pgpool2/watchdog/wd_packet.c +1159 -0
- data/pgpool2/watchdog/wd_ping.c +330 -0
- data/pgpool2/ylwrap +223 -0
- data/pgsql/presto_client.py +346 -0
- data/pgsql/prestogres.py +156 -0
- data/pgsql/setup_functions.sql +21 -0
- data/pgsql/setup_language.sql +3 -0
- data/prestogres.gemspec +23 -0
- metadata +496 -0
|
@@ -0,0 +1,4118 @@
|
|
|
1
|
+
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
|
|
2
|
+
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
|
|
3
|
+
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="fr">
|
|
4
|
+
<head>
|
|
5
|
+
<title>Manuel de l'utilisateur pgpool-II</title>
|
|
6
|
+
<meta http-equiv="Content-Type" content="text/HTML; charset=utf-8" />
|
|
7
|
+
</head>
|
|
8
|
+
|
|
9
|
+
<!-- hhmts start -->
|
|
10
|
+
Last modified: Sun Jan 30 09:14:28 JST 2011
|
|
11
|
+
<!-- hhmts end -->
|
|
12
|
+
|
|
13
|
+
<body bgcolor="#ffffff">
|
|
14
|
+
<a name="top"></a>
|
|
15
|
+
<table border="0" cellpadding="2" cellspacing="1">
|
|
16
|
+
<tr>
|
|
17
|
+
<td colspan="2" valign="top"><div class="header_text">Bienvenue sur la page de pgpool-II</div></td>
|
|
18
|
+
</tr>
|
|
19
|
+
<tr>
|
|
20
|
+
<td valign="top" style="border-right:1px dotted #cccccc;">
|
|
21
|
+
<br />
|
|
22
|
+
|
|
23
|
+
<div id="navcontainer">
|
|
24
|
+
<ul id="navlist">
|
|
25
|
+
<li id="active"><a href="#Whatis" id="current">pgpool-II</a></li>
|
|
26
|
+
<li><a href="#platform">Plates-formes</a></li>
|
|
27
|
+
<li><a href="#install">Installation de pgpool-II</a></li>
|
|
28
|
+
<li><a href="#config">Configuration de pgpool-II</a></li>
|
|
29
|
+
<li><a href="#common">Configuration des options communes</a></li>
|
|
30
|
+
<li><a href="#connection_pool_mode">Mode pooling de connexions</a></li>
|
|
31
|
+
<li><a href="#replication_mode">Mode Réplication</a></li>
|
|
32
|
+
<li><a href="#master_slave_mode">Mode Maître-Esclave</a></li>
|
|
33
|
+
<li><a href="#start">Arrêter/Démarrer pgpool-II</a></li>
|
|
34
|
+
<li><a href="#reload">Recharger les fichiers de configuration de pgpool-II</a></li>
|
|
35
|
+
<li><a href="#show-commands">Commandes SHOW</a></li>
|
|
36
|
+
<li><a href="#online-recovery">Online recovery</a></li>
|
|
37
|
+
<li><a href="#troubleshooting">Que faire en cas d'erreur</a></li>
|
|
38
|
+
<li><a href="#restriction">Restrictions</a></li>
|
|
39
|
+
<li><a href="#reference">Références</a></li>
|
|
40
|
+
<li><a href="#internal">Fonctionnement interne</a></li>
|
|
41
|
+
</ul>
|
|
42
|
+
</div>
|
|
43
|
+
<br />
|
|
44
|
+
|
|
45
|
+
<div class="header_small" align="center">
|
|
46
|
+
|
|
47
|
+
[<a href="pgpool-ja.html">Page Japonaise</a>] </div> </td>
|
|
48
|
+
<td valign="top" style="border-left:1px dotted #cccccc;">
|
|
49
|
+
|
|
50
|
+
|
|
51
|
+
|
|
52
|
+
|
|
53
|
+
<h1>pgpool-II<a name="whatis"></a></h1>
|
|
54
|
+
|
|
55
|
+
<p>pgpool-II est un middleware qui se place entre les serveurs PostgreSQL
|
|
56
|
+
et les clients de ces derniers. Voici ses différentes fonctionalités:</p>
|
|
57
|
+
<p>
|
|
58
|
+
<ul>
|
|
59
|
+
|
|
60
|
+
<li>Pooling de connexions</li>
|
|
61
|
+
<p>pgpool-II maintient les connexions établies aux serveurs PostgreSQL
|
|
62
|
+
et les réutilise dès qu'une nouvelle connexion partageant les mêmes propriétés
|
|
63
|
+
(c'est-à-dire même utilisateur, même base de données et même version de
|
|
64
|
+
protocole) arrive. Il réduit ainsi le coût de la connexion et améliore
|
|
65
|
+
les performances générales du système.</p>
|
|
66
|
+
|
|
67
|
+
<li>Réplication</li>
|
|
68
|
+
<p>pgpool-II peut gérer plusieurs serveurs PostgreSQL. En activant le
|
|
69
|
+
mode réplication, il devient possible de créer une sauvegarde continue sur
|
|
70
|
+
d'autres instances PostgreSQL, afin que le service puisse continuer sans
|
|
71
|
+
interruption si l'une de ces instances était défaillante.</p>
|
|
72
|
+
|
|
73
|
+
<li>Répartition de charge</li>
|
|
74
|
+
<p>Si une base de données est répliquée, exécuter une requête en SELECT
|
|
75
|
+
sur n'importe lequel de ceux-ci retournera le même résultat. pgpool-II
|
|
76
|
+
profite ainsi avantageusement de la réplication pour réduire la charge
|
|
77
|
+
sur chacun des serveurs PostgreSQL. Il parvient à cela en distribuant
|
|
78
|
+
les requêtes SELECT entre tous les serveurs disponibles, ce qui qui
|
|
79
|
+
améliore les performances générales du système. Dans un scénario
|
|
80
|
+
idéal, les performances en lecture s'améliorent proportionnellement au
|
|
81
|
+
nombre de serveurs PostgreSQL. La répartition de charge avec pgpool-II
|
|
82
|
+
fonctionne au mieux dans un scénario où il y a beaucoup d'utilisateurs
|
|
83
|
+
qui exécutent beaucoup de requêtes en lecture au même moment.</p>
|
|
84
|
+
|
|
85
|
+
<li>Limitation des connexions excédentaires</li>
|
|
86
|
+
<p>Dans PostgreSQL, il y a une limite maximum du nombre de connexions
|
|
87
|
+
concurrentes au serveur (NDT: paramètre max_connections), et toutes les
|
|
88
|
+
nouvelles connexions sont rejettées une fois que ce nombre est atteint.
|
|
89
|
+
Augmenter ce nombre est possible mais accroît la consommation de
|
|
90
|
+
ressources par le serveur et a un impact négatif sur les performances
|
|
91
|
+
générales du système. Bien que pgpool-II ait aussi une limite sur le
|
|
92
|
+
nombre de connexions maximum, il va mettre toute connexion excédentaire
|
|
93
|
+
dans une file d'attente au lieu de retourner immédiatement une erreur.</p>
|
|
94
|
+
|
|
95
|
+
<li>Requêtes parallèlisées</li>
|
|
96
|
+
<p>En utilisant la fonctionalité des requêtes parallèlisées, les données
|
|
97
|
+
peuvent être réparties sur plusieurs serveurs afin que les requêtes
|
|
98
|
+
puissent être exécutées sur tous les serveurs à la fois, en réduisant
|
|
99
|
+
ainsi le temps d'exécution global de la requête. Cette fonctionalité
|
|
100
|
+
donne les meilleurs résultats lorsqu'on cherche à extraire un très grand ensemble de
|
|
101
|
+
données.</p>
|
|
102
|
+
|
|
103
|
+
</ul>
|
|
104
|
+
</p>
|
|
105
|
+
|
|
106
|
+
<p>
|
|
107
|
+
pgpool-II utilise le même protocole que le serveur et les clients
|
|
108
|
+
PostgreSQL, et relaie les messages entre les deux. Ainsi, une application
|
|
109
|
+
cliente va prendre pgpool-II pour le serveur, et ce dernier va voir
|
|
110
|
+
pgpool-II comme une application cliente. Puisque pgpool-II est
|
|
111
|
+
complètement transparent, il peut-être utilisé pour une application
|
|
112
|
+
sans pratiquement rien changer de son code source.</p>
|
|
113
|
+
|
|
114
|
+
<p>
|
|
115
|
+
<strong>Il y a cependant quelques restrictions à l'utilisation du SQL via
|
|
116
|
+
pgpool-II. Veuillez vous reporter à la section <a href="#restriction">Restrictions</a> pour
|
|
117
|
+
plus de détails.</strong>
|
|
118
|
+
</p>
|
|
119
|
+
|
|
120
|
+
<h1>Plates-formes supportées<a name="platform"></a></h1>
|
|
121
|
+
|
|
122
|
+
<p>pgpool-II fonctionne sous Linux, Solaris, FreeBSD et la
|
|
123
|
+
plupart des architectures UNIX. <b>Windows n'est pas supporté</b>.
|
|
124
|
+
Les versions 6.4 et ultérieures de PostgreSQL sont supportées.
|
|
125
|
+
Cependant, pour utiliser la fonctionalité de requêtage en
|
|
126
|
+
parallèle, vous devez avoir un serveur en version 7.4 ou
|
|
127
|
+
supérieure.</p>
|
|
128
|
+
|
|
129
|
+
<p>Si vous utilisez PostgreSQL en version 7.3 ou inférieure, certaines
|
|
130
|
+
fonctionnalités de pgpool-II ne seront pas disponibles. Cependant, vous
|
|
131
|
+
ne devriez pas utiliser une si vieille version de toute façons.</p>
|
|
132
|
+
|
|
133
|
+
<p>
|
|
134
|
+
Vous devez aussi être certain que vos serveurs PostgreSQL sont tous dans la même
|
|
135
|
+
version majeure. De plus, les architectures matérielles et logicielles (systèmes
|
|
136
|
+
d'exploitation) doivent-être identiques si vous voulez utiliser la technologie
|
|
137
|
+
« online recovery ».
|
|
138
|
+
</p>
|
|
139
|
+
|
|
140
|
+
<h1>Installation de pgpool-II<a name="install"></a></h1>
|
|
141
|
+
|
|
142
|
+
<p>
|
|
143
|
+
pgpool-II est téléchargeable sur la <a href="http://pgfoundry.org/projects/pgpool/">page de développement
|
|
144
|
+
de pgpool</a>. Plusieurs packages sont aussi fournis pour diverses plates-formes incluant
|
|
145
|
+
CentOS, RedHat Enterprise Linux, Fedora et Debian.
|
|
146
|
+
</p>
|
|
147
|
+
|
|
148
|
+
<p>
|
|
149
|
+
Le code source de pgpool-II est téléchargeable sur la <a href="http://pgfoundry.org/projects/pgpool/">page de développement de pgpool</a>.
|
|
150
|
+
</p>
|
|
151
|
+
|
|
152
|
+
<p>Pour installer pgpool-II depuis son code source, vous aurez besoin de gcc,
|
|
153
|
+
en version 2.9 ou supérieure, et de GNU make. pgpool-II utilisant la
|
|
154
|
+
bibliothèque libpq de PostgreSQL, celle-ci doit aussi être installée ainsi
|
|
155
|
+
que les fichiers d'en-tête sur la machine utilisée pour compiler
|
|
156
|
+
pgpool-II. Si vous souhaitez activer le support d'OpenSSL dans pgpool-II,
|
|
157
|
+
il vous faudra aussi avoir cette bibliothèque ainsi que les fichiers d'en-tête
|
|
158
|
+
relatifs installés sur la machine de compilation.</p>
|
|
159
|
+
|
|
160
|
+
<dl>
|
|
161
|
+
<dt>Configuration</dt>
|
|
162
|
+
<dd>
|
|
163
|
+
<p>
|
|
164
|
+
Après avoir extrait les sources depuis l'archive, exécutez le script de
|
|
165
|
+
configuration comme suit.
|
|
166
|
+
<pre>
|
|
167
|
+
./configure
|
|
168
|
+
</pre>
|
|
169
|
+
|
|
170
|
+
Plusieurs options de configuration ont des valeurs par défaut,
|
|
171
|
+
mais vous pouvez cependant les surcharger comme suit :
|
|
172
|
+
|
|
173
|
+
<ul>
|
|
174
|
+
<li><code>--prefix=path</code><br/>
|
|
175
|
+
Les binaires de pgpool-II ainsi que sa documentation seront
|
|
176
|
+
installés dans ce répertoire. La valeur par défaut est <code>/usr/local</code>.</li>
|
|
177
|
+
<li><code>--with-pgsql=path</code><br/>
|
|
178
|
+
Répertoire sous lequel les bibliothèques de PostgreSQL
|
|
179
|
+
sont installées. La valeur par défaut est fournie par
|
|
180
|
+
l'utilitaire <code>pg_config</code>.</li>
|
|
181
|
+
<li><code>--with-openssl</code><br/>
|
|
182
|
+
Avec cette option, les binaires de pgpool-II seront compilés
|
|
183
|
+
avec le support d'OpenSSL. Par défaut, le support d'OpenSSL
|
|
184
|
+
est désactivé.</li>
|
|
185
|
+
</ul>
|
|
186
|
+
</p>
|
|
187
|
+
</dd>
|
|
188
|
+
|
|
189
|
+
<dt>Compilation</dt>
|
|
190
|
+
<dd>
|
|
191
|
+
<p>
|
|
192
|
+
<pre>
|
|
193
|
+
make
|
|
194
|
+
make install
|
|
195
|
+
</pre>
|
|
196
|
+
Ces deux commandes suffisent pour compiler et installer pgpool-II. Si vous
|
|
197
|
+
utilisez Solaris ou FreeBSD, remplacez make par gmake.
|
|
198
|
+
</p>
|
|
199
|
+
</dd>
|
|
200
|
+
|
|
201
|
+
<dt>Installation de pgpool_regclass</dt>
|
|
202
|
+
<dd>
|
|
203
|
+
<p>
|
|
204
|
+
Si vous utilisez PostgreSQL 8.0 ou supérieur, l'installation des
|
|
205
|
+
fonctions pgpool_regclass, utiles à pgpool-II, est fortement
|
|
206
|
+
recommandée. Sans celles-ci, le support de tables homonymes mais
|
|
207
|
+
figurant dans des schémas différents pourrait ne pas fonctionner
|
|
208
|
+
correctement (pour les tables temporaires, il n'y a aucun
|
|
209
|
+
problème).
|
|
210
|
+
</p>
|
|
211
|
+
<p>
|
|
212
|
+
<pre>
|
|
213
|
+
cd pgpool-II-x.x.x/sql/pgpool-regclass
|
|
214
|
+
make
|
|
215
|
+
make install
|
|
216
|
+
psql -f pgpool-regclass.sql template1
|
|
217
|
+
</pre>
|
|
218
|
+
</p>
|
|
219
|
+
<p>
|
|
220
|
+
L'exécution du script pgpool-regclass.sql doit être faite sur toutes les
|
|
221
|
+
bases qui sont accédées via pgpool-II.
|
|
222
|
+
|
|
223
|
+
Vous n'avez pas besoin de le faire pour toutes les bases de données
|
|
224
|
+
créées après l'exécution des commandes ci-dessus car la base template1
|
|
225
|
+
est la base utilisée comme modèle par défaut pour les nouvelles bases
|
|
226
|
+
de données sous PostgreSQL.
|
|
227
|
+
</p>
|
|
228
|
+
|
|
229
|
+
<dt>Installation de pgpool_walrecrunning</dt>
|
|
230
|
+
<dd>
|
|
231
|
+
<p>
|
|
232
|
+
Si vous utilisez PostgreSQL 9.0 ou supérieur avec le « streaming replication »,
|
|
233
|
+
vous aurez besoin d'installer la fonction pgpool_walrecrunning sur tous les
|
|
234
|
+
serveurs PostgreSQL accedées par pgpool-II.
|
|
235
|
+
</p>
|
|
236
|
+
<p>
|
|
237
|
+
<pre>
|
|
238
|
+
cd pgpool-II-x.x.x/sql/pgpool-walrecrunning
|
|
239
|
+
make
|
|
240
|
+
make install
|
|
241
|
+
psql -f pgpool-walrecrunning.sql template1
|
|
242
|
+
</pre>
|
|
243
|
+
</p>
|
|
244
|
+
<p>
|
|
245
|
+
L'exécution du script pgpool-walrecrunning.sql doit-être faite sur
|
|
246
|
+
toutes les bases de données accedées par pgpool-II.
|
|
247
|
+
|
|
248
|
+
Comme précedemment, vous n'avez pas besoin de le faire pour toutes les bases de données
|
|
249
|
+
créées après l'exécution des commandes ci-dessus car la base template1
|
|
250
|
+
est la base utilisée comme modèle par défaut pour les nouvelles bases
|
|
251
|
+
de données sous PostgreSQL.
|
|
252
|
+
|
|
253
|
+
</p>
|
|
254
|
+
|
|
255
|
+
</dl>
|
|
256
|
+
|
|
257
|
+
<h1>Configuration de pgpool-II<a name="config"></a></h1>
|
|
258
|
+
|
|
259
|
+
<p>Les fichiers de configuration par défaut de pgpool-II sont
|
|
260
|
+
<code>/usr/local/etc/pgpool.conf</code> et
|
|
261
|
+
<code>/usr/local/etc/pcp.conf</code>. Plusieurs modes de fonctionnement
|
|
262
|
+
sont disponibles sous pgpool-II. Chaque mode a des fonctionnalités
|
|
263
|
+
associées qui peuvent être activées ou désactivées, mais aussi configurées
|
|
264
|
+
pour contrôler leur comportement.</p>
|
|
265
|
+
|
|
266
|
+
<table border>
|
|
267
|
+
|
|
268
|
+
<tr>
|
|
269
|
+
<th>Fonction/Mode</th>
|
|
270
|
+
<th>Raw Mode (*3)</th>
|
|
271
|
+
<th>Mode réplication</th>
|
|
272
|
+
<th>Mode maître/esclave</th>
|
|
273
|
+
<th>Mode de requêtage en parallèle</th>
|
|
274
|
+
</tr>
|
|
275
|
+
|
|
276
|
+
<tr>
|
|
277
|
+
<td>Pooling de connexions</td>
|
|
278
|
+
<td align="center">X</td>
|
|
279
|
+
<td align="center">O</td>
|
|
280
|
+
<td align="center">O</td>
|
|
281
|
+
<td align="center">O</td>
|
|
282
|
+
</tr>
|
|
283
|
+
|
|
284
|
+
<tr>
|
|
285
|
+
<td>Réplication</td>
|
|
286
|
+
<td align="center">X</td>
|
|
287
|
+
<td align="center">O</td>
|
|
288
|
+
<td align="center">X</td>
|
|
289
|
+
<td align="center">(*1)</td>
|
|
290
|
+
</tr>
|
|
291
|
+
|
|
292
|
+
<tr>
|
|
293
|
+
<td>Répartition de charge</td>
|
|
294
|
+
<td align="center">X</td>
|
|
295
|
+
<td align="center">O</td>
|
|
296
|
+
<td align="center">O</td>
|
|
297
|
+
<td align="center">(*1)</td>
|
|
298
|
+
</tr>
|
|
299
|
+
|
|
300
|
+
<tr>
|
|
301
|
+
<td>Failover</td>
|
|
302
|
+
<td align="center">O</td>
|
|
303
|
+
<td align="center">O</td>
|
|
304
|
+
<td align="center">O</td>
|
|
305
|
+
<td align="center">X</td>
|
|
306
|
+
</tr>
|
|
307
|
+
|
|
308
|
+
<tr>
|
|
309
|
+
<td>Online recovery</td>
|
|
310
|
+
<td align="center">X</td>
|
|
311
|
+
<td align="center">0</td>
|
|
312
|
+
<td align="center">(*2)</td>
|
|
313
|
+
<td align="center">X</td>
|
|
314
|
+
</tr>
|
|
315
|
+
|
|
316
|
+
<tr>
|
|
317
|
+
<td>Requêtage en parallèle</td>
|
|
318
|
+
<td align="center">X</td>
|
|
319
|
+
<td align="center">X</td>
|
|
320
|
+
<td align="center">X</td>
|
|
321
|
+
<td align="center">O</td>
|
|
322
|
+
</tr>
|
|
323
|
+
|
|
324
|
+
<tr>
|
|
325
|
+
<td>Nombre de serveurs requis</td>
|
|
326
|
+
<td align="center">1 ou plus</td>
|
|
327
|
+
<td align="center">2 ou plus</td>
|
|
328
|
+
<td align="center">2 ou plus</td>
|
|
329
|
+
<td align="center">2 ou plus</td>
|
|
330
|
+
</tr>
|
|
331
|
+
|
|
332
|
+
<tr>
|
|
333
|
+
<td>Base de donnée système requise?</td>
|
|
334
|
+
<td align="center">non</td>
|
|
335
|
+
<td align="center">non</td>
|
|
336
|
+
<td align="center">non</td>
|
|
337
|
+
<td align="center">oui</td>
|
|
338
|
+
</tr>
|
|
339
|
+
|
|
340
|
+
</table>
|
|
341
|
+
|
|
342
|
+
<p>
|
|
343
|
+
<ul>
|
|
344
|
+
<li>0 signifie 'disponible' et X 'indisponible'
|
|
345
|
+
<li>(*1) Le mode de requêtage en parallèle nécessite que la réplication et la
|
|
346
|
+
répartition de charge soient activés, cependant la réplication et la
|
|
347
|
+
répartition de charge ne peuvent pas être utilisés pour les tables distribuées en
|
|
348
|
+
mode de requêtage parallèlisé.
|
|
349
|
+
<li>(*2) Le online recovery peut-être utilisé en mode maître/esclave avec
|
|
350
|
+
la « Streaming Replication ».
|
|
351
|
+
<li>(*3) Les clients se connectent simplement aux serveurs PostgreSQL via
|
|
352
|
+
pgpool-II. Ce mode est utile pour limiter simplement les connexions
|
|
353
|
+
excédentaires aux serveurs, ou activer le failover avec de multiples
|
|
354
|
+
serveurs.
|
|
355
|
+
</ul>
|
|
356
|
+
</p>
|
|
357
|
+
|
|
358
|
+
<h2>Configuration de <code>pcp.conf</code></h2>
|
|
359
|
+
|
|
360
|
+
<p>Une interface de contrôle est fournie avec pgpool-II et permet à
|
|
361
|
+
l'administrateur de vérifier l'état de pgpool-II et d'arrêter les processus
|
|
362
|
+
de pgpool-II à distance. <code>pcp.conf</code> est le fichier contenant
|
|
363
|
+
la définition des utilisateurs et de leurs mots de passe pour accéder
|
|
364
|
+
à cette interface. Tous les modes d'utilisation de pgpool-II nécessitent
|
|
365
|
+
que le fichier <code>pcp.conf</code> soit renseigné. Un fichier d'exemple
|
|
366
|
+
<code>$prefix/etc/pcp.conf.sample</code> est créé lors de l'installation
|
|
367
|
+
de pgpool-II. Renommez ce fichier en <code>pcp.conf</code>, ajoutez-y votre
|
|
368
|
+
nom d'utilisateur ainsi que votre mot de passe.
|
|
369
|
+
</p>
|
|
370
|
+
|
|
371
|
+
<pre>
|
|
372
|
+
cp $prefix/etc/pcp.conf.sample $prefix/etc/pcp.conf
|
|
373
|
+
</pre>
|
|
374
|
+
<p>
|
|
375
|
+
Une ligne vide ou commençant par un dièse (<code>#</code>) est traitée comme un
|
|
376
|
+
commentaire et sera ignorée. Un nom d'utilisateur et son mot de passe
|
|
377
|
+
doivent être écrits sur une seule ligne et respecter le format suivant :
|
|
378
|
+
</p>
|
|
379
|
+
<pre>
|
|
380
|
+
nom_d_utilisateur:[mot de passe crypté en md5]
|
|
381
|
+
</pre>
|
|
382
|
+
<p>
|
|
383
|
+
Le <code>[mot de passe crypté en md5]</code> peut être obtenu avec la
|
|
384
|
+
commande <code>$prefix/bin/pg_md5</code>.
|
|
385
|
+
</p>
|
|
386
|
+
|
|
387
|
+
<pre>
|
|
388
|
+
pg_md5 -p
|
|
389
|
+
password: <votre mot de passe>
|
|
390
|
+
</pre>
|
|
391
|
+
<p>
|
|
392
|
+
ou
|
|
393
|
+
</p>
|
|
394
|
+
<pre>
|
|
395
|
+
./pg_md5 foo
|
|
396
|
+
acbd18db4cc2f85cedef654fccc4a4d8
|
|
397
|
+
</pre>
|
|
398
|
+
<p>
|
|
399
|
+
Le fichier <code>pcp.conf</code> doit être lisible par l'utilisateur qui
|
|
400
|
+
exécute pgpool-II.</p>
|
|
401
|
+
|
|
402
|
+
<h2>Configuration de <code>pgpool.conf</code></h2>
|
|
403
|
+
|
|
404
|
+
<p>Comme cela a déjà été expliqué, chaque mode de pgpool-II a ses propres
|
|
405
|
+
paramètres de configuration dans le fichier <code>pgpool.conf</code>. Un fichier
|
|
406
|
+
d'exemple <code>$prefix/etc/pgpool.conf.sample</code> est créé lors de
|
|
407
|
+
l'installation de pgpool-II. Renommez ce fichier en <code>pgpool.conf</code>
|
|
408
|
+
et éditez son contenu.
|
|
409
|
+
|
|
410
|
+
<pre>
|
|
411
|
+
cp $prefix/etc/pgpool.conf.sample $prefix/etc/pgpool.conf
|
|
412
|
+
</pre>
|
|
413
|
+
<p>
|
|
414
|
+
Toute ligne vide ou commençant par "#" sera traitée comme un commentaire et sera
|
|
415
|
+
donc ignorée.</p>
|
|
416
|
+
</p>
|
|
417
|
+
<h3><a name="common"></a>Paramètres communs</h3>
|
|
418
|
+
|
|
419
|
+
<dl>
|
|
420
|
+
<dt>listen_addresses</dt>
|
|
421
|
+
<dd>
|
|
422
|
+
<p>Spécifie le nom de la machine ou son adresse IP, sur laquelle
|
|
423
|
+
pgpool-II acceptera les connexions TCP/IP. <code>'*'</code> accepte
|
|
424
|
+
toutes les connexions. <code>''</code> empêchera toute connexion
|
|
425
|
+
TCP/IP. La valeur par défaut est <code>'localhost'</code>. Les connexions
|
|
426
|
+
via les sockets UNIX sont toujours acceptées. Ce paramètre ne peut être
|
|
427
|
+
modifié qu'au démarrage du serveur.
|
|
428
|
+
</dd>
|
|
429
|
+
|
|
430
|
+
<dt>port</dt>
|
|
431
|
+
<dd>
|
|
432
|
+
<p>Spécifie le numéro de port sur lequel pgpool-II écoute les
|
|
433
|
+
connexions. La valeur par défaut est <code>9999</code>. Ce paramètre
|
|
434
|
+
ne peut être modifié qu'au démarrage du serveur.
|
|
435
|
+
</dd>
|
|
436
|
+
|
|
437
|
+
<dt>socket_dir</dt>
|
|
438
|
+
<dd>
|
|
439
|
+
<p>Répertoire dans lequel sera créé le socket UNIX de pgpool-II
|
|
440
|
+
pour les connexions entrantes. La valeur par défaut est
|
|
441
|
+
<code>'/tmp'</code>. Faites attention au fait que ce socket
|
|
442
|
+
pourrait être effacé par une tâche programmée en <code>cron</code>.
|
|
443
|
+
Aussi, nous vous recommandons de configurer cette valeur à
|
|
444
|
+
<code>'/var/run'</code> ou un répertoire de ce type. Ce paramètre ne
|
|
445
|
+
peut être modifié qu'au démarrage du serveur.</p>
|
|
446
|
+
</dd>
|
|
447
|
+
|
|
448
|
+
<dt>pcp_port</dt>
|
|
449
|
+
<dd>
|
|
450
|
+
<p>Numéro de port sur lequel le processus PCP accepte les connexions.
|
|
451
|
+
La valeur par défaut est <code>9898</code>. Ce paramètre ne peut être
|
|
452
|
+
modifié qu'au démarrage du serveur.</p>
|
|
453
|
+
</dd>
|
|
454
|
+
|
|
455
|
+
<dt>pcp_socket_dir</dt>
|
|
456
|
+
<dd>
|
|
457
|
+
<p>Chemin du répertoire UNIX où le socket UNIX acceptant les connexions
|
|
458
|
+
pour les commandes PCP est créé. La valeur par défaut est
|
|
459
|
+
<code>'/tmp'</code>. Faites attention au fait que cet socket
|
|
460
|
+
pourrait être effacé par une tâche programmée en <code>cron</code>.
|
|
461
|
+
Aussi, nous vous recommandons de configurer cette valeur à
|
|
462
|
+
<code>'/var/run'</code> ou un répertoire de ce type. Ce paramètre ne
|
|
463
|
+
peut être modifié qu'au démarrage du serveur.</p>
|
|
464
|
+
</dd>
|
|
465
|
+
|
|
466
|
+
<dt>backend_socket_dir</dt>
|
|
467
|
+
<dd>
|
|
468
|
+
<p><font color="red"><em>À NE PLUS UTILISER</em>
|
|
469
|
+
Ce paramètre n'est présent que pour garantir la cohérence avec la
|
|
470
|
+
politique par défaut de la bibliothèque libpq. Reportez-vous à la définition du
|
|
471
|
+
paramètre <code>backend_hostname</code> pour adapter votre configuration.
|
|
472
|
+
</font></p>
|
|
473
|
+
<p>Ce paramètre permettait de définir le répertoire UNIX servant au
|
|
474
|
+
serveur PostgreSQL.</p>
|
|
475
|
+
</dd>
|
|
476
|
+
|
|
477
|
+
<dt>pcp_timeout</dt>
|
|
478
|
+
<dd>
|
|
479
|
+
<p>Délai maximum en secondes pour l'établissement d'une connexion PCP.
|
|
480
|
+
Si un client ne répond plus
|
|
481
|
+
au bout de cette valeur en secondes, le processus PCP ferme la connexion
|
|
482
|
+
avec le client. La valeur par défaut est de 10 secondes. 0 signifie que la
|
|
483
|
+
vérification du délai est désactivée. Ce paramètre est pris en compte lors
|
|
484
|
+
du rechargement des fichiers de configuration.</p>
|
|
485
|
+
</dd>
|
|
486
|
+
|
|
487
|
+
<dt>num_init_children</dt>
|
|
488
|
+
<dd>
|
|
489
|
+
<p>Nombre de processus pré-forkés de pgpool-II. La valeur par défaut
|
|
490
|
+
est de 32. <code>num_init_children</code> est aussi la limite du nombre
|
|
491
|
+
de connexions clientes concurrentes à pgpool-II. Si plus de
|
|
492
|
+
<code>num_init_children</code> clients essaient de se connecter à
|
|
493
|
+
pgpool-II, ceux-ci sont bloqués (mais pas rejettés), jusqu'à ce qu'une
|
|
494
|
+
connexion à l'un des processus de pgpool-II soit fermé. On peut avoir
|
|
495
|
+
ansi jusqu'à <b>deux fois <code>num_init_children</code></b> clients
|
|
496
|
+
dans la queue de connexion.
|
|
497
|
+
<p>Quelques précisions et astuces :</p>
|
|
498
|
+
<p>
|
|
499
|
+
<ul>
|
|
500
|
+
<li>L'annulation d'une requête crée une autre connexion au
|
|
501
|
+
processus serveur PostgreSQL ; ainsi, une requête ne
|
|
502
|
+
peut pas être annulée si toutes les
|
|
503
|
+
connexions sont utilisées. Si vous voulez vous assurer que les
|
|
504
|
+
requêtes puissent être annulées, positionnez cette valeur au
|
|
505
|
+
double des connexions attendues.</li>
|
|
506
|
+
|
|
507
|
+
<li>PostgreSQL permet un certain nombre de connexions pour les
|
|
508
|
+
utilisateurs qui ne sont pas superutilisateurs. On le calcule
|
|
509
|
+
ainsi :<code>max_connections - superuser_reserved_connections</code></li>
|
|
510
|
+
</ul>
|
|
511
|
+
</p>
|
|
512
|
+
<p>Pour résumer, <code>max_pool</code>,<code>num_init_children</code>,
|
|
513
|
+
<code>max_connections</code> et
|
|
514
|
+
<code>superuser_reserved_connections</code> doivent satisfaire
|
|
515
|
+
la formule suivante :
|
|
516
|
+
</p>
|
|
517
|
+
<ul>
|
|
518
|
+
<li>Si on n'a pas besoin de l'annulation de requêtes :
|
|
519
|
+
<pre>max_pool*num_init_children <= (max_connections - superuser_reserved_connections)</pre></li>
|
|
520
|
+
<li>Si on a besoin de l'annulation de requêtes :
|
|
521
|
+
<pre>max_pool*num_init_children*2 <= (max_connections - superuser_reserved_connections)</pre>
|
|
522
|
+
</li>
|
|
523
|
+
</ul>
|
|
524
|
+
Ce paramètre ne peut être modifié qu'au démarrage du serveur.</p>
|
|
525
|
+
</dd>
|
|
526
|
+
|
|
527
|
+
<dt>child_life_time</dt>
|
|
528
|
+
<dd>
|
|
529
|
+
<p>Durée de vie en secondes d'un processus fils de pgpool-II. Lorsqu'un
|
|
530
|
+
processus fils est sans activité depuis ce nombre de secondes, il se
|
|
531
|
+
termine et un nouveau processus fils est créé. Ce paramètre est une
|
|
532
|
+
mesure pour prévenir tout problème de mémoire et autres erreurs
|
|
533
|
+
inattendues. La valeur par défaut est 300 (5 minutes). Cette
|
|
534
|
+
fonctionalité est désactivée si cette option a une valeur de 0. Notez
|
|
535
|
+
que cela ne s'applique qu'aux processus qui n'ont
|
|
536
|
+
pas encore été utilisés ou qui n'ont pas encore accepté de connexions.
|
|
537
|
+
Vous devez recharger le fichier de configuration <code>pgpool.conf</code>
|
|
538
|
+
si vous changez cette valeur.
|
|
539
|
+
</p>
|
|
540
|
+
</dd>
|
|
541
|
+
|
|
542
|
+
<dt>child_max_connections</dt>
|
|
543
|
+
<dd>
|
|
544
|
+
<p>Un processus fils de pgpool-II sera terminé après avoir accepté ce
|
|
545
|
+
nombre de connexions clientes. Ce paramètre est
|
|
546
|
+
utile sur un serveur à ce point chargé que ni
|
|
547
|
+
<code>child_life_time</code>, ni <code>connection_life_time</code>
|
|
548
|
+
ne sont déclenchés. Vous devez recharger pgpool-II si vous
|
|
549
|
+
changez cette valeur.
|
|
550
|
+
</p>
|
|
551
|
+
</dd>
|
|
552
|
+
|
|
553
|
+
<dt>client_idle_limit
|
|
554
|
+
<dd>
|
|
555
|
+
<p>Déconnecte un client s'il est resté inactif pendant ce nombre de secondes
|
|
556
|
+
après que la dernière requête ne se soit terminée. Ceci est utile pour
|
|
557
|
+
empêcher qu'un processus fils de pgpool-II ne soit occupé par un
|
|
558
|
+
client inactif ou une connexion TCP/IP rompue entre le client et
|
|
559
|
+
pgpool-II. La valeur par défaut de <code>client_idle_limit</code> est
|
|
560
|
+
de 0, ce qui signifie que cette fonctionalité est désactivée. Ce paramètre
|
|
561
|
+
est ignoré dans la seconde phase d'un online recovery. Vous aurez besoin
|
|
562
|
+
de recharger pgpool-II si vous modifiez <code>client_idle_limit</code>.</p>
|
|
563
|
+
|
|
564
|
+
<dt>authentication_timeout
|
|
565
|
+
<dd>
|
|
566
|
+
<p>Spécifie le délai maximum en secondes pour terminer une authentification. 0 désactive
|
|
567
|
+
cette fonctionnalité. Vous aurez besoin de redémarrer pgpool-II si vous changez cette
|
|
568
|
+
valeur.</p>
|
|
569
|
+
|
|
570
|
+
<dt>logdir</dt>
|
|
571
|
+
<dd>
|
|
572
|
+
<p>Répertoire utilisé pour les logs. <code>pgpool_status</code>
|
|
573
|
+
est écrit dans ce répertoire.</p>
|
|
574
|
+
</p>
|
|
575
|
+
</dd>
|
|
576
|
+
<dt>log_destination</dt>
|
|
577
|
+
<dd>
|
|
578
|
+
<p>pgpool-II utilise plusieurs méthodes pour écrire les messages du
|
|
579
|
+
serveur. Cela inclut stderr et syslog. La valeur par défaut est
|
|
580
|
+
d'envoyer les messages à stderr.</p>
|
|
581
|
+
<p>Note: vous aurez besoin de modifier la configuration du serveur
|
|
582
|
+
syslog de votre système pour que l'écriture des messages vers
|
|
583
|
+
syslog fonctionne. pgpool-II peut envoyer les traces à syslog en
|
|
584
|
+
utilisant les niveaux LOCAL0 à
|
|
585
|
+
LOCAL7 (voir la documentation de syslog), mais la valeur par
|
|
586
|
+
défaut de syslog sur la plupart des plates-formes ignorera de
|
|
587
|
+
tels messages. Vous aurez donc besoin d'ajouter quelque-chose
|
|
588
|
+
comme
|
|
589
|
+
</p>
|
|
590
|
+
<pre>
|
|
591
|
+
local0.* /var/log/pgpool.log
|
|
592
|
+
</pre>
|
|
593
|
+
<p>au fichier de configuration de votre démon syslog pour le faire
|
|
594
|
+
fonctionner.
|
|
595
|
+
</p>
|
|
596
|
+
</dd>
|
|
597
|
+
|
|
598
|
+
<dt>syslog_facility</dt>
|
|
599
|
+
<dd>
|
|
600
|
+
<p>Lorsque la sortie des messages vers syslog est configurée, ce paramètre
|
|
601
|
+
détermine le niveau syslog à utiliser. Vous pouvez choisir
|
|
602
|
+
toute valeur entre LOCAL0 et LOCAL7. La valeur par défaut est LOCAL0.
|
|
603
|
+
Veillez à vous reporter à la documentation système au sujet de syslog.
|
|
604
|
+
</p>
|
|
605
|
+
</dd>
|
|
606
|
+
|
|
607
|
+
<dt>syslog_ident</dt>
|
|
608
|
+
<dd>
|
|
609
|
+
<p>Lorsque la sortie vers syslog est configurée, ce paramètre permet de
|
|
610
|
+
déterminer le nom du programme utilisé pour identifier les messages
|
|
611
|
+
de pgpool-II dans les traces enregistrées par syslog. La valeur par défaut est pgpool.
|
|
612
|
+
</p>
|
|
613
|
+
</dd>
|
|
614
|
+
|
|
615
|
+
<dt>pid_file_name</dt>
|
|
616
|
+
<dd>
|
|
617
|
+
<p>Chemin complet vers le fichier qui contient le numéro
|
|
618
|
+
d'identifiant du processus pgpool. La valeur par défaut
|
|
619
|
+
est "/var/run/pgpool/pgpool.pid".
|
|
620
|
+
Vous aurez besoin de redémarrer pgpool-II pour changer
|
|
621
|
+
cette valeur.
|
|
622
|
+
</p>
|
|
623
|
+
</dd>
|
|
624
|
+
|
|
625
|
+
<dt>print_timestamp</dt>
|
|
626
|
+
<dd>
|
|
627
|
+
<p>Ajoute un horodatage dans les traces lorsque cette valeur
|
|
628
|
+
est à true. La valeur par défaut est true. Vous aurez
|
|
629
|
+
besoin de recharger pgpool-II si vous changez cette valeur
|
|
630
|
+
afin qu'elle soit prise en compte.
|
|
631
|
+
</p>
|
|
632
|
+
</dd>
|
|
633
|
+
|
|
634
|
+
<dt>connection_cache</dt>
|
|
635
|
+
<dd>
|
|
636
|
+
<p>Cache les connexions à PostgreSQL lorsque
|
|
637
|
+
cette valeur est configurée à true. La valeur par défaut
|
|
638
|
+
est true.</p>
|
|
639
|
+
</dd>
|
|
640
|
+
|
|
641
|
+
<dt>health_check_timeout</dt>
|
|
642
|
+
<dd>
|
|
643
|
+
<p>pgpool-II essaie périodiquement de se connecter à PostgreSQL
|
|
644
|
+
afin de détecter toute erreur sur les serveurs
|
|
645
|
+
ou sur le réseau. Cette procédure de vérification d'erreurs
|
|
646
|
+
est appelée « health check ». Si une erreur est détectée,
|
|
647
|
+
pgpool-II essaie d'exécuter un failover ou une dégénération.
|
|
648
|
+
|
|
649
|
+
Ce paramètre permet d'empêcher qu'un "health check" n'attende
|
|
650
|
+
trop longtemps dans les cas où un câble réseau est débranché
|
|
651
|
+
par exemple. La valeur du paramètre est en secondes. La valeur
|
|
652
|
+
par défaut est de 20 secondes. 0 désactive cette fonctionnalité
|
|
653
|
+
(dans ce cas, pgpool-II attend jusqu'à la fin du délai maximum
|
|
654
|
+
configuré au niveau TCP/IP).
|
|
655
|
+
|
|
656
|
+
Cette vérification nécessite une connexion supplémentaire à
|
|
657
|
+
chacun des serveurs PostgreSQL. Du coup, il faut le prendre en
|
|
658
|
+
compte dans la configuration du paramètre <code>max_connections</code>
|
|
659
|
+
de chaque serveur PostgreSQL.
|
|
660
|
+
|
|
661
|
+
Vous aurez besoin de recharger pgpool-II après toute modification
|
|
662
|
+
de ce paramètre.
|
|
663
|
+
</p>
|
|
664
|
+
</dd>
|
|
665
|
+
|
|
666
|
+
<dt>health_check_period</dt>
|
|
667
|
+
<dd>
|
|
668
|
+
<p>Ce paramètre précise l'intervalle de temps entre deux
|
|
669
|
+
vérifications en secondes. La valeur par défaut est de 0,
|
|
670
|
+
ce qui a pour effet de désactiver la vérification.
|
|
671
|
+
Vous aurez besoin de recharger pgpool-II après tout changement
|
|
672
|
+
de ce paramétrage.
|
|
673
|
+
</p>
|
|
674
|
+
</dd>
|
|
675
|
+
|
|
676
|
+
<dt>health_check_user</dt>
|
|
677
|
+
<dd>
|
|
678
|
+
<p>Nom de l'utilisateur PostgreSQL utilisé pour
|
|
679
|
+
exécuter la vérification. Cet utilisateur doit exister
|
|
680
|
+
dans tous les serveurs PostgreSQL. Vous aurez besoin de
|
|
681
|
+
recharger pgpool-II après tout changement de la valeur de
|
|
682
|
+
ce paramètre.
|
|
683
|
+
</p>
|
|
684
|
+
</dd>
|
|
685
|
+
|
|
686
|
+
<dt>failover_command
|
|
687
|
+
<dd>
|
|
688
|
+
<p>
|
|
689
|
+
Ce paramètre spécifie la commande à exécuter lorsqu'un nœud est détaché.
|
|
690
|
+
pgpool-II remplace les caractères spéciaux suivants avec les informations
|
|
691
|
+
associées.
|
|
692
|
+
</p>
|
|
693
|
+
|
|
694
|
+
<blockquote>
|
|
695
|
+
<table border>
|
|
696
|
+
<tr><td>Caractère spécial</td><td>Description</td></tr>
|
|
697
|
+
<tr><td>%d</td><td>ID du processus serveur correspondant au nœud détaché</td></tr>
|
|
698
|
+
<tr><td>%h</td><td>Nom d'hôte du nœud détaché</td></tr>
|
|
699
|
+
<tr><td>%p</td><td>Numéro de port du nœud détaché</td></tr>
|
|
700
|
+
<tr><td>%D</td><td>Répertoire de l'instance PostgreSQL du nœud détaché</td></tr>
|
|
701
|
+
<tr><td>%M</td><td>ID du nœud de l'ancien maître</td></tr>
|
|
702
|
+
<tr><td>%m</td><td>ID du nœud du nouveau maître</td></tr>
|
|
703
|
+
<tr><td>%H</td><td>Nom d'hôte du nouveau nœud maître</td></tr>
|
|
704
|
+
<tr><td>%P</td><td>ID de l'ancien nœud primaire</td></tr>
|
|
705
|
+
<tr><td>%%</td><td>Caractère '%'</td></tr>
|
|
706
|
+
</table>
|
|
707
|
+
</blockquote>
|
|
708
|
+
<p>
|
|
709
|
+
Vous devez recharger pgpool.conf si vous changez la valeur de
|
|
710
|
+
<code>failover_command</code>.
|
|
711
|
+
</p>
|
|
712
|
+
|
|
713
|
+
<p>
|
|
714
|
+
Lorsqu'une commande failover est exécutée, pgpool tue tous ses processus fils,
|
|
715
|
+
ce qui fermera toutes les sessions actives à pgpool. Alors, pgpool invoque la
|
|
716
|
+
commande <code>failover_command</code> et attend son exécution complète. Après
|
|
717
|
+
cela, pgpool démarre de nouveaux processus fils et est alors à nouveau
|
|
718
|
+
disponible pour accepter des connexions depuis les clients.
|
|
719
|
+
</p>
|
|
720
|
+
|
|
721
|
+
<dt>failback_command
|
|
722
|
+
<dd>
|
|
723
|
+
<p>
|
|
724
|
+
Ce paramètre contient une commande à exécuter lors qu'un nœud est attaché.
|
|
725
|
+
pgpool-II remplace les caractères spéciaux suivants avec les informations
|
|
726
|
+
associées.
|
|
727
|
+
</p>
|
|
728
|
+
<blockquote>
|
|
729
|
+
<table border>
|
|
730
|
+
<tr><td>Caractère spécial</td><td>Description</td></tr>
|
|
731
|
+
<tr><td>%d</td><td>ID du processus serveur d'un nœud attaché</td></tr>
|
|
732
|
+
<tr><td>%h</td><td>Nom d'hôte d'un nœud attaché</td></tr>
|
|
733
|
+
<tr><td>%p</td><td>Numéro de port d'un nœud attaché</td></tr>
|
|
734
|
+
<tr><td>%D</td><td>Répertoire de l'instance PostgreSQL d'un nœud attaché</td></tr>
|
|
735
|
+
<tr><td>%M</td><td>Ancien nœud maître</td></tr>
|
|
736
|
+
<tr><td>%m</td><td>Nouveau nœud maître</td></tr>
|
|
737
|
+
<tr><td>%H</td><td>Nom d'hôte du nouveau nœud maître</td></tr>
|
|
738
|
+
<tr><td>%P</td><td>ID de l'ancien nœud primaire</td></tr>
|
|
739
|
+
<tr><td>%%</td><td>Caractère '%'</td></tr>
|
|
740
|
+
</table>
|
|
741
|
+
</blockquote>
|
|
742
|
+
<p>
|
|
743
|
+
Vous devez recharger pgpool.conf si vous changez le contenu de la
|
|
744
|
+
commande <code>failback_command</code>.
|
|
745
|
+
</p>
|
|
746
|
+
|
|
747
|
+
<dt>fail_over_on_backend_error</dt>
|
|
748
|
+
<dd>
|
|
749
|
+
<p>
|
|
750
|
+
Si ce paramètre est à true et qu'une erreur apparaît lors d'une écriture sur le
|
|
751
|
+
canal de communication d'un processus serveur, pgpool-II déclenchera une procédure de
|
|
752
|
+
failover. C'est le même comportement qu'avec les versions 2.2.x ou précédentes
|
|
753
|
+
de pgpool-II. Si ce paramètre est à false, pgpool reportera une erreur dans ses
|
|
754
|
+
fichiers de traces et déconnectera la session.
|
|
755
|
+
Notez cependant que si ce paramètre est activé, pgpool effectuera aussi un
|
|
756
|
+
failover lorsque la connexion à un processus serveur échoue ou lorsqu'il détecte l'arrêt
|
|
757
|
+
du serveur PostgreSQL par un administrateur. Vous devez recharger pgpool.conf si vous
|
|
758
|
+
changez cette valeur.
|
|
759
|
+
</p>
|
|
760
|
+
</dd>
|
|
761
|
+
|
|
762
|
+
<dt>ignore_leading_white_space</dt>
|
|
763
|
+
<dd>
|
|
764
|
+
<p>Si ce paramètre est activé, pgpool-II ignorera les espaces en début
|
|
765
|
+
de requête SQL lorsqu'il
|
|
766
|
+
est dans le mode de répartition de charge. C'est
|
|
767
|
+
particulièrement intéressant lorsqu'il est utilisé avec des API
|
|
768
|
+
comme DBI/DBD::Pg qui ajoutent des espaces sans que l'utilisateur
|
|
769
|
+
le demande. Vous aurez besoin de demander à pgpool-II de recharger
|
|
770
|
+
sa configuration pour que ce paramètre soit pris en compte.
|
|
771
|
+
</p>
|
|
772
|
+
</dd>
|
|
773
|
+
|
|
774
|
+
<dt>log_statement</dt>
|
|
775
|
+
<dd>
|
|
776
|
+
<p>Lorsque ce paramètre est activé, pgpool-II tracera les
|
|
777
|
+
requêtes SQL qu'il reçoit dans son fichier de traces. Cela va
|
|
778
|
+
produire des traces même si l'option debug n'est pas passée
|
|
779
|
+
à pgpool-II au démarrage. Vous aurez besoin de recharger
|
|
780
|
+
pgpool.conf pour que ce paramètre soit pris en compte.
|
|
781
|
+
</p>
|
|
782
|
+
</dd>
|
|
783
|
+
|
|
784
|
+
<dt>log_per_node_statement</dt>
|
|
785
|
+
<dd>
|
|
786
|
+
<p>Similaire à log_statement, à l'exception qu'il écrit les traces
|
|
787
|
+
de manière séparée par nœud. Cela peut se révéler très utile si vous
|
|
788
|
+
voulez vous assurer, par exemple, que votre réplication fonctionne.
|
|
789
|
+
Vous aurez besoin de recharger pgpool.conf pour que ce paramètre
|
|
790
|
+
soit pris en compte.
|
|
791
|
+
</p>
|
|
792
|
+
</dd>
|
|
793
|
+
|
|
794
|
+
<dt>log_hostname</dt>
|
|
795
|
+
<dd>
|
|
796
|
+
<p>
|
|
797
|
+
Si ce paramètre est positionné à true, le nom de la commande affichée
|
|
798
|
+
dans la sortie de ps sera le nom de l'hôte plutôt que son IP. De même, si
|
|
799
|
+
log_connections est activé, le nom de l'hôte sera écrit dans les fichiers
|
|
800
|
+
de trace plutôt que son IP. Ce paramètre est pris en compte au
|
|
801
|
+
rechargement de pgpool.conf.
|
|
802
|
+
</p>
|
|
803
|
+
</dd>
|
|
804
|
+
|
|
805
|
+
<dt>log_connections</dt>
|
|
806
|
+
<dd>
|
|
807
|
+
<p>
|
|
808
|
+
Si ce paramètre est à true, toutes les connexions entrantes seront
|
|
809
|
+
tracées dans les journaux applicatifs. Ce paramètre est pris en compte
|
|
810
|
+
au rechargement de pgpool.conf.
|
|
811
|
+
</p>
|
|
812
|
+
</dd>
|
|
813
|
+
|
|
814
|
+
<dt>enable_pool_hba</dt>
|
|
815
|
+
<dd>
|
|
816
|
+
<p>
|
|
817
|
+
Si ce paramètre est à vrai, on utilisera le fichier pool_hba.conf pour
|
|
818
|
+
l'authentification des clients. Voir la <a href="#hba">configuration
|
|
819
|
+
de pool_hba.conf pour l'authentification des clients</a>. Ce paramètre
|
|
820
|
+
est pris en compte au rechargement de pgpool-II.
|
|
821
|
+
</p>
|
|
822
|
+
</dd>
|
|
823
|
+
|
|
824
|
+
<dt>backend_hostname</dt>
|
|
825
|
+
<dd>
|
|
826
|
+
<p>Permet de spécifier à quel serveur PostgreSQL on se connecte.
|
|
827
|
+
C'est utilisé par pgpool-II pour communiquer avec le serveur.
|
|
828
|
+
Ce paramètre n'est lu qu'au démarrage du serveur pgpool-II.
|
|
829
|
+
</p>
|
|
830
|
+
<p>
|
|
831
|
+
Pour les communications TCP/IP, ce paramètre accepte soit un nom
|
|
832
|
+
d'hôte, soit une adresse IP. Si ce dernier commence avec un slash,
|
|
833
|
+
il spécifie un socket Unix plutôt qu'une adresse IP ; la valeur est
|
|
834
|
+
alors le nom du répertoire dans lequel le fichier de socket UNIX est
|
|
835
|
+
stocké. Si ce paramètre est vide (<code>''</code>), le comportement par
|
|
836
|
+
défaut de pgpool-II est de se connecter à un socket UNIX stocké dans le
|
|
837
|
+
répertoire <code>/tmp</code>.
|
|
838
|
+
</p>
|
|
839
|
+
<p>
|
|
840
|
+
On peut spécifier ici plusieurs serveurs en ajoutant un nombre à la
|
|
841
|
+
fin du nom du paramète (par exemple <code>backend_hostname0</code>).
|
|
842
|
+
Ce nombre est l'identifiant du nœud au sein de pgpool-II. Le premier
|
|
843
|
+
nœud est toujours le nœud 0. Le serveur PostgreSQL qui se voit
|
|
844
|
+
attribuer l'identifiant 0 sera appelé le serveur maître. Lorsque plusieurs
|
|
845
|
+
serveurs sont définis et seulement pour certains modes, le service peut
|
|
846
|
+
continuer même si le serveur maître est arrêté. Dans ce
|
|
847
|
+
cas, c'est toujours le serveur qui a le plus petit identifiant de nœud
|
|
848
|
+
et qui est encore disponible qui est alors promu serveur maître.</p>
|
|
849
|
+
|
|
850
|
+
<p>Si vous pensez n'utiliser qu'un seul serveur PostgreSQL, spécifiez-le
|
|
851
|
+
avec <code>backend_hostname0</code>.</p>
|
|
852
|
+
<p>
|
|
853
|
+
De nouveaux serveurs PostgreSQL peuvent être ajoutés grâce à ce paramètre
|
|
854
|
+
mais Vous devez recharger le fichier de configuration. Par contre, les
|
|
855
|
+
valeurs de ces paramètres ne pouvant être mises à jour, si vous les
|
|
856
|
+
changez, vous devrez alors redémarrer pgpool-II.
|
|
857
|
+
</p>
|
|
858
|
+
</dd>
|
|
859
|
+
|
|
860
|
+
<dt>backend_port</dt>
|
|
861
|
+
<dd>
|
|
862
|
+
<p>Spécifie le numéro de port des serveurs. Comme précédemment, on peut
|
|
863
|
+
spécifier le port de plusieurs serveurs en ajoutant à la fin du nom du
|
|
864
|
+
paramètre l'identifiant du nœud (par exemple <code>backend_port0</code>).
|
|
865
|
+
Si vous n'utilisez qu'un seul serveur, vous devrez le spécifier par
|
|
866
|
+
<code>backend_port0</code>.</p>
|
|
867
|
+
|
|
868
|
+
<p>
|
|
869
|
+
Comme précédemment, vous pouvez ajouter de nouveaux paramètres concernant
|
|
870
|
+
de nouveaux nœuds, et alors, un rechargement de la configuration suffira.
|
|
871
|
+
Cependant, si vous mettez à jour des valeurs de paramètres existant, vous
|
|
872
|
+
devrez redémarrer le serveur pgpool-II.
|
|
873
|
+
</p>
|
|
874
|
+
</dd>
|
|
875
|
+
|
|
876
|
+
<dt>backend_weight</dt>
|
|
877
|
+
<dd>
|
|
878
|
+
<p>Spécifie le poids des serveurs pour la répartition de charge.
|
|
879
|
+
On peut indiquer une valeur pour chacun des serveurs. Il suffit
|
|
880
|
+
pour cela d'ajouter le numéro du serveur à la fin du nom du
|
|
881
|
+
paramètre (par exemple <code>backend_weight0</code>). Si vous
|
|
882
|
+
n'utilisez qu'un seul serveur PostgreSQL, utilisez le paramètre
|
|
883
|
+
<code>backend_weight0</code>. Si vous êtes dans le mode RAW de pgpool-II,
|
|
884
|
+
mettez toujours cette valeur à 1.</p>
|
|
885
|
+
<p>
|
|
886
|
+
De nouveaux poids pour les backends peuvent être ajoutés pour de nouveaux
|
|
887
|
+
nœuds. Cependant, si vous mettez à jour des valeurs de paramètres existant, vous
|
|
888
|
+
devrez redémarrer le serveur pgpool-II.
|
|
889
|
+
</p>
|
|
890
|
+
<p>
|
|
891
|
+
À partir de pgpool-II 2.2.6/2.3, vous pouvez changer cette valeur par
|
|
892
|
+
rechargement du fichier de configuration.
|
|
893
|
+
Le nouveau paramétrage prendra alors effet uniquement pour les nouvelles
|
|
894
|
+
sessions clientes.
|
|
895
|
+
C'est très pratique si vous voulez empêcher toute requête envoyée aux
|
|
896
|
+
serveurs esclaves de réaliser des tâches administratives en mode
|
|
897
|
+
maître/esclave.
|
|
898
|
+
</p>
|
|
899
|
+
</dd>
|
|
900
|
+
|
|
901
|
+
<dt>backend_data_directory</dt>
|
|
902
|
+
<dd>
|
|
903
|
+
<p>Précise le répertoire des données des serveurs PostgreSQL.
|
|
904
|
+
Plusieurs serveurs peuvent être spécifiés en ajoutant
|
|
905
|
+
un nombre à la fin du nom de paramètre (par exemple
|
|
906
|
+
<code>backend_data_directory0</code>).
|
|
907
|
+
Si vous ne pensez pas utiliser « online recovery », vous n'avez pas
|
|
908
|
+
besoin de spécifier ce paramètre.
|
|
909
|
+
</p>
|
|
910
|
+
|
|
911
|
+
<p>
|
|
912
|
+
Des spécifications de répertoires de données PostgreSQL additionnels
|
|
913
|
+
peuvent être ajoutés par rechargement du fichier de configuration.
|
|
914
|
+
En revanche, leur valeur ne peut pas être mise à jour de cette façon.
|
|
915
|
+
Du coup, vous devrez redémarrer pgpool-II si vous modifiez la valeur d'un
|
|
916
|
+
paramètre déjà configuré.
|
|
917
|
+
</p>
|
|
918
|
+
</dd>
|
|
919
|
+
|
|
920
|
+
<dt><a name="ssl">ssl</a></dt>
|
|
921
|
+
<dd>
|
|
922
|
+
<p>
|
|
923
|
+
Si ce paramètre est à "true", le support de SSL est activé à la fois pour
|
|
924
|
+
les connexions clientes et les connexions aux serveurs PostgreSQL.
|
|
925
|
+
Notez que <code>ssl_key</code> et <code>ssl_cert</code>
|
|
926
|
+
doivent être renseignés pour que les connexions clientes puissent
|
|
927
|
+
fonctionner en SSL.
|
|
928
|
+
</p>
|
|
929
|
+
|
|
930
|
+
<p>
|
|
931
|
+
SSL est désactivé par défaut. Notez que le support d'OpenSSL doit
|
|
932
|
+
aussi avoir été configuré au moment de la compilation, comme c'est
|
|
933
|
+
mentionné dans la section <a href="#install">installation</a>.
|
|
934
|
+
</p>
|
|
935
|
+
|
|
936
|
+
<p>
|
|
937
|
+
Le démon de pgpool-II doit être redémarré lorsqu'on met à jour les
|
|
938
|
+
paramètres relatifs à SSL.
|
|
939
|
+
</p>
|
|
940
|
+
</dd>
|
|
941
|
+
|
|
942
|
+
<dt>ssl_key</dt>
|
|
943
|
+
<dd>
|
|
944
|
+
<p>
|
|
945
|
+
Chemin du fichier de clé privée pour les connexions clientes entrantes.
|
|
946
|
+
</p>
|
|
947
|
+
|
|
948
|
+
<p>
|
|
949
|
+
Il n'y a aucune valeur par défaut pour ce paramètre. S'il n'est pas modifié,
|
|
950
|
+
le support de SSL sera désactivé pour les connexions clientes
|
|
951
|
+
entrantes.
|
|
952
|
+
</p>
|
|
953
|
+
</dd>
|
|
954
|
+
|
|
955
|
+
<dt>ssl_cert</dt>
|
|
956
|
+
<dd>
|
|
957
|
+
<p>
|
|
958
|
+
Chemin complet vers le certificat public x509 à utiliser pour les
|
|
959
|
+
connexions clientes entrantes.
|
|
960
|
+
</p>
|
|
961
|
+
|
|
962
|
+
<p>
|
|
963
|
+
Il n'y a aucune valeur par défaut pour ce paramètre. S'il n'est pas modifié,
|
|
964
|
+
le support de SSL sera désactivé pour les connexions clientes
|
|
965
|
+
entrantes.
|
|
966
|
+
</p>
|
|
967
|
+
</dd>
|
|
968
|
+
|
|
969
|
+
<dt>debug_level</dt>
|
|
970
|
+
<dd>
|
|
971
|
+
<p>
|
|
972
|
+
Niveau de verbosité des messages de débogage. 0 signifie aucun message,
|
|
973
|
+
plus grand que 1 engendre des messages plus verbeux. La valeur par défaut
|
|
974
|
+
est 0.
|
|
975
|
+
</p>
|
|
976
|
+
</dd>
|
|
977
|
+
|
|
978
|
+
<dt>relcache_expire</dt>
|
|
979
|
+
<dd>
|
|
980
|
+
<p>
|
|
981
|
+
Durée de vie en secondes d'une relation en cache. 0 signifie qu'il n'y
|
|
982
|
+
a pas d'expiration (valeur par défaut).
|
|
983
|
+
Ce cache de relations est utilisé pour cacher le résultat de requêtes effectuées
|
|
984
|
+
sur le catalogue système de PostgreSQL pour obtenir diverses informations
|
|
985
|
+
comme la structure des tables ou pour savoir si telle ou telle table est temporaire.
|
|
986
|
+
Ce cache est maintenu dans une mémoire locale au processus fils de pgpool
|
|
987
|
+
et est gardé aussi longtemps que le processus est en vie.
|
|
988
|
+
Si un utilisateur modifie une table avec un ALTER TABLE, par exemple,
|
|
989
|
+
ce cache n'est alors plus cohérent.
|
|
990
|
+
À cet effet, le paramète relcache_expiration contrôle la durée de vie du
|
|
991
|
+
cache.
|
|
992
|
+
</p>
|
|
993
|
+
</dd>
|
|
994
|
+
</dl>
|
|
995
|
+
</dl>
|
|
996
|
+
|
|
997
|
+
<h4>Génération de certificats SSL</h4>
|
|
998
|
+
<p>
|
|
999
|
+
La manipulation des certificats n'est pas couvert dans ce document. La page
|
|
1000
|
+
<a href="http://developer.postgresql.org/pgdocs/postgres/ssl-tcp.html">
|
|
1001
|
+
Secure TCP/IP Connections with SSL</a> (en anglais) sur le site
|
|
1002
|
+
PostgreSQL.org référence des documents qui expliquent en détail
|
|
1003
|
+
les commandes à taper pour engendrer des certificats auto-signés.
|
|
1004
|
+
</p>
|
|
1005
|
+
|
|
1006
|
+
<h4>Failover dans le mode Raw</h4>
|
|
1007
|
+
|
|
1008
|
+
<p>Le failover peut être accompli dans le mode Raw si plusieurs serveurs
|
|
1009
|
+
sont définis. pgpool-II accède en général au serveur spécifié par
|
|
1010
|
+
<code>backend_hostname0</code> pendant son fonctionnement normal.
|
|
1011
|
+
Si le backend_hostname0 est en échec, quel que soit la raison, pgpool-II
|
|
1012
|
+
essaie d'accéder au serveur spécifié par backend_hostname1. En cas d'échec,
|
|
1013
|
+
pgpool-II essaie alors backend_hostname2, et ainsi de suite.
|
|
1014
|
+
</p>
|
|
1015
|
+
|
|
1016
|
+
<h3><a name="connection_pool_mode"></a>Mode pooling de connexions</h3>
|
|
1017
|
+
|
|
1018
|
+
<p>Dans le mode pooling de connexions, toutes les fonctions du mode
|
|
1019
|
+
raw et du mode pooling de connexions peuvent être utilisées. Pour activer ce
|
|
1020
|
+
mode, configurez les paramètres du mode raw ainsi que les autres
|
|
1021
|
+
paramètres ci-après.</p>
|
|
1022
|
+
|
|
1023
|
+
<dl>
|
|
1024
|
+
<dt>max_pool</dt>
|
|
1025
|
+
<dd>
|
|
1026
|
+
<p>Nombre maximum de connexions en cache dans les processus
|
|
1027
|
+
fils de pgpool-II. pgpool-II réutilise les connexions en cache si une
|
|
1028
|
+
connexion entrante se connecte à la même base de données avec le
|
|
1029
|
+
même nom d'utilisateur. Sinon, pgpool-II crée une nouvelle connexion
|
|
1030
|
+
au serveur PostgreSQL. Si le nombre de connexions en cache dépasse
|
|
1031
|
+
max_pool, la plus vieille des connexions sera supprimée et on utilisera
|
|
1032
|
+
cet emplacement ainsi libéré pour la nouvelle connexion.
|
|
1033
|
+
|
|
1034
|
+
La valeur par défaut est 4. Faites bien attention au fait que le nombre
|
|
1035
|
+
total de connexions des processus pgpool-II aux serveurs PostgreSQL
|
|
1036
|
+
pourraient atteindre ainsi :
|
|
1037
|
+
<code>num_init_children</code> * <code>max_pool</code>.
|
|
1038
|
+
|
|
1039
|
+
Ce paramètre n'est pris en compte qu'au démarrage du serveur
|
|
1040
|
+
pgpool-II.
|
|
1041
|
+
</p>
|
|
1042
|
+
</dd>
|
|
1043
|
+
|
|
1044
|
+
<dt>connection_life_time</dt>
|
|
1045
|
+
<dd>
|
|
1046
|
+
<p>
|
|
1047
|
+
Durée de vie en seconde d'une connexion en cache. Une
|
|
1048
|
+
connexion en cache dont la durée de vie expire sera alors déconnectée.
|
|
1049
|
+
La valeur par défaut est 0, ce qui signifie que les connexions en cache
|
|
1050
|
+
ne seront jamais déconnectées.</p>
|
|
1051
|
+
</dd>
|
|
1052
|
+
|
|
1053
|
+
<dt>reset_query_list</dt>
|
|
1054
|
+
<dd>
|
|
1055
|
+
<p>Spécifie les requêtes SQL envoyées à la connexion au serveur
|
|
1056
|
+
PostgreSQL lorsqu'une session se termine, côté client de pgpool-II.
|
|
1057
|
+
Plusieurs commandes peuvent être spécifiées en les séparant par
|
|
1058
|
+
un point-virgule. La valeur ci-dessous est la valeur par défault,
|
|
1059
|
+
mais elle peut être adaptée pour satisfaire vos besoins.
|
|
1060
|
+
|
|
1061
|
+
<pre>
|
|
1062
|
+
reset_query_list = 'ABORT; DISCARD ALL'
|
|
1063
|
+
</pre>
|
|
1064
|
+
|
|
1065
|
+
<p>
|
|
1066
|
+
Les commandes diffèrent dans chaque version de PostgreSQL. Voici les
|
|
1067
|
+
paramètres recommandés par version.
|
|
1068
|
+
</p>
|
|
1069
|
+
<p>
|
|
1070
|
+
<table border>
|
|
1071
|
+
<tr><th>Version de PostgreSQL</th><th>reset_query_list value</th></tr>
|
|
1072
|
+
<tr><td>7.1 ou précédentes</td><td>ABORT</td></tr>
|
|
1073
|
+
<tr><td>7.2 à 8.2</td><td>ABORT; RESET ALL; SET SESSION AUTHORIZATION DEFAULT</td></tr>
|
|
1074
|
+
<tr><td>8.3 et suivantes</td><td>ABORT; DISCARD ALL</td></tr>
|
|
1075
|
+
</table>
|
|
1076
|
+
</p>
|
|
1077
|
+
<ul>
|
|
1078
|
+
<li>"ABORT" n'est pas envoyé en dehors d'un bloc de transactions à partir de la 7.4.
|
|
1079
|
+
</ul>
|
|
1080
|
+
|
|
1081
|
+
<p>
|
|
1082
|
+
Vous aurez besoin de recharger pgpool.conf après toute modification de
|
|
1083
|
+
ce paramètre pour que sa nouvelle valeur soit prise en compte.
|
|
1084
|
+
</p>
|
|
1085
|
+
</dd>
|
|
1086
|
+
</dl>
|
|
1087
|
+
|
|
1088
|
+
<h4><p>Le failover dans le mode pooling de connexions</p></h4>
|
|
1089
|
+
|
|
1090
|
+
<p>Le failover dans le mode pooling de connexions est identique à celui du
|
|
1091
|
+
mode raw.</p>
|
|
1092
|
+
|
|
1093
|
+
<h3><a name="replication_mode"></a>Mode réplication</h3>
|
|
1094
|
+
|
|
1095
|
+
<p>Ce mode permet la réplication des données entre les serveurs PostgreSQL.
|
|
1096
|
+
Les paramètres de configuration ci-dessous doivent être renseignés, en plus
|
|
1097
|
+
de tout ce qui a été vu plus haut.
|
|
1098
|
+
</p>
|
|
1099
|
+
|
|
1100
|
+
<dl>
|
|
1101
|
+
<dt>replication_mode
|
|
1102
|
+
<dd>
|
|
1103
|
+
<p>Mettre ce paramètre à <code>true</code> active le mode de
|
|
1104
|
+
réplication. La valeur par défaut est <code>false</code>.
|
|
1105
|
+
</p>
|
|
1106
|
+
</dd>
|
|
1107
|
+
|
|
1108
|
+
<dt>load_balance_mode</dt>
|
|
1109
|
+
<dd>
|
|
1110
|
+
<p>Lorsque ce paramètre est à <code>true</code>, les requêtes de
|
|
1111
|
+
type SELECT sont distribuées à chaque serveur PostgreSQL pour
|
|
1112
|
+
obtenir une répartition de la charge entre les serveurs. La valeur
|
|
1113
|
+
par défaut est <code>false</code>.
|
|
1114
|
+
</p>
|
|
1115
|
+
</dd>
|
|
1116
|
+
|
|
1117
|
+
<dt>failover_if_affected_tuples_mismatch</dt>
|
|
1118
|
+
<dd>
|
|
1119
|
+
<p>Lorsque ce paramètre est positionné à <code>true</code>,
|
|
1120
|
+
si les serveurs PostgreSQL ne retournent pas le même nombre de
|
|
1121
|
+
lignes affectées lors d'un INSERT, UPDATE ou DELETE, les serveurs
|
|
1122
|
+
qui diffèrent de la valeur la plus fréquente sont « dégénérés »
|
|
1123
|
+
(NDT: ils ne sont alors plus jamais utilisés par pgpool-II, qui les
|
|
1124
|
+
considère comme incohérents).
|
|
1125
|
+
Si ce paramètre est à <code>false</code>, la session est terminée
|
|
1126
|
+
et les serveurs PostgreSQL ne sont pas « dégénérés ». La valeur par
|
|
1127
|
+
défaut est à <code>false</code>.
|
|
1128
|
+
</p>
|
|
1129
|
+
</dd>
|
|
1130
|
+
|
|
1131
|
+
<dt>replication_stop_on_mismatch</dt>
|
|
1132
|
+
<dd>
|
|
1133
|
+
<p>Si ce paramètre est à <code>true</code> et si tous les serveurs
|
|
1134
|
+
PostgreSQL ne retournent pas le même type de paquet, les serveurs
|
|
1135
|
+
dont la valeur diffère du résultat le plus fréquent sont « dégénérés ».
|
|
1136
|
+
Un cas d'utilisation typique est une requête SELECT dans une
|
|
1137
|
+
transaction, avec replicate_select à <code>true</code>, qui
|
|
1138
|
+
retournerait un nombre d'enregistrements différent suivant les
|
|
1139
|
+
serveurs PostgreSQL.
|
|
1140
|
+
Les requêtes qui ne sont pas en SELECT pourraient aussi déclencher
|
|
1141
|
+
cette action. Par exemple, si un serveur PostgreSQL réussit un
|
|
1142
|
+
UPDATE alors que les autres échouent.
|
|
1143
|
+
Notez que pgpool-II n'examine <b>pas</b> le contenu des
|
|
1144
|
+
enregistrements retournés par un SELECT.
|
|
1145
|
+
Si ce paramètre est à <code>false</code>, la session est terminée
|
|
1146
|
+
et les serveurs PostgreSQL ne sont pas « dégénérés ». La valeur par
|
|
1147
|
+
défaut est <code>false</code>.
|
|
1148
|
+
</p>
|
|
1149
|
+
</dd>
|
|
1150
|
+
|
|
1151
|
+
<a name="white_function_list"></a>
|
|
1152
|
+
<dt>white_function_list
|
|
1153
|
+
<dd>
|
|
1154
|
+
<p>
|
|
1155
|
+
Permet de spécifier une liste de noms de fonctions, séparées par des virgules,
|
|
1156
|
+
qui ne font <strong>pas</strong> d'écritures dans la base de données.
|
|
1157
|
+
Tous les SELECTs qui font appel à des fonctions qui ne sont pas spécifiées
|
|
1158
|
+
dans cette liste ne seront ainsi jamais répartis entre les serveurs PostgreSQL,
|
|
1159
|
+
ni même répliqués dans le mode réplication.
|
|
1160
|
+
Dans le mode maître/esclave, de tels SELECTs sont envoyés au maître
|
|
1161
|
+
(ou primaire) uniquement.
|
|
1162
|
+
</p>
|
|
1163
|
+
<p>
|
|
1164
|
+
Vous pouvez utiliser des expressions régulières dans la liste pour établir
|
|
1165
|
+
une correspondance à une famille de fonctions. Par exemple, si vous avez eu la
|
|
1166
|
+
bonne idée de préfixer toutes les fonctions de votre base qui ne font que
|
|
1167
|
+
des lectures avec 'get_' ou 'select_' par exemple, vous pourrez ainsi vous
|
|
1168
|
+
limiter à n'écrire que les deux expressions régulières dans ce paramètre :
|
|
1169
|
+
|
|
1170
|
+
</p>
|
|
1171
|
+
<pre>
|
|
1172
|
+
white_function_list = 'get_.*,select_.*'
|
|
1173
|
+
</pre>
|
|
1174
|
+
</dd>
|
|
1175
|
+
|
|
1176
|
+
<a name="black_function_list"></a>
|
|
1177
|
+
<dt>black_function_list
|
|
1178
|
+
<dd>
|
|
1179
|
+
<p>
|
|
1180
|
+
Permet de spécifier une liste de noms de fonctions, séparées par des virgules,
|
|
1181
|
+
qui <strong>font</strong> des écritures dans la base de données.
|
|
1182
|
+
Les SELECT qui utilisent les fonctions spécifiées dans cette liste ne seront
|
|
1183
|
+
jamais répartis entre les serveurs PostgreSQL, ni répliqués dans le mode
|
|
1184
|
+
de réplication.
|
|
1185
|
+
Dans le mode maître/esclave, de tels SELECT sont envoyés uniquement au
|
|
1186
|
+
maître.
|
|
1187
|
+
</p>
|
|
1188
|
+
<p>
|
|
1189
|
+
Vous pouvez utiliser des expressions régulières dans la liste pour établir une
|
|
1190
|
+
correspondance avec une famille de fonctions. Par exemple, si vous avez eu la
|
|
1191
|
+
bonne idée de préfixer toutes les fonctions de votre base qui font
|
|
1192
|
+
des écritures avec 'set_','update_','delete_' ou 'insert_'
|
|
1193
|
+
par exemple, vous pourrez ainsi vous limiter à n'écrire que les
|
|
1194
|
+
expressions régulières suivantes dans ce paramètre :
|
|
1195
|
+
</p>
|
|
1196
|
+
<pre>
|
|
1197
|
+
black_function_list = 'nextval,setval,set_.*,update_.*,delete_.*,insert_.*'
|
|
1198
|
+
</pre>
|
|
1199
|
+
<p>
|
|
1200
|
+
<b>Attention</b>, une seule de ces deux listes ne peut être renseignée
|
|
1201
|
+
dans la configuration de pgpool-II. Autrement dit, vous devez opter pour l'un ou
|
|
1202
|
+
l'autre des paramètres : autoriser de manière explicite, ou interdire
|
|
1203
|
+
de manière explicite. De préférence, optez pour la sécurité d'autoriser
|
|
1204
|
+
explicitement, c'est-à-dire utiliser le paramètre white_function_list.
|
|
1205
|
+
En effet, en cas
|
|
1206
|
+
d'oubli d'une fonction en écriture dans le paramètre black_function_list,
|
|
1207
|
+
vous risquez de demander l'exécution d'une fonction en écriture sur un serveur
|
|
1208
|
+
en lecture seule, dans le mode maître/esclave par exemple.
|
|
1209
|
+
</p>
|
|
1210
|
+
<p>
|
|
1211
|
+
Avant la version 3.0 de pgpool-II, les fonctions nextval() et setval()
|
|
1212
|
+
étaient connues pour leurs écritures dans la base de données.
|
|
1213
|
+
Vous pouvez émuler ce comportement en utilisant les deux paramètres vus
|
|
1214
|
+
précédemment de la façon suivante :
|
|
1215
|
+
</p>
|
|
1216
|
+
<p>
|
|
1217
|
+
<pre>
|
|
1218
|
+
white_function_list = ''
|
|
1219
|
+
black_function_list = 'nextval,setval,lastval,currval'
|
|
1220
|
+
</pre>
|
|
1221
|
+
</p>
|
|
1222
|
+
<p>
|
|
1223
|
+
Notez que l'on a lastval() et currval() en plus des nextval() et setval().
|
|
1224
|
+
Bien que lastval() et currval() ne soient pas des fonctions qui provoquent des
|
|
1225
|
+
écritures, il vaux mieux les ajouter pour éviter toute erreur dans le cas où
|
|
1226
|
+
ces fonctions seraient accidentellement réparties entre les différents nœuds.
|
|
1227
|
+
Ainsi, les ajouter à la black_function_list permettra d'éviter qu'elles soient
|
|
1228
|
+
réparties.
|
|
1229
|
+
</p>
|
|
1230
|
+
</dd>
|
|
1231
|
+
|
|
1232
|
+
<a name="replicate_select"></a>
|
|
1233
|
+
<dt>replicate_select</dt>
|
|
1234
|
+
<dd>
|
|
1235
|
+
<p>Lorsque ce paramètre est à <code>true</code>, pgpool-II va répliquer
|
|
1236
|
+
les SELECT dans le mode de réplication. Si c'est à <code>false</code>,
|
|
1237
|
+
pgpool-II va les envoyer uniquement au serveur maître (primaire). La valeur
|
|
1238
|
+
par défaut est <code>false</code>.</p>
|
|
1239
|
+
|
|
1240
|
+
<p>
|
|
1241
|
+
Si une requête SELECT est à l'intérieur d'un bloc de transaction explicite,
|
|
1242
|
+
replicate_select et load_balance_mode auront un effet sur le fonctionnement de
|
|
1243
|
+
la réplication. Les détails sont expliqués ci-dessous.
|
|
1244
|
+
</p>
|
|
1245
|
+
|
|
1246
|
+
<p>
|
|
1247
|
+
<table border>
|
|
1248
|
+
|
|
1249
|
+
<tr>
|
|
1250
|
+
<td>Le SELECT est à l'intérieur d'un bloc de transaction</td>
|
|
1251
|
+
<td>O</td>
|
|
1252
|
+
<td>O</td>
|
|
1253
|
+
<td>O</td>
|
|
1254
|
+
<td>N</td>
|
|
1255
|
+
<td>N</td>
|
|
1256
|
+
<td>N</td>
|
|
1257
|
+
<td>O</td>
|
|
1258
|
+
<td>N</td>
|
|
1259
|
+
</tr>
|
|
1260
|
+
|
|
1261
|
+
<tr>
|
|
1262
|
+
<td>replicate_select = true</td>
|
|
1263
|
+
<td>O</td>
|
|
1264
|
+
<td>O</td>
|
|
1265
|
+
<td>N</td>
|
|
1266
|
+
<td>N</td>
|
|
1267
|
+
<td>O</td>
|
|
1268
|
+
<td>O</td>
|
|
1269
|
+
<td>N</td>
|
|
1270
|
+
<td>N</td>
|
|
1271
|
+
</tr>
|
|
1272
|
+
|
|
1273
|
+
<tr>
|
|
1274
|
+
<td>load_balance_mode = true</td>
|
|
1275
|
+
<td>O</td>
|
|
1276
|
+
<td>N</td>
|
|
1277
|
+
<td>N</td>
|
|
1278
|
+
<td>N</td>
|
|
1279
|
+
<td>O</td>
|
|
1280
|
+
<td>N</td>
|
|
1281
|
+
<td>O</td>
|
|
1282
|
+
<td>O</td>
|
|
1283
|
+
</tr>
|
|
1284
|
+
|
|
1285
|
+
<tr>
|
|
1286
|
+
<td>resultats (R:réplication, M:envoyé au maître uniquement, L:réparti)</td>
|
|
1287
|
+
<td>R</td>
|
|
1288
|
+
<td>R</td>
|
|
1289
|
+
<td>M</td>
|
|
1290
|
+
<td>M</td>
|
|
1291
|
+
<td>R</td>
|
|
1292
|
+
<td>R</td>
|
|
1293
|
+
<td>M</td>
|
|
1294
|
+
<td>L</td>
|
|
1295
|
+
</tr>
|
|
1296
|
+
</table>
|
|
1297
|
+
</p>
|
|
1298
|
+
</dd>
|
|
1299
|
+
|
|
1300
|
+
<dt>insert_lock</dt>
|
|
1301
|
+
<dd>
|
|
1302
|
+
<p>Si on réplique une table qui utilise le type de données SERIAL,
|
|
1303
|
+
la valeur du SERIAL pourrait être différente entre les serveurs
|
|
1304
|
+
PostgreSQL. On peut éviter ce problème en verrouillant la table
|
|
1305
|
+
de manière explicite (bien que le parallélisme des transactions sera
|
|
1306
|
+
alors sévèrement dégradé). Pour arriver à cela, les
|
|
1307
|
+
changements suivants doivent être faits :
|
|
1308
|
+
|
|
1309
|
+
<pre>
|
|
1310
|
+
INSERT INTO ...
|
|
1311
|
+
</pre>
|
|
1312
|
+
<p>
|
|
1313
|
+
à
|
|
1314
|
+
</p>
|
|
1315
|
+
<pre>
|
|
1316
|
+
BEGIN;
|
|
1317
|
+
LOCK TABLE ...
|
|
1318
|
+
INSERT INTO ...
|
|
1319
|
+
COMMIT;
|
|
1320
|
+
</pre>
|
|
1321
|
+
|
|
1322
|
+
<p>Lorsque <code>insert_lock</code> est à
|
|
1323
|
+
<code>true</code>, pgpool-II ajoute automatiquement
|
|
1324
|
+
les requêtes ci-dessus à chaque fois qu'un INSERT est
|
|
1325
|
+
exécuté. Si on est alors déjà dans une transaction, il ajoute
|
|
1326
|
+
alors simplement un LOCK TABLE.
|
|
1327
|
+
</p>
|
|
1328
|
+
<p>À partir de pgpool-II 2.2, la détection des tables qui ont
|
|
1329
|
+
un SERIAL ou non est automatique. Ainsi, seules les tables qui
|
|
1330
|
+
ont un SERIAL sont verrouillées de manière exclusive.
|
|
1331
|
+
</p>
|
|
1332
|
+
<p>
|
|
1333
|
+
pgpool-II 3.0 utilise désormais un verrou de ligne sur la relation
|
|
1334
|
+
de la séquence, plutôt qu'un verrou de table exclusif. Cela
|
|
1335
|
+
minimise les conflits sur les verrous, comme par exemple
|
|
1336
|
+
VACUUM (direct ou via autovacuum).
|
|
1337
|
+
</p>
|
|
1338
|
+
<p>
|
|
1339
|
+
Si vous souhaitez un contrôle plus fin (par
|
|
1340
|
+
requête) :
|
|
1341
|
+
</p>
|
|
1342
|
+
|
|
1343
|
+
<ol>
|
|
1344
|
+
<li>positionnez <code>insert_lock</code> à <code>true</code>, et
|
|
1345
|
+
ajoutez <code>/*NO INSERT LOCK*/</code> au début d'une requête
|
|
1346
|
+
INSERT pour laquelle vous ne voulez pas qu'un verrou exclusif de
|
|
1347
|
+
table ne soit ajouté.</li>
|
|
1348
|
+
|
|
1349
|
+
<li>positionnez <code>insert_lock</code> à <code>false</code>, et
|
|
1350
|
+
ajoutez <code>/*INSERT LOCK*/</code> au début d'une requête
|
|
1351
|
+
INSERT pour laquelle vous voulez provoquer un verrouillage
|
|
1352
|
+
exclusif de la table.</li>
|
|
1353
|
+
</ol>
|
|
1354
|
+
|
|
1355
|
+
<p>
|
|
1356
|
+
La valeur par défaut est <code>false</code>. Si
|
|
1357
|
+
<code>insert_lock</code> est activé, les tests de régression pour
|
|
1358
|
+
PostgreSQL 8.0 échoueront dans les transactions, droits, règles
|
|
1359
|
+
(rules) et ALTER TABLE. La raison en est que pgpool-II essaie de
|
|
1360
|
+
verrouiller une vue pour le test sur les règles, ce qui a pour conséquence
|
|
1361
|
+
l'erreur suivante :</p>
|
|
1362
|
+
<pre>
|
|
1363
|
+
! ERROR: current transaction is aborted, commands ignored until
|
|
1364
|
+
end of transaction block
|
|
1365
|
+
</pre>
|
|
1366
|
+
|
|
1367
|
+
<p>Par exemple, le test sur les transactions essaie un INSERT dans une
|
|
1368
|
+
table qui n'existe pas, et pgpool-II essaie d'acquérir un verrou
|
|
1369
|
+
exclusif avant cela. La transaction sera alors interrompue et la requête
|
|
1370
|
+
d'INSERT qui suit produira le message ci-dessus.</p>
|
|
1371
|
+
|
|
1372
|
+
<dt>recovery_user
|
|
1373
|
+
<dd>
|
|
1374
|
+
<p>
|
|
1375
|
+
Ce paramètre permet de spécifier l'utilisateur PostgreSQL à utiliser pour
|
|
1376
|
+
le « online recovery ». Il peut être changé sans avoir besoin de redémarrer
|
|
1377
|
+
pgpool-II.
|
|
1378
|
+
</p>
|
|
1379
|
+
|
|
1380
|
+
<dt>recovery_password
|
|
1381
|
+
<dd>
|
|
1382
|
+
<p>
|
|
1383
|
+
Ce paramètre permet de spécifier le mot de passe de l'utilisateur spécifié dans
|
|
1384
|
+
le paramètre ci-dessus, à savoir <code>recovery_user</code>, qui est utilisé
|
|
1385
|
+
lors du « online recovery ». Comme le paramètre précédent, il peut être changé
|
|
1386
|
+
sans avoir à redémarrer le serveur pgpool-II.
|
|
1387
|
+
</p>
|
|
1388
|
+
|
|
1389
|
+
<dt>recovery_1st_stage_command
|
|
1390
|
+
<dd>
|
|
1391
|
+
<p>
|
|
1392
|
+
Ce paramètre permet de préciser une commande à exécuter pour la première
|
|
1393
|
+
phase du « online recovery ». Le fichier de commandes spécifié ici doit être placé
|
|
1394
|
+
à la racine du répertoire des données de l'instance PostgreSQL, pour des
|
|
1395
|
+
raisons de sécurité.
|
|
1396
|
+
|
|
1397
|
+
Par exemple, si <code>recovery_1st_stage_command = 'sync-command'</code>,
|
|
1398
|
+
alors pgpool-II exécute <code>$PGDATA/sync-command</code>.
|
|
1399
|
+
|
|
1400
|
+
Notez que pgpool-II <b>accepte</b> les connexions et les requêtes alors que
|
|
1401
|
+
<code>recovery_1st_stage command</code> est en cours d'exécution. On peut
|
|
1402
|
+
ainsi lire et écrire dans la base de données pendant cette première phase du
|
|
1403
|
+
« online recovery ».
|
|
1404
|
+
</p>
|
|
1405
|
+
<p>
|
|
1406
|
+
Ce paramètre peut être changé sans avoir à redémarrer pgpool-II.
|
|
1407
|
+
</p>
|
|
1408
|
+
|
|
1409
|
+
<dt>recovery_2nd_stage_command
|
|
1410
|
+
<dd>
|
|
1411
|
+
<p>
|
|
1412
|
+
Ce paramètre spécifie une commande à exécuter lors de la deuxième phase
|
|
1413
|
+
du « online recovery ». Ce fichier de commandes doit être placé à la racine
|
|
1414
|
+
du répertoire des données de l'instance PostgreSQL pour des raisons de sécurité.
|
|
1415
|
+
|
|
1416
|
+
Par exemple, si <code>recovery_2nd_stage_command = 'sync-command'</code>,
|
|
1417
|
+
alors pgpool-II exécute <code>$PGDATA/sync-command</code>.
|
|
1418
|
+
|
|
1419
|
+
Notez que pgpool-II <b>n'accepte pas</b> de connexions ou d'exécution de
|
|
1420
|
+
requêtes pendant que <code>recovery_2nd_stage_command</code> est en
|
|
1421
|
+
cours d'exécution. Ainsi, si un client reste connecté pendant une longue période,
|
|
1422
|
+
rien ne sera exécuté. En effet, pgpool-II attends que tous les clients aient
|
|
1423
|
+
fermé leurs connexions pour exécuter cette seconde phase du « online recovery ».
|
|
1424
|
+
La commande n'est donc exécutée que lorsqu'il n'y a plus aucun client de
|
|
1425
|
+
connecté.
|
|
1426
|
+
</p>
|
|
1427
|
+
<p>
|
|
1428
|
+
Ce paramètre peut être changé sans redémarrer pgpool-II.
|
|
1429
|
+
</p>
|
|
1430
|
+
|
|
1431
|
+
<dt>recovery_timeout
|
|
1432
|
+
<dd>
|
|
1433
|
+
<p>
|
|
1434
|
+
pgpool n'accepte plus de nouvelle connexion pendant la seconde phase du
|
|
1435
|
+
« online recovery ». Si un client essaie de se connecter à pgpool-II pendant un
|
|
1436
|
+
« online recovery », il devra attendre la fin de ce dernier.
|
|
1437
|
+
</p>
|
|
1438
|
+
<p>
|
|
1439
|
+
Ce paramètre spécifie un délai au terme duquel le « online recovery » sera annulé
|
|
1440
|
+
s'il n'est pas terminé. Après l'annulation, pgpool-II acceptera alors de nouveau
|
|
1441
|
+
les connexions. La valeur <code>0</code> désactive cette fonctionnalité.
|
|
1442
|
+
</p>
|
|
1443
|
+
<p>
|
|
1444
|
+
Ce paramètre peut être changé sans avoir à redémarrer pgpool-II.
|
|
1445
|
+
</p>
|
|
1446
|
+
|
|
1447
|
+
<dt>client_idle_limit_in_recovery
|
|
1448
|
+
<dd>
|
|
1449
|
+
<p>Similaire à <code>client_idle_limit</code>. Cependant, il n'agit
|
|
1450
|
+
que lors de la seconde phase du « online recovery ». Un client qui aura
|
|
1451
|
+
été inactif pendant <code>client_idle_limit_in_recovery</code>
|
|
1452
|
+
secondes depuis sa dernière requête sera déconnecté.
|
|
1453
|
+
Ce paramètre permet d'éviter que le « online recovery » ne soit perturbé
|
|
1454
|
+
par un client inactif, ou si la connexion TCP/IP entre le client et
|
|
1455
|
+
pgpool tombe de manière accidentelle (un câble réseau défectueux
|
|
1456
|
+
par exemple). Si ce paramètre est à <code>-1</code>, le client
|
|
1457
|
+
est déconnecté immédiatement. La valeur par défaut de ce paramètre
|
|
1458
|
+
est <code>0</code>, ce qui signifie que cette fonctionalité est
|
|
1459
|
+
désactivée.
|
|
1460
|
+
</p>
|
|
1461
|
+
<p> Si vos clients sont très actifs, pgpool-II ne pourra jamais entrer dans
|
|
1462
|
+
la seconde phase du « online recovery », quelle que soit la valeur de
|
|
1463
|
+
<code>client_idle_limit_in_recovery</code> que vous aurez choisie.
|
|
1464
|
+
Dans ce cas, vous pouvez paramétrer <code>client_idle_limit_in_recovery</code>
|
|
1465
|
+
à <code>-1</code> afin que pgpool-II puisse déconnecter immédiatement
|
|
1466
|
+
des clients aussi actifs avant de passer à la seconde phase du « online
|
|
1467
|
+
recovery ».
|
|
1468
|
+
</p>
|
|
1469
|
+
<p>
|
|
1470
|
+
Vous devez recharger la configuration de pgpool-II si vous changer la
|
|
1471
|
+
valeur de <code>client_idle_limit_in_recovery</code>.</p>
|
|
1472
|
+
|
|
1473
|
+
<dt><a name="lobj_lock_table"></a>lobj_lock_table
|
|
1474
|
+
<dd>
|
|
1475
|
+
<p>
|
|
1476
|
+
Ce paramètre spécifie un nom de table utilisé pour le contrôle de la
|
|
1477
|
+
réplication des « large objects ». Si elle est spécifiée, pgpool-II verrouillera
|
|
1478
|
+
cette table, et génèrera un identifiant de « large object » en regardant
|
|
1479
|
+
dans la table pg_largeobject du catalogue système, et enfin, appellera
|
|
1480
|
+
lo_create pour créer le « large object ».
|
|
1481
|
+
Cette procédure garantie que pgpool-II obtiendra le même identifiant de
|
|
1482
|
+
« large object » sur tous les serveurs PostgreSQL lorsque pgpool-II est dans
|
|
1483
|
+
le mode réplication. Notez que PostgreSQL 8.0 et ultérieur n'a plus de fonction
|
|
1484
|
+
lo_create. Du coup, cette fonctionalité est pas utilisable pour ces versions.
|
|
1485
|
+
</p>
|
|
1486
|
+
<p>
|
|
1487
|
+
Un appel à la fonction de la libpq lo_creat() utilisera cette fonctionalité. De
|
|
1488
|
+
même, la création de « large objects » via l'API Java (driver JDBC) devrait
|
|
1489
|
+
fonctionner, tout comme l'API PHP (pg_lo_create, ou API similaire dans
|
|
1490
|
+
la bibliothèque de PHP, comme PDO), et ce genre d'API similaires dans
|
|
1491
|
+
plusieurs langages de programmation qui sont réputées pour utiliser un
|
|
1492
|
+
protocole similaire.
|
|
1493
|
+
</p>
|
|
1494
|
+
<p>
|
|
1495
|
+
Les opérations suivantes de création d'un « large object » ne fonctionneront pas :
|
|
1496
|
+
<p>
|
|
1497
|
+
<ul>
|
|
1498
|
+
<li>lo_create de la libpq
|
|
1499
|
+
<li>l'API d'un langage qui utilise lo_create
|
|
1500
|
+
<li>la fonction lo_import dans le serveur PostgreSQL
|
|
1501
|
+
<li>SELECT lo_creat
|
|
1502
|
+
</ul>
|
|
1503
|
+
</p>
|
|
1504
|
+
<p>
|
|
1505
|
+
Peu importe le schéma où est stockée la table <code>lobj_lock_table</code>,
|
|
1506
|
+
celle-ci doit en revanche être accessible en écriture à tous les utilisateurs.
|
|
1507
|
+
Voici un exemple de création d'une telle table :
|
|
1508
|
+
</p>
|
|
1509
|
+
<p>
|
|
1510
|
+
<pre>
|
|
1511
|
+
CREATE TABLE public.my_lock_table ();
|
|
1512
|
+
GRANT ALL ON public.my_lock_table TO PUBLIC;
|
|
1513
|
+
</pre>
|
|
1514
|
+
</p>
|
|
1515
|
+
<p>
|
|
1516
|
+
La table spécifiée par <code>lobj_lock_table</code> doit être créée à
|
|
1517
|
+
l'avance. Vous pouvez par exemple la créer dans la base <code>template1</code>
|
|
1518
|
+
afin que toute base de données créée par la suite en dispose.
|
|
1519
|
+
</p>
|
|
1520
|
+
<p>
|
|
1521
|
+
Si <code>lobj_lock_table</code> contient une chaîne vide (<code>''</code>),
|
|
1522
|
+
la fonctionalité est désactivée. Du coup, la réplication des « large objects »
|
|
1523
|
+
ne fonctionnera pas.
|
|
1524
|
+
|
|
1525
|
+
La valeur par défaut de ce paramètre est justement la chaîne vide (<code>''</code>).
|
|
1526
|
+
</p>
|
|
1527
|
+
|
|
1528
|
+
</dl>
|
|
1529
|
+
|
|
1530
|
+
<h4><p>Pré-requis pour la répartition de charge</p></h4>
|
|
1531
|
+
<p>
|
|
1532
|
+
Pour qu'une requête soit répartie, les pré-requis suivants
|
|
1533
|
+
doivent être respectés :
|
|
1534
|
+
<ul>
|
|
1535
|
+
<li>Version 7.4 ou ultérieure de PostgreSQL</li>
|
|
1536
|
+
<li>La requête ne doit pas être déclarée explicitement
|
|
1537
|
+
(c'est-à-dire qu'on ne doit pas être dans un bloc
|
|
1538
|
+
BEGIN ~ END)</li>
|
|
1539
|
+
<li>Il ne s'agit pas d'un SELECT nextval ou d'un SELECT setval
|
|
1540
|
+
<li>Il ne s'agit pas d'un SELECT INTO
|
|
1541
|
+
<li>Il ne s'agit pas d'un SELECT FOR UPDATE ou FOR SHARE
|
|
1542
|
+
<li>La requête commence par un SELECT ou COPY TO STDOUT, EXPLAIN, EXPLAIN ANALYZE SELECT...
|
|
1543
|
+
le paramètre <code>ignore_leading_white_space = true</code> permettra
|
|
1544
|
+
d'ignorer tous les éventuels espaces présents avant la requête.
|
|
1545
|
+
</ul>
|
|
1546
|
+
</p>
|
|
1547
|
+
<p>
|
|
1548
|
+
Notez que vous pouvez interdire de manière explicite la répartition d'une charge sur
|
|
1549
|
+
une requête SELECT en ajoutant un commentaire au début de la requête SELECT (quel que ce
|
|
1550
|
+
soit ce commentaire). Par exemple :
|
|
1551
|
+
<pre>
|
|
1552
|
+
/*REPLICATION*/ SELECT ...
|
|
1553
|
+
</pre>
|
|
1554
|
+
</p>
|
|
1555
|
+
|
|
1556
|
+
<p>
|
|
1557
|
+
Merci de lire attentivement la page
|
|
1558
|
+
<a href="#replicate_select">replicate_select</a> au sujet de la réplication.
|
|
1559
|
+
De même, étudiez attentivement ce
|
|
1560
|
+
<a href="where_to_send_queries.pdf">schéma</a> qui explique comment
|
|
1561
|
+
pgpool-II détermine à quel serveur PostgreSQL envoyer telle ou telle requête.
|
|
1562
|
+
</p>
|
|
1563
|
+
|
|
1564
|
+
<p>
|
|
1565
|
+
<font color="red">
|
|
1566
|
+
Attention : le connecteur JDBC a une option autocommit. Si autocommit est à
|
|
1567
|
+
<code>false</code>, le connecteur JDBC envoie un BEGIN et un COMMIT
|
|
1568
|
+
lui-même. Ainsi, pgpool-II ne pourra faire aucune répartition de charge. Vous devez
|
|
1569
|
+
alors appeler <code>setAutoCommit(true)</code> pour activer
|
|
1570
|
+
l'autocommit.
|
|
1571
|
+
</font>
|
|
1572
|
+
</p>
|
|
1573
|
+
|
|
1574
|
+
<h4><p>Failover dans le mode Réplication</p></h4>
|
|
1575
|
+
|
|
1576
|
+
<p> pgpool-II désactive un serveur « mort » et le service continue, à condition
|
|
1577
|
+
qu'il y ait au moins un serveur PostgreSQL en vie.
|
|
1578
|
+
</p>
|
|
1579
|
+
|
|
1580
|
+
<h3><a name="master_slave_mode"></a>Mode Maître-Esclave</h3>
|
|
1581
|
+
|
|
1582
|
+
<p>Ce mode est utilisé lorsque pgpool-II est couplé avec un autre outil
|
|
1583
|
+
de réplication de type maître/esclave(s) (comme Slony-I ou le Streaming
|
|
1584
|
+
Réplication intégré à PostgreSQL). Cet outil est alors responsable de la
|
|
1585
|
+
réplication des données.
|
|
1586
|
+
|
|
1587
|
+
L'information sur les serveurs PostgreSQL doit être renseignée (les paramètres
|
|
1588
|
+
backend_hostname, backend_port, backend_weight et backend_data_directory),
|
|
1589
|
+
de la même façon que dans le mode réplication.
|
|
1590
|
+
|
|
1591
|
+
De plus, il faut paramétrer <code>master_slave_mode</code> et
|
|
1592
|
+
<code>load_balance_mode</code> à <code>true</code>.
|
|
1593
|
+
|
|
1594
|
+
pgpool-II enverra alors les requêtes qui doivent être répliquées au serveur
|
|
1595
|
+
PostgreSQL maître, et les autres requêtes seront réparties parmi les différents
|
|
1596
|
+
serveurs lorsque c'est possible.
|
|
1597
|
+
|
|
1598
|
+
L'algorithme de pgpool-II prend bien sûr en compte les requêtes qui ne peuvent être
|
|
1599
|
+
réparties ; elles sont alors systématiquement envoyées au serveur maître.</p>
|
|
1600
|
+
|
|
1601
|
+
<p>Dans le mode maître-esclave, les DDL et DML pour une table temporaire ne
|
|
1602
|
+
peuvent être exécutées que sur le serveur maître.
|
|
1603
|
+
|
|
1604
|
+
Vous pouvez forcer un SELECT à ne s'exécuter que sur le maître en ajoutant un
|
|
1605
|
+
commentaire <code>/*NO LOAD BALANCE*/</code> devant le SELECT.</p>
|
|
1606
|
+
|
|
1607
|
+
<p>Dans le mode maître-esclave, vous devez positionner
|
|
1608
|
+
<code>replication_mode</code> à <code>false</code> et
|
|
1609
|
+
<code>master_slave_mode</code> à <code>true</code>.</p>
|
|
1610
|
+
|
|
1611
|
+
<p>Le mode maître-esclave a un sous-mode piloté par le paramètre
|
|
1612
|
+
<code>'master_slave_sub_mode'</code>. Il vaut par défaut
|
|
1613
|
+
<code>slony</code> et convient si vous utilisez Slony-I.
|
|
1614
|
+
|
|
1615
|
+
Vous pouvez aussi le paramétrer à <code>stream</code> si
|
|
1616
|
+
vous utilisez le système de réplication intégré à PostgreSQL (le
|
|
1617
|
+
Streaming Replication).
|
|
1618
|
+
|
|
1619
|
+
Le fichier de configuration d'exemple pour le sous-mode Slony-I
|
|
1620
|
+
est <code>pgpool.conf.sample-master-slave</code>, et celui
|
|
1621
|
+
concernant la Streaming Replication est
|
|
1622
|
+
<code>pgpool.conf.sample-stream</code>.
|
|
1623
|
+
</p>
|
|
1624
|
+
<p>
|
|
1625
|
+
Vous devez redémarrer pgpool-II si vous changez l'un des paramètres
|
|
1626
|
+
vu précédemment.
|
|
1627
|
+
</p>
|
|
1628
|
+
<p>
|
|
1629
|
+
Vous devrez probablement aussi renseigner les paramètres
|
|
1630
|
+
<code>white_function_list</code> et
|
|
1631
|
+
<code>black_function_list</code> si vous voulez contrôler plus finement
|
|
1632
|
+
la répartition de charge dans le mode maître-esclave.
|
|
1633
|
+
Reportez-vous à <a href="#white_function_list">white_function_list</a>
|
|
1634
|
+
pour plus de détails.
|
|
1635
|
+
</p>
|
|
1636
|
+
|
|
1637
|
+
<h4>Streaming Replication</h4>
|
|
1638
|
+
<p>
|
|
1639
|
+
Comme nous l'avons vu précédemment, pgpool-II peut fonctionner de pair avec
|
|
1640
|
+
la Streaming Replication, qui est disponible depuis la version 9.0 de PostgreSQL.
|
|
1641
|
+
Pour l'utiliser, il faut activer le paramètre master_slave et positionner le
|
|
1642
|
+
paramètre master_slave_sub_mode1 à stream. pgpool-II suppose que le Streaming
|
|
1643
|
+
Replication fonctionne et que les serveurs PostgreSQL esclaves sont en Hot
|
|
1644
|
+
Standby, ce qui signifie que les bases de données sont ouvertes en lecture
|
|
1645
|
+
seule sur ces derniers.
|
|
1646
|
+
|
|
1647
|
+
Les directives suivantes peuvent être utilisées dans ce mode :
|
|
1648
|
+
</p>
|
|
1649
|
+
<p>
|
|
1650
|
+
<ul>
|
|
1651
|
+
<li>delay_threshold
|
|
1652
|
+
<p>
|
|
1653
|
+
Permet de spécifier le décalage maximum toléré entre le serveur maître et
|
|
1654
|
+
un serveur esclave dans une réplication, exprimé en octets de journaux de
|
|
1655
|
+
transactions.
|
|
1656
|
+
Si le décalage dépasse <code>delay_threshold</code>, pgpool-II n'envoie
|
|
1657
|
+
alors plus de SELECT au serveur(s) esclave(s). Tout est alors envoyé au serveur
|
|
1658
|
+
maître, même si la répartition de charge est activée, jusqu'à ce que le(s) serveur(s)
|
|
1659
|
+
esclave(s) soit(soient) en deçà du décalage maximum autorisé.
|
|
1660
|
+
|
|
1661
|
+
Si <code>delay_threshold</code> est à <code>0</code> ou si le test
|
|
1662
|
+
de vie est désactivé, ce test de décalage n'est jamais fait. Ce dernier est
|
|
1663
|
+
effectué tous les <code>health_check_period</code>. La valeur par défaut
|
|
1664
|
+
pour <code>delay_threshold</code> est <code>0</code>.
|
|
1665
|
+
|
|
1666
|
+
Vous devez recharger la configuration de pgpool-II si vous changez cette
|
|
1667
|
+
directive.
|
|
1668
|
+
</p>
|
|
1669
|
+
|
|
1670
|
+
<li>log_standby_delay
|
|
1671
|
+
<p>
|
|
1672
|
+
Permet de spécifier comment le décalage de réplication est tracé dans le
|
|
1673
|
+
journal applicatif de pgpool-II. Si <code>none</code> est spécifié ici,
|
|
1674
|
+
rien n'est écrit. Si <code>always</code> est spécifié, alors le décalage
|
|
1675
|
+
sera tracé à chaque fois que le test est effectué.
|
|
1676
|
+
Si <code>if_over_threshold</code> est spécifié, alors le décalage est
|
|
1677
|
+
tracé uniquement lorsqu'il dépasse le <code>delay_threshold</code>.
|
|
1678
|
+
La valeur par défaut pour <code>log_standby_delay</code> est
|
|
1679
|
+
<code>none</code>.
|
|
1680
|
+
|
|
1681
|
+
Vous devez recharger la configuration de pgool-II si vous changez ce
|
|
1682
|
+
paramètre.
|
|
1683
|
+
</p>
|
|
1684
|
+
<p>
|
|
1685
|
+
Vous pouvez aussi superviser le décalage éventuel de la réplication en
|
|
1686
|
+
utilisant la commande "show pool_status".
|
|
1687
|
+
</p>
|
|
1688
|
+
</ul>
|
|
1689
|
+
</p>
|
|
1690
|
+
|
|
1691
|
+
<h4>Le failover avec la Streaming Replication</h4>
|
|
1692
|
+
<p>
|
|
1693
|
+
Dans le mode maître/esclave avec la Streaming Replication, si le
|
|
1694
|
+
nœud primaire ou le nœud en attente s'arrête, pgpool-II peut être
|
|
1695
|
+
configuré pour exécuter un Failover.
|
|
1696
|
+
Les nœuds peuvent alors être attachés automatiquement sans
|
|
1697
|
+
configuration ou opérations complémentaires.
|
|
1698
|
+
Alors qu'il est en pleine réplication [~], le nœud en attente vérifie
|
|
1699
|
+
régulièrement si un fichier de déclenchement existe. S'il le trouve,
|
|
1700
|
+
le nœud en attente sort de son mode réplication et s'ouvre en mode
|
|
1701
|
+
lecture/écriture. En utilisant ce mécanisme, on peut avoir une base
|
|
1702
|
+
de données en attente qui prends le relais quand le nœud primaire
|
|
1703
|
+
tombe.
|
|
1704
|
+
</p>
|
|
1705
|
+
<p>
|
|
1706
|
+
<strong>Attention : si vous pensez utiliser plusieurs nœuds en mode
|
|
1707
|
+
standby, il est recommandé de définir le paramètre delay_threshold pour
|
|
1708
|
+
empêcher tout requête dirigée vers d'autres nœuds en standby de
|
|
1709
|
+
récupérer des données plus vieilles.</strong>
|
|
1710
|
+
</p>
|
|
1711
|
+
<p>
|
|
1712
|
+
Si un second nœud en standby prends le relais quand le premier
|
|
1713
|
+
nœud en standby avait déjà pris le relais, vous pourriez avoir
|
|
1714
|
+
des données erronnées en provenance du second standby.
|
|
1715
|
+
Nous vous recommandons de ne pas utiliser ce genre de configuration.
|
|
1716
|
+
</p>
|
|
1717
|
+
<p>
|
|
1718
|
+
Voici commment configurer un mécanisme de Failover.
|
|
1719
|
+
</p>
|
|
1720
|
+
<p>
|
|
1721
|
+
<ol>
|
|
1722
|
+
<li>Il faut créer un script de Failover quelque part sur le système,
|
|
1723
|
+
par exemple dans /usr/local/pgsql/bin, puis le rendre exécutable.
|
|
1724
|
+
|
|
1725
|
+
<pre>
|
|
1726
|
+
$ cd /usr/loca/pgsql/bin
|
|
1727
|
+
$ cat failover_stream.sh
|
|
1728
|
+
#! /bin/sh
|
|
1729
|
+
# Commandes pour faire un Failover en mode Streaming Replication
|
|
1730
|
+
# Ce script suppose que le nœud Maitre est le 0 et 1 le standby
|
|
1731
|
+
#
|
|
1732
|
+
# Si le Standby s'arrête, ne rien faire. Si le Primaire s'arrête, créer
|
|
1733
|
+
# un fichier de déclenchement afin que le standby prenne le relais sur le
|
|
1734
|
+
# nœud Primaire.
|
|
1735
|
+
#
|
|
1736
|
+
# Arguments:
|
|
1737
|
+
# $1: identifiant du nœud qui ne répond plus
|
|
1738
|
+
# $2: nom d'hôte du nouveau maître
|
|
1739
|
+
# $3: chemin vers le fichier trigger
|
|
1740
|
+
|
|
1741
|
+
failed_node=$1
|
|
1742
|
+
new_master=$2
|
|
1743
|
+
trigger_file=$3
|
|
1744
|
+
|
|
1745
|
+
# Ne rien faire si c'est le standby qui tombe
|
|
1746
|
+
if [ $failed_node = 1 ]; then
|
|
1747
|
+
exit 0;
|
|
1748
|
+
fi
|
|
1749
|
+
|
|
1750
|
+
# Créer un fichier de déclenchement
|
|
1751
|
+
/usr/bin/ssh -T $new_master /bin/touch $trigger_file
|
|
1752
|
+
|
|
1753
|
+
exit 0;
|
|
1754
|
+
|
|
1755
|
+
chmod 755 failover_stream.sh
|
|
1756
|
+
</pre>
|
|
1757
|
+
<li>Il faut à présent définir la commande failover_commmand
|
|
1758
|
+
dans le fichier pgpool.conf :
|
|
1759
|
+
<pre>
|
|
1760
|
+
failover_command = '/usr/local/src/pgsql/9.0-beta/bin/failover_stream.sh %d %H /tmp/trigger_file0'
|
|
1761
|
+
</pre>
|
|
1762
|
+
|
|
1763
|
+
<li>Et créer le fichier recovery.conf sur le nœud en standby. Un
|
|
1764
|
+
<a href="recovery.conf.sample">exemple de fichier recovery.conf</a>
|
|
1765
|
+
est disponible dans le répertoire d'installation de PostgreSQL.
|
|
1766
|
+
Son nom complet est "share/recovery.conf.sample".
|
|
1767
|
+
Copier recovery.conf.sample en recovery.conf dans le répertoire de base
|
|
1768
|
+
de PostgreSQL et l'éditer comme suit.
|
|
1769
|
+
<pre>
|
|
1770
|
+
standby_mode = 'on'
|
|
1771
|
+
primary_conninfo = 'host=nom_du_nœud_primaire user=postgres'
|
|
1772
|
+
trigger_file = '/tmp/trigger_file0'
|
|
1773
|
+
</pre>
|
|
1774
|
+
|
|
1775
|
+
<li>Ajuster le postgresql.conf sur le nœud primaire. La configuration
|
|
1776
|
+
ci-dessous est donneé à titre indicatif, vous devrez probablement
|
|
1777
|
+
l'ajuster pour votre environnement.
|
|
1778
|
+
<pre>
|
|
1779
|
+
wal_level = hot_standby
|
|
1780
|
+
max_wal_senders = 1
|
|
1781
|
+
</pre>
|
|
1782
|
+
|
|
1783
|
+
<li>Définir pg_hba.conf sur le nœud Primaire. La configuration
|
|
1784
|
+
ci-dessous est donnée à titre indicatif, vous devrez probablement
|
|
1785
|
+
l'ajuster pour votre environnement.
|
|
1786
|
+
<pre>
|
|
1787
|
+
host replication postgres 192.168.0.10/32 trust
|
|
1788
|
+
</pre>
|
|
1789
|
+
|
|
1790
|
+
</ol>
|
|
1791
|
+
|
|
1792
|
+
<p>
|
|
1793
|
+
Démarrez PostgreSQL sur les nœuds primaire et secondaire pour initialiser
|
|
1794
|
+
la réplication. Si le nœud primaire venait à tomber, le nœud secondaire
|
|
1795
|
+
prendra automatiquement le relais, en tant que nouveau nœud primaire, et
|
|
1796
|
+
sera alors prêt à recevoir les requêtes en écriture.
|
|
1797
|
+
</p>
|
|
1798
|
+
|
|
1799
|
+
<h4>Streaming Replication</h4>
|
|
1800
|
+
<p>
|
|
1801
|
+
Lorsqu'on utilise la Streaming Replication et le Hot Standby, il est important
|
|
1802
|
+
de déterminer les requêtes pouvant être envoyées sur le nœud principal ou
|
|
1803
|
+
sur le nœud en standby (secondaire), et les requêtes qui ne peuvent pas l'être.
|
|
1804
|
+
Le mode Streaming Replication de pgpool-II se charge complètement de
|
|
1805
|
+
cette problématique.
|
|
1806
|
+
Dans ce chapitre, nous expliquerons comment pgpool-II parvient à cela.
|
|
1807
|
+
</p>
|
|
1808
|
+
<p>
|
|
1809
|
+
Nous distinguons les requêtes qui devraient être envoyées à tel ou tel
|
|
1810
|
+
nœud en les examinant.
|
|
1811
|
+
</p>
|
|
1812
|
+
<p>
|
|
1813
|
+
<ul>
|
|
1814
|
+
<li>Les requêtes suivantes devraient être envoyées au nœud primaire uniquement :
|
|
1815
|
+
<ul>
|
|
1816
|
+
<li>INSERT, UPDATE, DELETE, COPY FROM, TRUNCATE, CREATE, DROP, ALTER, COMMENT
|
|
1817
|
+
<li>SELECT ... FOR SHARE | UPDATE
|
|
1818
|
+
<li>SELECT dans un niveau d'isolation transactionnel de type SERIALIZABLE
|
|
1819
|
+
<li>LOCK, commande plus stricte que ROW EXCLUSIVE MODE
|
|
1820
|
+
<li>Quelques commandes transactionnelles :
|
|
1821
|
+
<ul>
|
|
1822
|
+
<li>BEGIN READ WRITE, START TRANSACTION READ WRITE
|
|
1823
|
+
<li>SET TRANSACTION READ WRITE, SET SESSION CHARACTERISTICS AS TRANSACTION READ WRITE
|
|
1824
|
+
<li>SET transaction_read_only = off
|
|
1825
|
+
</ul>
|
|
1826
|
+
<li>Les commandes relatives à la validation en deux phases : PREPARE TRANSACTION, COMMIT PREPARED, ROLLBACK PREPARED
|
|
1827
|
+
<li>LISTEN, UNLISTEN, NOTIFY
|
|
1828
|
+
<li>VACUUM
|
|
1829
|
+
<li>Quelques fonctions liées aux séquences (nextval et setval)
|
|
1830
|
+
<li>Les commandes de création de « Large Objects »
|
|
1831
|
+
</ul>
|
|
1832
|
+
<li>Ces requêtes peuvent être envoyées à la fois au nœud primaire et au
|
|
1833
|
+
nœud en standby. Si la répartition de charge est activée, ce type de requêtes
|
|
1834
|
+
peut être envoyé au nœud en standby.
|
|
1835
|
+
Cependant, si le paramètre delay_threshold est défini et que le délai dans la
|
|
1836
|
+
réplication est supérieur au delay_threshold, les requêtes sont envoyées au
|
|
1837
|
+
nœud primaire.
|
|
1838
|
+
<ul>
|
|
1839
|
+
<li>tout SELECT non listé ci-dessus
|
|
1840
|
+
<li>COPY TO
|
|
1841
|
+
<li>DECLARE, FETCH, CLOSE
|
|
1842
|
+
<li>SHOW
|
|
1843
|
+
</ul>
|
|
1844
|
+
<li>Les requêtes suivantes sont envoyées à la fois au nœud primaire et secondaire :
|
|
1845
|
+
<ul>
|
|
1846
|
+
<li>SET
|
|
1847
|
+
<li>DISCARD
|
|
1848
|
+
<li>DEALLOCATE ALL
|
|
1849
|
+
</ul>
|
|
1850
|
+
</ul>
|
|
1851
|
+
</p>
|
|
1852
|
+
|
|
1853
|
+
<p>
|
|
1854
|
+
Dans une transaction explicite :
|
|
1855
|
+
<ul>
|
|
1856
|
+
<li>Toute transaction commençant par une commande comme BEGIN est envoyée
|
|
1857
|
+
au nœud primaire.
|
|
1858
|
+
<li>Tout SELECT qui survient immédiatement après, ainsi que toutes les requêtes
|
|
1859
|
+
qui peuvent être envoyées aussi bien au primaire qu'au secondaire, sont réparties
|
|
1860
|
+
entre les nœuds.
|
|
1861
|
+
<li><p>
|
|
1862
|
+
Toute commande qui ne peut être exécutée sur un nœud en standby (secondaire)
|
|
1863
|
+
comme un INSERT sont envoyées uniquement au primaire.
|
|
1864
|
+
Après toute commande de ce type, absolument tous les ordres SQL sont envoyés
|
|
1865
|
+
au nœud primaire. En effet, les SELECT suivant pourraient vouloir voir les
|
|
1866
|
+
résultats d'un INSERT immédiatement.
|
|
1867
|
+
Ce comportement continue jusqu'à ce que la transaction se ferme ou soit
|
|
1868
|
+
interrompue.
|
|
1869
|
+
</p>
|
|
1870
|
+
</ul>
|
|
1871
|
+
</p>
|
|
1872
|
+
|
|
1873
|
+
<p>
|
|
1874
|
+
Dans le protocole étendu, il est possible de déterminer si la requête
|
|
1875
|
+
peut être envoyée au nœud en standby ou pas dans le mode de répartition de charge
|
|
1876
|
+
au moment où on analyse la requête. Les rêgles sont les mêmes que dans le
|
|
1877
|
+
protocole non-étendu.
|
|
1878
|
+
Par exemple, les INSERT sont envoyés au primaire, ainsi que toute requête
|
|
1879
|
+
qui suivra.
|
|
1880
|
+
</p>
|
|
1881
|
+
|
|
1882
|
+
<p>
|
|
1883
|
+
Note : si l'analyse d'une requête en SELECT est envoyée sur le standby à
|
|
1884
|
+
cause de la répartition de charge et qu'une requête en modification de données, comme
|
|
1885
|
+
un INSERT est envoyé à pgpool-II, alors le SELECT analysé devra être exécuté
|
|
1886
|
+
sur le nœud primaire. Cependant, on analyse de nouveau le SELECT sur le nœud primaire.
|
|
1887
|
+
|
|
1888
|
+
<p>
|
|
1889
|
+
Enfin, les requêtes qui semblent douteuses ou possiblement en erreur sont
|
|
1890
|
+
envoyées sur le nœud primaire.
|
|
1891
|
+
</p>
|
|
1892
|
+
|
|
1893
|
+
<h4>Online recovery avec la Streaming Replication</h4>
|
|
1894
|
+
<p>
|
|
1895
|
+
Dans le mode maître/esclave avec la Streaming Replication, on peut procéder à une
|
|
1896
|
+
restauration à chaud (« Online recovery »).
|
|
1897
|
+
Cependant, seul un nœud en standby peut être ainsi récupéré. On ne peut pas
|
|
1898
|
+
reconstruire un nœud primaire. Pour ce faire, il faudra stopper toutes les
|
|
1899
|
+
bases de données, ainsi que pgpool-II, puis restaurer le nœud primaire à
|
|
1900
|
+
partir d'une sauvegarde.
|
|
1901
|
+
</p>
|
|
1902
|
+
|
|
1903
|
+
<p>
|
|
1904
|
+
Voici les étapes.
|
|
1905
|
+
<ol>
|
|
1906
|
+
<li>Définir le paramètre recovery_user. C'est souvent postgres.
|
|
1907
|
+
<pre>
|
|
1908
|
+
recovery_user = 'postgres'
|
|
1909
|
+
</pre>
|
|
1910
|
+
<li>Définir le paramètre recovery_password pour que le recovery_user
|
|
1911
|
+
puisse se connecter à la base.
|
|
1912
|
+
<pre>
|
|
1913
|
+
recovery_password = 't-ishii'
|
|
1914
|
+
</pre>
|
|
1915
|
+
|
|
1916
|
+
<li> Définir le paramètre recovery_1st_stage_command.
|
|
1917
|
+
Le script pour cette étape doit procéder à une sauvegarde
|
|
1918
|
+
du nœud primaire et à sa restauration sur le nœud en standby.
|
|
1919
|
+
Placez ce script à l'intérieur du répertoire de données du nœud primaire
|
|
1920
|
+
et donnez-lui les droits nécessaires pour être exécutable.
|
|
1921
|
+
Un script d'exemple est disponible : <a href="basebackup.sh">basebackup.sh</a>,
|
|
1922
|
+
avec une configuration simple d'un primaire et d'un standby.
|
|
1923
|
+
Il faut configurer SSH pour que l'utilisateur indiqué dans le paramètre
|
|
1924
|
+
recovery_user puisse se connecter depuis le primaire vers le standby sans
|
|
1925
|
+
qu'un mot de passe ne soit demandé.
|
|
1926
|
+
<pre>
|
|
1927
|
+
recovery_1st_stage_command = 'basebackup.sh'
|
|
1928
|
+
</pre>
|
|
1929
|
+
<li>Laisser le paramètre recovery_2nd_stage_command vide.
|
|
1930
|
+
<pre>
|
|
1931
|
+
recovery_2nd_stage_command = ''
|
|
1932
|
+
</pre>
|
|
1933
|
+
|
|
1934
|
+
<li>Installer à présent les fonctions C et SQL nécessaires dans chacune
|
|
1935
|
+
des bases de données pour que le « online recovery » fonctionne.
|
|
1936
|
+
</p>
|
|
1937
|
+
|
|
1938
|
+
<pre>
|
|
1939
|
+
# cd pgpool-II-x.x.x/sql/pgpool-recovery
|
|
1940
|
+
# make
|
|
1941
|
+
# make install
|
|
1942
|
+
# psql -f pgpool-recovery.sql template1
|
|
1943
|
+
</pre>
|
|
1944
|
+
|
|
1945
|
+
<li>Après avoir terminé le « online recovery », pgpool-II démarre PostgreSQL
|
|
1946
|
+
sur le nœud standby.
|
|
1947
|
+
À cet effet, il faut installer un script sur chacun des nœuds.
|
|
1948
|
+
Un <a href="pgpool_remote_start">script d'exemple</a> est inclus dans le
|
|
1949
|
+
répertoire sample du répertoire des sources.
|
|
1950
|
+
Ce script utilise SSH. Il faudra permettre à l'utilisateur indiqué dans
|
|
1951
|
+
le paramètre recovery_user de se connecter depuis le primaire vers le standby
|
|
1952
|
+
sans qu'un mot de passe ne soit demandé.
|
|
1953
|
+
</ol>
|
|
1954
|
+
</p>
|
|
1955
|
+
|
|
1956
|
+
<p>
|
|
1957
|
+
C'est tout.
|
|
1958
|
+
On peut à présent utiliser pcp_recovery_node (dès qu'un nœud en standby
|
|
1959
|
+
s'arrête) ou alors cliquer sur le bouton « recovery » dans l'interface de
|
|
1960
|
+
pgpoolAdmin pour exécuter un « Online Recovery ».
|
|
1961
|
+
</p>
|
|
1962
|
+
|
|
1963
|
+
<h3>Mode parallèle</h3>
|
|
1964
|
+
|
|
1965
|
+
<p>Ce mode permet l'exécution en parallèle de requêtes. Les tables
|
|
1966
|
+
peuvent être découpées, et les données distribuées sur chaque nœud. De plus,
|
|
1967
|
+
les fonctionnalités de réplication et de répartition de charge peuvent être utilisées
|
|
1968
|
+
avec ce mode, en même temps. Dans le mode parallèle, replication_mode et
|
|
1969
|
+
load_balance_mode sont positionnés à true dans le fichier pgpool.conf, alors
|
|
1970
|
+
que master_slave est positionné à false, et que parallel_mode est positionné
|
|
1971
|
+
à true. Si ce paramètre est changé, il faut redémarrer pgpool-II pour qu'il
|
|
1972
|
+
soit pris en compte.
|
|
1973
|
+
</p>
|
|
1974
|
+
|
|
1975
|
+
<h4><p>Configuration de la base système</p></h4>
|
|
1976
|
+
|
|
1977
|
+
<p>Pour utiliser le mode parallèle, la base système doit être configurée
|
|
1978
|
+
correctement. La base système contient des règles, stockées dans une table,
|
|
1979
|
+
pour choisir le nœud PostgreSQL approprié auquel envoyer les données.
|
|
1980
|
+
La base de données système n'a pas besoin d'être créée sur le même nœud que
|
|
1981
|
+
pgpool-II. La configuration de cette dernière est faite dans
|
|
1982
|
+
<code>pgpool.conf</code>.</p>
|
|
1983
|
+
|
|
1984
|
+
<dl>
|
|
1985
|
+
<dt>system_db_hostname</dt>
|
|
1986
|
+
<dd>
|
|
1987
|
+
<p>Nom de l'hôte où la base de données système réside. Une chaîne vide
|
|
1988
|
+
dans ce paramètre ('') signifie que celle-ci est sur le même nœud que
|
|
1989
|
+
pgpool-II, et sera alors accédée via un socket UNIX.</p>
|
|
1990
|
+
</dd>
|
|
1991
|
+
|
|
1992
|
+
<dt>system_db_port</dt>
|
|
1993
|
+
<dd>
|
|
1994
|
+
<p>Numéro de port de la base de données système</p>
|
|
1995
|
+
</dd>
|
|
1996
|
+
|
|
1997
|
+
<dt>system_dbname</dt>
|
|
1998
|
+
<dd>
|
|
1999
|
+
<p>Les règles de partitionnement et autres informations seront définies
|
|
2000
|
+
dans la base de données spécifiée ici. La valeur par défaut est
|
|
2001
|
+
<code>'pgpool'</code>.</p>
|
|
2002
|
+
</dd>
|
|
2003
|
+
|
|
2004
|
+
<dt>system_db_schema</dt>
|
|
2005
|
+
<dd>
|
|
2006
|
+
<p>Les règles de partitionnement et autres informations seront stockées
|
|
2007
|
+
dans le schéma spécifié ici. La valeur par défaut est
|
|
2008
|
+
<code>'pgpool_catalog'</code>.</p>
|
|
2009
|
+
</dd>
|
|
2010
|
+
|
|
2011
|
+
<dt>system_db_user</dt>
|
|
2012
|
+
<dd>
|
|
2013
|
+
<p>Nom de l'utilisateur qui se connecte à la base de données système.</p>
|
|
2014
|
+
</dd>
|
|
2015
|
+
|
|
2016
|
+
<dt>system_db_password</dt>
|
|
2017
|
+
<dd>
|
|
2018
|
+
<p>Mot de passe pour l'utilisateur de la base de données système. Si aucun mot de passe
|
|
2019
|
+
n'est nécessaire, laissez une chaîne vide dans ce paramètre ('').</p>
|
|
2020
|
+
</dd>
|
|
2021
|
+
|
|
2022
|
+
<dt>ssl_ca_cert</dt>
|
|
2023
|
+
<dd>
|
|
2024
|
+
<p>
|
|
2025
|
+
Chemin complet vers un fichier au format PEM contenant un ou plusieurs
|
|
2026
|
+
certificats CA, qui doivent être utilisés pour vérifier le certificat du
|
|
2027
|
+
serveur. C'est analogue à l'option <code>-CAfile</code> de la
|
|
2028
|
+
commande <code>verify(1)</code> d'OpenSSL.
|
|
2029
|
+
</p>
|
|
2030
|
+
|
|
2031
|
+
<p>
|
|
2032
|
+
Il n'y a pas de valeur par défaut pour cette option. Du coup, aucune
|
|
2033
|
+
vérification n'a lieu par défaut. Par contre, une vérification sera réalisée
|
|
2034
|
+
si une valeur a été définie pour <code>ssl_ca_cert_dir</code>.
|
|
2035
|
+
</p>
|
|
2036
|
+
</dd>
|
|
2037
|
+
|
|
2038
|
+
<dt>ssl_ca_cert_dir</dt>
|
|
2039
|
+
<dd>
|
|
2040
|
+
<p>
|
|
2041
|
+
Chemin vers un répertoire qui contient les certificats CA au format PEM,
|
|
2042
|
+
qui peuvent être utilisés pour vérifier le certificat du serveur.
|
|
2043
|
+
C'est analogue à l'option <code>-CAfile</code> de la commande
|
|
2044
|
+
<code>verify(1)</code> d'OpenSSL.
|
|
2045
|
+
</p>
|
|
2046
|
+
|
|
2047
|
+
<p>
|
|
2048
|
+
Il n'y a pas de valeur par défaut pour cette option. Du coup, aucune
|
|
2049
|
+
vérification n'a lieu par défaut. Par contre, une vérification sera réalisée
|
|
2050
|
+
si une valeur a été définie pour <code>ssl_ca_cert</code>.
|
|
2051
|
+
</p>
|
|
2052
|
+
</dd>
|
|
2053
|
+
|
|
2054
|
+
</dl>
|
|
2055
|
+
|
|
2056
|
+
<h4><p>Configuration initiale de la base de données système</p></h4>
|
|
2057
|
+
|
|
2058
|
+
<p>Il faut d'abord créer la base de données et le schéma spécifiés dans le
|
|
2059
|
+
fichier <code>pgpool.conf</code>. Un script d'exemple peut être trouvé dans
|
|
2060
|
+
<code>$prefix/share/system_db.sql</code>. Si vous avez indiqué un nom
|
|
2061
|
+
différent pour la base de données ou le schéma, adaptez ce script en
|
|
2062
|
+
conséquence.
|
|
2063
|
+
<pre>
|
|
2064
|
+
psql -f $prefix/share/system_db.sql pgpool
|
|
2065
|
+
</pre>
|
|
2066
|
+
|
|
2067
|
+
</p>
|
|
2068
|
+
|
|
2069
|
+
<h4><p>Enregistrement d'une règle de partitionnement</p></h4>
|
|
2070
|
+
|
|
2071
|
+
<p>Les règles pour le partitionnement des données doivent être enregistrées
|
|
2072
|
+
dans la table <code>pgpool_catalog.dist_def</code>.</p>
|
|
2073
|
+
|
|
2074
|
+
<pre>
|
|
2075
|
+
CREATE TABLE pgpool_catalog.dist_def(
|
|
2076
|
+
dbname TEXT, -- nom de la base
|
|
2077
|
+
schema_name TEXT, -- nom du schéma
|
|
2078
|
+
table_name TEXT, -- nom de la table
|
|
2079
|
+
col_name TEXT NOT NULL CHECK (col_name = ANY (col_list)), -- nom de la colonne
|
|
2080
|
+
de la clé de partitionnement
|
|
2081
|
+
col_list TEXT[] NOT NULL, -- noms des
|
|
2082
|
+
attributs de la table
|
|
2083
|
+
type_list TEXT[] NOT NULL, -- types de
|
|
2084
|
+
données de la table des attributs
|
|
2085
|
+
dist_def_func TEXT NOT NULL, -- nom de la
|
|
2086
|
+
fonction pour la règle de partitionnement
|
|
2087
|
+
PRIMARY KEY (dbname,schema_name,table_name)
|
|
2088
|
+
);
|
|
2089
|
+
</pre>
|
|
2090
|
+
|
|
2091
|
+
|
|
2092
|
+
<h4><p>Enregistrement d'une règle de réplication</p></h4>
|
|
2093
|
+
<p>
|
|
2094
|
+
Les tables qui ne sont pas distribuées doivent être répliquées. Lorsqu'une
|
|
2095
|
+
requête fait la jointure d'une table distribuée avec une autre table, pgpool
|
|
2096
|
+
récupère l'information de réplication dans la table pgpool_catalog.replicate_def.
|
|
2097
|
+
Ainsi, une table est soit répliquée, soit ditribuée.
|
|
2098
|
+
</p>
|
|
2099
|
+
|
|
2100
|
+
<pre>
|
|
2101
|
+
CREATE TABLE pgpool_catalog.replicate_def(
|
|
2102
|
+
dbname TEXT, --nom de la base
|
|
2103
|
+
schema_name TEXT, --nom du schéma
|
|
2104
|
+
table_name TEXT, --nom de la table
|
|
2105
|
+
col_list TEXT[] NOT NULL, -- nom des attributs de la table
|
|
2106
|
+
type_list TEXT[] NOT NULL, -- types de données des attributs de
|
|
2107
|
+
la table
|
|
2108
|
+
PRIMARY KEY (dbname,schema_name,table_name)
|
|
2109
|
+
);
|
|
2110
|
+
</pre>
|
|
2111
|
+
|
|
2112
|
+
<h4><p>Exemple basé sur le partitionnement des tables de pgbench</p></h4>
|
|
2113
|
+
|
|
2114
|
+
<p>pgbench est un outil simple de tests de performance de PostgreSQL, disponible
|
|
2115
|
+
dans le répertoire contrib de PostgreSQL.</p>
|
|
2116
|
+
|
|
2117
|
+
<p>
|
|
2118
|
+
Dans cet exemple, la table accounts est partitionnée, les tables
|
|
2119
|
+
branches et tellers sont répliquées.
|
|
2120
|
+
Les tables accounts et branches sont jointes sur la colonne bid.
|
|
2121
|
+
La table branches est enregistrée dans la table de réplication.
|
|
2122
|
+
Si les trois tables (accounts, branches et tellers) doivent être jointes,
|
|
2123
|
+
il est nécessaire d'enregistrer aussi une règle de réplication pour la table
|
|
2124
|
+
tellers.
|
|
2125
|
+
</p>
|
|
2126
|
+
|
|
2127
|
+
<pre>
|
|
2128
|
+
INSERT INTO pgpool_catalog.dist_def VALUES (
|
|
2129
|
+
'pgpool',
|
|
2130
|
+
'public',
|
|
2131
|
+
'accounts',
|
|
2132
|
+
'aid',
|
|
2133
|
+
ARRAY['aid','bid','abalance','filler'],
|
|
2134
|
+
ARRAY['integer','integer','integer','character(84)'],
|
|
2135
|
+
'pgpool_catalog.dist_def_accounts'
|
|
2136
|
+
);
|
|
2137
|
+
|
|
2138
|
+
INSERT INTO pgpool_catalog.replicate_def VALUES (
|
|
2139
|
+
'pgpool',
|
|
2140
|
+
'public',
|
|
2141
|
+
'branches',
|
|
2142
|
+
ARRAY['bid','bbalance','filler'],
|
|
2143
|
+
ARRAY['integer','integer','character(84)']
|
|
2144
|
+
);
|
|
2145
|
+
</pre>
|
|
2146
|
+
|
|
2147
|
+
<p>La règle de partitionnement (ici, pgpool_catalog.dist_def_accounts) prends
|
|
2148
|
+
une valeur pour la colonne qui sert de clé de partitionnement, et retourne le
|
|
2149
|
+
numéro du nœud de la base de données correspondante. Notez que l'identifiant
|
|
2150
|
+
des nœuds doit commencer par 0. Voici un exemple de cette fonction pour
|
|
2151
|
+
pgbench.
|
|
2152
|
+
</p>
|
|
2153
|
+
<pre>
|
|
2154
|
+
CREATE OR REPLACE FUNCTION pgpool_catalog.dist_def_accounts (val ANYELEMENT) RETURNS INTEGER AS '
|
|
2155
|
+
SELECT CASE WHEN $1 >= 1 and $1 <= 30000 THEN 0
|
|
2156
|
+
WHEN $1 > 30000 and $1 <= 60000 THEN 1
|
|
2157
|
+
ELSE 2
|
|
2158
|
+
</pre>
|
|
2159
|
+
|
|
2160
|
+
<h2><a name="hba"></a>Configuration de pool_hba.conf pour l'authentification
|
|
2161
|
+
des clients (HBA)</h2>
|
|
2162
|
+
<p>
|
|
2163
|
+
Tout comme le fichier pg_hba.conf pour PostgreSQL, pgpool a la même
|
|
2164
|
+
fonctionnalité d'authentification des clients, qui est basée sur un fichier
|
|
2165
|
+
appelé pool_hba.conf.
|
|
2166
|
+
</p>
|
|
2167
|
+
<p>
|
|
2168
|
+
Lorsque pgpool est installé, le fichier pool_hba.conf.sample est installé
|
|
2169
|
+
dans /usr/local/etc, qui est le répertoire par défaut des fichiers de
|
|
2170
|
+
configuration. Il faut copier pool_hba.conf.sample en pool_hba.conf puis
|
|
2171
|
+
l'éditer si nécessaire. Par défaut, l'authentification par pool_hba est
|
|
2172
|
+
activée. Se reporter à « 6. Configuration de pgpool.conf » pour plus de détails.
|
|
2173
|
+
</p>
|
|
2174
|
+
<p>
|
|
2175
|
+
Le format du fichier pool_hba.conf est très similaire à celui du fichier
|
|
2176
|
+
pg_hba.conf de PostgreSQL.
|
|
2177
|
+
</p>
|
|
2178
|
+
<pre>
|
|
2179
|
+
local DATABASE USER METHOD [OPTION]
|
|
2180
|
+
host DATABASE USER CIDR-ADDRESS METHOD [OPTION]
|
|
2181
|
+
</pre>
|
|
2182
|
+
<p>
|
|
2183
|
+
Voir pool_hba.conf.sample pour une explication détaillée de chaque champ.
|
|
2184
|
+
</p>
|
|
2185
|
+
<p>
|
|
2186
|
+
Voici les limitations de pool_hba.
|
|
2187
|
+
<ul>
|
|
2188
|
+
<li>la connexion de type hostssl n'est pas supportée</li>
|
|
2189
|
+
<p>
|
|
2190
|
+
Bien que hostssl soit invalide, pgpool-II 2.3 et supérieur supporte
|
|
2191
|
+
SSL. Voir <a href="#ssl">SSL</a> pour plus de détails.
|
|
2192
|
+
</p>
|
|
2193
|
+
<li>samegroup dans la colonne DATABASE n'est pas supporté</li>
|
|
2194
|
+
<p>
|
|
2195
|
+
Comme pgpool ne sait rien à propos des utilisateurs déclarés dans le
|
|
2196
|
+
serveur PostgreSQL, le nom de la base de données est testé simplement
|
|
2197
|
+
par rapport aux entrées de la colonne DATABASE dans le fichier
|
|
2198
|
+
pool_hba.conf.
|
|
2199
|
+
</p>
|
|
2200
|
+
<li>les noms de groupes suivis du signe + pour la colonne USER ne sont pas
|
|
2201
|
+
supportés</li>
|
|
2202
|
+
<p>
|
|
2203
|
+
Cela est dû à la même raison que pour samegroup décrit ci-dessus.
|
|
2204
|
+
Un nom d'utilisateur est testé simplement par rapport aux entrées
|
|
2205
|
+
dans la colonne USER du fichier pool_hba.conf.
|
|
2206
|
+
</p>
|
|
2207
|
+
<li>l'IPv6 pour l'adresse/masque dans la colonne IP n'est pas supporté</li>
|
|
2208
|
+
<p>
|
|
2209
|
+
À ce jour, pgpool ne supporte pas l'IPv6.
|
|
2210
|
+
</p>
|
|
2211
|
+
<li>Seules les méthodes trust, reject, md5 et pam sont supportées
|
|
2212
|
+
dans la colonne METHOD</li>
|
|
2213
|
+
<p>
|
|
2214
|
+
Encore une fois, c'est pour la même raison que pour samegroup (décrit
|
|
2215
|
+
ci-dessus) : pgpool n'a pas accès aux informations sur les utilisateurs et
|
|
2216
|
+
mots de passes stockés dans le serveur PostgreSQL.
|
|
2217
|
+
</p>
|
|
2218
|
+
<p>
|
|
2219
|
+
Pour utiliser l'authentification md5, il faudra enregistrer votre nom
|
|
2220
|
+
d'utilisateur et son mot de passe dans pool_passwd.
|
|
2221
|
+
Voir <a href="#md5">Authentification / Contrôle d'accès</a> pour plus de
|
|
2222
|
+
détails.
|
|
2223
|
+
</ul>
|
|
2224
|
+
<p>
|
|
2225
|
+
Notez que tout ce qui est décrit dans cette section concerne
|
|
2226
|
+
l'authentification entre un client et pgpool ; un client doit toujours
|
|
2227
|
+
passer à travers le processus d'authentification de PostgreSQL. Bien que
|
|
2228
|
+
pool_hba soit concerné, cela n'a pas d'importance si un nom d'utilisateur
|
|
2229
|
+
et/ou de base de données donné par un client (i.e. psql -U testuser testdb)
|
|
2230
|
+
existe ou non dans le serveur. pool_hba ne regarde en effet que si une
|
|
2231
|
+
correspondance est trouvée dans le fichier pool_hba.conf.
|
|
2232
|
+
</p>
|
|
2233
|
+
|
|
2234
|
+
<p>
|
|
2235
|
+
L'authentification PAM fonctionne grâce à l'information sur l'utilisateur
|
|
2236
|
+
trouvée sur le serveur où pgpool est exécuté. Pour activer le support de PAM
|
|
2237
|
+
dans pgpool, spécifier l'option "--with-pam" lors de la phase de configuration
|
|
2238
|
+
de la compilation :
|
|
2239
|
+
</p>
|
|
2240
|
+
<pre>
|
|
2241
|
+
configure --with-pam
|
|
2242
|
+
</pre>
|
|
2243
|
+
<p>
|
|
2244
|
+
Pour activer l'authentification PAM, on a besoin de créer un fichier de
|
|
2245
|
+
configuration du service pour pgpool dans le répertoire de configuration de
|
|
2246
|
+
PAM sur le système (qui est en général /etc/pam.d). Un fichier d'exemple
|
|
2247
|
+
nommé share/pgpool.pam est présent dans le répertoire d'installation.
|
|
2248
|
+
</p>
|
|
2249
|
+
|
|
2250
|
+
<h2>Configuration de la méthode de cache de requêtes</h2>
|
|
2251
|
+
<p>Le cache de requêtes est utilisable dans tous les modes de pgpool-II.
|
|
2252
|
+
Son activation dans le fichier pgpool.conf se fait de la manière suivante :
|
|
2253
|
+
<pre>
|
|
2254
|
+
enable_query_cache = true
|
|
2255
|
+
</pre>
|
|
2256
|
+
|
|
2257
|
+
<p>
|
|
2258
|
+
Cependant, il faut aussi créer la table suivante dans la base de
|
|
2259
|
+
données système de pgpool-II :
|
|
2260
|
+
</p>
|
|
2261
|
+
<pre>
|
|
2262
|
+
CREATE TABLE pgpool_catalog.query_cache (
|
|
2263
|
+
hash TEXT,
|
|
2264
|
+
query TEXT,
|
|
2265
|
+
value bytea,
|
|
2266
|
+
dbname TEXT,
|
|
2267
|
+
create_time TIMESTAMP WITH TIME ZONE,
|
|
2268
|
+
PRIMARY KEY(hash, dbname)
|
|
2269
|
+
);
|
|
2270
|
+
</pre>
|
|
2271
|
+
<p>
|
|
2272
|
+
Notez qu'il peut aussi être nécessaire de modifier le nom du schéma dans l'exemple
|
|
2273
|
+
ci-dessus si pgpool_catalog n'est pas utilisé.
|
|
2274
|
+
</p>
|
|
2275
|
+
|
|
2276
|
+
<h1>Démarrage et arrêt de pgpool-II<a name="start"></a></h1>
|
|
2277
|
+
|
|
2278
|
+
<p>Tous les serveurs PostgreSQL doivent être démarrés, y compris celui qui
|
|
2279
|
+
contient la base de données système de pgpool-II (si le mode utilisé l'impose),
|
|
2280
|
+
avant de démarrer pgpool-II.</p>
|
|
2281
|
+
|
|
2282
|
+
<pre>
|
|
2283
|
+
pgpool [-c][-f config_file][-a hba_file][-F pcp_config_file][-n][-D][-d]
|
|
2284
|
+
</pre>
|
|
2285
|
+
<p>
|
|
2286
|
+
<table>
|
|
2287
|
+
<tr><td>-c<br/>--clear-cache</td><td>vide le cache de requêtes</tr>
|
|
2288
|
+
<tr><td>-f config_file<br/>--config-file config-file</td><td>spécifie
|
|
2289
|
+
le fichier pgpool.conf</tr>
|
|
2290
|
+
<tr><td>-a hba_file<br/>--hba-file hba_file</td><td>spécifie le
|
|
2291
|
+
fichier pool_hba.conf</tr>
|
|
2292
|
+
<tr><td>-F pcp_config_file<br/>--pcp-password-file</td><td>spécifie
|
|
2293
|
+
le fichier pcp.conf</tr>
|
|
2294
|
+
<tr><td>-n<br/>--no-daemon</td><td>ne pas fonctionner en mode démon
|
|
2295
|
+
(le terminal n'est alors pas détaché)</tr>
|
|
2296
|
+
<tr><td>-D<br/>--discard-status</td><td>ignore le fichier de statut
|
|
2297
|
+
précédent</tr>
|
|
2298
|
+
<tr><td>-d<br/>--debug</td><td>mode de débogage</tr>
|
|
2299
|
+
</table>
|
|
2300
|
+
pgpool-II peut être arrêté de deux façons. La première est d'utiliser une
|
|
2301
|
+
commande PCP (détaillée plus loin dans ce document). La seconde est d'utiliser
|
|
2302
|
+
une commande pgpool-II, dont voici un exemple :
|
|
2303
|
+
</p>
|
|
2304
|
+
|
|
2305
|
+
<pre>
|
|
2306
|
+
pgpool [-f config_file][-F pcp_config_file] [-m {s[mart]|f[ast]|i[mmediate]}] stop
|
|
2307
|
+
</pre>
|
|
2308
|
+
<p>
|
|
2309
|
+
<table>
|
|
2310
|
+
<tr><td><code>-m s[mart]</code><br/><code>--mode s[mart]</code></td>
|
|
2311
|
+
<td>attends que les clients se déconnectent avant de s'arrêter (mode par
|
|
2312
|
+
défaut)</td></tr>
|
|
2313
|
+
<tr><td><code>-m f[ast]</code><br/><code>--mode f[ast]</code></td>
|
|
2314
|
+
<td>n'attend pas la déconnexion des clients, et s'arrête
|
|
2315
|
+
immédiatement</td></tr>
|
|
2316
|
+
<tr><td><code>-m i[mmediate]</code><br/><code>--mode i[mmediate]</code></td>
|
|
2317
|
+
<td>même chose que <code>'-m f'</code></td></tr> </table>
|
|
2318
|
+
</p>
|
|
2319
|
+
<p>
|
|
2320
|
+
pgpool enregistre son état dans le fichier [logdir]/pgpool_status. Lorsque
|
|
2321
|
+
pgpool redémarre, il lit ce fichier et restaure le statut de chaque serveur (tel qu'il
|
|
2322
|
+
était à l'arrêt de pgpool). Cela permettra d'éviter une différence au niveau
|
|
2323
|
+
des données dans les différents nœuds PostgreSQL, qui pourrait être causée
|
|
2324
|
+
selon le scénario suivant :
|
|
2325
|
+
<ol>
|
|
2326
|
+
<li>Un serveur s'arrête inopinément et pgpool exécute la procédure de fail-over
|
|
2327
|
+
<li>Une mise à jour est effectuée sur l'une des bases de données actives, via
|
|
2328
|
+
pgpool
|
|
2329
|
+
<li>L'administrateur décide d'arrêter pgpool
|
|
2330
|
+
<li>Quelqu'un d'autre décide de redémarrer la base de données qui est en train
|
|
2331
|
+
de s'arrêter, sans en informer l'administrateur
|
|
2332
|
+
<li>L'administrateur redémarre pgpool
|
|
2333
|
+
</ol>
|
|
2334
|
+
</p>
|
|
2335
|
+
<p>
|
|
2336
|
+
Si, pour une raison quelconque, la base de données arrêtée a été synchronisée
|
|
2337
|
+
avec la base de données active d'une autre manière, pgpool_status peut alors
|
|
2338
|
+
être supprimé sereinement avant de démarrer pgpool.
|
|
2339
|
+
</p>
|
|
2340
|
+
|
|
2341
|
+
<h1>Rechargement des fichiers de configuration de pgpool-II<a
|
|
2342
|
+
name="reload"></a></h1>
|
|
2343
|
+
<p>pgpool-II peut recharger ses fichiers de configuration et se mettre alors à
|
|
2344
|
+
jour par rapport à ces derniers, sans avoir à être redémarré.
|
|
2345
|
+
</p>
|
|
2346
|
+
|
|
2347
|
+
<pre>
|
|
2348
|
+
pgpool [-c][-f config_file][-a hba_file][-F pcp_config_file] reload
|
|
2349
|
+
</pre>
|
|
2350
|
+
<p>
|
|
2351
|
+
<table>
|
|
2352
|
+
<tr><td>-f config_file<br/>--config-file config-file</td><td>spécifie
|
|
2353
|
+
le fichier pgpool.conf</tr>
|
|
2354
|
+
<tr><td>-a hba_file<br/>--hba-file hba_file</td><td>spécifie le
|
|
2355
|
+
fichier pool_hba.conf</tr>
|
|
2356
|
+
<tr><td>-F pcp_config_file<br/>--pcp-password-file</td><td>spécifie
|
|
2357
|
+
le fichier pcp.conf</tr>
|
|
2358
|
+
</table>
|
|
2359
|
+
|
|
2360
|
+
<p>
|
|
2361
|
+
Il faut bien faire attention au fait que certains paramètres de configuration
|
|
2362
|
+
ne peuvent pas être changés par un rechargement. De plus, la nouvelle
|
|
2363
|
+
configuration ne prend effet qu'à partir des nouvelles sessions créées.
|
|
2364
|
+
</p>
|
|
2365
|
+
|
|
2366
|
+
<h1><a name="show-commands"></a>Commandes SHOW</h1>
|
|
2367
|
+
<h2>Aperçu</h2>
|
|
2368
|
+
<p>
|
|
2369
|
+
pgpool-II donne quelques informations via les commandes SHOW. SHOW est une
|
|
2370
|
+
commande SQL existante, mais pgpool-II l'intercepte si la requête concerne des
|
|
2371
|
+
informations spécifiques à pgpool-II. Voici les options spécifiques à pgpool-II :
|
|
2372
|
+
<ul>
|
|
2373
|
+
<li>pool_status, pour avoir la configuration</li>
|
|
2374
|
+
<li>pool_nodes, pour avoir des informations sur les nœuds</li>
|
|
2375
|
+
<li>pool_processes, pour avoir l'information sur les processus de
|
|
2376
|
+
pgpool-II</li>
|
|
2377
|
+
<li>pool_pools, pour avoir l'information sur les pools de pgpool-II</li>
|
|
2378
|
+
<li>pool_version, pour avoir la version de pgpool-II</li>
|
|
2379
|
+
</ul>
|
|
2380
|
+
<p>
|
|
2381
|
+
<u>Note</u> : Le terme 'pool' réfère au nombre de sessions PostgreSQL détenues
|
|
2382
|
+
par un processus pgpool, et non le nombre total de sessions détenues par pgpool.
|
|
2383
|
+
</p>
|
|
2384
|
+
</p>
|
|
2385
|
+
<p>L'option pool_status était disponible dans les versions précédentes, mais
|
|
2386
|
+
les autres sont apparues avec la version 3.0.</p>
|
|
2387
|
+
<h2>pool_status</h2>
|
|
2388
|
+
<p>"SHOW pool_status" renvoie la liste des paramètres de configuration avec
|
|
2389
|
+
leur nom, leur valeur et leur description. Voici un exemple du résultat obtenu
|
|
2390
|
+
avec cette commande :
|
|
2391
|
+
<pre>
|
|
2392
|
+
benchs2=# show pool_status;
|
|
2393
|
+
item | value | description
|
|
2394
|
+
-------------------------------+---------------------------------+------------------------------------------------------------------
|
|
2395
|
+
listen_addresses | 127.0.0.1 | host name(s) or IP address(es) to listen to
|
|
2396
|
+
port | 9999 | pgpool accepting port number
|
|
2397
|
+
socket_dir | /tmp | pgpool socket directory
|
|
2398
|
+
num_init_children | 5 | # of children initially pre-forked
|
|
2399
|
+
child_life_time | 300 | if idle for this seconds, child exits
|
|
2400
|
+
</pre>
|
|
2401
|
+
</p>
|
|
2402
|
+
<h2>pool_nodes</h2>
|
|
2403
|
+
<p>"SHOW pool_nodes" renvoie une liste de nœuds configurés. Il affiche
|
|
2404
|
+
l'identifiant du nœud, son nom d'hôte (ou son adresse IP), son port, son statut et le
|
|
2405
|
+
poids (qui n'a d'intérêt que si on utilise le mode de répartition de charge des
|
|
2406
|
+
requêtes en lecture). Les valeurs possibles pour la colonne status
|
|
2407
|
+
sont explicitées dans la <a href="#pcp_node_info">partie dédiée à
|
|
2408
|
+
pcp_node_info</a>.
|
|
2409
|
+
|
|
2410
|
+
<pre>
|
|
2411
|
+
benchs2=# show pool_nodes;
|
|
2412
|
+
id | hostname | port | status | lb_weight
|
|
2413
|
+
------+-------------+------+--------+-----------
|
|
2414
|
+
0 | 127.0.0.1 | 5432 | 2 | 0.5
|
|
2415
|
+
1 | 192.168.1.7 | 5432 | 3 | 0.5
|
|
2416
|
+
(2 lignes)
|
|
2417
|
+
</pre>
|
|
2418
|
+
</p>
|
|
2419
|
+
<h2>pool_processes</h2>
|
|
2420
|
+
<p>"SHOW pool_processes" renvoie une liste de tous les processus qui attendent
|
|
2421
|
+
une connexion ou interagissent avec une connexion.
|
|
2422
|
+
</p>
|
|
2423
|
+
<p>
|
|
2424
|
+
Cette liste a 6 colonnes :
|
|
2425
|
+
<ul>
|
|
2426
|
+
<li>pool_pid est le PID du processus pgpool affiché</li>
|
|
2427
|
+
<li>start_time est l'horodatage correspondant au démarrage du processus</li>
|
|
2428
|
+
<li>database est le nom de la base de données où le serveur est actuellement
|
|
2429
|
+
connecté</li>
|
|
2430
|
+
<li>username est le nom de l'utilisateur utilisé dans la connexion au serveur
|
|
2431
|
+
pour ce processus</li>
|
|
2432
|
+
<li>create_time est l'horodatage correspondant à la création de la
|
|
2433
|
+
connexion</li>
|
|
2434
|
+
<li>pool_counter compte le nombre de fois que ce pool de connexions (le
|
|
2435
|
+
processus) a été utilisé par les clients</li>
|
|
2436
|
+
</ul>
|
|
2437
|
+
</p>
|
|
2438
|
+
<p>Cette vue retournera toujours un nombre de lignes
|
|
2439
|
+
équivalent à num_init_children.</p>
|
|
2440
|
+
<pre>
|
|
2441
|
+
benchs2=# show pool_processes;
|
|
2442
|
+
pool_pid | start_time | database | username | create_time | pool_counter
|
|
2443
|
+
----------+---------------------+----------+-----------+---------------------+--------------
|
|
2444
|
+
8465 | 2010-08-14 08:35:40 | | | |
|
|
2445
|
+
8466 | 2010-08-14 08:35:40 | benchs | guillaume | 2010-08-14 08:35:43 | 1
|
|
2446
|
+
8467 | 2010-08-14 08:35:40 | | | |
|
|
2447
|
+
8468 | 2010-08-14 08:35:40 | | | |
|
|
2448
|
+
8469 | 2010-08-14 08:35:40 | | | |
|
|
2449
|
+
(5 lines)
|
|
2450
|
+
</pre>
|
|
2451
|
+
<h2>pool_pools</h2>
|
|
2452
|
+
<p>"SHOW pool_pools" renvoie une liste de pools détenus par pgpool-II, avec
|
|
2453
|
+
leurs noms, valeurs et description. Voici un exemple de résultat :
|
|
2454
|
+
</p>
|
|
2455
|
+
<p>
|
|
2456
|
+
Cette liste a 11 colonnes :
|
|
2457
|
+
<ul>
|
|
2458
|
+
<li>pool_pid est le PID du processus pgpool-II</li>
|
|
2459
|
+
<li>start_time est l'horodatage qui correspond au lancement du processus</li>
|
|
2460
|
+
<li>pool_id est l'identifiant du pool (qui doit être entre 0 et
|
|
2461
|
+
max_pool-1)</li>
|
|
2462
|
+
<li>backend_id est l'identifiant du serveur (qui doit être entre 0 et le
|
|
2463
|
+
nombre de serveurs configurés moins un).</li>
|
|
2464
|
+
<li>database est le nom de la base de données utilisée dans cette connexion</li>
|
|
2465
|
+
<li>username est le nom d'utilisateur utilisé dans cette connexion</li>
|
|
2466
|
+
<li>create_time est l'horodatage de création de cette connexion</li>
|
|
2467
|
+
<li>majorversion et minorversion sont les versions de protocole utilisées par
|
|
2468
|
+
cette connexion</li>
|
|
2469
|
+
<li>pool_counter compte le nombre de fois que cette connexion a été utilisée
|
|
2470
|
+
par les clients</li>
|
|
2471
|
+
<li>pool_backendpid et le PID du processus PostgreSQL</li>
|
|
2472
|
+
<li>pool_connected et à vrai (1) si un client utilise actuellement cette
|
|
2473
|
+
connexion</li>
|
|
2474
|
+
</ul>
|
|
2475
|
+
</p>
|
|
2476
|
+
<p>Cette vue retournera toujours le même nombre de lignes que
|
|
2477
|
+
num_init_children * max_pool</p>
|
|
2478
|
+
<pre>
|
|
2479
|
+
pool_pid | start_time | pool_id | backend_id | database | username | create_time | majorversion | minorversion | pool_counter | pool_backendpid | pool_connected
|
|
2480
|
+
----------+---------------------+---------+------------+----------+-----------+---------------------+--------------+--------------+--------------+-----------------+----------------
|
|
2481
|
+
8465 | 2010-08-14 08:35:40 | 0 | 0 | | | | | | | |
|
|
2482
|
+
8465 | 2010-08-14 08:35:40 | 1 | 0 | | | | | | | |
|
|
2483
|
+
8465 | 2010-08-14 08:35:40 | 2 | 0 | | | | | | | |
|
|
2484
|
+
8465 | 2010-08-14 08:35:40 | 3 | 0 | | | | | | | |
|
|
2485
|
+
8466 | 2010-08-14 08:35:40 | 0 | 0 | benchs | guillaume | 2010-08-14 08:35:43 | 3 | 0 | 1 | 8473 | 1
|
|
2486
|
+
8466 | 2010-08-14 08:35:40 | 1 | 0 | | | | | | | |
|
|
2487
|
+
8466 | 2010-08-14 08:35:40 | 2 | 0 | | | | | | | |
|
|
2488
|
+
8466 | 2010-08-14 08:35:40 | 3 | 0 | | | | | | | |
|
|
2489
|
+
8467 | 2010-08-14 08:35:40 | 0 | 0 | | | | | | | |
|
|
2490
|
+
8467 | 2010-08-14 08:35:40 | 1 | 0 | | | | | | | |
|
|
2491
|
+
8467 | 2010-08-14 08:35:40 | 2 | 0 | | | | | | | |
|
|
2492
|
+
8467 | 2010-08-14 08:35:40 | 3 | 0 | | | | | | | |
|
|
2493
|
+
8468 | 2010-08-14 08:35:40 | 0 | 0 | | | | | | | |
|
|
2494
|
+
8468 | 2010-08-14 08:35:40 | 1 | 0 | | | | | | | |
|
|
2495
|
+
8468 | 2010-08-14 08:35:40 | 2 | 0 | | | | | | | |
|
|
2496
|
+
8468 | 2010-08-14 08:35:40 | 3 | 0 | | | | | | | |
|
|
2497
|
+
8469 | 2010-08-14 08:35:40 | 0 | 0 | | | | | | | |
|
|
2498
|
+
8469 | 2010-08-14 08:35:40 | 1 | 0 | | | | | | | |
|
|
2499
|
+
8469 | 2010-08-14 08:35:40 | 2 | 0 | | | | | | | |
|
|
2500
|
+
8469 | 2010-08-14 08:35:40 | 3 | 0 | | | | | | | |
|
|
2501
|
+
(20 lines)
|
|
2502
|
+
</pre>
|
|
2503
|
+
</p>
|
|
2504
|
+
<h2>pool_version</h2>
|
|
2505
|
+
<p>"SHOW pool_version" affiche la version de pgpool-II. En voici un exemple :
|
|
2506
|
+
<pre>
|
|
2507
|
+
benchs2=# show pool_version;
|
|
2508
|
+
pool_version
|
|
2509
|
+
------------------------
|
|
2510
|
+
3.0-dev (umiyameboshi)
|
|
2511
|
+
(1 line)
|
|
2512
|
+
</pre>
|
|
2513
|
+
</p>
|
|
2514
|
+
<h1><a name="online-recovery"></a>Online Recovery</h1>
|
|
2515
|
+
<h2>Aperçu</h2>
|
|
2516
|
+
<p>
|
|
2517
|
+
pgpool-II, alors qu'il est en mode réplication, peut synchroniser une base de
|
|
2518
|
+
données et attacher un nœud tout en continuant à répondre aux clients. Cette
|
|
2519
|
+
fonctionnalité est appelée « online recovery ».
|
|
2520
|
+
</p>
|
|
2521
|
+
|
|
2522
|
+
<p>
|
|
2523
|
+
Le nœud cible de cette restauration doit être dans l'état détaché avant de
|
|
2524
|
+
lancer le « online recovery ».
|
|
2525
|
+
|
|
2526
|
+
Si on veut ajouter un serveur PostgreSQL dynamiquement, ajoutez un
|
|
2527
|
+
paramètre backend_hostname et ces paramètres associés, et rechargez pgpool.conf.
|
|
2528
|
+
pgpool-II va alors enregistrer ce nouveau serveur et l'afficher dans l'état
|
|
2529
|
+
détaché.
|
|
2530
|
+
</p>
|
|
2531
|
+
|
|
2532
|
+
<p>
|
|
2533
|
+
<font color="red">Attention : Penser à arrêter l'autovacuum sur le nœud maître
|
|
2534
|
+
(autrement dit le premier qui est ouvert et en fonctionnement). En effet, autovacuum
|
|
2535
|
+
pourrait changer le contenu d'une base de données et alors causer une
|
|
2536
|
+
incohérence après un « online recovery ». Cela s'applique uniquement si on fait
|
|
2537
|
+
la restauration avec un mécanisme simple tel que la
|
|
2538
|
+
technique rsync détaillée plus bas. Cela ne s'applique bien sûr pas si on
|
|
2539
|
+
utilise la technique basée sur le PITR de PostgreSQL.</font>
|
|
2540
|
+
</p>
|
|
2541
|
+
|
|
2542
|
+
<p>
|
|
2543
|
+
Si le serveur PostgreSQL a déjà été démarré, il faut l'arrêter.
|
|
2544
|
+
</p>
|
|
2545
|
+
|
|
2546
|
+
<p>
|
|
2547
|
+
pgpool-II effectue le « online recovery » en deux phase séparées. Il y a quelques
|
|
2548
|
+
secondes ou minutes pendant lesquelles un client sera en attente de connexion à
|
|
2549
|
+
pgpool-II, lorsque la restauration et la synchronisation du nœud a lieu. Ce
|
|
2550
|
+
mécanisme suit les étapes suivantes :
|
|
2551
|
+
<ol>
|
|
2552
|
+
<li> CHECKPOINT
|
|
2553
|
+
<li> Première phase du « online recovery »
|
|
2554
|
+
<li> Attendre que tous les clients soient déconnectés
|
|
2555
|
+
<li> CHECKPOINT
|
|
2556
|
+
<li> Seconde phase du « online recovery »
|
|
2557
|
+
<li> Démarrage du nouveau postmaster (effectué par pgpool_remote_start)
|
|
2558
|
+
<li> Attachement du nœud
|
|
2559
|
+
</ol>
|
|
2560
|
+
</p>
|
|
2561
|
+
|
|
2562
|
+
<p>
|
|
2563
|
+
La première étape de la synchronisation des données est appelée première
|
|
2564
|
+
phase. Les données sont en effet synchronisées pendant cette étape.
|
|
2565
|
+
Pendant cette dernière, les données <b>peuvent</b> être mises à jour ou
|
|
2566
|
+
récupérées par les clients, sur toutes les tables, de manière concurrente.
|
|
2567
|
+
</p>
|
|
2568
|
+
|
|
2569
|
+
<p>
|
|
2570
|
+
On peut spécifier un script qui sera exécuté pendant cette première phase.
|
|
2571
|
+
pgpool-II passe alors trois arguments à ce dernier :
|
|
2572
|
+
|
|
2573
|
+
<ol>
|
|
2574
|
+
<li> le chemin complet vers le répertoire des données de l'instance PostgreSQL du nœud maître
|
|
2575
|
+
<li> le nom d'hôte (ou IP) du serveur à restaurer
|
|
2576
|
+
<li> le chemin complet vers le répertoire des données de l'instance PostgreSQL du serveur à restaurer
|
|
2577
|
+
</ol>
|
|
2578
|
+
</p>
|
|
2579
|
+
|
|
2580
|
+
<p>
|
|
2581
|
+
La synchronisation des données est finalisée dans ce qui est appelé la
|
|
2582
|
+
seconde phase. Avant d'entrer dans cette dernière, pgpool-II attend que
|
|
2583
|
+
tous les clients soient déconnectés. Il bloque alors toute nouvelle connexion
|
|
2584
|
+
jusqu'à ce que cette seconde phase soit terminée.
|
|
2585
|
+
|
|
2586
|
+
Après que toutes les connexions soient terminées, pgpool-II applique toutes les
|
|
2587
|
+
données mises à jour pendant la première et la seconde phase sur le nœud en
|
|
2588
|
+
cours de restauration. Cela achève ainsi la dernière phase de synchronisation
|
|
2589
|
+
des données.
|
|
2590
|
+
</p>
|
|
2591
|
+
|
|
2592
|
+
<p>
|
|
2593
|
+
<font color="red">
|
|
2594
|
+
Il est à noter qu'il y a une restriction sur le « online recovery ». Si pgpool-II
|
|
2595
|
+
lui-même est installé sur plusieurs serveurs, le « online recovery » ne
|
|
2596
|
+
fonctionnera pas correctement car pgpool-II doit arrêter tous les clients
|
|
2597
|
+
pendant la seconde phase du « online recovery ». Ainsi, s'il y a plusieurs
|
|
2598
|
+
serveurs pgpool, un seul aura reçu la commande de « online recovery » et bloquera
|
|
2599
|
+
les connexions.
|
|
2600
|
+
</font>
|
|
2601
|
+
</p>
|
|
2602
|
+
|
|
2603
|
+
<h2>Configuration du « online recovery »</h2>
|
|
2604
|
+
<p>
|
|
2605
|
+
Il convient de configurer les paramètres suivants pour le « online recovery »
|
|
2606
|
+
dans le fichier pgpool.conf.
|
|
2607
|
+
<ul>
|
|
2608
|
+
<li> backend_data_directory
|
|
2609
|
+
<li> recovery_user
|
|
2610
|
+
<li> recovery_password
|
|
2611
|
+
<li> recovery_1st_stage_command
|
|
2612
|
+
<li> recovery_2nd_stage_command
|
|
2613
|
+
</ul>
|
|
2614
|
+
</p>
|
|
2615
|
+
|
|
2616
|
+
|
|
2617
|
+
<h2><a name="installing-c-functions"></a>Installation des fonctions en
|
|
2618
|
+
langage C</h2>
|
|
2619
|
+
<p>
|
|
2620
|
+
Les fonctions en langage C suivantes doivent être installées dans la base
|
|
2621
|
+
template1 de tous les serveurs PostgreSQL pour que le « online recovery »
|
|
2622
|
+
fonctionne.
|
|
2623
|
+
|
|
2624
|
+
Leur code source est dans le répertoire suivant de l'archive de pgpool-II :
|
|
2625
|
+
</p>
|
|
2626
|
+
|
|
2627
|
+
<pre>
|
|
2628
|
+
pgpool-II-x.x.x/sql/pgpool-recovery/
|
|
2629
|
+
</pre>
|
|
2630
|
+
|
|
2631
|
+
<p>
|
|
2632
|
+
Il convient de changer le nom du répertoire ci-dessus pour l'ajuster à votre
|
|
2633
|
+
version précise de pgpool-II.
|
|
2634
|
+
|
|
2635
|
+
On se place dans ce dernier et on lance la commande « make install » :
|
|
2636
|
+
|
|
2637
|
+
</p>
|
|
2638
|
+
|
|
2639
|
+
<pre>
|
|
2640
|
+
% cd pgpool-II-x.x.x/sql/pgpool-recovery/
|
|
2641
|
+
% make install
|
|
2642
|
+
</pre>
|
|
2643
|
+
|
|
2644
|
+
<p>
|
|
2645
|
+
À présent, il faut installer les fonctions SQL correspondantes :
|
|
2646
|
+
</p>
|
|
2647
|
+
|
|
2648
|
+
<pre>
|
|
2649
|
+
% cd pgpool-II-x.x.x/sql/pgpool-recovery/
|
|
2650
|
+
% psql -f pgpool-recovery.sql template1
|
|
2651
|
+
</pre>
|
|
2652
|
+
|
|
2653
|
+
|
|
2654
|
+
<h2>Déploiement du script de restauration</h2>
|
|
2655
|
+
<p>
|
|
2656
|
+
Des scripts de synchronisation de données doivent être déployés ainsi qu'un
|
|
2657
|
+
script qui permet de démarrer PostgreSQL à distance, et tout ceci, dans le
|
|
2658
|
+
répertoire des données de l'instance de PostgreSQL ($PGDATA). Plusieurs scripts d'exemple sont
|
|
2659
|
+
disponibles dans le répertoire pgpool-II-x.x.x/sample.
|
|
2660
|
+
</p>
|
|
2661
|
+
|
|
2662
|
+
<h3>« Online recovery » grâce au PITR</h3>
|
|
2663
|
+
<p>
|
|
2664
|
+
Voici comment faire un « online recovery » grâce au Point In Time Recovery (PITR),
|
|
2665
|
+
qui est disponible à partir de la version 8.2 de PostgreSQL.
|
|
2666
|
+
Attention, tous les serveurs impliqués doivent avoir le PITR d'activé et correctement
|
|
2667
|
+
configuré.
|
|
2668
|
+
</p>
|
|
2669
|
+
|
|
2670
|
+
<p>
|
|
2671
|
+
Il est nécessaire d'avoir un script qui se charge d'effectuer une
|
|
2672
|
+
sauvegarde complète du serveur PostgreSQL sur un nœud maître et de l'envoyer sur
|
|
2673
|
+
un nœud cible pour la restauration lors de la première phase. Ce script
|
|
2674
|
+
peut être nommé copy-base-backup par exemple. Voici un exemple de ce script :
|
|
2675
|
+
</p>
|
|
2676
|
+
|
|
2677
|
+
<pre>
|
|
2678
|
+
#! /bin/sh
|
|
2679
|
+
DATA=$1
|
|
2680
|
+
RECOVERY_TARGET=$2
|
|
2681
|
+
RECOVERY_DATA=$3
|
|
2682
|
+
|
|
2683
|
+
psql -c "select pg_start_backup('pgpool-recovery')" postgres
|
|
2684
|
+
echo "restore_command = 'scp $HOSTNAME:/data/archive_log/%f %p'" > /data/recovery.conf
|
|
2685
|
+
tar -C /data -zcf pgsql.tar.gz pgsql
|
|
2686
|
+
psql -c 'select pg_stop_backup()' postgres
|
|
2687
|
+
scp pgsql.tar.gz $RECOVERY_TARGET:$RECOVERY_DATA
|
|
2688
|
+
</pre>
|
|
2689
|
+
|
|
2690
|
+
<p>
|
|
2691
|
+
Ce script place le serveur maître en mode sauvegarde à chaud, puis génère le
|
|
2692
|
+
fichier recovery.conf suivant :
|
|
2693
|
+
</p>
|
|
2694
|
+
<pre>
|
|
2695
|
+
restore_command = 'scp master:/data/archive_log/%f %p'
|
|
2696
|
+
</pre>
|
|
2697
|
+
Ensuite, il effectue la sauvegarde, puis sort le serveur maître du mode sauvegarde à chaud
|
|
2698
|
+
et copie enfin la sauvegarde sur le nœud désiré.
|
|
2699
|
+
</p>
|
|
2700
|
+
|
|
2701
|
+
<p>
|
|
2702
|
+
La seconde phase de cette procédure est un script qui va forcer un changement
|
|
2703
|
+
de journal de transactions (XLOG). Ce script est nommé pgpool_recovery_pitr ici.
|
|
2704
|
+
Il utilise pg_switch_xlog. Cependant, il pourrait rendre la main <b>avant</b>
|
|
2705
|
+
que le changement de journal ne soit fait, ce qui pourrait alors provoquer un
|
|
2706
|
+
échec de la procédure d'« online recovery ».
|
|
2707
|
+
|
|
2708
|
+
pgpool-II fournit une méthode plus sûre avec la fonction pgpool_swich_xlog,
|
|
2709
|
+
qui attend que le changement effectif de journal de transaction
|
|
2710
|
+
ait eu lieu.
|
|
2711
|
+
|
|
2712
|
+
Cette fonction est installée avec la procédure explicitée dans la section
|
|
2713
|
+
<a href="#installing-c-functions">Installation des fonctions en
|
|
2714
|
+
langage C</a>.
|
|
2715
|
+
</p>
|
|
2716
|
+
<p>
|
|
2717
|
+
Voici un script d'exemple :
|
|
2718
|
+
</p>
|
|
2719
|
+
<p>
|
|
2720
|
+
<pre>
|
|
2721
|
+
#! /bin/sh
|
|
2722
|
+
# Online recovery 2nd stage script
|
|
2723
|
+
#
|
|
2724
|
+
datadir=$1 # master dabatase cluster
|
|
2725
|
+
DEST=$2 # hostname of the DB node to be recovered
|
|
2726
|
+
DESTDIR=$3 # database cluster of the DB node to be recovered
|
|
2727
|
+
port=5432 # PostgreSQL port number
|
|
2728
|
+
archdir=/data/archive_log # archive log directory
|
|
2729
|
+
|
|
2730
|
+
# Force to flush current value of sequences to xlog
|
|
2731
|
+
psql -p $port -t -c 'SELECT datname FROM pg_database WHERE NOT datistemplate AND datallowconn' template1|
|
|
2732
|
+
while read i
|
|
2733
|
+
do
|
|
2734
|
+
if [ "$i" != "" ];then
|
|
2735
|
+
psql -p $port -c "SELECT setval(oid, nextval(oid)) FROM pg_class WHERE relkind = 'S'" $i
|
|
2736
|
+
fi
|
|
2737
|
+
done
|
|
2738
|
+
|
|
2739
|
+
psql -p $port -c "SELECT pgpool_switch_xlog('$archdir')" template1
|
|
2740
|
+
</pre>
|
|
2741
|
+
</p>
|
|
2742
|
+
|
|
2743
|
+
<p>
|
|
2744
|
+
Cette mise à jour des séquences est uniquement utile dans le mode réplication :
|
|
2745
|
+
dans ce cas, les séquences doivent avoir le même numéro de démarrage sur tous
|
|
2746
|
+
les nœuds. Ça n'est pas utile dans le mode maître-esclave.
|
|
2747
|
+
|
|
2748
|
+
La boucle dans ce script force PostgreSQL à émettre la valeur courante de toutes
|
|
2749
|
+
les séquences dans toutes les bases du nœud maître dans le journal de
|
|
2750
|
+
transactions afin que celles-ci soient propagées au nœud en cours de
|
|
2751
|
+
restauration.
|
|
2752
|
+
</p>
|
|
2753
|
+
|
|
2754
|
+
<p>
|
|
2755
|
+
Ces scripts doivent être déployés dans le répertoire des données de l'instance PostgreSQL
|
|
2756
|
+
(autrement dit $PGDATA).
|
|
2757
|
+
</p>
|
|
2758
|
+
<p>
|
|
2759
|
+
Enfin, on édite le fichier pgpool.conf.
|
|
2760
|
+
|
|
2761
|
+
<pre>
|
|
2762
|
+
recovery_1st_stage_command = 'copy-base-backup'
|
|
2763
|
+
recovery_2nd_stage_command = 'pgpool_recovery_pitr'
|
|
2764
|
+
</pre>
|
|
2765
|
+
|
|
2766
|
+
</p>
|
|
2767
|
+
|
|
2768
|
+
<p>
|
|
2769
|
+
Cette opération termine la préparation du « online recovery » via le PITR.
|
|
2770
|
+
</p>
|
|
2771
|
+
|
|
2772
|
+
<h4><p>pgpool_remote_start</p></h4>
|
|
2773
|
+
<p>
|
|
2774
|
+
Ce script démarre le processus postmaster sur les nœuds distants.
|
|
2775
|
+
pgpool-II l'exécute de la manière suivante.
|
|
2776
|
+
</p>
|
|
2777
|
+
|
|
2778
|
+
<pre>
|
|
2779
|
+
% pgpool_remote_start remote_host remote_datadir
|
|
2780
|
+
remote_host: Nom d'hôte de la machine cible à restaurer
|
|
2781
|
+
remote_datadir: Chemin vers le répertoire des données de l'instance PostgreSQL sur une machine en
|
|
2782
|
+
restauration
|
|
2783
|
+
</pre>
|
|
2784
|
+
|
|
2785
|
+
<p>
|
|
2786
|
+
Dans ce script d'exemple, on démarre le processus postmaster via ssh.
|
|
2787
|
+
Afin qu'il fonctionne, on doit pouvoir se connecter via ssh sans mot de passe.
|
|
2788
|
+
</p>
|
|
2789
|
+
|
|
2790
|
+
<p>
|
|
2791
|
+
Si la restauration se fait avec PITR, il faut déployer le script de sauvegarde de
|
|
2792
|
+
base. PostgreSQL démarrera alors automatiquement en effectuant une restauration
|
|
2793
|
+
via le PITR. Il acceptera ensuite les connexions.
|
|
2794
|
+
</p>
|
|
2795
|
+
|
|
2796
|
+
<pre>
|
|
2797
|
+
#! /bin/sh
|
|
2798
|
+
DEST=$1
|
|
2799
|
+
DESTDIR=$2
|
|
2800
|
+
PGCTL=/usr/local/pgsql/bin/pg_ctl
|
|
2801
|
+
|
|
2802
|
+
# Déploiement du script de backup
|
|
2803
|
+
ssh -T $DEST 'cd /data/; tar zxf pgsql.tar.gz' 2>/dev/null 1>/dev/null < /dev/null
|
|
2804
|
+
# Démarrage du serveur PostgreSQL
|
|
2805
|
+
ssh -T $DEST $PGCTL -w -D $DESTDIR start 2>/dev/null 1>/dev/null < /dev/null &
|
|
2806
|
+
</pre>
|
|
2807
|
+
|
|
2808
|
+
<h3>« Online recovery » avec rsync</h3>
|
|
2809
|
+
<p>
|
|
2810
|
+
PostgreSQL 7.4 n'a pas le PITR, qui n'est apparu qu'en version 8.0. rsync peut alors être
|
|
2811
|
+
utilisé pour effectuer le « online recovery ». Dans le script d'exemple disponible
|
|
2812
|
+
dans les sources de pgpool-II, il y a un script de restauration qui est
|
|
2813
|
+
nommé pgpool_recovery. Ce dernier utilise la commande rsync. pgpool-II
|
|
2814
|
+
appelle ce script avec trois arguments.
|
|
2815
|
+
</p>
|
|
2816
|
+
|
|
2817
|
+
<pre>
|
|
2818
|
+
% pgpool_recovery datadir remote_host remote_datadir
|
|
2819
|
+
datadir: Répertoire des données de l'instance PostgreSQL sur un serveur maître
|
|
2820
|
+
remote_host: Nom d'hôte (ou IP) du serveur cible à restaurer
|
|
2821
|
+
remote_datadir: Répertoire des données de l'instance PostgreSQL du serveur cible à
|
|
2822
|
+
restaurer
|
|
2823
|
+
</pre>
|
|
2824
|
+
|
|
2825
|
+
<p>
|
|
2826
|
+
Ce script copie les fichiers de manière physique grâce à rsync et via ssh.
|
|
2827
|
+
Comme précédemment, on doit pouvoir se connecter via ssh sans mot de passe.
|
|
2828
|
+
</p>
|
|
2829
|
+
|
|
2830
|
+
<p>
|
|
2831
|
+
Note à propos de rsync :
|
|
2832
|
+
<ul>
|
|
2833
|
+
<li>-c (ou --checksum) : cette option est requise pour assurer une
|
|
2834
|
+
transmission fiable
|
|
2835
|
+
|
|
2836
|
+
<li>-z (ou --compress) : cette option fait de la compression des fichiers lors
|
|
2837
|
+
de leur transmission. Cela sera fort utile pour les connexions réseau lentes,
|
|
2838
|
+
mais pourrait ajouter une grosse surcharge inutile sur le CPU (à cause de la
|
|
2839
|
+
compression) pour des réseaux à 100 Mbits voire supérieurs. Dans ces derniers
|
|
2840
|
+
cas, il sera préférable de ne pas utiliser la compression.
|
|
2841
|
+
|
|
2842
|
+
<li>rsync 3.0.5 a d'excellentes améliorations de performances en vitesse (près
|
|
2843
|
+
de 50% plus rapide d'après les discussions qui ont eu lieu sur la liste de
|
|
2844
|
+
discussion pgpool-general)
|
|
2845
|
+
</ul>
|
|
2846
|
+
|
|
2847
|
+
</p>
|
|
2848
|
+
|
|
2849
|
+
<p>
|
|
2850
|
+
Si on utilise pgpool_recovery, il convient d'ajouter les lignes suivantes au
|
|
2851
|
+
ficher pgpool.conf :
|
|
2852
|
+
|
|
2853
|
+
<pre>
|
|
2854
|
+
recovery_1st_stage_command = 'pgpool_recovery'
|
|
2855
|
+
recovery_2nd_stage_command = 'pgpool_recovery'
|
|
2856
|
+
</pre>
|
|
2857
|
+
</p>
|
|
2858
|
+
|
|
2859
|
+
<h2>Comment effectuer un « online recovery »</h2>
|
|
2860
|
+
<p>
|
|
2861
|
+
Afin de réaliser un « online recovery », on peut utiliser la commande
|
|
2862
|
+
pcp_recovery_node ou bien pgpoolAdmin.
|
|
2863
|
+
</p>
|
|
2864
|
+
|
|
2865
|
+
<p>
|
|
2866
|
+
Il est à noter qu'on doit positionner un nombre important dans le tout premier
|
|
2867
|
+
argument de pcp_recovery_node. Il s'agit d'un délai maximum en secondes. Si on
|
|
2868
|
+
utilise pgpoolAdmin, il convient aussi de mettre un grand nombre au paramètre
|
|
2869
|
+
"_PGPOOL2_PCP_TIMEOUT" dans le fichier de configuration pgmgt.conf.php.
|
|
2870
|
+
</p>
|
|
2871
|
+
|
|
2872
|
+
<h1><a name="troubleshooting"></a>Que faire en cas d'erreur</h1>
|
|
2873
|
+
<p>
|
|
2874
|
+
Cette section décrit quelques problèmes qui peuvent survenir lors de
|
|
2875
|
+
l'utilisation de pgpool-II, ainsi que leur solutions.
|
|
2876
|
+
</p>
|
|
2877
|
+
<p>
|
|
2878
|
+
<ul>
|
|
2879
|
+
|
|
2880
|
+
<dt>Health check failed
|
|
2881
|
+
<dd>
|
|
2882
|
+
<p>
|
|
2883
|
+
pgpool-II vérifie périodiquement que tous les serveurs configurés fonctionnent
|
|
2884
|
+
correctement.
|
|
2885
|
+
</p>
|
|
2886
|
+
<p>
|
|
2887
|
+
<pre>
|
|
2888
|
+
2010-07-23 16:42:57 ERROR: pid 20031: health check failed. 1 th host foo at port 5432 is down
|
|
2889
|
+
2010-07-23 16:42:57 LOG: pid 20031: set 1 th backend down status
|
|
2890
|
+
2010-07-23 16:42:57 LOG: pid 20031: starting degeneration. shutdown host foo(5432)
|
|
2891
|
+
2010-07-23 16:42:58 LOG: pid 20031: failover_handler: set new master node: 0
|
|
2892
|
+
2010-07-23 16:42:58 LOG: pid 20031: failover done. shutdown host foo(5432)
|
|
2893
|
+
</pre>
|
|
2894
|
+
</p>
|
|
2895
|
+
<p>
|
|
2896
|
+
Ici, la trace montre que le serveur 1 (nom d'hôte "foo") s'arrête puis est
|
|
2897
|
+
déconnecté (shutdown) de pgpool. Ensuite, le serveur 0 devient le nouveau
|
|
2898
|
+
maître.
|
|
2899
|
+
|
|
2900
|
+
Il convient donc de vérifier le serveur 1 et corriger la cause de l'erreur.
|
|
2901
|
+
Ensuite, il faudra effectuer un « online recovery » sur le serveur 1 si c'est
|
|
2902
|
+
possible.
|
|
2903
|
+
</p>
|
|
2904
|
+
|
|
2905
|
+
<dt>Failed to read kind from frontend
|
|
2906
|
+
<dd>
|
|
2907
|
+
<p>
|
|
2908
|
+
<pre>
|
|
2909
|
+
2010-07-26 18:43:24 LOG: pid 24161: ProcessFrontendResponse: failed to read kind from frontend. frontend abnormally exited
|
|
2910
|
+
</pre>
|
|
2911
|
+
<p>
|
|
2912
|
+
Cette trace indique simplement que le programme client ne s'est pas connecté
|
|
2913
|
+
correctement à pgpool-II.
|
|
2914
|
+
|
|
2915
|
+
Les causes possibles sont : un bug dans les applications clientes, la
|
|
2916
|
+
déconnexion forcée d'une application cliente (un "kill" par exemple) ou bien
|
|
2917
|
+
une erreur réseau temporaire.
|
|
2918
|
+
|
|
2919
|
+
Ce genre d'évènements ne mène pas à la destruction d'une base de données ou
|
|
2920
|
+
même à une corruption de données. Il s'agit juste d'un avertissement sur le
|
|
2921
|
+
fait qu'il y a eu une violation du protocole utilisé par pgpool-II.
|
|
2922
|
+
|
|
2923
|
+
Il est cependant recommandé d'investiguer plus en avant si ce message arrive
|
|
2924
|
+
trop souvent.
|
|
2925
|
+
</p>
|
|
2926
|
+
|
|
2927
|
+
<dt>Kind mismatch errors
|
|
2928
|
+
<dd>
|
|
2929
|
+
<p>
|
|
2930
|
+
Cette erreur peut survenir si pgpool-II fonctionne en mode réplication.
|
|
2931
|
+
</p>
|
|
2932
|
+
<pre>
|
|
2933
|
+
2010-07-22 14:18:32 ERROR: pid 9966: kind mismatch among backends. Possible last query was: "FETCH ALL FROM c;" kind details are: 0[T] 1[E: cursor "c" does not exist]
|
|
2934
|
+
</pre>
|
|
2935
|
+
<p>
|
|
2936
|
+
pgpool-II attend les réponses des serveurs PostgreSQL après leur avoir envoyé
|
|
2937
|
+
une commande SQL.
|
|
2938
|
+
Ce message indique que tous les serveurs de données ne retournent pas le même
|
|
2939
|
+
type de réponse.
|
|
2940
|
+
|
|
2941
|
+
La requête SQL qui a causé l'erreur se trouve après « Possible last query was: ».
|
|
2942
|
+
|
|
2943
|
+
Ensuite, le type de réponse suit.
|
|
2944
|
+
|
|
2945
|
+
Ici, on peut lire que « 0[T] » affiche la réponse du serveur de données:
|
|
2946
|
+
« 0[T] » (renvoi de la description de l'enregistrement), et que « 1[E » affiche que
|
|
2947
|
+
le serveur 1 retourne une erreur avec le message « cursor c does not exist »,
|
|
2948
|
+
alors que le serveur 0 renvoie bien la description de l'enregistrement.
|
|
2949
|
+
<p>
|
|
2950
|
+
Attention, on pourrait aussi avoir cette erreur dans le mode maître-esclave.
|
|
2951
|
+
|
|
2952
|
+
Par exemple, même dans le mode maître-esclave, la commande SET sera envoyée à
|
|
2953
|
+
tous les serveurs de données pour qu'ils soient dans le même état.
|
|
2954
|
+
</p>
|
|
2955
|
+
<p>
|
|
2956
|
+
Il convient de vérifier alors les serveurs de données et éventuellement les
|
|
2957
|
+
resynchroniser en utilisant le « online recovery », quand c'est possible et si
|
|
2958
|
+
nécessaire.
|
|
2959
|
+
</p>
|
|
2960
|
+
|
|
2961
|
+
<p>
|
|
2962
|
+
<dt>Pgpool detected difference of the number of inserted, updated or deleted tuples
|
|
2963
|
+
<dd>
|
|
2964
|
+
<p>
|
|
2965
|
+
Dans le mode réplication, pgpool-II a détecté un nombre différent
|
|
2966
|
+
d'enregistrements mis à jour (en INSERT, UPDATE ou DELETE) sur les différents
|
|
2967
|
+
serveurs.
|
|
2968
|
+
</p>
|
|
2969
|
+
<p>
|
|
2970
|
+
<pre>
|
|
2971
|
+
2010-07-22 11:49:28 ERROR: pid 30710: pgpool detected difference of the number of inserted, updated or deleted tuples. Possible last query was: "update t1 set i = 1;"
|
|
2972
|
+
2010-07-22 11:49:28 LOG: pid 30710: ReadyForQuery: Degenerate backends: 1
|
|
2973
|
+
2010-07-22 11:49:28 LOG: pid 30710: ReadyForQuery: Affected tuples are: 0 1
|
|
2974
|
+
</pre>
|
|
2975
|
+
<p>
|
|
2976
|
+
Dans l'exemple ci-dessus, le nombre d'enregistrements mis à jour grâce à
|
|
2977
|
+
« UPDATE t1 SET i = 1 » est différent à travers les différents serveurs de
|
|
2978
|
+
données.
|
|
2979
|
+
|
|
2980
|
+
La ligne qui suit indique que le serveur 1 a été dégénéré (déconnecté) :
|
|
2981
|
+
c'est la conséquence du fait que pour le serveur 0 le nombre d'enregistrement
|
|
2982
|
+
mis à jours a été de 0, alors que pour le serveur 1 le nombre d'enregistrements
|
|
2983
|
+
modifiés a été de 1.
|
|
2984
|
+
</p>
|
|
2985
|
+
<p>
|
|
2986
|
+
Il convient alors d'arrêter le serveur que l'on suspecte être désynchronisé (ou
|
|
2987
|
+
simplement ne pas avoir les bonnes données), puis de procéder à un « online
|
|
2988
|
+
recovery ».
|
|
2989
|
+
</ul>
|
|
2990
|
+
|
|
2991
|
+
|
|
2992
|
+
<h1>Restrictions<a name="restriction"></a></h1>
|
|
2993
|
+
|
|
2994
|
+
<p>
|
|
2995
|
+
<h2>Fonctionnalités de PostgreSQL</h2>
|
|
2996
|
+
<p>
|
|
2997
|
+
<ul>
|
|
2998
|
+
<li>Si on utilise pg_terminate_backend() pour arrêter un processus serveur PostgreSQL,
|
|
2999
|
+
cela provoquera un failover. La raison de ce comportement est que PostgreSQL
|
|
3000
|
+
envoie alors exactement le même message que si c'était le postmaster lui-même
|
|
3001
|
+
qui s'arrêtait complètement. Il n'existe pas de contournement à ce problème à ce
|
|
3002
|
+
jour. Aussi, il faut veiller à ne pas utiliser cette fonction pour le moment.
|
|
3003
|
+
</ul>
|
|
3004
|
+
|
|
3005
|
+
<p>
|
|
3006
|
+
<h2><a name="md5"></a>Authentification / Contrôle d'accès</h2>
|
|
3007
|
+
|
|
3008
|
+
<p>
|
|
3009
|
+
<ul>
|
|
3010
|
+
<li>Dans le mode réplication ou maître-esclave, les méthode
|
|
3011
|
+
d'authentification supportées sont trust, mot de passe en clair et pam. md5 est
|
|
3012
|
+
aussi supporté depuis la version 3.0 de pgpool-II.
|
|
3013
|
+
md5 est supporté en utilisant pool_passwd. Voici les étapes à respecter pour
|
|
3014
|
+
autoriser l'authentification md5 :
|
|
3015
|
+
<ol>
|
|
3016
|
+
<li>Se connecter au système d'exploitation du serveur de
|
|
3017
|
+
données, avec l'utilisateur qui a les droits (postgres) et entrer :
|
|
3018
|
+
pg_md5 --md5auth <mot_de_passe><br/>
|
|
3019
|
+
le nom d'utilisateur et son mot de passe chiffré en md5 sont
|
|
3020
|
+
alors enregistrés dans pool_passwd. Si ce dernier n'existe pas encore, la
|
|
3021
|
+
commande pg_md5 va le créer automatiquement.</li>
|
|
3022
|
+
<li>Le format utilisé par pool_passwd est
|
|
3023
|
+
"nom_d_utilisateur:mot_de_passe_encrypté_md5"</li>
|
|
3024
|
+
<li>Il faudra aussi une entrée appropriée md5 dans le
|
|
3025
|
+
fichier pool_hba.conf. À cet effet, voir <a href="#hba">Configuration de pool_hba.conf
|
|
3026
|
+
pour l'authentification des clients</a> pour plus de détails</li>
|
|
3027
|
+
<li>Il faut bien veiller à ce que le nom d'utilisateur et son
|
|
3028
|
+
mot de passe soient strictement identiques à ce qui se trouvent dans le serveur
|
|
3029
|
+
PostgreSQL pour que cela fonctionne</li>
|
|
3030
|
+
</ol>
|
|
3031
|
+
|
|
3032
|
+
</li>
|
|
3033
|
+
<li>Dans tous les autres modes, les méthodes trust, mot de passe en clair,
|
|
3034
|
+
crypt, md5 et pam sont supportées.</li>
|
|
3035
|
+
<li>pgpool-II ne supporte pas les contrôles d'accès comme pg_hba.conf de
|
|
3036
|
+
PostgreSQL. Par exemple, si les connexions TCP/IP sont activées, pgpool-II
|
|
3037
|
+
accepte toutes les connexions TCP/IP, quel que soient leurs origines. Si
|
|
3038
|
+
c'est absolument requis dans le contexte, il convient d'utiliser un programme
|
|
3039
|
+
comme iptables afin de contrôler les accès TCP/IP. Bien sûr, les serveurs
|
|
3040
|
+
PostgreSQL qui acceptent les connexions pgpool-II peuvent utiliser leur
|
|
3041
|
+
configuration pg_hba.conf propre.</li>
|
|
3042
|
+
</ul>
|
|
3043
|
+
</p>
|
|
3044
|
+
|
|
3045
|
+
<h2>Large objects</h2>
|
|
3046
|
+
<p>
|
|
3047
|
+
pgpool-II 2.3.2 et suivants supportent la réplication des « large objects » si le
|
|
3048
|
+
serveur PostgreSQL est au moins en version 8.1.
|
|
3049
|
+
|
|
3050
|
+
Pour que cela fonctionne, il faut activer la directive de configuration <a
|
|
3051
|
+
href="#lobj_lock_table">lobj_lock_table</a> dans le fichier pgpool.conf.
|
|
3052
|
+
|
|
3053
|
+
Cependant, la réplication des « large objects » utilisant la fonction PostgreSQL
|
|
3054
|
+
lo_import n'est pas supportée.
|
|
3055
|
+
</p>
|
|
3056
|
+
|
|
3057
|
+
<h2>Tables temporaires en mode maître-esclave</h2>
|
|
3058
|
+
<p>
|
|
3059
|
+
Tout ce qui concerne les tables temporaires est toujours exécuté sur le maître.
|
|
3060
|
+
|
|
3061
|
+
À partir de la version 3.0 de pgpool-II, les SELECT sur ces tables sont
|
|
3062
|
+
eux-aussi exécutés sur le maître.
|
|
3063
|
+
|
|
3064
|
+
Cependant, si le nom de la table temporaire est utilisé comme un littéral dans
|
|
3065
|
+
le SELECT, il n'y a aucun moyen de le détecter. Du coup, les SELECT seront
|
|
3066
|
+
répartis entre les serveurs PostgreSQL.
|
|
3067
|
+
|
|
3068
|
+
Cela amènera à une erreur, la table n'existant que sur le maître ("not found
|
|
3069
|
+
the table...").
|
|
3070
|
+
|
|
3071
|
+
Pour éviter ce problème, il faut utiliser le commentaire « /*NO LOAD BALANCE*/ »
|
|
3072
|
+
dans le corps de la requête SQL contenant l'appel en SELECT sur la table
|
|
3073
|
+
temporaire.
|
|
3074
|
+
</p>
|
|
3075
|
+
<p>
|
|
3076
|
+
<pre>
|
|
3077
|
+
Voici en uxemple de SELECT qui pose problème :
|
|
3078
|
+
SELECT 't1'::regclass::oid;
|
|
3079
|
+
</pre>
|
|
3080
|
+
</p>
|
|
3081
|
+
<p>
|
|
3082
|
+
La commande "\d" de psql utilise les tables de nom en littéral. À partir de la
|
|
3083
|
+
version 3.0 de pgpool-II, ce dernier va tester si le SELECT contient un accès
|
|
3084
|
+
au catalogue système et enverra alors les requêtes au maître dans
|
|
3085
|
+
l'affirmative.
|
|
3086
|
+
|
|
3087
|
+
Cela permet de contourner le problème.
|
|
3088
|
+
</p>
|
|
3089
|
+
|
|
3090
|
+
<h2>Fonctions et autres en mode réplication</h2>
|
|
3091
|
+
|
|
3092
|
+
<p>
|
|
3093
|
+
Il n'y a aucune garantie que toute donnée obtenue via un mécanisme dépendant du
|
|
3094
|
+
contexte (par exemple un nombre au hasard, un numéro de transaction, un OID,
|
|
3095
|
+
un SERIAL ou une sequence) sera répliquée correctement sur plusieurs serveurs
|
|
3096
|
+
PostgreSQL.
|
|
3097
|
+
</p>
|
|
3098
|
+
<p>Pour SERIAL, l'activation de la directive de configuration insert_lock
|
|
3099
|
+
permettra de répliquer correctement la donnée. Cela permettra aussi un bon
|
|
3100
|
+
fonctionnement de "SELECT setval()" et "SELECT nextval()".</p>
|
|
3101
|
+
|
|
3102
|
+
<p>
|
|
3103
|
+
À partir de la version 2.3 de pgpool, les INSERT et UPDATE qui utilisent
|
|
3104
|
+
CURRENT_TIMESTAMP, CURRENT_DATE et now() seront répliqués correctement. De
|
|
3105
|
+
même, les INSERT et UPDATE pour les tables qui utilisent CURRENT_TIMESTAMP,
|
|
3106
|
+
CURRENT_DATE et now() comme leur valeur par défaut (DEFAULT valeur) seront aussi
|
|
3107
|
+
répliqués correctement.
|
|
3108
|
+
|
|
3109
|
+
Cela est obtenu en remplaçant ces fonctions par des constantes qui sont
|
|
3110
|
+
récupérées sur le maître au moment de l'exécution de la requête.
|
|
3111
|
+
|
|
3112
|
+
Il y a cependant quelques limitations :
|
|
3113
|
+
<ul>
|
|
3114
|
+
<li>Le calcul de la donnée temporelle n'est pas correct dans quelques cas. Par
|
|
3115
|
+
exemple, voici une définition de table :
|
|
3116
|
+
<pre>
|
|
3117
|
+
CREATE TABLE rel1(
|
|
3118
|
+
d1 date DEFAULT CURRENT_DATE + 1
|
|
3119
|
+
)
|
|
3120
|
+
</pre>
|
|
3121
|
+
Ceci est traité de la même façon que :
|
|
3122
|
+
<pre>
|
|
3123
|
+
CREATE TABLE rel1(
|
|
3124
|
+
d1 date DEFAULT CURRENT_DATE
|
|
3125
|
+
)
|
|
3126
|
+
</pre>
|
|
3127
|
+
<p>
|
|
3128
|
+
Il est à noter que si le type de la colonne n'est pas temporel, la réécriture
|
|
3129
|
+
n'est pas effectuée. En voici un exemple :
|
|
3130
|
+
<pre>
|
|
3131
|
+
foo bigint default (date_part('epoch'::text,('now'::text)::timestamp(3) with time zone) * (1000)::double precision)
|
|
3132
|
+
</pre>
|
|
3133
|
+
</p>
|
|
3134
|
+
<li>Supposons à présent que nous ayons la table suivante :
|
|
3135
|
+
<pre>
|
|
3136
|
+
CREATE TABLE rel1(
|
|
3137
|
+
c1 int,
|
|
3138
|
+
c2 timestamp default now()
|
|
3139
|
+
)
|
|
3140
|
+
</pre>
|
|
3141
|
+
On peut répliquer :
|
|
3142
|
+
<pre>
|
|
3143
|
+
INSERT INTO rel1(c1) VALUES(1)
|
|
3144
|
+
</pre>
|
|
3145
|
+
puis que cela se transforme en :
|
|
3146
|
+
<pre>
|
|
3147
|
+
INSERT INTO rel1(c1, c2) VALUES(1, '2009-01-01 23:59:59.123456+09')
|
|
3148
|
+
</pre>
|
|
3149
|
+
Cependant :
|
|
3150
|
+
<pre>
|
|
3151
|
+
INSERT INTO rel1(c1) SELECT 1
|
|
3152
|
+
</pre>
|
|
3153
|
+
ne peut pas être transformé. Il ne sera donc pas correctement répliqué avec
|
|
3154
|
+
l'implémentation actuelle. Les valeurs seront cependant insérées, mais sans
|
|
3155
|
+
aucune transformation.
|
|
3156
|
+
</ul>
|
|
3157
|
+
</p>
|
|
3158
|
+
<p>
|
|
3159
|
+
Les tables créées avec <code>CREATE TEMP TABLE</code> seront supprimées à la
|
|
3160
|
+
fin de la session en spécifiant DISCARD ALL dans le paramètre de configuration
|
|
3161
|
+
reset_query_list si on utilise la version 8.3 ou supérieure de PostgreSQL.
|
|
3162
|
+
</p>
|
|
3163
|
+
<p>
|
|
3164
|
+
Pour les version 8.2.X et précédentes, <code>CREATE TEMP TABLE</code> ne
|
|
3165
|
+
sera pas supprimé à la sortie de la session.
|
|
3166
|
+
|
|
3167
|
+
Ceci est dû au pooling de connexion, qui, du point de vue du serveur
|
|
3168
|
+
PostgreSQL, garde la session en vie.
|
|
3169
|
+
|
|
3170
|
+
Pour éviter cela, on doit supprimer explicitement la table dans le bloc de
|
|
3171
|
+
transaction, soit en ajoutant un <code>DROP TABLE</code>, soit en créant la
|
|
3172
|
+
table temporaire avec <code>CREATE TEMP TABLE ... ON COMMIT DROP</code>.
|
|
3173
|
+
|
|
3174
|
+
<h2>Requêtes</h2>
|
|
3175
|
+
|
|
3176
|
+
<p>Voici les requêtes qui ne peuvent pas être traitées par pgpool-II :</p>
|
|
3177
|
+
|
|
3178
|
+
<h3>INSERT (en mode parallèle)</h3>
|
|
3179
|
+
|
|
3180
|
+
<p>On ne peut pas utiliser <code>DEFAULT</code> avec la colonne qui sert de clé
|
|
3181
|
+
de partitionnement. Par exemple, si la colonne x dans la table t est la colonne
|
|
3182
|
+
qui sert de clé de partitionnement :
|
|
3183
|
+
|
|
3184
|
+
<pre>
|
|
3185
|
+
INSERT INTO t(x) VALUES (DEFAULT);
|
|
3186
|
+
</pre>
|
|
3187
|
+
<p>
|
|
3188
|
+
est invalide. De même, les fonctions ne peuvent pas être utilisées pour cette
|
|
3189
|
+
valeur non plus.</p>
|
|
3190
|
+
|
|
3191
|
+
<pre>
|
|
3192
|
+
INSERT INTO t(x) VALUES (func());
|
|
3193
|
+
</pre>
|
|
3194
|
+
<p>
|
|
3195
|
+
Les valeurs constantes doivent être utilisées pour un INSERT avec la clé de
|
|
3196
|
+
partitionnement.
|
|
3197
|
+
|
|
3198
|
+
<code>SELECT INTO</code> et <code>INSERT INTO ... SELECT</code>
|
|
3199
|
+
ne sont pas supportés non plus.
|
|
3200
|
+
</p>
|
|
3201
|
+
|
|
3202
|
+
<h3>UPDATE (en mode parallèle)</h3>
|
|
3203
|
+
|
|
3204
|
+
<p>La cohérence des données entre les serveurs pourrait être perdue si la
|
|
3205
|
+
colonne qui sert de clé de partitionnement subit des mises à jour. En effet,
|
|
3206
|
+
pgpool-II ne re-partitionne pas les données ainsi mises à jour.</p>
|
|
3207
|
+
|
|
3208
|
+
<p>Une transaction ne peut pas être annulée (ROLLBACK) si la requête qui a
|
|
3209
|
+
causé l'erreur sur un ou plusieurs serveurs PostgreSQL est due à une violation
|
|
3210
|
+
de contrainte.</p>
|
|
3211
|
+
|
|
3212
|
+
<p>
|
|
3213
|
+
Si une fonction est appelée dans la clause <code>WHERE</code>, la requête
|
|
3214
|
+
pourrait ne pas être correctement exécutée. Par exemple :
|
|
3215
|
+
<pre>
|
|
3216
|
+
UPDATE branches set bid = 100 where bid = (select max(bid) from beances);
|
|
3217
|
+
</pre>
|
|
3218
|
+
</p>
|
|
3219
|
+
|
|
3220
|
+
<h3>SELECT ... FOR UPDATE (en mode parallèle)</h3>
|
|
3221
|
+
|
|
3222
|
+
<p>Si une fonction est appelée dans la clause <code>WHERE</code>, la requête
|
|
3223
|
+
pourrait ne pas être correctement exécutée. Par exemple :
|
|
3224
|
+
<pre>
|
|
3225
|
+
SELECT * FROM branches where bid = (select max(bid) from beances) FOR UPDATE;
|
|
3226
|
+
</pre>
|
|
3227
|
+
</p>
|
|
3228
|
+
|
|
3229
|
+
<h3>COPY (en mode parallèle)</h3>
|
|
3230
|
+
|
|
3231
|
+
<p><code>COPY BINARY</code> n'est pas supporté.
|
|
3232
|
+
|
|
3233
|
+
COPY à partir de fichiers n'est pas non plus supporté. Seuls <code>COPY FROM
|
|
3234
|
+
STDIN</code> et <code>COPY TO STDOUT</code> sont supportés.</p>
|
|
3235
|
+
|
|
3236
|
+
<h3>ALTER/CREATE TABLE (en mode parallèle)</h3>
|
|
3237
|
+
|
|
3238
|
+
<p>Pour mettre à jour une règle de partitionnement, pgpool-II doit être
|
|
3239
|
+
redémarré pour qu'il puisse relire les règles dans sa base de données système.</p>
|
|
3240
|
+
|
|
3241
|
+
<h3>Transactions (en mode parallèle)</h3>
|
|
3242
|
+
|
|
3243
|
+
<p>Les requêtes <code>SELECT</code> exécutées à l'intérieur d'un bloc
|
|
3244
|
+
de transactions seront exécutés dans des transactions séparées. Voici un
|
|
3245
|
+
exemple :
|
|
3246
|
+
|
|
3247
|
+
<pre>
|
|
3248
|
+
BEGIN;
|
|
3249
|
+
INSERT INTO t(a) VALUES (1);
|
|
3250
|
+
SELECT * FROM t ORDER BY a; << l'INSERT ci-dessus n'est pas visible pour
|
|
3251
|
+
cette requête SELECT
|
|
3252
|
+
END;
|
|
3253
|
+
</pre>
|
|
3254
|
+
|
|
3255
|
+
<h3>Vues et règles (en mode parallèle)</h3>
|
|
3256
|
+
|
|
3257
|
+
<p>
|
|
3258
|
+
La même définition de vue ou de règle (RULE) sera créée sur tous les serveurs.
|
|
3259
|
+
</p>
|
|
3260
|
+
|
|
3261
|
+
<pre>
|
|
3262
|
+
SELECT * FROM a, b where a.i = b.i
|
|
3263
|
+
</pre>
|
|
3264
|
+
<p>
|
|
3265
|
+
Les <code>jointures</code> comme celles ci-dessus seront exécutées sur chaque
|
|
3266
|
+
serveur, et le résultat de chaque serveur sera intégré pour être retourné au
|
|
3267
|
+
client. Les vues et règles ne peuvent pas faire de jointures à travers les
|
|
3268
|
+
différents serveurs.
|
|
3269
|
+
|
|
3270
|
+
Cependant, pour faire une jointure entre des tables dont les données sont
|
|
3271
|
+
présentes sur un même serveur, une vue peut être utilisée.
|
|
3272
|
+
|
|
3273
|
+
Cette vue doit être enregistrée dans la table du catalogue
|
|
3274
|
+
pgpool_catalog.dist_def. De même, un col_name et un dist_def_func devront
|
|
3275
|
+
être enregistrés. Ces derniers sont utilisés lors qu'une insertion est réalisée
|
|
3276
|
+
sur la vue.
|
|
3277
|
+
</p>
|
|
3278
|
+
|
|
3279
|
+
<h3>Fonctions et triggers (en mode parallèle)</h3>
|
|
3280
|
+
|
|
3281
|
+
<p>Pour les fonctions, c'est la même définition qui sera utilisée pour leur
|
|
3282
|
+
création dans les différents serveurs de données. Comme précédemment, on ne
|
|
3283
|
+
peut pas faire de jointure entre les différents serveurs au sein d'une
|
|
3284
|
+
fonction.</p>
|
|
3285
|
+
|
|
3286
|
+
<h3>Protocole étendu de requêtage (en mode parallèle)</h3>
|
|
3287
|
+
|
|
3288
|
+
<p>Le protocole étendu de requêtage (« extended query protocol ») utilisé par les
|
|
3289
|
+
connecteurs JDBC, entre autres, n'est pas supporté.
|
|
3290
|
+
|
|
3291
|
+
Le protocole simple doit être utilisé à la place. Cela veut dire, entre autres,
|
|
3292
|
+
qu'on ne peut pas utiliser les requêtes préparées.</p>
|
|
3293
|
+
|
|
3294
|
+
<h3>Jointure naturelle (en mode parallèle)</h3>
|
|
3295
|
+
|
|
3296
|
+
<p>Ce n'est pas supporté non plus. Les clauses ON et USING
|
|
3297
|
+
doivent être utilisées à la place.</p>
|
|
3298
|
+
|
|
3299
|
+
<h3>Clause USING (en mode parallèle)</h3>
|
|
3300
|
+
|
|
3301
|
+
<p>La clause USING est convertie en une clause ON par le processus qui réécrit
|
|
3302
|
+
les requêtes. Ainsi, lorsque * est utilisé comme liste cible, les colonnes
|
|
3303
|
+
jointes apparaissent deux fois.</p>
|
|
3304
|
+
<p>
|
|
3305
|
+
Voici un exemple :
|
|
3306
|
+
</p>
|
|
3307
|
+
<p><pre>
|
|
3308
|
+
=# SELECT * FROM t1 JOIN t2 USING(id);
|
|
3309
|
+
id | t | t
|
|
3310
|
+
----+-----+-------
|
|
3311
|
+
1 | 1st | first
|
|
3312
|
+
(1 row)
|
|
3313
|
+
</pre></p>
|
|
3314
|
+
<p>
|
|
3315
|
+
Le processus de réécriture de requêtes va réécrire USING en ON. Le résultat
|
|
3316
|
+
est alors :
|
|
3317
|
+
</p><p><pre>
|
|
3318
|
+
=# SELECT * FROM t1 JOIN t2 ON t1.id = t2.id;
|
|
3319
|
+
id | t | id | t
|
|
3320
|
+
----+-----+----+-------
|
|
3321
|
+
1 | 1st | 1 | first
|
|
3322
|
+
(1 row)
|
|
3323
|
+
</pre>
|
|
3324
|
+
</p>
|
|
3325
|
+
<p>
|
|
3326
|
+
On remarque que la colonne t est dupliquée.
|
|
3327
|
+
</p>
|
|
3328
|
+
|
|
3329
|
+
<h3>Caractères multi-octets (pour tous les modes)</h3>
|
|
3330
|
+
|
|
3331
|
+
<p>pgpool-II n'opère pas de traduction entre les différents caractères
|
|
3332
|
+
multi-octets. L'encodage utilisé par le client, le serveur et la base de données
|
|
3333
|
+
système doit donc être identique.
|
|
3334
|
+
</p>
|
|
3335
|
+
|
|
3336
|
+
<h3>Requêtes multiples (tous modes)</h3>
|
|
3337
|
+
<p>
|
|
3338
|
+
pgpool-II ne peut pas prendre en charge les requêtes multiples (plusieurs requêtes
|
|
3339
|
+
séparées par un point-virgule, exécutées en un coup).
|
|
3340
|
+
</p>
|
|
3341
|
+
|
|
3342
|
+
<h3>Deadlocks (en mode parallèle)</h3>
|
|
3343
|
+
|
|
3344
|
+
<p>Les deadlocks à travers plusieurs serveurs ne peuvent pas être
|
|
3345
|
+
détectés. Par exemple :
|
|
3346
|
+
</p>
|
|
3347
|
+
<pre>
|
|
3348
|
+
(la table "tellers" est partitionnée avec la règle suivante)
|
|
3349
|
+
tid <= 10 --> node 0
|
|
3350
|
+
tid >= 10 --> node 1
|
|
3351
|
+
|
|
3352
|
+
A) BEGIN;
|
|
3353
|
+
B) BEGIN;
|
|
3354
|
+
A) SELECT * FROM tellers WHERE tid = 11 FOR UPDATE;
|
|
3355
|
+
B) SELECT * FROM tellers WHERE tid = 1 FOR UPDATE;
|
|
3356
|
+
A) SELECT * FROM tellers WHERE tid = 1 FOR UPDATE;
|
|
3357
|
+
B) SELECT * FROM tellers WHERE tid = 11 FOR UPDATE;
|
|
3358
|
+
</pre>
|
|
3359
|
+
<p>
|
|
3360
|
+
Dans le cas ci-dessus, un serveur seul ne peut pas détecter de deadlock. Du coup,
|
|
3361
|
+
pgpool-II attendra une réponse indéfiniment. Ce phénomène peut apparaître avec
|
|
3362
|
+
toute requête qui acquiert un verrou au niveau de l'enregistrement.
|
|
3363
|
+
</p>
|
|
3364
|
+
<p>Aussi, si un deadlock arrive sur un serveur, l'état de la transaction sur
|
|
3365
|
+
chaque serveur ne sera pas cohérent. Ainsi, pgpool-II arrête le processus si
|
|
3366
|
+
un deadlock est détecté.
|
|
3367
|
+
</p>
|
|
3368
|
+
<pre>
|
|
3369
|
+
pool_read_kind: kind does not match between master(84) slot[1] (69)
|
|
3370
|
+
</pre>
|
|
3371
|
+
|
|
3372
|
+
<h3>Schémas (en mode parallèle)</h3>
|
|
3373
|
+
|
|
3374
|
+
<p>Les objets qui se trouve dans un autre schéma que public doivent être
|
|
3375
|
+
préfixés par le nom du schéma dans lequel ils se trouvent :
|
|
3376
|
+
</p>
|
|
3377
|
+
<pre>
|
|
3378
|
+
schéma.objet
|
|
3379
|
+
</pre>
|
|
3380
|
+
<p>
|
|
3381
|
+
pgpool-II ne peut pas résoudre le nom de schéma correct lorsque le chemin est
|
|
3382
|
+
configuré comme suit :
|
|
3383
|
+
</p>
|
|
3384
|
+
<pre>
|
|
3385
|
+
set search_path = xxx
|
|
3386
|
+
</pre>
|
|
3387
|
+
<p>
|
|
3388
|
+
et que le nom du schéma n'est pas précisé dans la requête.
|
|
3389
|
+
</p>
|
|
3390
|
+
|
|
3391
|
+
<h3>nom de table - nom de colonne (en mode parallèle)</h3>
|
|
3392
|
+
|
|
3393
|
+
<p>
|
|
3394
|
+
Une table ou un nom de colonne ne peut pas être préfixé par « pool_ ».
|
|
3395
|
+
|
|
3396
|
+
En effet, lors de la réécriture des requêtes, ces noms sont utilisés par des
|
|
3397
|
+
processus internes à pgpool-II.
|
|
3398
|
+
</p>
|
|
3399
|
+
|
|
3400
|
+
<h2>Base de données système</h2>
|
|
3401
|
+
|
|
3402
|
+
<h3>Règles de partitionnement</h3>
|
|
3403
|
+
|
|
3404
|
+
<p>On ne peut définir qu'une seule clé de partitionnement par règle de
|
|
3405
|
+
partitionnement. Les condition comme « x ou y » ne sont pas supportées.
|
|
3406
|
+
</p>
|
|
3407
|
+
|
|
3408
|
+
<h2>Pré-requis de l'environnement</h2>
|
|
3409
|
+
|
|
3410
|
+
<h3>libpq</h3>
|
|
3411
|
+
|
|
3412
|
+
<p>La bibliothèque <code>libpq</code> est liée lors de la compilation de
|
|
3413
|
+
pgpool-II. La version de la libpq doit être la 3.0.
|
|
3414
|
+
|
|
3415
|
+
Toute tentative de compilation de pgpool-II avec la version 2.0 de la libpq
|
|
3416
|
+
finira par un échec. De même, la base de données système doit être au minimum dans
|
|
3417
|
+
une version 7.4 de PostgreSQL.
|
|
3418
|
+
</p>
|
|
3419
|
+
|
|
3420
|
+
<h2>Cache de requêtes</h2>
|
|
3421
|
+
|
|
3422
|
+
<p>Actuellement, le cache de requêtes doit être supprimé manuellement.
|
|
3423
|
+
pgpool-II n'a pas de mécanisme d'invalidation de cache automatique lorsque les
|
|
3424
|
+
données sont mises à jour.
|
|
3425
|
+
</p>
|
|
3426
|
+
|
|
3427
|
+
<h2>Compatibilité avec pgpool</h2>
|
|
3428
|
+
|
|
3429
|
+
<h1>Référence<a name="reference"></a></h1>
|
|
3430
|
+
<h2>Référence des commandes PCP</h2>
|
|
3431
|
+
|
|
3432
|
+
<h3>Liste des commandes PCP</h3>
|
|
3433
|
+
|
|
3434
|
+
<p>Les commandes PCP sont des commandes UNIX qui interagissent avec pgpool-II à
|
|
3435
|
+
travers le réseau.
|
|
3436
|
+
|
|
3437
|
+
<pre>
|
|
3438
|
+
* pcp_node_count - retourne le nombre de nœuds (serveurs PostgreSQL)
|
|
3439
|
+
* pcp_node_info - retourne l'information sur un nœud
|
|
3440
|
+
* pcp_proc_count - retourne la liste des processus
|
|
3441
|
+
* pcp_proc_info - retourne l'information sur un processus
|
|
3442
|
+
* pcp_systemdb_info - retourne l'information sur la base de donnée système
|
|
3443
|
+
* pcp_detach_node - détache un nœud de pgpool-II
|
|
3444
|
+
* pcp_attach_node - attache un nœud à pgpool-II
|
|
3445
|
+
* pcp_stop_pgpool - stoppe pgpool-II
|
|
3446
|
+
</pre>
|
|
3447
|
+
</p>
|
|
3448
|
+
|
|
3449
|
+
|
|
3450
|
+
<h2>Arguments communs aux outils en ligne de commande</h2>
|
|
3451
|
+
|
|
3452
|
+
<p>Il y a cinq arguments qui sont communs à toutes les commandes PCP. Ils donnent
|
|
3453
|
+
l'information relative à l'authentification et à pgpool-II. Des arguments
|
|
3454
|
+
complémentaires peuvent être nécessaires pour quelques commandes.
|
|
3455
|
+
|
|
3456
|
+
<pre>
|
|
3457
|
+
$ pcp_node_count 10 localhost 9898 postgres hogehoge
|
|
3458
|
+
|
|
3459
|
+
1er argument - délai maximum en secondes (PCP se déconnecte si
|
|
3460
|
+
pgpool-II ne répond pas dans le temps imparti ici)
|
|
3461
|
+
2nd argument - nom d'hôte (ou adresse IP) du serveur pgpool-II
|
|
3462
|
+
3ème argument - numéro de port de PCP
|
|
3463
|
+
4ème argument - nom d'utilisateur de PCP
|
|
3464
|
+
5ème argument - mot de passe de l'utilisateur de PCP
|
|
3465
|
+
</pre>
|
|
3466
|
+
|
|
3467
|
+
<p>Les noms d'utilisateurs et mot de passe PCP doivent être déclarés
|
|
3468
|
+
dans le fichier <code>pcp.conf</code> installé dans le répertoire
|
|
3469
|
+
<code>$prefix/etc</code>.
|
|
3470
|
+
|
|
3471
|
+
L'option <code>-F</code> peut être utilisée lors du démarrage de pgpool-II si
|
|
3472
|
+
le fichier <code>pcp.conf</code> est placé ailleurs. Les mots de passe n'ont pas besoin
|
|
3473
|
+
d'être au format md5 lorsqu'on les passe aux commandes PCP.
|
|
3474
|
+
</p>
|
|
3475
|
+
|
|
3476
|
+
|
|
3477
|
+
<h2>Commandes PCP</h2>
|
|
3478
|
+
|
|
3479
|
+
<p>Toutes les commandes PCP renvoie les résultats vers la sortie standard.</p>
|
|
3480
|
+
|
|
3481
|
+
|
|
3482
|
+
<h3>pcp_node_count</h3>
|
|
3483
|
+
|
|
3484
|
+
<pre>
|
|
3485
|
+
Format :
|
|
3486
|
+
pcp_node_count _timeout_ _hôte_ _port_ _userid_ _passwd_
|
|
3487
|
+
</pre>
|
|
3488
|
+
|
|
3489
|
+
<p>
|
|
3490
|
+
Affiche le nombre total de nœuds définis dans le fichier <code>pgpool.conf</code>. Il ne
|
|
3491
|
+
fait aucune distinction entre le statut des différents nœuds. Ainsi, tous les nœuds
|
|
3492
|
+
sont comptés ici.
|
|
3493
|
+
</p>
|
|
3494
|
+
|
|
3495
|
+
|
|
3496
|
+
<h3><a name="pcp_node_info"/>pcp_node_info</h3>
|
|
3497
|
+
|
|
3498
|
+
<pre>
|
|
3499
|
+
Format :
|
|
3500
|
+
pcp_node_info _timeout_ _hôte_ _port_ _userid_ _passwd_ _nodeid_
|
|
3501
|
+
</pre>
|
|
3502
|
+
|
|
3503
|
+
<p>
|
|
3504
|
+
Affiche l'information relative au numéro de nœud donné. Voici un exemple de
|
|
3505
|
+
sortie :
|
|
3506
|
+
</p>
|
|
3507
|
+
|
|
3508
|
+
<pre>
|
|
3509
|
+
$ pcp_node_info 10 localhost 9898 postgres hogehoge 0
|
|
3510
|
+
host1 5432 1 1073741823.500000
|
|
3511
|
+
|
|
3512
|
+
Le résultat est dans l'ordre suivant:
|
|
3513
|
+
1. nom d'hôte
|
|
3514
|
+
2. numéro de port
|
|
3515
|
+
3. statut
|
|
3516
|
+
4. poids configuré pour la répartition de charge
|
|
3517
|
+
|
|
3518
|
+
Le statut est représenté par un chiffre de 0 à 3 :
|
|
3519
|
+
|
|
3520
|
+
0 - Cet état est uniquement utilisé pendant l'initialisation. PCP ne l'affichera jamais
|
|
3521
|
+
1 - Le nœud est en ligne, mais aucune connexion n'est encore faite dessus
|
|
3522
|
+
2 - Le nœud est en ligne, et les connexions sont poolés
|
|
3523
|
+
3 - Le nœud est arrêté
|
|
3524
|
+
</pre>
|
|
3525
|
+
<p>
|
|
3526
|
+
Le poids configuré pour la répartition de charge est affiché dans un format normalisé.
|
|
3527
|
+
</p>
|
|
3528
|
+
|
|
3529
|
+
<p>
|
|
3530
|
+
L'option --verbose peut permettre une meilleure compréhension. Par exemple :
|
|
3531
|
+
</p>
|
|
3532
|
+
|
|
3533
|
+
<pre>
|
|
3534
|
+
$ pcp_node_info --verbose 10 localhost 9898 postgres hogehoge 0
|
|
3535
|
+
Hostname: host1
|
|
3536
|
+
Port : 5432
|
|
3537
|
+
Status : 1
|
|
3538
|
+
Weight : 0.5
|
|
3539
|
+
</pre>
|
|
3540
|
+
|
|
3541
|
+
<p>La spécification d'un identifiant de nœud invalide résultera dans une erreur
|
|
3542
|
+
avec un code de sortie 12, et « BackendError » sera alors affiché.</p>
|
|
3543
|
+
|
|
3544
|
+
<h3>pcp_proc_count</h3>
|
|
3545
|
+
<p>
|
|
3546
|
+
<pre>
|
|
3547
|
+
Format :
|
|
3548
|
+
pcp_proc_count _timeout_ _host_ _port_ _userid_ _passwd_
|
|
3549
|
+
</pre>
|
|
3550
|
+
<p>
|
|
3551
|
+
Liste les identifiants des processus fils de pgpool-II. S'il y a plus d'un
|
|
3552
|
+
processus, les identifiants seront délimités par un espace.
|
|
3553
|
+
</p>
|
|
3554
|
+
<h3>pcp_proc_info</h3>
|
|
3555
|
+
<p>
|
|
3556
|
+
<pre>
|
|
3557
|
+
Format:
|
|
3558
|
+
pcp_proc_info _timeout_ _host_ _port_ _userid_ _passwd_ _processid_
|
|
3559
|
+
</pre>
|
|
3560
|
+
<p>
|
|
3561
|
+
Affiche l'information d'un processus fils de pgpool-II, désigné par son identifiant de
|
|
3562
|
+
processus. Voici un exemple de retour de cette commande :
|
|
3563
|
+
</p>
|
|
3564
|
+
<pre>
|
|
3565
|
+
$ pcp_proc_info 10 localhost 9898 postgres hogehoge 3815
|
|
3566
|
+
postgres_db postgres 1150769932 1150767351 3 0 1 1467 1
|
|
3567
|
+
postgres_db postgres 1150769932 1150767351 3 0 1 1468 1
|
|
3568
|
+
|
|
3569
|
+
Le résultat est affiché dans l'ordre suivant :
|
|
3570
|
+
1. nom de la base de données connectée
|
|
3571
|
+
2. nom de l'utilisateur connecté
|
|
3572
|
+
3. horodatage correspondant au démarrage du processus
|
|
3573
|
+
4. horodatage correspondant au démarrage de la connexion
|
|
3574
|
+
5. numéro de version majeure du protocole
|
|
3575
|
+
6. numéro de version mineure du protocole
|
|
3576
|
+
7. compteur du nombre de réutilisations de cette connexion
|
|
3577
|
+
8. numéro d'identifiant du processus serveur PostgreSQL
|
|
3578
|
+
9. 1 si le client est connecté, 0 sinon
|
|
3579
|
+
</pre>
|
|
3580
|
+
<p>
|
|
3581
|
+
S'il n'y a aucune connexion aux processus serveurs, rien ne sera affiché. S'il y a
|
|
3582
|
+
plusieurs connexions, les informations seront affichées sur plusieurs lignes et
|
|
3583
|
+
plusieurs fois. Les horodatages sont affichés au format EPOCH.
|
|
3584
|
+
</p>
|
|
3585
|
+
|
|
3586
|
+
<p>
|
|
3587
|
+
L'option --verbose permet de mieux comprendre la sortie de la commande. Par
|
|
3588
|
+
exemple :
|
|
3589
|
+
</p>
|
|
3590
|
+
|
|
3591
|
+
<pre>
|
|
3592
|
+
$ pcp_proc_info --verbose 10 localhost 9898 postgres hogehoge 3815
|
|
3593
|
+
Database : postgres_db
|
|
3594
|
+
Username : postgres
|
|
3595
|
+
Start time : 1150769932
|
|
3596
|
+
Creation time: 1150767351
|
|
3597
|
+
Major : 3
|
|
3598
|
+
Minor : 0
|
|
3599
|
+
Counter : 1
|
|
3600
|
+
PID : 1467
|
|
3601
|
+
Connected : 1
|
|
3602
|
+
Database : postgres_db
|
|
3603
|
+
Username : postgres
|
|
3604
|
+
Start time : 1150769932
|
|
3605
|
+
Creation time: 1150767351
|
|
3606
|
+
Major : 3
|
|
3607
|
+
Minor : 0
|
|
3608
|
+
Counter : 1
|
|
3609
|
+
PID : 1468
|
|
3610
|
+
Connected : 1
|
|
3611
|
+
</pre>
|
|
3612
|
+
|
|
3613
|
+
<p>La spécification d'un identifiant de nœud invalide résultera dans une erreur
|
|
3614
|
+
avec un code de sortie 12, et « BackendError » sera alors affiché.</p>
|
|
3615
|
+
|
|
3616
|
+
<h3>pcp_systemdb_info</h3>
|
|
3617
|
+
<p>
|
|
3618
|
+
<pre>
|
|
3619
|
+
Format :
|
|
3620
|
+
pcp_systemdb_info _timeout_ _host_ _port_ _userid_ _passwd_
|
|
3621
|
+
</pre>
|
|
3622
|
+
<p>
|
|
3623
|
+
Affiche des informations sur la base de données système. Voici un exemple de
|
|
3624
|
+
sortie :
|
|
3625
|
+
</p>
|
|
3626
|
+
<pre>
|
|
3627
|
+
$ pcp_systemdb_info 10 localhost 9898 postgres hogehoge
|
|
3628
|
+
localhost 5432 yamaguti '' pgpool_catalog pgpool 3
|
|
3629
|
+
yamaguti public accounts aid 4 aid bid abalance filler integer integer integer character(84) dist_def_accounts
|
|
3630
|
+
yamaguti public branches bid 3 bid bbalance filler integer integer character(84) dist_def_branches
|
|
3631
|
+
yamaguti public tellers bid 4 tid bid tbalance filler integer integer integer character(84) dist_def_tellers
|
|
3632
|
+
|
|
3633
|
+
L'information sur la base de donnée système sera affichée sur la toute première
|
|
3634
|
+
ligne. Voici l'ordre des résultats :
|
|
3635
|
+
|
|
3636
|
+
1. nom d'hôte
|
|
3637
|
+
2. numéro de port
|
|
3638
|
+
3. nom d'utilisateur
|
|
3639
|
+
4. mot de passe (une chaîne vide s'il n'y en a pas)
|
|
3640
|
+
5. nom de schéma
|
|
3641
|
+
6. nom de la base de données
|
|
3642
|
+
7. nombre de règles de partitionnement définies
|
|
3643
|
+
</pre>
|
|
3644
|
+
<p>
|
|
3645
|
+
|
|
3646
|
+
Ensuite, les règles de partitionnement sont affichées sur les lignes suivantes.
|
|
3647
|
+
S'il y a de multiples définitions, elles seront affichées sur autant de lignes
|
|
3648
|
+
que nécessaire. Le résultat s'affiche dans l'ordre suivant :
|
|
3649
|
+
</p>
|
|
3650
|
+
<pre>
|
|
3651
|
+
1. le nom de la base de données cible du partitionnement
|
|
3652
|
+
2. le nom du schéma dans cette base
|
|
3653
|
+
3. le nom de la table dans ce schéma
|
|
3654
|
+
4. le nom de la colonne qui sert de clé de partitionnement
|
|
3655
|
+
5. le nombre de colonnes dans la table
|
|
3656
|
+
6. le nom de ces colonnes (autant de fois que précisé au 5.)
|
|
3657
|
+
7. le nom des types de données de ces colonnes (autant de fois que précisé au 5.)
|
|
3658
|
+
8. le nom de la fonction utilisée pour la règle de partitionnement
|
|
3659
|
+
</pre>
|
|
3660
|
+
<p>
|
|
3661
|
+
Si la base de données système n'est pas définie (autrement dit, on n'est pas dans un mode
|
|
3662
|
+
pgpool-II, et le cache de requêtes est désactivé), on a une erreur avec un
|
|
3663
|
+
statut de sortie à 12, et le message « BackendError » est affiché.</p>
|
|
3664
|
+
|
|
3665
|
+
|
|
3666
|
+
<h3>pcp_detach_node</h3>
|
|
3667
|
+
<pre>
|
|
3668
|
+
Format :
|
|
3669
|
+
pcp_detach_node [-g] _timeout_ _host_ _port_ _userid_ _passwd_ _nodeid_
|
|
3670
|
+
</pre>
|
|
3671
|
+
<p>
|
|
3672
|
+
Détache le nœud spécifié de pgpool-II.
|
|
3673
|
+
Si l'option -g est donnée, la commande attend que tous les clients soient
|
|
3674
|
+
déconnectés (à moins que le paramètre client_idle_limit_in_recovery soit configuré
|
|
3675
|
+
à -1 ou que le paramètre recovery_timeout soit expiré).
|
|
3676
|
+
</p>
|
|
3677
|
+
|
|
3678
|
+
|
|
3679
|
+
<h3>pcp_attach_node</h3>
|
|
3680
|
+
<p>
|
|
3681
|
+
<pre>
|
|
3682
|
+
Format :
|
|
3683
|
+
pcp_attach_node _timeout_ _host_ _port_ _userid_ _passwd_ _nodeid_
|
|
3684
|
+
|
|
3685
|
+
Attache le nœud spécifié à pgpool-II.
|
|
3686
|
+
</pre>
|
|
3687
|
+
</p>
|
|
3688
|
+
|
|
3689
|
+
<h3>pcp_stop_pgpool</h3>
|
|
3690
|
+
<pre>
|
|
3691
|
+
Format :
|
|
3692
|
+
pcp_stop_pgpool _timeout_ _host_ _port_ _userid_ _passwd_ _mode_
|
|
3693
|
+
</pre>
|
|
3694
|
+
|
|
3695
|
+
<p>
|
|
3696
|
+
Arrête le processus pgpool-II dans le mode d'arrêt spécifié. Les
|
|
3697
|
+
différents modes d'arrêt sont les suivants :
|
|
3698
|
+
</p>
|
|
3699
|
+
|
|
3700
|
+
<pre>
|
|
3701
|
+
s - mode intelligent
|
|
3702
|
+
f - mode rapide
|
|
3703
|
+
i - mode immédiat
|
|
3704
|
+
</pre>
|
|
3705
|
+
<p>
|
|
3706
|
+
Si le processus pgpool-II n'existe pas, on a une erreur avec un statut de
|
|
3707
|
+
sortie à 8, et le message « ConnectionError » sera affiché.
|
|
3708
|
+
</p>
|
|
3709
|
+
<p>
|
|
3710
|
+
En fait, il n'y a pas de différence entre les modes rapide et immédiat.
|
|
3711
|
+
pgpool-II arrête tous les processus, qu'il y ait des clients connectés aux
|
|
3712
|
+
processus serveurs ou pas.</p>
|
|
3713
|
+
|
|
3714
|
+
|
|
3715
|
+
<h2>Statuts de sortie</h2>
|
|
3716
|
+
|
|
3717
|
+
<p>Les commandes PCP on un code de sortie à 0 lorsque tout se passe bien. Si
|
|
3718
|
+
une erreur arrive, ces dernières ont un code de sortie différent, dont voici
|
|
3719
|
+
la liste :
|
|
3720
|
+
|
|
3721
|
+
<pre>
|
|
3722
|
+
UNKNOWNERR 1 Erreur inconnue (ne devrait pas arriver)
|
|
3723
|
+
EOFERR 2 Erreur de fin de fichier
|
|
3724
|
+
NOMEMERR 3 Erreur liée à une insuffisance de mémoire disponible
|
|
3725
|
+
READERR 4 Erreur alors qu'une lecture sur le serveur était en cours
|
|
3726
|
+
WRITEERR 5 Erreur alors qu'une écriture sur le serveur était en cours
|
|
3727
|
+
TIMEOUTERR 6 Timeout
|
|
3728
|
+
INVALERR 7 Les arguments passés à une commande PCP sont invalides
|
|
3729
|
+
CONNERR 8 Erreur de connexion au serveur
|
|
3730
|
+
NOCONNERR 9 Aucune connexion n'existe
|
|
3731
|
+
SOCKERR 10 Erreur de socket unix
|
|
3732
|
+
HOSTERR 11 Erreur de résolution de nom d'hôte
|
|
3733
|
+
BACKENDERR 12 Erreur sur le processus PCP sur le serveur
|
|
3734
|
+
AUTHERR 13 Erreur d'autorisation
|
|
3735
|
+
</pre>
|
|
3736
|
+
</p>
|
|
3737
|
+
|
|
3738
|
+
<h1>Fonctionnement interne<a name="internal"></a></h1>
|
|
3739
|
+
<p>
|
|
3740
|
+
La version 2.0 de pgpool-II amène de nombreuses améliorations, en comparaison à
|
|
3741
|
+
la version 1. Attention, ce qui suit ne s'applique pas à la version 1.
|
|
3742
|
+
</p>
|
|
3743
|
+
|
|
3744
|
+
<h2>Moteur d'exécution parallèle</h2>
|
|
3745
|
+
<p>
|
|
3746
|
+
Le moteur d'exécution parallèle est implémenté dans pgpool-II.
|
|
3747
|
+
Ce moteur exécute la même requête sur tous les nœuds, et pilote le moteur qui
|
|
3748
|
+
transmet les résultats au client, en fonction de la réponse des différents
|
|
3749
|
+
nœuds.
|
|
3750
|
+
</p>
|
|
3751
|
+
|
|
3752
|
+
<h2>Réécriture de requêtes</h2>
|
|
3753
|
+
<p>
|
|
3754
|
+
Cette partie explique le fonctionnement de la réécriture de requêtes que fait
|
|
3755
|
+
pgpool-II en mode parallèle.
|
|
3756
|
+
</p>
|
|
3757
|
+
<p>
|
|
3758
|
+
En mode parallèle, une requête transmise par les clients passe par deux étapes
|
|
3759
|
+
de traitements :
|
|
3760
|
+
</p>
|
|
3761
|
+
<ul>
|
|
3762
|
+
<li>analyse de la requête ;
|
|
3763
|
+
<li>réécriture de la requête ;
|
|
3764
|
+
</ul>
|
|
3765
|
+
<p>
|
|
3766
|
+
Ce qui suit détaille ces deux étapes.
|
|
3767
|
+
</p>
|
|
3768
|
+
<h3>Analyse de la requête</h3>
|
|
3769
|
+
<h4><p>Introduction</p></h4>
|
|
3770
|
+
<p>
|
|
3771
|
+
La récupération de la requête soumise par le client passe par l'analyseur SQL.
|
|
3772
|
+
Elle est alors analysée grâce aux informations stockées dans la base de données
|
|
3773
|
+
système. Le statut d'exécution stocke alors sur quel(s) nœud(s) la requête
|
|
3774
|
+
peut être traitée. Par exemple, si les données d'une table sont distribuées sur
|
|
3775
|
+
plusieurs serveurs (comme déclaré dans la table pgpool_catalog.dist_def du
|
|
3776
|
+
catalogue), ces dernières doivent être récupérées de plusieurs serveurs.
|
|
3777
|
+
|
|
3778
|
+
Ainsi, cette étape retourne le statut P lors que les données doivent être
|
|
3779
|
+
récupérées sur tous les serveurs, L quand elles peuvent être récupérées sur
|
|
3780
|
+
un seul serveur. Le statut spécial S intervient dans un cas particulier : ce
|
|
3781
|
+
dernier signifie qu'il doit y avoir au moins une autre étape exécutée avant
|
|
3782
|
+
de pouvoir récupérer les données de tous les serveurs. Par exemple, trier les
|
|
3783
|
+
données en provenance d'une table enregistrée dans la table catalogue
|
|
3784
|
+
pgpool_catalog.dist_def.
|
|
3785
|
+
</p>
|
|
3786
|
+
|
|
3787
|
+
<p>
|
|
3788
|
+
La requête est analysée dans l'ordre suivant, et son statut d'exécution change
|
|
3789
|
+
alors au cours de cette analyse. Comment et où sera exécutée la requête dépend
|
|
3790
|
+
du statut final de la requête principale.
|
|
3791
|
+
</p>
|
|
3792
|
+
|
|
3793
|
+
<ol>
|
|
3794
|
+
<li>Est-ce que UNION, EXTRACT ou INTERSECT sont utilisées ?
|
|
3795
|
+
<li>Quel est le statut d'exécution de la clause FROM ?
|
|
3796
|
+
<li>Changer le statut d'exécution par TARGETLIST
|
|
3797
|
+
<li>Changer le statut d'exécution en fonction de la clause WHERE
|
|
3798
|
+
<li>Changer le statut d'exécution en fonction de la clause GROUP BY
|
|
3799
|
+
<li>Changer le statut d'exécution en fonction de la clause HAVING
|
|
3800
|
+
<li>Changer le statut d'exécution en fonction de la clause ORDER BY
|
|
3801
|
+
<li>Changer le statut d'exécution en fonction du prédicat LIMIT OFFSET
|
|
3802
|
+
<li>Acquisition du statut final d'exécution du SELECT
|
|
3803
|
+
</ol>
|
|
3804
|
+
|
|
3805
|
+
<p>
|
|
3806
|
+
La relation entre le statut d'exécution final du SELECT et l'endroit où il est
|
|
3807
|
+
exécuté est comme suit :
|
|
3808
|
+
</p>
|
|
3809
|
+
|
|
3810
|
+
<p>
|
|
3811
|
+
<table border>
|
|
3812
|
+
<tr><td>Statut d'exécution</td><td>Lieu d'exécution</td></tr>
|
|
3813
|
+
<tr><td align=center>L</td><td>La requête peut-être
|
|
3814
|
+
exécutée sur n'importe quel serveur</td></tr>
|
|
3815
|
+
<tr><td align=center>P</td><td>Retourne les données au client
|
|
3816
|
+
en exécutant la même requête sur tous les serveurs en utilisant le moteur
|
|
3817
|
+
d'exécution en parallèle.</td></tr>
|
|
3818
|
+
<tr><td align=center>S</td><td>Après traitement dans la base de
|
|
3819
|
+
données système, les données sont renvoyées au client.</td></tr>
|
|
3820
|
+
</table>
|
|
3821
|
+
</p>
|
|
3822
|
+
|
|
3823
|
+
<p>
|
|
3824
|
+
Ces règles s'appliquent aussi aux sous-requêtes. Dans l'exemple simple
|
|
3825
|
+
ci-dessous, si la table P1-table est enregistrée dans la table catalogue
|
|
3826
|
+
pgpool_catalog.dist_def sur la base de données système (P1-table est alors
|
|
3827
|
+
distribuée), le statut d'exécution final de la sous-requête est alors P, et
|
|
3828
|
+
comme résultat, la requête parent du SELECT devient alors obligatoirement P.
|
|
3829
|
+
</p>
|
|
3830
|
+
|
|
3831
|
+
<pre>
|
|
3832
|
+
SELECT * FROM (SELECT * FROM P1-table) as P2-table;
|
|
3833
|
+
</pre>
|
|
3834
|
+
|
|
3835
|
+
<p>
|
|
3836
|
+
Il convient d'expliquer à présent comment le statut d'exécution change
|
|
3837
|
+
concrètement. Commençons par un exemple simple, pour expliquer le statut lié à
|
|
3838
|
+
la clause FROM.
|
|
3839
|
+
</p>
|
|
3840
|
+
|
|
3841
|
+
|
|
3842
|
+
|
|
3843
|
+
<h4><p>Statut d'exécution de la clause FROM</p></h4>
|
|
3844
|
+
<p>
|
|
3845
|
+
Ceci est une requête qui récupère des données (SELECT). L'ensemble de données et
|
|
3846
|
+
son statut (P, L et S) sont définis en fonction de la clause FROM.
|
|
3847
|
+
|
|
3848
|
+
Le statut d'exécution de la table est comme suit : lorsqu'il n'y a qu'une seule
|
|
3849
|
+
table dans la clause FROM, le statut d'exécution de l'ensemble de données entier est le
|
|
3850
|
+
même que celui de cette table. Lorsqu'il y a deux ou plusieurs tables ou des
|
|
3851
|
+
sous-requêtes dans la clause FROM, l'exécution est décidée en fonction de la
|
|
3852
|
+
méthode de jointure et des statuts d'exécutions, comme précisé dans la table
|
|
3853
|
+
suivante.
|
|
3854
|
+
</p>
|
|
3855
|
+
|
|
3856
|
+
<p>
|
|
3857
|
+
<table border>
|
|
3858
|
+
<tr><td>Type de jointure</td><td align = center colspan = 3> LEFT OUTER JOIN
|
|
3859
|
+
</td><td align = center colspan = 3> RIGHT OUTER JOIN </td><td align = center
|
|
3860
|
+
colspan = 3>FULL OUTER JOIN</td><td align = center colspan = 3>Other</td></tr>
|
|
3861
|
+
<tr><td align = center>left/right</td><td> P </td><td> L </td><td> S </td><td> P </td><td> L </td><td> S </td><td> P </td><td> L </td><td> S </td><td> P </td><td> L </td><td> S </td></tr>
|
|
3862
|
+
|
|
3863
|
+
<tr><td align = center> P </td><td> S </td><td> P </td><td> S </td><td> S </td><td> S </td><td> S </td><td> S </td><td> S </td><td> S </td><td> S </td><td> P </td><td> S </td></tr>
|
|
3864
|
+
|
|
3865
|
+
<tr><td align = center> L </td><td> S </td><td> L </td><td> S </td><td> P </td><td> L </td><td> S </td><td> S </td><td> L </td><td> S </td><td> P </td><td> L </td><td> S </td></tr>
|
|
3866
|
+
|
|
3867
|
+
<tr><td align = center> S </td><td> S </td><td> S </td><td> S </td><td> S </td><td> S </td><td> S </td><td> S </td><td> S </td><td> S </td><td> S </td><td> S </td><td> S </td></tr>
|
|
3868
|
+
|
|
3869
|
+
</td></tr>
|
|
3870
|
+
</table>
|
|
3871
|
+
</p>
|
|
3872
|
+
|
|
3873
|
+
<p>
|
|
3874
|
+
Dans les exemple suivants, la table P1-table est en statut P.
|
|
3875
|
+
Les tables L1-table et L2-table sont dans le statut L.
|
|
3876
|
+
<pre>
|
|
3877
|
+
SELECT * FROM P1-table,L1-table,L2-table;
|
|
3878
|
+
</pre>
|
|
3879
|
+
|
|
3880
|
+
|
|
3881
|
+
P1-table (gauche) et L1-table (droite) sont jointes, et en fonction du tableau
|
|
3882
|
+
ci-dessus, prennent le statut P. Avec ce statut P, elles sont jointes avec la
|
|
3883
|
+
table L2-table, qui est de statut L et qui devient alors en statut P aussi.
|
|
3884
|
+
</p>
|
|
3885
|
+
|
|
3886
|
+
|
|
3887
|
+
<h4><p>Changement de statut d'exécution dus aux clause TARGETLIST et
|
|
3888
|
+
WHERE</p></h4>
|
|
3889
|
+
<p>
|
|
3890
|
+
Dans une requête simple, le statut d'exécution est le même que celui de la
|
|
3891
|
+
clause FROM. Cependant, s'il y a une TARGETLIST, le statut d'exécution de la
|
|
3892
|
+
clause WHERE peut changer dans les cas suivants :
|
|
3893
|
+
</p>
|
|
3894
|
+
<ol>
|
|
3895
|
+
<li>lorsqu'il y a une sous-requête
|
|
3896
|
+
<li>lorsqu'il y a une fonction d'agrégat ou un DISTINCT dans la
|
|
3897
|
+
TARGETLIST marquée P
|
|
3898
|
+
<li>lorsqu'une colonne qui n'existe pas dans la table
|
|
3899
|
+
(l'ensemble de données) est utilisée dans la clause FROM.
|
|
3900
|
+
</ol>
|
|
3901
|
+
<p>
|
|
3902
|
+
Dans ces cas, le statut d'exécution final de la sous-requête, le statut
|
|
3903
|
+
d'exécution de la TARGETLIST et la clause WHERE passent en statut S si leur
|
|
3904
|
+
statut initial était P ou S.
|
|
3905
|
+
<p>
|
|
3906
|
+
Dans l'exemple suivant, lorsqu'une table de statut P est utilisée par une
|
|
3907
|
+
sous-requête, le statut d'exécution final de la sous-requête prend le statut P.
|
|
3908
|
+
Ainsi, le statut d'exécution de la clause WHERE passe au statut S, quel que
|
|
3909
|
+
soit le statut d'exécution de LA, et cette requête est exécutée dans la base de
|
|
3910
|
+
données système.
|
|
3911
|
+
<pre>
|
|
3912
|
+
SELECT * FROM L1-table where L1-table.column IN (SELECT * FROM P1-table);
|
|
3913
|
+
</pre>
|
|
3914
|
+
<p>
|
|
3915
|
+
La clause FROM passe au statut S lorsqu'il y a une fonction d'agrégat marquée P
|
|
3916
|
+
dans la TARGETLIST, afin de faire cet agrégat après que toutes les données
|
|
3917
|
+
aient été récupérées.
|
|
3918
|
+
Certaines optimisations sur la fonction d'agrégat sont faites dans des cas
|
|
3919
|
+
spécifiques.</p>
|
|
3920
|
+
<p>
|
|
3921
|
+
Une colonne qui n'existe pas dans la table peut être utilisée dans la requête.
|
|
3922
|
+
Par exemple, dans une sous-requête corrélée :
|
|
3923
|
+
</p>
|
|
3924
|
+
<pre>
|
|
3925
|
+
SELECT * FROM L1-table WHERE L1-table.col1 IN (SELECT * FROM
|
|
3926
|
+
P1-table WHERE P1-table.col = L1-table.col1);
|
|
3927
|
+
</pre>
|
|
3928
|
+
<p>
|
|
3929
|
+
Cette sous-requête fait référence à L1-table.col1, dans la table L1-table. Le
|
|
3930
|
+
statut d'exécution de la clause WHERE de la sous-requête est S.
|
|
3931
|
+
</p>
|
|
3932
|
+
|
|
3933
|
+
<h4><p>Changement de statuts d'exécution provoqués par GROUP BY, HAVING, ORDER
|
|
3934
|
+
BY et LIMIT/OFFSET</p></h4>
|
|
3935
|
+
|
|
3936
|
+
<p>
|
|
3937
|
+
Le statut d'exécution de la cause WHERE est changé à S lorsqu'il y a une
|
|
3938
|
+
clause GROUP BY, HAVING, ORDER BY ou bien un prédicat LIMIT/OFFSET avec un
|
|
3939
|
+
statut P. Une requête sans la clause GROUP BY prend le statut d'exécution de
|
|
3940
|
+
la clause WHERE.
|
|
3941
|
+
|
|
3942
|
+
De même, le statut d'exécution de la clause GROUP BY est utilisé lorsqu'il n'y
|
|
3943
|
+
a pas de clause HAVING. La clause ORDER BY et le prédicat LIMIT/OFFSET ont
|
|
3944
|
+
aussi le même comportement.
|
|
3945
|
+
</p>
|
|
3946
|
+
|
|
3947
|
+
<h4><p>Lorsque UNION, EXTRACT et INTERSECT sont utilisés</p></h4>
|
|
3948
|
+
<p>
|
|
3949
|
+
Le statut des requêtes avec UNION, EXTRACT, ou INTERSECT dépend des deux statuts
|
|
3950
|
+
d'exécution finaux des requêtes gauche et droite à la fois. Si les deux sont
|
|
3951
|
+
en P et que la requête est un UNION ALL, le statut d'exécution combiné est P.
|
|
3952
|
+
Dans toutes les autres combinaisons, le statut final sera S.
|
|
3953
|
+
</p>
|
|
3954
|
+
<h4><p>Acquisition du statut d'exécution final d'une requête SELECT</p></h4>
|
|
3955
|
+
<p>
|
|
3956
|
+
Si tout ce qui est dans le SELECT est de statut L, alors le statut d'exécution
|
|
3957
|
+
final est L. La même règle s'applique pour P. Pour toutes les autres
|
|
3958
|
+
combinaisons, le statut final est S. Si le statut est L, la charge est
|
|
3959
|
+
distribuée sur tous les serveurs lorsque le paramètre loadbalance_mode vaut true,
|
|
3960
|
+
sinon elle est envoyée sur le maître (false). Pour P, un traitement parallèle
|
|
3961
|
+
est fait grâce au moteur d'exécution parallèle. Pour S, la réécriture de la
|
|
3962
|
+
requête est présentée ci-dessous est effectuée.
|
|
3963
|
+
</p>
|
|
3964
|
+
|
|
3965
|
+
<h3>Réécriture de requête</h3>
|
|
3966
|
+
<p>
|
|
3967
|
+
La requête est réécrite ou pas en fonction de son statut d'exécution qui est
|
|
3968
|
+
acquis lors de l'analyse de la requête.
|
|
3969
|
+
Voici un exemple. La table P1-table est de statut P, la table L1-table est elle
|
|
3970
|
+
de statut L.
|
|
3971
|
+
|
|
3972
|
+
</p>
|
|
3973
|
+
<pre>
|
|
3974
|
+
SELECT P1-table.col, L1-table.col
|
|
3975
|
+
FROM P1-table,L1-table
|
|
3976
|
+
WHERE P1-table.col = L1-table.col
|
|
3977
|
+
ORDER BY P1-table.col;
|
|
3978
|
+
</pre>
|
|
3979
|
+
|
|
3980
|
+
<p>
|
|
3981
|
+
Dans cette requête, le statut est S à cause de la clause ORDER BY.
|
|
3982
|
+
Les clauses FROM, WHERE et TARGETLIST sont de statut P.
|
|
3983
|
+
La requête est alors réécrite en quelque chose ressemblant à ceci :
|
|
3984
|
+
</p>
|
|
3985
|
+
|
|
3986
|
+
<pre>
|
|
3987
|
+
SELECT P1-table.col, L1-table.col FROM
|
|
3988
|
+
dblink(select pool_parallel(SELECT P1-table.col, L1-table.col FROM P1-table,L1-table where P1-table.col = L1-table.col))
|
|
3989
|
+
ORDER BY P1-table.col;
|
|
3990
|
+
</pre>
|
|
3991
|
+
<p>
|
|
3992
|
+
dblink transmet ici la requête à pgpool-II.
|
|
3993
|
+
La fonction pool_parallel a la responsabilité de transmettre la requête au
|
|
3994
|
+
moteur d'exécution parallèle.
|
|
3995
|
+
</p>
|
|
3996
|
+
<p>Dans cet exemple, les clauses FROM et WHERE, ainsi que la TARGETLIST, sont
|
|
3997
|
+
exécutés en mode parallèle. Ceci n'est pas la requête réellement réécrite, mais
|
|
3998
|
+
juste fournie en guise d'exemple, par soucis de lisibilité et de
|
|
3999
|
+
compréhension.
|
|
4000
|
+
</p>
|
|
4001
|
+
<p>
|
|
4002
|
+
Voici un autre cas :
|
|
4003
|
+
</p>
|
|
4004
|
+
|
|
4005
|
+
<pre>
|
|
4006
|
+
SELECT L1-table.col FROM L1-table WHERE L1-table.col % 2 = 0 AND L1-table.col IN (SELECT P1-table FROM P1-table) ;
|
|
4007
|
+
</pre>
|
|
4008
|
+
|
|
4009
|
+
<p>
|
|
4010
|
+
Dans cet exemple, les clauses FROM, WHERE et la TARGETLIST sont en statut L, à
|
|
4011
|
+
cause de la sous-requête qui est de statut P. La requête elle-même est de
|
|
4012
|
+
statut S. En conséquence, une réécrite est effectuée comme suit :
|
|
4013
|
+
</p>
|
|
4014
|
+
<pre>
|
|
4015
|
+
SELECT L1-table.col
|
|
4016
|
+
FROM dblink(SELECT loadbalance(SELECT L1-table.col
|
|
4017
|
+
FROM L1-table
|
|
4018
|
+
WHERE L1-table.col % 2 = 0
|
|
4019
|
+
AND TRUE))
|
|
4020
|
+
WHERE
|
|
4021
|
+
L1-table.col %2 = 0 AND
|
|
4022
|
+
L1-table.col IN
|
|
4023
|
+
(
|
|
4024
|
+
SELECT P1-Table FROM
|
|
4025
|
+
dblink(select pool_parallel(SELECT P1-table FROM P1-table))
|
|
4026
|
+
) ;
|
|
4027
|
+
</pre>
|
|
4028
|
+
<p>
|
|
4029
|
+
La fonction pool_loadbalance a la responsabilité de répartir les requêtes
|
|
4030
|
+
sur les différents nœuds.
|
|
4031
|
+
</p>
|
|
4032
|
+
|
|
4033
|
+
|
|
4034
|
+
<h3>Réécriture de requêtes pour les fonctions d'agrégat</h3>
|
|
4035
|
+
<p>
|
|
4036
|
+
Pour les requêtes d'agrégation (fonctions d'agrégat ainsi que GROUP BY), le
|
|
4037
|
+
mécanisme de réécriture tente de réduire la charge sur la base de données
|
|
4038
|
+
système en exécutant un premier agrégat sur chacun des serveurs.
|
|
4039
|
+
</p>
|
|
4040
|
+
<p>
|
|
4041
|
+
Voyons tout d'abord comment pgpool-II fait cette réécriture.
|
|
4042
|
+
</p>
|
|
4043
|
+
<p>
|
|
4044
|
+
Cette requête est en statut P dans la clause FROM et possède un count(*) dans
|
|
4045
|
+
la TARGETLIST.
|
|
4046
|
+
Aussi, la réécriture est faite comme suit.
|
|
4047
|
+
</p>
|
|
4048
|
+
<pre>
|
|
4049
|
+
SELECT count(*) from P1-table;
|
|
4050
|
+
|
|
4051
|
+
-> réécriture
|
|
4052
|
+
|
|
4053
|
+
SELECT
|
|
4054
|
+
sum(pool_c$1) AS count
|
|
4055
|
+
FROM
|
|
4056
|
+
dblink(select pool_parallel('SELECT count(*) FROM P1-table'))
|
|
4057
|
+
AS pool_$1g (pool_c$1 bigint);
|
|
4058
|
+
</pre>
|
|
4059
|
+
<p>
|
|
4060
|
+
Une réécriture comme ci-dessus est faite dans les conditions suivantes.
|
|
4061
|
+
</p>
|
|
4062
|
+
<ol>
|
|
4063
|
+
<li>la clause FROM est de statut P ;
|
|
4064
|
+
<li>la colonne spécifiée est dans la fonction d'agrégat
|
|
4065
|
+
(seulement COUNT, SUM, MIN, MAX et AVG) et GROUP BY est utilisé dans la
|
|
4066
|
+
TARGETLIST ;
|
|
4067
|
+
<li>la clause WHERE est de statut P ;
|
|
4068
|
+
<li>seules les colonnes définies dans la fonction d'agrégat
|
|
4069
|
+
(seulement COUNT, SUM, MIN, MAX et AVG), utilisées dans la clause HAVING et la
|
|
4070
|
+
clause FROM, et la colonne spécifiée pour le GROUP BY sont utilisées.
|
|
4071
|
+
</ol>
|
|
4072
|
+
<h3>Notes sur le mode parallèle</h3>
|
|
4073
|
+
<p>
|
|
4074
|
+
Le nom des colonnes et leur type de données doivent être connus lorsqu'une
|
|
4075
|
+
requête est analysée en mode parallèle. Ainsi, lorsqu'une expression ou une
|
|
4076
|
+
fonction est utilisée dans la TARGETLIST d'une sous-requête, l'alias et le type
|
|
4077
|
+
(via un CAST) sont nécessaires. Si aucun cast n'est défini explicitement dans
|
|
4078
|
+
une expression ou une fonction, le type TEXT sera choisi par défaut. Pour
|
|
4079
|
+
count(), le type BIGINT est celui par défaut, et pour sum(), NUMERIC. Pour
|
|
4080
|
+
min()/max(), si l'argument est de type DATE, le type de données retournée est
|
|
4081
|
+
DATE, sinon NUMERIC est utilisé. avg() est traité comme sum()/count() (sum
|
|
4082
|
+
divisé par count).
|
|
4083
|
+
|
|
4084
|
+
<h3>À propos des performances du mode parallèle</h3>
|
|
4085
|
+
<p>Voici une estimation des performances de la requête en fonction de son
|
|
4086
|
+
statut d'exécution</p>
|
|
4087
|
+
<p>
|
|
4088
|
+
<table border>
|
|
4089
|
+
<tr><td>Statut d'exécution</td><td>Performances</td></tr>
|
|
4090
|
+
<tr><td align = center>L</td><td>Il n'y a aucune déterioration de performance
|
|
4091
|
+
avec un unique serveur, mis à part la sucharge provoquée par pgpool-II,
|
|
4092
|
+
parce qu'aucune exécution en parallèle n'est possible.</td></tr>
|
|
4093
|
+
<tr><td align = center>P</td><td>Le traitement parallélisé est rapide, en
|
|
4094
|
+
particulier, pour les parcours séquentiels. Il est alors aisé d'avoir de grandes
|
|
4095
|
+
améliorations de performances car le parcours séquentiel d'une grosse table devient
|
|
4096
|
+
un parcours en parallèle sur des tables bien plus petites, distribuées sur
|
|
4097
|
+
plusieurs serveurs.
|
|
4098
|
+
<tr><td align = center>S</td><td>Lorsque les fonctions d'agrégat peuvent être
|
|
4099
|
+
réécrites pour être compatibles avec une exécution en parallèle, elles
|
|
4100
|
+
deviennent rapides.</td></tr>
|
|
4101
|
+
</td></tr>
|
|
4102
|
+
</table>
|
|
4103
|
+
</p>
|
|
4104
|
+
|
|
4105
|
+
<h1>Tutoriel</h1>
|
|
4106
|
+
<p>
|
|
4107
|
+
Un <a href="tutorial-en.html">tutoriel (en anglais) pour pgpool-II</a> est
|
|
4108
|
+
disponible.
|
|
4109
|
+
</p>
|
|
4110
|
+
|
|
4111
|
+
<div class="copyright">
|
|
4112
|
+
<hr>
|
|
4113
|
+
<copyright>
|
|
4114
|
+
Copyright © 2003 – 2010 pgpool Global Development Group
|
|
4115
|
+
</copyright>
|
|
4116
|
+
</div>
|
|
4117
|
+
</body>
|
|
4118
|
+
</html>
|