Une présentation générale de Sybase HA (High Availability) pour survoler les fonctionnalités offertes parmi lesquelles - Sybase HA et Sun Cluster - Sybase HA, configuration active-avtive et active-passive. Cette option requiert une licence et n'a pas malheureusement pu être testée techniquement.

Un précédent article paru au mois de novembre 2010 présente l’installation silencieuse d’une instance SQL Server 2008 R2 : Microsoft SQL Server 2008 R2 - Installation silencieuse. Attardons nous à présent sur les paramètres spécifiques aux installations silencieuses d’un cluster SQL Server 2008 R2 en mode failover sur Windows 2003 SP2 64 bits. En préambule, l’utilitaire cluster pour naviguer dans un cluster et la terminologie propre aux clusters Microsoft (groupes, groupes de ressources…) sont présentés puis l’installation des nœuds MS SQL Server en mode silencieux est réalisée (InstallFailoverCluster, AddNode). La bascule d’un groupe de ressources MS SQL Server avec l’option moveTo de l’utilitaire cluster et la suppression d’un nœud (RemoveNode) sont également abordées.

Le "mirroring" (ou miroir) est une fonctionnalité qui, depuis SQL Server 2005, maintient une base de données "standby" inactive à des fins de DR (Disaster/Recovery) et/ou de bascule automatique en cas d’échec (automatic failover). Dans ce guide pratique : une solution de miroir SQL Server 2008 R2 avec bascule automatique grâce à une instance témoin (witness). Son implémentation est réalisée et industrialisée en utilisant les variables de scripts, fonctionnalité de l’utilitaire SQLCMD introduite avec SQL Server 2005. De chaleureux remerciements sont d’ailleurs adressés à Richard PRADE pour cette version industrialisée. Au delà de l’industrialisation de l’installation du miroir, sont également abordés :

• des exemples de bascules automatiques et manuelles
• la prise en charge du mirroring par les couches clientes ODBC, OLE DB, ADO.NET et JDBC avec la propriété Failover Partner
• les aspects performances et la mesure de la latence vers le miroir (sp_dbmmonitorchangealert et sp_dbmmonitorresults)

De nombreux articles traitent de la promotion d’un serveur de secours PostgreSQL en serveur principal avec la commande pg_ctl promote. Beaucoup d’entre eux concluent que le serveur de secours doit être reconstruit lorsque le serveur principal est de retour. Qu’en est-il d’une maintenance programmée, maintenance incluant des arrêts, sur le serveur primaire ? Doit-on reconstruire le système primaire/standby ? Évidemment la réponse est : NON. En supposant qu’il y a suffisamment d’espace disque pour conserver les fichiers WAL pendant la tâche de maintenance, en gérant prudemment le point de réplication (replication slot) et l’option de récupération recovery_timeline_target durant les procédures failover/failback, il n’y a pas besoin de reconstruire le système standby impliquant des sauvegardes/restaurations de bases de données et/ou d’utiliser pg_rewind.