{"id":7539,"date":"2016-04-08T14:48:02","date_gmt":"2016-04-08T12:48:02","guid":{"rendered":"https:\/\/www.dbi-services.com\/blog\/maintenance-scenarios-with-edb-failover-manager-1-standby-node\/"},"modified":"2016-04-08T14:48:02","modified_gmt":"2016-04-08T12:48:02","slug":"maintenance-scenarios-with-edb-failover-manager-1-standby-node","status":"publish","type":"post","link":"https:\/\/www.dbi-services.com\/blog\/maintenance-scenarios-with-edb-failover-manager-1-standby-node\/","title":{"rendered":"Maintenance scenarios with EDB Failover Manager (1) – Standby node"},"content":{"rendered":"

Recently at a customer we again implemented a PostgreSQL architecture as described some time ago<\/a>. When we delivered the first draft of the documentation the question popped up how to handle maintenance tasks in a failover cluster protected by EDB Failover Manager<\/a>. So, here we go…<\/p>\n

<\/p>\n

The setup of my little test environment is as follows:<\/p>\n\n\n\n\n\n\n
IP<\/th>\nDescription<\/th>\n<\/tr>\n
192.168.22.243<\/td>\nCurrent PostgreSQL hot standby instance<\/td>\n<\/tr>\n
192.168.22.245<\/td>\nCurrent PostgreSQL primary instance<\/td>\n<\/tr>\n
192.168.22.244<\/td>\nEDB Failover Manager Witness Node + EDB BART<\/td>\n<\/tr>\n
192.168.22.250<\/td>\nVirtual IP that is used for client connections to the master database<\/td>\n<\/tr>\n<\/table>\n

In words there is one master database streaming to a hot standby database. On the third node there is EDB BART for backup and recovery and EDB Failover Manager as a witness. For this specific setup we used a VIP that will fail over as well if the master database goes down for any reason.<\/p>\n

Using the EFM command line utility the current status of the cluster can be displayed:<\/p>\n

\npostgres@edbbart:\/home\/postgres\/ [pg950] efm cluster-status efm\nCluster Status: efm\nAutomatic failover is disabled.\n\n\tAgent Type  Address              Agent  DB       Info\n\t--------------------------------------------------------------\n\tStandby     192.168.22.243       UP     UP        \n\tWitness     192.168.22.244       UP     N\/A       \n\tMaster      192.168.22.245       UP     UP        \n\nAllowed node host list:\n\t192.168.22.244 192.168.22.245 192.168.22.243\n\nStandby priority host list:\n\t192.168.22.243\n\nPromote Status:\n\n\tDB Type     Address              XLog Loc         Info\n\t--------------------------------------------------------------\n\tMaster      192.168.22.245       0\/320001E8       \n\tStandby     192.168.22.243       0\/320001E8       \n\n\tStandby database(s) in sync with master. It is safe to promote.\n<\/pre>\n
This clearly shows the cluster is healthy at the moment and a promote could be safely executed. Note that automatic failover is disabled here. <\/p>\n
What do you need to do when you want to perform maintenance on the current standby node and you need to take the database down for being able to do so? Actually not much. Lets confirm that this is really the standby node:<\/p>\n
\npostgres@edbppas:\/home\/postgres\/ [PGSITE1] psql postgres\npsql.bin (9.5.0.5)\nType \"help\" for help.\n\npostgres=# select * from pg_is_in_recovery();\n pg_is_in_recovery \n-------------------\n t\n(1 row)\n\npostgres=# \n<\/pre>\n
Fine. I’ll be doing it the hard way and will just reboot the server (autostart for the PostgreSQL instance is disabled in my case):<\/p>\n
\n[root@edbppas ~] reboot\nConnection to 192.168.22.243 closed by remote host.\nConnection to 192.168.22.243 closed.\n<\/pre>\n
What is the status of my cluster now?<\/p>\n
\npostgres@edbbart:\/home\/postgres\/ [pg950] efm cluster-status efm\nCluster Status: efm\nAutomatic failover is disabled.\n\n\tAgent Type  Address              Agent  DB       Info\n\t--------------------------------------------------------------\n\tWitness     192.168.22.244       UP     N\/A       \n\tMaster      192.168.22.245       UP     UP        \n\nAllowed node host list:\n\t192.168.22.244 192.168.22.245 192.168.22.243\n\nStandby priority host list:\n\t(List is empty.)\n\nPromote Status:\n\n\tDB Type     Address              XLog Loc         Info\n\t--------------------------------------------------------------\n\tMaster      192.168.22.245       0\/320002C8       \n\n\tNo standby databases were found.\n<\/pre>\n
The standby database disappeared. Once the node comes up again lets check the failover manager on that node:<\/p>\n
\n[root@edbppas ~] systemctl status efm-2.0.service\nefm-2.0.service - EnterpriseDB Failover Manager 2.0\n   Loaded: loaded (\/usr\/lib\/systemd\/system\/efm-2.0.service; enabled)\n   Active: failed (Result: exit-code) since Fri 2016-04-08 15:51:51 CEST; 1min 39s ago\n  Process: 583 ExecStart=\/bin\/java -cp \/usr\/efm-2.0\/lib\/EFM-2.0.4.jar com.enterprisedb.hal.main.ServiceCommand start \/etc\/efm-2.0\/${CLUSTER}.properties (code=exited, status=1\/FAILURE)\n\nApr 08 15:51:51 edbppas java[583]: [ 4\/8\/16 3:51:51 PM ]\nApr 08 15:51:51 edbppas java[583]: [ 4\/8\/16 3:51:51 PM ] 4\/8\/16 3:51:50 PM com.enterprisedb.hal.exec.ExecUtil performExe...ey efm]\nApr 08 15:51:51 edbppas java[583]: [ 4\/8\/16 3:51:51 PM ]\nApr 08 15:51:51 edbppas java[583]: [ 4\/8\/16 3:51:51 PM ] 4\/8\/16 3:51:50 PM com.enterprisedb.hal.exec.ExecUtil performExe...Out=''}\nApr 08 15:51:51 edbppas java[583]: [ 4\/8\/16 3:51:51 PM ]\nApr 08 15:51:51 edbppas java[583]: [ 4\/8\/16 3:51:51 PM ] 4\/8\/16 3:51:50 PM com.enterprisedb.hal.nodes.HalAgent shutdown ...xiting.\nApr 08 15:51:51 edbppas java[583]: [ 4\/8\/16 3:51:51 PM ]\nApr 08 15:51:51 edbppas systemd[1]: efm-2.0.service: control process exited, code=exited status=1\nApr 08 15:51:51 edbppas systemd[1]: Failed to start EnterpriseDB Failover Manager 2.0.\nApr 08 15:51:51 edbppas systemd[1]: Unit efm-2.0.service entered failed state.\nHint: Some lines were ellipsized, use -l to show in full.\n[root@edbppas ~] cat \/var\/log\/efm-2.0\/efm.log\n[root@edbppas ~] \n<\/pre>\n
Hm, not so good. Although the service is enabled for automatic restart it did not come up. How to fix it? The database is still configured for recovery:<\/p>\n
\npostgres@edbppas:\/home\/postgres\/ [PGSITE1] cat $PGDATA\/recovery.conf\nstandby_mode = 'on'\nprimary_slot_name = 'standby1'\nprimary_conninfo = 'user=postgres password=admin123 host=192.168.22.245 port=4445 sslmode=prefer sslcompression=1'\nrecovery_target_timeline = 'latest'\ntrigger_file='\/u02\/pgdata\/PGSITE1\/trigger_file'\n<\/pre>\n
It should be safe to start it up. Once it comes up, looking at the logfile:<\/p>\n
\n2016-04-08 14:25:24.350 GMT - 3 - 2428 -  - @ LOG:  consistent recovery state reached at 0\/320001E8\n2016-04-08 14:25:24.350 GMT - 4 - 2428 -  - @ LOG:  redo starts at 0\/320001E8\n2016-04-08 14:25:24.350 GMT - 5 - 2428 -  - @ LOG:  invalid record length at 0\/320002C8\n2016-04-08 14:25:24.351 GMT - 4 - 2426 -  - @ LOG:  database system is ready to accept read only connections\n2016-04-08 14:25:24.359 GMT - 1 - 2432 -  - @ LOG:  started streaming WAL from primary at 0\/32000000 on timeline 2\n<\/pre>\n
Fine. Streaming started again and from a database perspective we are fine. But what about our failover manager? In this case we need to tell failover manager to rejoin the cluster by adding all noes to the efm.nodes file:<\/p>\n
\n[root@edbppas efm-2.0] pwd\n\/etc\/efm-2.0\n[root@edbppas efm-2.0] cat efm.nodes\n# List of node address:port combinations separated by whitespace.\n192.168.22.244:9998 192.168.22.245:9998 192.168.22.243:9998\n<\/pre>\n
Once this is ready we can restart and everything is back to normal operations:<\/p>\n
\n[root@edbppas efm-2.0] systemctl start efm-2.0.service\n[root@edbppas efm-2.0] \/usr\/efm\nefm\/     efm-2.0\/ \n[root@edbppas efm-2.0] \/usr\/efm-2.0\/bin\/efm cluster-status efm\nCluster Status: efm\nAutomatic failover is disabled.\n\n\tAgent Type  Address              Agent  DB       Info\n\t--------------------------------------------------------------\n\tWitness     192.168.22.244       UP     N\/A       \n\tStandby     192.168.22.243       UP     UP        \n\tMaster      192.168.22.245       UP     UP        \n\nAllowed node host list:\n\t192.168.22.244 192.168.22.243 192.168.22.245\n\nStandby priority host list:\n\t192.168.22.243\n\nPromote Status:\n\n\tDB Type     Address              XLog Loc         Info\n\t--------------------------------------------------------------\n\tMaster      192.168.22.245       0\/330000D0       \n\tStandby     192.168.22.243       0\/330000D0       \n\n\tStandby database(s) in sync with master. It is safe to promote.\n<\/pre>\n
Note 1: If you need to reboot the whole node where currently the standby is running on you’ll need to rejoin to the cluster.<\/p>\n
What happens if we stop the standby database without rebooting the node?<\/p>\n
\npostgres@edbppas:\/home\/postgres\/ [PGSITE1] pgstop\nwaiting for server to shut down.... done\nserver stopped\npostgres@edbppas:\/home\/postgres\/ [PGSITE1] efm cluster-status efm\nCluster Status: efm\nAutomatic failover is disabled.\n\n\tAgent Type  Address              Agent  DB       Info\n\t--------------------------------------------------------------\n\tWitness     192.168.22.244       UP     N\/A       \n\tMaster      192.168.22.245       UP     UP        \n\tStandby     192.168.22.243       UP     UP        \n\nAllowed node host list:\n\t192.168.22.244 192.168.22.243 192.168.22.245\n\nStandby priority host list:\n\t192.168.22.243\n\nPromote Status:\n\n\tDB Type     Address              XLog Loc         Info\n\t--------------------------------------------------------------\n\tMaster      192.168.22.245       0\/330000D0       \n\tUnknown     192.168.22.243       UNKNOWN          Connection refused. Check that the hostname and port are correct and that the postmaster is accepting TCP\/IP connections.\n\n\tOne or more standby databases are not in sync with the master database.\n<\/pre>\n
The configuration itself is still fine but the standby database is reported as “UNKNOWN”. This is fine, in this case you can just restart the instance:<\/p>\n
\npostgres@edbppas:\/home\/postgres\/ [PGSITE1] pgstart\nserver starting\npostgres@edbppas:\/home\/postgres\/ [PGSITE1] 2016-04-08 14:35:50.411 GMT - 1 - 3202 -  - @ LOG:  redirecting log output to logging collector process\n2016-04-08 14:35:50.411 GMT - 2 - 3202 -  - @ HINT:  Future log output will appear in directory \"\/u02\/pgdata\/PGSITE1\/pg_log\".\n\npostgres@edbppas:\/home\/postgres\/ [PGSITE1] efm cluster-status efm\nCluster Status: efm\nAutomatic failover is disabled.\n\n\tAgent Type  Address              Agent  DB       Info\n\t--------------------------------------------------------------\n\tWitness     192.168.22.244       UP     N\/A       \n\tIdle        192.168.22.243       UP     UNKNOWN   \n\tMaster      192.168.22.245       UP     UP        \n\nAllowed node host list:\n\t192.168.22.244 192.168.22.243 192.168.22.245\n\nStandby priority host list:\n\t(List is empty.)\n\nPromote Status:\n\n\tDB Type     Address              XLog Loc         Info\n\t--------------------------------------------------------------\n\tMaster      192.168.22.245       0\/330000D0       \n\n\tNo standby databases were found.\n\nIdle Node Status (idle nodes ignored in XLog location comparisons):\n\n\tAddress              XLog Loc         Info\n\t--------------------------------------------------------------\n\t192.168.22.243       0\/330000D0       DB is in recovery.\n<\/pre>\n
The standby now is reported as “DB is in recovery.” How to fix this? Use the “resume” command:<\/p>\n
\n[root@edbppas ~] \/usr\/efm-2.0\/bin\/efm resume efm\nResume command successful on local agent.\n[root@edbppas ~] \/usr\/efm-2.0\/bin\/efm cluster-status efm\nCluster Status: efm\nAutomatic failover is disabled.\n\n\tAgent Type  Address              Agent  DB       Info\n\t--------------------------------------------------------------\n\tStandby     192.168.22.243       UP     UP        \n\tWitness     192.168.22.244       UP     N\/A       \n\tMaster      192.168.22.245       UP     UP        \n\nAllowed node host list:\n\t192.168.22.244 192.168.22.243 192.168.22.245\n\nStandby priority host list:\n\t192.168.22.243\n\nPromote Status:\n\n\tDB Type     Address              XLog Loc         Info\n\t--------------------------------------------------------------\n\tMaster      192.168.22.245       0\/34000060       \n\tStandby     192.168.22.243       0\/34000060       \n\n\tStandby database(s) in sync with master. It is safe to promote.\n<\/pre>\n
Ready again.<\/p>\n
Note 2: If you take down the standby database: Once you started it up again use the “resume” command to return to normal operation.<\/p>\n","protected":false},"excerpt":{"rendered":"
Recently at a customer we again implemented a PostgreSQL architecture as described some time ago. When we delivered the first draft of the documentation the question popped up how to handle maintenance tasks in a failover cluster protected by EDB Failover Manager. So, here we go…<\/p>\n","protected":false},"author":29,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[229],"tags":[713,464,77,238],"type_dbi":[],"class_list":["post-7539","post","type-post","status-publish","format-standard","hentry","category-database-administration-monitoring","tag-enterprisedb","tag-failover-cluster","tag-postgresql","tag-standby"],"acf":[],"yoast_head":"\nMaintenance scenarios with EDB Failover Manager (1) - Standby node - dbi Blog<\/title>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/www.dbi-services.com\/blog\/maintenance-scenarios-with-edb-failover-manager-1-standby-node\/\" \/>\n<meta property=\"og:locale\" content=\"en_US\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"Maintenance scenarios with EDB Failover Manager (1) - Standby node\" \/>\n<meta property=\"og:description\" content=\"Recently at a customer we again implemented a PostgreSQL architecture as described some time ago. When we delivered the first draft of the documentation the question popped up how to handle maintenance tasks in a failover cluster protected by EDB Failover Manager. So, here we go…\" \/>\n<meta property=\"og:url\" content=\"https:\/\/www.dbi-services.com\/blog\/maintenance-scenarios-with-edb-failover-manager-1-standby-node\/\" \/>\n<meta property=\"og:site_name\" content=\"dbi Blog\" \/>\n<meta property=\"article:published_time\" content=\"2016-04-08T12:48:02+00:00\" \/>\n<meta name=\"author\" content=\"Daniel Westermann\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:creator\" content=\"@westermanndanie\" \/>\n<meta name=\"twitter:label1\" content=\"Written by\" \/>\n\t<meta name=\"twitter:data1\" content=\"Daniel Westermann\" \/>\n\t<meta name=\"twitter:label2\" content=\"Est. reading time\" \/>\n\t<meta name=\"twitter:data2\" content=\"7 minutes\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\/\/schema.org\",\"@graph\":[{\"@type\":\"Article\",\"@id\":\"https:\/\/www.dbi-services.com\/blog\/maintenance-scenarios-with-edb-failover-manager-1-standby-node\/#article\",\"isPartOf\":{\"@id\":\"https:\/\/www.dbi-services.com\/blog\/maintenance-scenarios-with-edb-failover-manager-1-standby-node\/\"},\"author\":{\"name\":\"Daniel Westermann\",\"@id\":\"https:\/\/www.dbi-services.com\/blog\/#\/schema\/person\/8d08e9bd996a89bd75c0286cbabf3c66\"},\"headline\":\"Maintenance scenarios with EDB Failover Manager (1) – Standby node\",\"datePublished\":\"2016-04-08T12:48:02+00:00\",\"mainEntityOfPage\":{\"@id\":\"https:\/\/www.dbi-services.com\/blog\/maintenance-scenarios-with-edb-failover-manager-1-standby-node\/\"},\"wordCount\":486,\"commentCount\":0,\"keywords\":[\"enterprisedb\",\"Failover cluster\",\"PostgreSQL\",\"Standby\"],\"articleSection\":[\"Database Administration & Monitoring\"],\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"CommentAction\",\"name\":\"Comment\",\"target\":[\"https:\/\/www.dbi-services.com\/blog\/maintenance-scenarios-with-edb-failover-manager-1-standby-node\/#respond\"]}]},{\"@type\":\"WebPage\",\"@id\":\"https:\/\/www.dbi-services.com\/blog\/maintenance-scenarios-with-edb-failover-manager-1-standby-node\/\",\"url\":\"https:\/\/www.dbi-services.com\/blog\/maintenance-scenarios-with-edb-failover-manager-1-standby-node\/\",\"name\":\"Maintenance scenarios with EDB Failover Manager (1) - Standby node - dbi Blog\",\"isPartOf\":{\"@id\":\"https:\/\/www.dbi-services.com\/blog\/#website\"},\"datePublished\":\"2016-04-08T12:48:02+00:00\",\"author\":{\"@id\":\"https:\/\/www.dbi-services.com\/blog\/#\/schema\/person\/8d08e9bd996a89bd75c0286cbabf3c66\"},\"breadcrumb\":{\"@id\":\"https:\/\/www.dbi-services.com\/blog\/maintenance-scenarios-with-edb-failover-manager-1-standby-node\/#breadcrumb\"},\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\/\/www.dbi-services.com\/blog\/maintenance-scenarios-with-edb-failover-manager-1-standby-node\/\"]}]},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\/\/www.dbi-services.com\/blog\/maintenance-scenarios-with-edb-failover-manager-1-standby-node\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Accueil\",\"item\":\"https:\/\/www.dbi-services.com\/blog\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"Maintenance scenarios with EDB Failover Manager (1) – Standby node\"}]},{\"@type\":\"WebSite\",\"@id\":\"https:\/\/www.dbi-services.com\/blog\/#website\",\"url\":\"https:\/\/www.dbi-services.com\/blog\/\",\"name\":\"dbi Blog\",\"description\":\"\",\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\/\/www.dbi-services.com\/blog\/?s={search_term_string}\"},\"query-input\":{\"@type\":\"PropertyValueSpecification\",\"valueRequired\":true,\"valueName\":\"search_term_string\"}}],\"inLanguage\":\"en-US\"},{\"@type\":\"Person\",\"@id\":\"https:\/\/www.dbi-services.com\/blog\/#\/schema\/person\/8d08e9bd996a89bd75c0286cbabf3c66\",\"name\":\"Daniel Westermann\",\"image\":{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\/\/secure.gravatar.com\/avatar\/31350ceeecb1dd8986339a29bf040d4cd3cd087d410deccd8f55234466d6c317?s=96&d=mm&r=g\",\"url\":\"https:\/\/secure.gravatar.com\/avatar\/31350ceeecb1dd8986339a29bf040d4cd3cd087d410deccd8f55234466d6c317?s=96&d=mm&r=g\",\"contentUrl\":\"https:\/\/secure.gravatar.com\/avatar\/31350ceeecb1dd8986339a29bf040d4cd3cd087d410deccd8f55234466d6c317?s=96&d=mm&r=g\",\"caption\":\"Daniel Westermann\"},\"description\":\"Daniel Westermann is Principal Consultant and Technology Leader Open Infrastructure at dbi services. He has more than 15 years of experience in management, engineering and optimization of databases and infrastructures, especially on Oracle and PostgreSQL. Since the beginning of his career, he has specialized in Oracle Technologies and is Oracle Certified Professional 12c and Oracle Certified Expert RAC\/GridInfra. Over time, Daniel has become increasingly interested in open source technologies, becoming \u201cTechnology Leader Open Infrastructure\u201d and PostgreSQL expert. \u00a0Based on community or EnterpriseDB tools, he develops and installs complex high available solutions with PostgreSQL. He is also a certified PostgreSQL Plus 9.0 Professional and a Postgres Advanced Server 9.4 Professional. He is a regular speaker at PostgreSQL conferences in Switzerland and Europe. Today Daniel is also supporting our customers on AWS services such as AWS RDS, database migrations into the cloud, EC2 and automated infrastructure management with AWS SSM (System Manager). He is a certified AWS Solutions Architect Professional. Prior to dbi services, Daniel was Management System Engineer at LC SYSTEMS-Engineering AG in Basel. Before that, he worked as Oracle Developper &\u00a0Project Manager at Delta Energy Solutions AG in Basel (today Powel AG). Daniel holds a diploma in Business Informatics (DHBW, Germany). His branch-related experience mainly covers the pharma industry, the financial sector, energy, lottery and telecommunications.\",\"sameAs\":[\"https:\/\/x.com\/westermanndanie\"],\"url\":\"https:\/\/www.dbi-services.com\/blog\/author\/daniel-westermann\/\"}]}<\/script>\n<!-- \/ Yoast SEO Premium plugin. -->","yoast_head_json":{"title":"Maintenance scenarios with EDB Failover Manager (1) - Standby node - dbi Blog","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/www.dbi-services.com\/blog\/maintenance-scenarios-with-edb-failover-manager-1-standby-node\/","og_locale":"en_US","og_type":"article","og_title":"Maintenance scenarios with EDB Failover Manager (1) - Standby node","og_description":"Recently at a customer we again implemented a PostgreSQL architecture as described some time ago. When we delivered the first draft of the documentation the question popped up how to handle maintenance tasks in a failover cluster protected by EDB Failover Manager. So, here we go…","og_url":"https:\/\/www.dbi-services.com\/blog\/maintenance-scenarios-with-edb-failover-manager-1-standby-node\/","og_site_name":"dbi Blog","article_published_time":"2016-04-08T12:48:02+00:00","author":"Daniel Westermann","twitter_card":"summary_large_image","twitter_creator":"@westermanndanie","twitter_misc":{"Written by":"Daniel Westermann","Est. reading time":"7 minutes"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"Article","@id":"https:\/\/www.dbi-services.com\/blog\/maintenance-scenarios-with-edb-failover-manager-1-standby-node\/#article","isPartOf":{"@id":"https:\/\/www.dbi-services.com\/blog\/maintenance-scenarios-with-edb-failover-manager-1-standby-node\/"},"author":{"name":"Daniel Westermann","@id":"https:\/\/www.dbi-services.com\/blog\/#\/schema\/person\/8d08e9bd996a89bd75c0286cbabf3c66"},"headline":"Maintenance scenarios with EDB Failover Manager (1) – Standby node","datePublished":"2016-04-08T12:48:02+00:00","mainEntityOfPage":{"@id":"https:\/\/www.dbi-services.com\/blog\/maintenance-scenarios-with-edb-failover-manager-1-standby-node\/"},"wordCount":486,"commentCount":0,"keywords":["enterprisedb","Failover cluster","PostgreSQL","Standby"],"articleSection":["Database Administration & Monitoring"],"inLanguage":"en-US","potentialAction":[{"@type":"CommentAction","name":"Comment","target":["https:\/\/www.dbi-services.com\/blog\/maintenance-scenarios-with-edb-failover-manager-1-standby-node\/#respond"]}]},{"@type":"WebPage","@id":"https:\/\/www.dbi-services.com\/blog\/maintenance-scenarios-with-edb-failover-manager-1-standby-node\/","url":"https:\/\/www.dbi-services.com\/blog\/maintenance-scenarios-with-edb-failover-manager-1-standby-node\/","name":"Maintenance scenarios with EDB Failover Manager (1) - Standby node - dbi Blog","isPartOf":{"@id":"https:\/\/www.dbi-services.com\/blog\/#website"},"datePublished":"2016-04-08T12:48:02+00:00","author":{"@id":"https:\/\/www.dbi-services.com\/blog\/#\/schema\/person\/8d08e9bd996a89bd75c0286cbabf3c66"},"breadcrumb":{"@id":"https:\/\/www.dbi-services.com\/blog\/maintenance-scenarios-with-edb-failover-manager-1-standby-node\/#breadcrumb"},"inLanguage":"en-US","potentialAction":[{"@type":"ReadAction","target":["https:\/\/www.dbi-services.com\/blog\/maintenance-scenarios-with-edb-failover-manager-1-standby-node\/"]}]},{"@type":"BreadcrumbList","@id":"https:\/\/www.dbi-services.com\/blog\/maintenance-scenarios-with-edb-failover-manager-1-standby-node\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Accueil","item":"https:\/\/www.dbi-services.com\/blog\/"},{"@type":"ListItem","position":2,"name":"Maintenance scenarios with EDB Failover Manager (1) – Standby node"}]},{"@type":"WebSite","@id":"https:\/\/www.dbi-services.com\/blog\/#website","url":"https:\/\/www.dbi-services.com\/blog\/","name":"dbi Blog","description":"","potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/www.dbi-services.com\/blog\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"en-US"},{"@type":"Person","@id":"https:\/\/www.dbi-services.com\/blog\/#\/schema\/person\/8d08e9bd996a89bd75c0286cbabf3c66","name":"Daniel Westermann","image":{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/secure.gravatar.com\/avatar\/31350ceeecb1dd8986339a29bf040d4cd3cd087d410deccd8f55234466d6c317?s=96&d=mm&r=g","url":"https:\/\/secure.gravatar.com\/avatar\/31350ceeecb1dd8986339a29bf040d4cd3cd087d410deccd8f55234466d6c317?s=96&d=mm&r=g","contentUrl":"https:\/\/secure.gravatar.com\/avatar\/31350ceeecb1dd8986339a29bf040d4cd3cd087d410deccd8f55234466d6c317?s=96&d=mm&r=g","caption":"Daniel Westermann"},"description":"Daniel Westermann is Principal Consultant and Technology Leader Open Infrastructure at dbi services. He has more than 15 years of experience in management, engineering and optimization of databases and infrastructures, especially on Oracle and PostgreSQL. Since the beginning of his career, he has specialized in Oracle Technologies and is Oracle Certified Professional 12c and Oracle Certified Expert RAC\/GridInfra. Over time, Daniel has become increasingly interested in open source technologies, becoming \u201cTechnology Leader Open Infrastructure\u201d and PostgreSQL expert. \u00a0Based on community or EnterpriseDB tools, he develops and installs complex high available solutions with PostgreSQL. He is also a certified PostgreSQL Plus 9.0 Professional and a Postgres Advanced Server 9.4 Professional. He is a regular speaker at PostgreSQL conferences in Switzerland and Europe. Today Daniel is also supporting our customers on AWS services such as AWS RDS, database migrations into the cloud, EC2 and automated infrastructure management with AWS SSM (System Manager). He is a certified AWS Solutions Architect Professional. Prior to dbi services, Daniel was Management System Engineer at LC SYSTEMS-Engineering AG in Basel. Before that, he worked as Oracle Developper &\u00a0Project Manager at Delta Energy Solutions AG in Basel (today Powel AG). Daniel holds a diploma in Business Informatics (DHBW, Germany). His branch-related experience mainly covers the pharma industry, the financial sector, energy, lottery and telecommunications.","sameAs":["https:\/\/x.com\/westermanndanie"],"url":"https:\/\/www.dbi-services.com\/blog\/author\/daniel-westermann\/"}]}},"_links":{"self":[{"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/posts\/7539","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/users\/29"}],"replies":[{"embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/comments?post=7539"}],"version-history":[{"count":0,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/posts\/7539\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/media?parent=7539"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/categories?post=7539"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/tags?post=7539"},{"taxonomy":"type","embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/type_dbi?post=7539"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}