Réplication temps réel avec PostgreSQL 9.0.3 et Slony 2.0.6

Dans ce billet, un tutoriel pour installer un PostgreSQL 9 avec l'utilitaire de réplication Slony afin de répliquer a chaud les données.

Un schéma de réplication horizontale et verticale sera d'ailleurs expliqué, avec, dans un futur proche, un exemple de bascule de machines maîtres !

Dans ce tutoriel :

  • Installation de Postgres9
  • Création d'une base de données que l'on répliquera
  • Création des utilisateurs
  • Installation de Slony
  • Création et souscription de la réplication
  • Exemple de reprise après crash

Schéma de réplication

Nous envisageons donc une réplication horizontale + verticale (aussi appelée "Cascaded Master") permet de synchroniser 2 masters ensemble, eux-même répliqués sur deux esclaves. Voici un exemple :

Database Name: madb01

 1: master-db01.cp2i.com (master)
	|
	 -> 3: master-db02.cp2i.com (cascaded master)
	|    |
	|     -> 4: slave-db02.cp2i.com (cascaded slave)
	|
	 -> 2: slave-db01.cp2i.com (slave)

Nous pourrons donc envisager d'avoir le master-db01 dans le DatacenterA, accompagné du slave-db01, puis, dans un DatacenterB, le master-db02 et le slave-db02. Ainsi, si un soucis intervient sur le DatacenterA (maintenance programmée, surcharge prévue, soucis machine, etc.), il sera facile de basculer d'un Datacenter vers l'autre.

D'autre part, et contrairement aux autres outils de réplication, Slony permet une réplication active Master-Master ne bloquant pas l'accès en lecture au second master. Il est cependant impossible d'envisager de l'écriture simultanée sur les deux maîtres en même temps, mais il est tout à fait possible d'envisager une lecture simultanée sur les deux sites.

