Error 19405 al configurar nuevo nodo alwaysON sobre ambiente primario configurado como FailoverCluster

Hace pocos días tuve una problemática al añadir un nodo nuevo a un ambiente alwaysON existente. En mi cliente tengo una configuración de AlwaysON compuesta por una réplica primaria formada por un ambiente Failover Cluster de dos nodos, y como réplica secundaria tengo un nodo standalone dónde están las bases en modalidad lectura para que el cliente también lo ocupe como sistema de reporteria.

Ahora por necesidades del negocio para una prueba de DRP necesitábamos añadir un nodo secundario adicional al alwaysON (este nuevo nodo sería un standalone). Pero al añadir dicho nuevo nodo desde el wizzard de alwaysON apareció un error un poco extraño:

Naturalmente revisé lo que estaba mencionado ahí teniendo en cuenta que mi servicio sqlserver primario el cual estaba en realidad en un failover cluster no tuviera como nodo propietario al nuevo servidor standalone que estaba agregando al alwaysON. Al revisarlo desde el failover cluster manager efectivamente el servicio sqlserver no tenía seleccionado como owner al nuevo nodo:

Una vez que comprobé que el failover del servicio sqlserver en cluster  nunca podría ser pasado al nuevo nodo (que es lo que corresponde), me puse a revisar si no habría algún bug o error que me estuviese mostrando el GUI del failover manager. Por lo que desde consola powershell en el nodo primario del failover cluster consulté los posibles owner del servicio sqlserver  y en dicho caso si me mostró que mi nuevo nodo standalone de alwaysON estaba asignado como posible owner para el servicio lo cual está mal.

Comando: Get-ClusterOwnerNode –Resource “sql server”

El último nodo que termina con el nombre 136 no tiene que estar asignado como owner al servicio clusterizado de sqlserver. Esto es un bug ya que desde la herramienta  gráfica de failover cluster el nodo no aparece asignado, pero desde consola claramente se puede ver lo contrario (aún no encuentro ninguna nota que haga referencia formal a este error)

Ahora como esto no lo pude arreglar desde la interfaz gráfica del cluster administrator (porque el error se repetía nuevamente al agregar la réplica), me dispuse a solucionarlo desde la consola de comandos de powershell. Por lo cual eliminé el nuevo nodo standalone de la siguiente manera:

Comandos:

Get-ClusterOwnerNode –Resource “sql server” |Set-ClusterOwnerNode –Owners nodo1,nodo2

Como se podrá apreciar ahora los nodos preferentes para mi servicio de cluster solo aprecen los nodos antiguos y ya no mi nuevo nodo que termina con nombre 136. Posterior a eso ya no tuve problemas para añadir mi nueva replica standalone:

Espero que haya sido de utilidad.

Problema al agregar una nueva base de datos a un availability group existente (SQLServer AlwaysOn): Error Message: Availability-group DDL operations are permitted only when you are using the master database. Run the USE MASTER command, and retry your availability-group DDL command.

Hace poco estimados obtuve el siguiente error al momento de agregar una nueva base de datos a un availability group de SQLServer (AlwaysOn):

Error Message: Availability-group DDL operations are permitted
only when you are using the master database.  Run the USE MASTER
command, and retry your availability-group DDL command.

Dicho error no me estaba permitiendo agregar una nueva base de datos a un grupo de disponibilidad  ya existente en mi infraestructura AlwaysOn. Es decir al momento de finalizar el wizard y agregar la nueva base de datos aparecia el error antes mencionado. También aparecia el siguiente error:



Investigando al respecto en el siguiente link:https://blogs.msdn.microsoft.com/svarukala/2014/03/31/sql-alwayson-failed-to-join-the-database-to-the-availability-group-error-35250/, se podrá apreciar algunas recomendaciones y sugerencias que se pueden aplicar para evitar los anteriores errores, como por ejemplo
agregar el privilegio de conexión al endpoint corespondiente según la consulta: SELECT name, state_desc, port from sys.tcp_endpoints where type_desc='DATABASE_MIRRORING;
USE master;
 GRANT CONNECT on ENDPOINT::Hadr_endpoint TO [dominio\cuenta_servicio_que_levanta_el_motor];
 GO

En mi caso el problema radicaba en que la cuenta de dominio con la cual intentaba agregar la nueva base al grupo de dispobilidad de los otros dos nodos Secundarios de AQN, tenian como base de datos por defecto la TEMPDB, y cuando se realizan estas operaciones tanto en el primario como en el (o los) secundario(s) el usuario en cuestión debe tener como base de datos por default la MASTER.




Dado lo anterior cambié la configuración de la base de datos por default para la cuenta con la cual estoy interviniendo el availability group y asunto solucionado:


 Espero haya sido de ayuda.
Algunos memes para alegrar el dìa: