Link: https://learn.microsoft.com/en-us/sql/sql-server/failover-clusters/windows/always-on-failover-cluster-instances-sql-server?view=sql-server-ver15#FCIelements > Each node in the resource group maintains a synchronized copy of the > configuration settings and check-pointed registry keys to ensure full > functionality of the FCI after a failover My understanding is that service account and other sql config manager settings are stored in the registry. Does the above quote imply that when any sql config manager change is made on 1 FCI node (sql server service account, sql agent service account, sql integration services service account, protocol changes [tcp/shared memory]) then it will auto apply this on the node 2? For example: following link suggests that password change made on 1 node gets communicated on other nodes: https://learn.microsoft.com/en-us/sql/sql-server/failover-clusters/windows/failover-cluster-instance-administration-and-maintenance?view=sql-server-ver15#changing-service-accounts > You should not change passwords for any of the SQL Server service > accounts when an FCI node is down or offline. If you must do this, you > must reset the password again by using SQL Server Configuration > Manager when all nodes are back online.

To have an Availability Group, I must have a Windows Server Failover Cluster. All Windows Server Failover Clusters have the ability to form exactly one quorum. This clearly means that if I have two Failover Cluster Instances, I must have two quorums. But what happens if I make an Availability Group out of two Failover Cluster Instances? **Do I need to manage three quorums?** [The documentation](https://learn.microsoft.com/en-us/sql/database-engine/availability-groups/windows/failover-clustering-and-always-on-availability-groups-sql-server?view=sql-server-ver17#WSFC) certainly gives the impression that the Availability Group is subject to the vote of a quorum, but I don't know which quorum.

If I am in topologyMode Single-Primary, it's possible to switchover the primary instance between machines in the cluster? I did not find anything in the documentation. Ie: in my lab I have: topology": { "mysql0:3306": { "address": "mysql0:3306", "memberRole": "PRIMARY", "mode": "R/W", "readReplicas": {}, "role": "HA", "status": "ONLINE", "version": "5.7.42" }, "mysql1:3306": { "address": "mysql1:3306", "memberRole": "SECONDARY", "mode": "R/O", "readReplicas": {}, "role": "HA", "status": "ONLINE", "version": "5.7.42" How to switch mysql1 as primary? **Update:** Seems to have the command cluster.setPrimaryInstance() but it did not work in MySQL 5.7, only 8.0. So, there isn't a way to do it in MySQL 5.7?

I have a 4 node cluster SQL 2012 availability group database with one witness server at the primary site. 3 nodes are in the primary site and one node in the DR site. Due to maintenance at the Primary Site I need to failover to the DR site and making it as the primary. Here is my question, if I Failover to the Dr Site and turn off all the nodes one by one gracefully including the witness server, will the Dynamin Quorum take over and keep the cluster and the availability group alive or the Windows Server Failover Cluster goes down and AG is inaccessible and as a result I will have to bring the cluster service up with force quorum

I'm tasked with setting up a 2 node cluster that will host a MS SQL availability group. I have the servers setup and the AG looks to be working as expected. However, there is another requirement to hang a file share off one of the drives. I'm not crazy about it, but I have to deal with it. Since this is a windows failover cluster, my understanding is that I need to add the file server role and configure it to host the share. I've done this and it's working but, because the AG and FS roles each need their own IP and DNS name (Example: AG = \\\ServerName, FS = \\\ServerName-FS), I'm getting pushback from some people because they want the share to answer from the same server name as the SQL instance, as if it were a one-server solution. I've been looking for a way to accommodate their request, but have come up short. Am I missing something or is this just not possible? OS = Windows Server 2022 Datacenter SQL = SQL 2022 Enterprise All resources are on-prem Thanks in advance,

I have 1 MariaDB Galera cluster composed of 5 nodes in 2 different datacenters: 3 in DC1, 2 in DC2, On DC1, one of the nodes has a pc.weight=2. Bootstrap was set on Node 1 from DC1. Data between the 5 nodes is correctly synced and system works perfectly fine. I created a table, with column ID (PK int auto increment) and column Data (varchar) where the DC's id would be inserted, such that I know from where the data was generated. Also a 3rd column InsertDate as Timestamp. During a test case, i use the following procedure: - run in both DCs a script that inserts 1 row every second, during 10 seconds. We endup with 20 rows inserted and synced in all 5 nodes. This is OK. - disconnect network connectivity between the 2 DCs - the 3 nodes on DC 1 are still available and ready for query - the 2 nodes on DC 2 are unavailable for query. However, by executing:

SET GLOBAL wsrep_provider_options='pc.bootstrap=YES';

the 2 nodes present on DC2 start accepting queries. We have now 2 independent clusters, 1 in each DC. - still while the network is down between DC's, on DC2 I run once again the script during 10 seconds, inserting 10 new rows on DC2. And I do the same for DC1. - currently we have 30 rows on DC1 (20 from previous run, and 10 of the last run) and on DC2 we also have 30 rows. - I reconnect network communications between DCs - the 3 nodes in DC1 is still on, accepting queries, but DC2 nodes are still not available to DC1, because the did not join DC1 nodes yet. - so I reboot nodes from DC2 and the have now joined DC1 and forme da sinclge cluster with 5 nodes where DC1 has the majority (2+1+1) Checking data, I find that the whole cluster still has 30 rows, when there should be 40 (20 from fist run, 10 from second run from DC1 + 10 from DC2) so it seems that rows from DC2 were discarded. What I need is when nodes from DC2 join the cluster, the new rows found on DC2 should be replicated on DC1 nodes, and the same from DC1 to DC2: nodes from DC1 should replicated to DC2. I noticed that some IDs (PK autoincrement) from DC1 would be found on DC2 but the column Data would not be the correct one, as well as InsertedDate that would differ between DC1 and DC2. I suspect that the fact that during the test and while data was being inserted when both DCs were not communicating, the PKs matched and once the connectivity was UP again, Galera just discarded values that would conflict. Could that be the reason? How can I make sure that when connectivity is back, new data found on DC2 and DC1 are synced between nodes, without dicarding any? I thought about auto_increment_increment and auto_increment_offset, but that did work, Galera overrides those settings and manages the auto increment PK. Any idea?

We were recently asked to remove unsupported software from our servers and the list included SQL 2012 Native Client. Version 11 was installed, so we removed it from test & dev servers without any issues. When it came to the Live servers which are HA Availability Groups built on Windows Clustering, there were no issues... until we ran Failover Cluster Manager, then the cluster went down. Has anyone experienced similar issues? Is anyone aware of this being an issue? I have not seen any documentation from Microsoft, but it is clear from our subsequent testing that removing SQL 2012 Native Client breaks Failover Cluster Manager. SQL is running on 2017 and the OS is Windows Server 2016.

After having to restart a node in a RAC cluster, we ran into "ORA-29707: inconsistent value 1 for initialization parameter 1146 with other instances" when trying to use srvctl start instance -i ORAPD3 -d ORAPD. CMD output was something like: PRCR-1013 : Failed to start resource ora.orapd.db PRCR-1064 : Failed to start resource ora.orapd.db on node corprac03 CRS-5017: The resource action "ora.orapd.db start" encountered the following error: ORA-29707: inconsistent value 1 for initialization parameter 1146 with other instances . For details refer to "(:CLSN00107:)" in "/u01/app/grid/diag/crs/corprac03/crs/trace/crsd_oraagent_oracle.trc".

Currently running several databases on an Active/Passive SQL Server 2014 Failover Cluster on Windows Server 2012 R2. Recently there was an event that caused the active server to failover. The failover was just a quick moment. The problem is when the passive node came online, the data was a month old. It wasn't just one database, it was multiple (all six) databases that must have rolled back ~30 days. This is the first time this has ever happened. We've had plenty of failovers; virtual host update/failure, SQL server update/failure, or even failures on the SQL server itself. We don't yet know why the SQL machine instance itself failed over yet, and we don't know why all the data was rolled back. We fortunately have full and transaction log backups we are currently restoring to. However, we'd like to understand why did this happen and how do we prevent this in the future; how can we troubleshoot this issue?

Using SQL Server 2019 with 200+ databases in a 2 node FCI, what is considered best practice regarding SQL Server Agent when performing manual failover for SQL Server CU patching. Should we manually stop the SQL Server Agent before failover? I ask because we see that sometimes failover takes over 10 minutes, and sometimes failover takes less than 3 seconds.

In a 2 node WSFC where Node 1 owns the disk witness, would Node 1 crashing result in the entire cluster going down (loss of quorum because only 1/3 votes remain)? Or does disk witness ownership transfer to Node 2 regardless of whether Node 1 was powered down gracefully or not?

I have 2-node SQL Server 2019 FCI cluster, which takes up to 4 minutes to failover from one node to another. The cluster has 3 user databases, migrated from the older SQL server versions: - 2 databases with higher load have SIMPLE recovery model (and compatibility level 100) - 1 database has FULL recovery model (and compatibility level 130) Would changing recovery model and/or increasing compatibility level reduce failover time of the cluster? Unfortunately, I have no access to the server, but checking logs is definitely the first thing I requested already. Also, I understand that compatibility level might be the last thing to affect failover time. But I was not able to find any data on relation of recovery model to failover time of a FCI cluster. I'm afraid using ADR yet having read somewhere on Microsoft that it was introduced on SQL Server 2019 and improved in SQL Server 2022. Maybe when I get next environment upgrade in a few years.

I'm relatively new to high availability groups in SQL Server, and am hoping for a bit of advice on best practices for configuration. I didn't set up this configuration, I inherited it and am trying to get an understanding as I've been moved towards a more DB Admin-focused role of late. There's a specific issue we encountered recently which I'll try to explain. We have a SQL Server cluster on 2019 with two nodes and a file share witness. Load balancing enabled, low aggressiveness. I noticed the file share witness is configured to fail over if the restart period fails (set to 10 minutes). Anyways, the problem. Last night our WSUS server installed updates which took the file share witness offline and triggered a failover to our secondary node. However, since the problem wasn't with any of the database availability groups, they all remained on the primary node, rendering them inaccessible on the cluster. EDIT: This is an availability group setup alone; the file share witness was on the primary node at the time. The file share witness is owned by the primary node. Logs seem to indicate that the fsw failed a periodic health check when it was rebooting/installing updates, timed out of the automatic restart attempts, was marked as failed, and triggered a failover from primary to secondary. None of the availability groups on the primary node failed over to the secondary. I assume that either the file share witness shouldn't be triggering a failover, or there's something I should be doing to make sure everything fails over when triggered. I just wanted to reach out to see if anyone had any advice, or anything I should be aware of to better prevent problems like this. Thanks for your time. If there's anything I can add to clarify things, please let me know.

I know that Always on Availability Groups can be set up on a windows server failover cluster without active directory integration. But can a SQL Server Failover Cluster Instance high availability solution be created without active directory integration? I couldn't find anything on the subject online.

There was a planned cluster failover to the secondary node of our FCI. Afterwards, sp_execute_external_script stopped working. Examples with error messages are below: EXEC sp_execute_external_script @script=N'print(R.version)',@language=N'R'; GO > Msg 39012, Level 16, State 14, Line 0 Unable to communicate with the
> runtime for 'R' script for request id:
> 4B918DE5-B534-4F35-8723-34F818536F68. Please check the requirements of
> 'R' runtime. STDERR message(s) from external script:
> > SQLSatellite Run() failed. Error code:0x80004004. Error in eval(ei,
> envir) : SQLSatellite Run() failed. Error code:0x80004004. Calls:
> runScriptFile -> source -> withVisible -> eval -> eval -> .Call
> Execution halted EXEC sp_execute_external_script @script=N'import sys;print(sys.version)',@language=N'Python' GO > Msg 39012, Level 16, State 14, Line 3 Unable to communicate with the
> runtime for 'Python' script for request id:
> D1397DA5-79FD-4C4A-891C-C01E436FA20F. Please check the requirements of
> 'Python' runtime. STDERR message(s) from external script:
> > SQLSatellite Run() failed. Error code:0x80004004. SqlSatelliteCall
> error: SQLSatellite Run() failed. Error code:0x80004004. STDOUT
> message(s) from external script: SqlSatelliteCall function failed.
> Please see the console output for more information. Traceback (most > recent call last):
> File "C:\Program Files\Python310\lib\site-packages\revoscalepy\computecontext\RxInSqlServer.py",
> line 608, in rx_sql_satellite_call
> rx_native_call("SqlSatelliteCall", params)
> File "C:\Program Files\Python310\lib\site-packages\revoscalepy\RxSerializable.py", line > 375, in rx_native_call
> ret = px_call(functionname, params) RuntimeError: revoscalepy function failed. Other notes that may or may not be relevant: - In my mind, the setup and configuration of R and Python is the same on both cluster nodes. (But I'm fallible.) - The logon account for the SQL Server Launchpad service is a domain account on both nodes (same account). - Whether it's R or Python, sp_execute_external_script runs for 60 seconds before erroring out. I reviewed the documentation for the following two articles. I'm not seeing anything that is missing or out of order:
Install SQL Server 2022 Machine Learning Services (Python and R) on Windows
Known issues for Python and R in SQL Server Machine Learning Services More documentation:
Create a login for SQLRUserGroup : This suggested there is supposed to be a login for SQLRUserGroup, which is a local machine group account. However, sp_execute_external_script works on the primary node. And there is no [NodeA\SQLRUserGroup] login. Nonetheless, I thought I'd try creating the [NodeB\SQLRUserGroup] for the secondary node. No additional permissions were granted to the login, and it is not a member of any server roles (except for [public]) USE [master] CREATE LOGIN [NodeB\SQLRUserGroup] FROM WINDOWS WITH DEFAULT_DATABASE=[master] GO **My Question**
What could be causing sp_execute_external_script to fail on the secondary node (NodeB)?

- We have two node Windows Server cluster with installed SQL Server (2019 Standard Edition) Clustered instances on each node - There are 500 active databases - There are no any Availability Groups or any other HA solutions configured - All databases are on Simple recovery mode - VLF count and size are not so big - Both nodes are virtualized Windows Server 2019 with 64 GB of memory and 16 cores. After patching the passive node and rebooting it, we've tried to failover to that node. But surprisingly it took ~ 10 minutes to start the SQL Server service which hanged on **change pending** state. In regular case without patching it takes ~ 10 seconds. I know from Microsoft documentation that downtime depends on the failover time and the overall time for database upgrade scripts execution: > This process results in downtime limited to one failover time and database upgrade script execution time during the whole failover cluster upgrade. This downtime period seems to me very long, just searching for ways to decrease it somehow. If you have any suggestions, I'll be more than happy to listen to them.

In a SQL Server failover cluster environment, I can move the SQL Server role to node a and the quorum drive at node b. Although it's possible, is this a correct configuration? While I was Googling around, I noticed some people believe this is considered a bad configuration. But I can't find anything in SQL Server's documentation.

I'm looking at a sql server fci that has the database engine installed. My task is to add the full text search service and integration services. I'm exploring how to do this when I came across this link: https://learn.microsoft.com/en-us/sql/sql-server/failover-clusters/install/create-a-new-sql-server-failover-cluster-setup?view=sql-server-ver16#to-install-a-new--failover-cluster-instance-using-integrated-install-with-add-node > You cannot add features to a failover cluster instance after creation. Has anyone added features to an fci post installation and do you know whether the above quote is true for instance level and shared feature? For example full text is an instance level feature whereas integration services is a shared feature. I'm not sure it is acceptable to install new fci as that would require migration so hoping to get some advise here.

I'm learning about handling fci issues and stuck at 2 concepts to recover from cluster failure: 1. Forced quorum 2. Force start without quorum What is the factor to decide whether to use which of the above? For example does forced quorum also mean manual forced failover?

I have FCI with 2 nodes. Following is steps to patch the nodes: 1. Remove node from Possible owners 2. Patch the inactive node 3. Add the node to the Possible owners 4. Failover to inactive node 5. Leave it running for 1 week to ensure no patch related issues 6. Remove the other node from the Possible owners 7. Patch the inactive node 8. Add the node to the Possible owners 9. Failover My questions: 1. Point 2: before this, do I need to change the FailureConditionLevel to 0 so that it doesn't attempt a failover? 2. Point 5: At this point if a failover occurs then it will make sql server go from the patched node to the unmatched node. Will this introduce any compatibility issues since both nodes don't have the same patch?