Ainsi, vous pourrez "load-balancer" la charge de lecture sur les deux sites. Les délais de réplication étant très rapides (entre 2 et 8 secondes entre le maître et l'esclave cascadé), rares seront les applications qui nécessiteront une disponibilité instantanée qui ne puisse être satisfaite par ce système.

Données pré-installation

Nos machines sont intallées avec le strict minimum. Voici leurs DNS/IP

  • Machine 1 : master-db01.cp2i.com /192.168.0.2
  • Machine 2 : slave-db01.cp2i.com / 192.168.0.3
  • Machine 3 : master-db02.cp2i.com / 192.168.0.4
  • Machine 4 : slave-db02.cp2i.com / 192.168.0.5

Installation de PostgreSQL 9 (tous les serveurs)

Tout commence comme toujours par la même commande :

root@> aptitude update
root@> aptitude install postgresql-9.0-slony1

Se connecter à PostgreSQL pour créer les administrateurs, tablespaces et autres "objets" nécessaires au tutoriel

root@> su - postgres
postgres@> psql
psql #= CREATE USER psql_admin SUPERUSER PASSWORD 'psql4dm1n';
psql #= CREATE USER slon_admin SUPERUSER PASSWORD 'sl0n4dm1n';
psql #= CREATE TABLESPACE psql_data LOCATION '/DATA/postgres';
psql #= CREATE TABLESPACE psql_slon OWNER slon_admin LOCATION '/DATA/slony';
psql #= CREATE DATABASE madb01 WITH TEMPLATE template0 ENCODING 'UTF8' TABLESPACE psql_data;
psql #= GRANT ALL PRIVILEGES ON DATABASE madb01 to psql_admin;
psql #= CREATE LANGUAGE plpgsql;

A ce moment-là, vous avez :

  • 2 espaces de stockage pour vos données PG et Slony (tablespace)
  • 1 base de données
  • 2 utilisateurs (un pour la DB, un pour slony)

Continuons avec Slony

Installation de Slony (tous les serveurs)

Inévitablement, on lancera :

root@> aptitude update
root@> aptitude install slony1-bin

Configuration

Nous allons maintenant nous attarder sur la partie configuration des deux logiciels installés

Posgtres

La première modification sera à faire dans le fichier /etc/postgresql/9.0/main/pg_hba.conf. Rajoutez en fin de fichier les lignes :

host    madb01    psql_admin    192.168.0.0/28    md5
host    madb01    slon_admin    192.168.0.0/28    md5

Ensuite, pour le fichier /etc/postgresql/9.0/main/postgresql.conf, décommentez la ligne:

listen_addresses = '*'

Puis ajustez les paramètres suivants en fonction de votre serveur (pour ma part, 32GB de RAM) :

max_connections = 400
shared_buffers = 3000MB
maintenance_work_mem = 1000MB

Slony

Les fichiers Slony se décomposent en plusieurs fichiers :

  • dans /etc/slony1/
  • dans /etc/slony1/XXXX/

Nous verrons en détail tous ces fichiers

Conseils

Afin d'être totalement indépendant de la configuration initiale de slony dans dans un soucis de scalabilité des services, je vous conseille de générer un jeu complet de fichier de configuration pour chaque ligne de réplication (jeu de tables ou bases) afin de pouvoir relancer indépendamment chaque ligne sans impacter une autre.

Ainsi nous aurons 3 fichiers par ligne de réplication : madb01 dans notre exemple

Dans /etc/slony1

Sur tous les serveurs, créez le fichier /etc/slony1/slon_tools_replication01_madb01.conf avec comme contenu :

  1. if ($ENV{"SLONYNODES"}) {
  2. require $ENV{"SLONYNODES"};
  3. } else {
  4. $CLUSTER_NAME = 'slony_replication01_madb01';
  5. # The directory where Slony should record log messages. This
  6. # directory will need to be writable by the user that invokes
  7. # Slony.
  8. $LOGDIR = '/var/log/slony1';
  9. # SYNC check interval (slon -s option)
  10. $SYNC_CHECK_INTERVAL = 4000;
  11. # Which node is the default master for all sets?
  12. $MASTERNODE = 1001;
  13. # Include add_node lines for each node in the cluster. Be sure to
  14. # use host names that will resolve properly on all nodes
  15. # (i.e. only use 'localhost' if all nodes are on the same host).
  16. # Also, note that the user must be a superuser account.
  17.  
  18. add_node(
  19. node => 1001,
  20. host => 'master-db01.cp2i.com',
  21. dbname => 'madb01',
  22. port => 5432,
  23. user => 'slon_admin',
  24. password => 'sl0n4dm1n'
  25. );
  26. add_node(
  27. node => 1002,
  28. host => 'slave-db01.cp2i.com',
  29. dbname => 'madb01',
  30. port => 5432,
  31. user => 'slon_admin',
  32. password => 'sl0n4dm1n'
  33. );
  34. add_node(node => 1003,
  35. host => 'master-db02.cp2i.com',
  36. dbname => 'madb01',
  37. port => 5432,
  38. user => 'slon_admin',
  39. password => 'sl0n4dm1n'
  40. );
  41. add_node(node => 1004,
  42. host => 'slave-db02.cp2i.com',
  43. dbname => 'madb01',
  44. port => 5432,
  45. user => 'slon_admin',
  46. password => 'sl0n4dm1n'
  47. );
  48. # If the node should only receive event notifications from a
  49. # single node (e.g. if it can't access the other nodes), you can
  50. # specify a single parent. The downside to this approach is that
  51. # if the parent goes down, your node becomes stranded.
  52. }
  53. # The $SLONY_SETS variable contains information about all of the sets
  54. # in your cluster.
  55. $SLONY_SETS = {
  56. "set1" => {
  57. "set_id" => 1,
  58. "pkeyedtables" => ["matable_0","matable_1","matable_2","matable_3"],
  59. "table_id" => 1,
  60. },
  61. "set2" => {
  62. "set_id" => 2,
  63. "pkeyedtables" => ["matable_4","matable_5","matable_6","matable_7"],
  64. "table_id" => 5,
  65. },
  66. "set3" => {
  67. "set_id" => 3,
  68. "pkeyedtables" => ["matable_8","matable_9","matable_10","matable_11"],
  69. "table_id" => 9,
  70. }
  71. };
  72. # Keeping the following three lines for backwards compatibility in
  73. # case this gets incorporated into a 1.0.6 release.
  74. #
  75. # TODO: The scripts should check for an environment variable
  76. # containing the location of a configuration file. That would
  77. # simplify this configuration file and allow Slony tools to still work
  78. # in situations where it doesn't exist.
  79. if ($ENV{"SLONYSET"}) {
  80. require $ENV{"SLONYSET"};
  81. }
  82. # Please do not add or change anything below this point.
  83. 1;

Dans ce fichier, nous voyons donc que nous avons 4 noeuds de réplication, qui synchronisent la base de données madb01 et qu'elle contient 12 tables nommées matable_XX, et que la réplication se lance toutes les 4 secondes (SYNC_CHECK_INTERVAL).

Nous avons choisi de créer 3 sets de 4 tables. Mais rien de nous empêche de créer 2 sets de 6 tables, ou bien encore 12 sets de 1 table.

Veillez cependant à essayer d'équilibrer la taille des sets (i.e : ne pas avoir les 3 plus grosses tables dans le même set).

Ensuite, il faut, sur chaque machine, créer un sous-dossier dans /etc/slony1/ contenant l'id du noeud avec un fichier de conf à l'intérieur.

Dans /etc/slony1/XXXX/

Sur la machine 1 (master-db01.cp2i.com) créez le répertoire 1001 dans /etc/slony1/

Editez ensuite le fichier /etc/slony1/1001/slon_replication01_madb01.conf avec le contenu suivant :

  1. # Sets how many cleanup cycles to run before a vacuum is done.
  2. # Range: [0,100], default: 3
  3. #vac_frequency=3
  4.  
  5. # Debug log level (higher value ==> more output). Range: [0,4], default 4
  6. log_level=1
  7.  
  8. # Check for updates at least this often in milliseconds.
  9. # Range: [10-60000], default 100
  10. # sync_interval=100
  11. sync_interval=4000
  12.  
  13. # Maximum amount of time in milliseconds before issuing a SYNC event,
  14. # This prevents a possible race condition in which the action sequence
  15. # is bumped by the trigger while inserting the log row, which makes
  16. # this bump is immediately visible to the sync thread, but
  17. # the resulting log rows are not visible yet. If the sync is picked
  18. # up by the subscriber, processed and finished before the transaction
  19. # commits, this transaction's changes will not be replicated until the
  20. # next SYNC. But if all application activity suddenly stops,
  21. # there will be no more sequence bumps, so the high frequent -s check
  22. # won't detect that. Thus, the need for sync_interval_timeout.
  23. # Range: [0-120000], default 1000
  24. #sync_interval_timeout=1000
  25. sync_interval_timeout=5000
  26.  
  27. # Maximum number of SYNC events to group together when/if a subscriber
  28. # falls behind. SYNCs are batched only if there are that many available
  29. # and if they are contiguous. Every other event type in between leads to
  30. # a smaller batch. And if there is only one SYNC available, even -g60
  31. # will apply just that one. As soon as a subscriber catches up, it will
  32. # apply every single SYNC by itself.
  33. # Range: [0,100], default: 6
  34. #sync_group_maxsize=6
  35. sync_group_maxsize=80
  36.  
  37. # Size above which an sl_log_? row's log_cmddata is considered large.
  38. # Up to 500 rows of this size are allowed in memory at once. Rows larger
  39. # than that count into the sync_max_largemem space allocated and free'd
  40. # on demand.
  41. # Range: [1024,32768], default: 8192
  42. #sync_max_rowsize=8192
  43.  
  44. # Maximum amount of memory allowed for large rows. Note that the algorithm
  45. # will stop fetching rows AFTER this amount is exceeded, not BEFORE. This
  46. # is done to ensure that a single row exceeding this limit alone does not
  47. # stall replication.
  48. # Range: [1048576,1073741824], default: 5242880
  49. #sync_max_largemem=5242880
  50.  
  51. # If this parameter is 1, messages go both to syslog and the standard
  52. # output. A value of 2 sends output only to syslog (some messages will
  53. # still go to the standard output/error). The default is 0, which means
  54. # syslog is off.
  55. # Range: [0-2], default: 0
  56. syslog=1
  57.  
  58. # If true, include the process ID on each log line. Default is false.
  59. log_pid=true
  60.  
  61. # If true, include the timestamp on each log line. Default is true.
  62. #log_timestamp=true
  63.  
  64. # A strftime()-conformant format string for use with log timestamps.
  65. # Default is '%Y-%m-%d %H:%M:%S %Z'
  66. #log_timestamp_format='%Y-%m-%d %H:%M:%S %Z'
  67.  
  68. # Where to write the pid file. Default: no pid file
  69. pid_file='/var/run/slony1'
  70.  
  71. # Sets the syslog "facility" to be used when syslog enabled. Valid
  72. # values are LOCAL0, LOCAL1, LOCAL2, LOCAL3, LOCAL4, LOCAL5, LOCAL6, LOCAL7.
  73. syslog_facility=LOCAL4
  74.  
  75. # Sets the program name used to identify slon messages in syslog.
  76. syslog_ident=slon
  77.  
  78. # Set the cluster name that this instance of slon is running against
  79. # default is to read it off the command line
  80. cluster_name='_slony_replication01_madb01'
  81.  
  82. # Set slon's connection info, default is to read it off the command line
  83. conn_info='host=master-db01.cp2i.com port=5432 dbname=madb01 user=slon_admin password=sl0n4dm1n'
  84.  
  85. # maximum time planned for grouped SYNCs
  86. # If replication is behind, slon will try to increase numbers of
  87. # syncs done targetting that they should take this quantity of
  88. # time to process. in ms
  89. # Range [10000,600000], default 60000.
  90. #desired_sync_time=60000
  91.  
  92. # Execute the following SQL on each node at slon connect time
  93. # useful to set logging levels, or to tune the planner/memory
  94. # settings. You can specify multiple statements by separating
  95. # them with a ;
  96. #sql_on_connection="SET log_min_duration_statement TO '1000';"
  97.  
  98. # Command to run upon committing a log archive.
  99. # This command is passed one parameter, namely the full pathname of
  100. # the archive file
  101. #command_on_logarchive="/usr/local/bin/movearchivetoarchive"
  102.  
  103. # A PostgreSQL value compatible with ::interval which indicates how
  104. # far behind this node should lag its providers.
  105. # lag_interval="8 minutes"
  106.  
  107. # Directory in which to stow sync archive files
  108. # archive_dir="/tmp/somewhere"

Sur les autres machines, créez le répertoire dont le nom est le n° de node (1002, 1003, 1004) en éditant le fichier ci-dessus et en modifiant la variable conn_info pour l'adapter à la machine courante.

Préparation des binaires de lancement des lignes de réplication

Nous allons créer un script de lancement de notre ligne de réplication, et vous ferez de même pour toutes les futures lignes de réplication que vous créerez

Ici, nous allons créer /etc/init.d/slony1_replication01_madb01 :

  1. #!/bin/sh
  2.  
  3. ### BEGIN INIT INFO
  4. # Provides: slony1
  5. # Required-Start: $local_fs $remote_fs $network
  6. # Required-Stop: $local_fs $remote_fs $network
  7. # Should-Start: $time postgresql
  8. # Should-Stop: $time postgresql
  9. # Default-Start: 2 3 4 5
  10. # Default-Stop: 0 1 6
  11. # Short-Description: start Slony-I daemon
  12. # Description: Slony-I is a replication system for PostgreSQL.
  13. ### END INIT INFO
  14.  
  15. PATH=/sbin:/bin:/usr/sbin:/usr/bin
  16. DAEMON=/usr/bin/slon
  17.  
  18. test -x $DAEMON || exit 5
  19.  
  20. if [ -r /etc/default/slony1_replication01_madb01 ]; then
  21. . /etc/default/slony1_replication01_madb01
  22. fi
  23.  
  24. . /lib/lsb/init-functions
  25.  
  26. instances() {
  27. ls /etc/slony1/*/slon_replication01_madb01.conf 2>/dev/null | sed -n 's,^/etc/slony1/\(.*\)/slon_replication01_madb01.conf$,\1,p'
  28. echo $SLON_TOOLS_START_NODES
  29. }
  30.  
  31. conffile() {
  32. echo "/etc/slony1/$1/slon_replication01_madb01.conf"
  33. }
  34.  
  35. logfile() {
  36. dbname=`egrep -A20 "node *=> $1" /etc/slony1/slon_tools_replication01_madb01.conf|grep -m1 dbname|awk -F"'" '{print $2}'` && echo "/var/log/slony1/node$1-$dbname.log"
  37. }
  38. pidfile() {
  39. echo "/var/run/slony1/node$1.pid"
  40. }
  41.  
  42. prepare_start() {
  43. mkdir -p /var/run/slony1 \
  44. && chown postgres:postgres /var/run/slony1/ \
  45. && chmod 2775 /var/run/slony1/
  46. }
  47.  
  48. d_start() {
  49. if [ -e $(conffile $1) ]; then
  50. (egrep -q '^\s*cluster_name' $(conffile $1) && egrep -q '^\s*conn_info' $(conffile $1)) || (log_failure_msg "cluster_name or conn_info missed in "$(conffile $1); return 1)
  51. su -c ". /lib/lsb/init-functions ; start_daemon $DAEMON -f $(conffile $1) -p $(pidfile $1) >>$(logfile $1) 2>&1 </dev/null &" - postgres
  52. else
  53. is_running $x || su -c "slon_start --nowatchdog $x >/dev/null" - postgres
  54. fi
  55. }
  56.  
  57. d_stop() {
  58. killproc -p $(pidfile $1) $DAEMON
  59. }
  60.  
  61. is_running() {
  62. pidofproc -p $(pidfile $1) $DAEMON >/dev/null
  63. }
  64.  
  65. case $1 in
  66. start)
  67. status=0
  68. log_daemon_msg "Starting Slony-I daemon"
  69. prepare_start
  70. for x in $(instances); do
  71. log_progress_msg $x
  72. d_start $x
  73. status=$(($status || $?))
  74. done
  75. log_end_msg $status
  76. ;;
  77. stop)
  78. status=0
  79. log_daemon_msg "Stopping Slony-I daemon"
  80. for x in $(instances); do
  81. log_progress_msg $x
  82. d_stop $x
  83. status=$(($status || $?))
  84. done
  85. log_end_msg $status
  86. ;;
  87. status)
  88. status=0
  89. for x in $(instances); do
  90. is_running $x
  91. instancestatus=$?
  92. if [ $instancestatus -eq 0 ]; then
  93. log_success_msg "Slony-I daemon $x is running."
  94. else
  95. log_failure_msg "Slony-I daemon $x is not running."
  96. fi
  97. status=$(($status || $instancestatus))
  98. done
  99. exit $((3 * $status))
  100. ;;
  101. restart|force-reload)
  102. status=0
  103. log_daemon_msg "Restarting Slony-I daemon"
  104. for x in $(instances); do
  105. log_progress_msg $x
  106. d_stop $x && sleep 1 && d_start $x
  107. status=$(($status || $?))
  108. done
  109. log_end_msg $status
  110. ;;
  111. try-restart)
  112. if $0 status >/dev/null; then
  113. $0 restart
  114. else
  115. exit 0
  116. fi
  117. ;;
  118. reload)
  119. exit 3
  120. ;;
  121. *)
  122. log_failure_msg "Usage: $0 {start|stop|status|restart|try-restart|reload|force-reload}"
  123. exit 2
  124. ;;
  125. esac

Rendez-le exécutable, puis éditez le fichier /etc/init.d/slony pour le rendre comme suit :

  1. #!/bin/bash
  2.  
  3. . /lib/lsb/init-functions
  4.  
  5. confirm_action() {
  6. echo "You're about to $1 all slony processes on the current server..."
  7. echo "Confirm ? [y/N]"
  8. read confirmation
  9. case $confirmation in
  10. y|Y|yes|YES|Yes|o|O|oui|Oui|OUI)
  11. return 0
  12. ;;
  13. *)
  14. return 1
  15. ;;
  16. esac
  17. }
  18.  
  19. case $1 in
  20. start|stop|status|restart|try-restart|reload|force-reload)
  21. /etc/init.d/slony1_replication01_madb01 $1
  22. ;;
  23. *)
  24. log_success_msg "Usage: /etc/init.d/slony {start|stop|status|restart|try-restart|reload|force-reload}"
  25. ;;
  26. esac

Ainsi, pour chaque ligne de réplication créée, vous ajouterez l'exécutable servant à démarrer votre ligne de réplication à la suite de /etc/init.d/slony1_replication01_madb01 $1.

Création / Souscription de la réplication

Sur le master du site maître (master-db01.cp2i.com)

Création du cluster :

root@> su - postgres
postgres@> export PGOPTIONS='-c default_tablespace=psql_slon'
postgres@> slonik_init_cluster --config /etc/slony1/slon_tools_replication01_madb01.conf |slonik

Sur toutes les machines

Lancement de la réplication Slony

root@> /etc/init.d/slony1_replication01_madb01 start

Sur le master du site maître (master-db01.cp2i.com)

Création des sets:

root@> su - postgres
postgres@> export PGOPTIONS='-c default_tablespace=psql_slon'
postgres@> for set in `seq 1 3`; do slonik_create_set --config /etc/slony1/slon_tools_replication01_madb01.conf $set |slonik; done

Sur le slave du site maître (slave-db01.cp2i.com)

Souscription aux sets du site maître

root@> su - postgres
postgres@> export PGOPTIONS='-c default_tablespace=psql_slon'
postgres@> for set in `seq 1 3`; do slonik_subscribe_set --config /etc/slony1/slon_tools_replication01_madb01.conf $set 1002 |slonik; done

Sur le master cascadé (master-db02.cp2i.com)

Souscription aux sets du site maître :

root@> su - postgres
postgres@> export PGOPTIONS='-c default_tablespace=psql_slon'
postgres@> for set in `seq 1 3`; do slonik_subscribe_set --config /etc/slony1/slon_tools_replication01_madb01.conf $set 1003 |slonik; done

Sur le slave cascadé (slave-db02.cp2i.com)

ATTENTION : avant de souscrire le slave cascadé, il faut s'assurer que le master cascadé ait fini de se répliquer avec le site maître.

Pour cela faites un :

root@> tail -f /var/log/slony1/node1003-madb01.log

Vérifier qu'il n'indique pas qu'il est en train de copier une table

Une fois fait, souscrire au maître cascadé :

root@> su - postgres 
postgres@> export PGOPTIONS='-c default_tablespace=psql_slon'
postgres@> for set in `seq 1 3`; do slonik_subscribe_set --config /etc/slony1/slon_tools_replication01_madb01.conf $set 1003 | sed -e 's/provider = 1001/provider = 1003/'  |slonik; done

Vous aurez noté que nous changeons le provider "à la volée" de 1001 (master du site maître) à 1003 (master du site cascadé).

Exemple de reprise après crash

Dans 90% des cas, après un arrêt de la réplication Slony, un simple redémarrage de la ligne de la réplication en question suffit :

root@> /etc/init.d/slony1_replication01_madb01 restart

Mais parfois, notamment quand la réplication s'est arrêtée trop longtemps, une reprise est impossible. Pour résoudre ce soucis, il faut casser la réplication et la créer à nouveau de zéro. Attention cependant : si la machine en défaut est le master cascadé (master-db02.cp2i.com dans notre exemple), il faudra procéder également à la reprise sur le slave cascadé.

Nous prendrons dans notre exemple le cas du slave cascadé qui est en erreur (slave-db02.cp2i.com)

Pour cela, il vous faudra commencer par stopper la ligne de réplication :

root@> /etc/init.d/slony1_replication01_madb01 stop

On informe l'ensemble de la ligne de réplication (ie les autres serveurs) que la machine slave-db02.cp2i.com ne fait plus partie de la boucle, et ce afin d'éviter de recevoir des erreurs "Could not send event to node 1004".

root@> su - postgres
postgres@~> export PGOPTIONS='-c default_tablespace=psql_slon'
postgres@~> slonik_drop_node --config /etc/slony1/slon_tools_replication01_madb01.conf 1004 1003|slonik

Nous demandons donc de retirer le nœud 1004 qui a pour fournisseur de données le nœud 1003.

Supprimer le schéma de réplication Slony en cascade, ce qui aura également pour conséquence de supprimer les bases de données répliquées:

root@> su - postgres
postgres@> psql madb01
madb01 =# DROP SCHEMA _slony_replication01_madb01 CASCADE;
madb01 =# \q

On recrée le noeud de réplication sur la machine :

postgres@> slonik_store_node --config /etc/slony1/slon_tools_replication01_madb01.conf 1004 |slonik

On redémarre la ligne de réplication sur la machine

postgres@> exit
root@> /etc/init.d/slony1_replication01_madb01 start

On ressouscrit aux sets de la ligne de réplication (comme lors de la création) :

 su - postgres
postgres@~> export PGOPTIONS='-c default_tablespace=psql_slon'
postgres@~> for set in `seq 1 3`; do slonik_subscribe_set --config /etc/slony1/slon_tools_replication01_madb01.conf $set 1003 | sed -e 's/provider = 1001/provider = 1003/'  |slonik; done

Et voilà ! Dans les logs, vous vous apercevrez que la resynchronisation des données prendra plus de temps qu'à la création, surtout si vous avez injecté beaucoup de données.

Prenez donc garde à ne pas faire cela n'importe quand, surtout s'il s'agit du master cascadé, et principalement dans le cas où les deux masters soient dans des datacenters différents. La reprise s'effectue par la copie intégrale des données, et passera donc pas la liaison Internet / VPN que vous autre mis en place.

The End.. ou pas

Voilà, à l'heure où vous lisez ces lignes, votre base de données et ses 12 pauvres tables se répliquent

A vous d'améliorer, customiser et adapter la configuration !

Amusez-vous bien !

Ajouter un commentaire

Le code HTML est affiché comme du texte et les adresses web sont automatiquement transformées.

Fil des commentaires de ce billet