SQL Server 2019 の累積的な更新プログラム適用後に発生するイベント名 feature_restriction_usage が見つからないエラーについて
こんにちは SQL Server サポートチームです。 今回は SQL Server 2019 CU2 以降を適用した際に ERRORLOG に記録されるエラーについてご説明します。 ■概要 SQL Server 2019 CU2 以降で拡張イベントの"sqlserver.feature_restriction_usage"が廃止されたことにより、 累積的な更新プログラムを適用した後の初回起動時に、下記のエラーが記録されることがあります。 このエラーは更新プログラム適用後の一時的なものであり、無視していただいて問題ありません。 Error: 25623, Severity: 16, State: 1. The event name, "XXXXXXXXXXXXXXXX.sqlserver.feature_restriction_usage", is invalid, or the object could not be found Error: 25710, Severity: 16, State: 1. Event session "telemetry_xevents" failed to start. Refer to previous errors in the current session to identify the cause, and correct any associated problems. Error: 25709, Severity: 16, State: 1. One or more event sessions failed to start. Refer to previous errors in the current session to identify the cause, and correct any associated problems. ■発生条件 SQL Server 2019 CU1 以下のバージョンの SQL Server を使っている環境に対して、SQL Server 2019 CU2 以降の更新プログラムを適用することで発生します。 ■影響 このエラーによるお客様のアプリケーションへの影響はありません。 拡張イベントの"feature_restriction_usage"は、SQL Server CEIP サービス に関連して動作する拡張イベントセッション"telemetry_xevents"で使用されています。 SQL Server CEIP サービスは、Microsoft が SQL Server の使用状態に関する情報を収集する内部機能となっており、お客様のすべてのアプリケーションの動作には影響しません。 SQL Server CEIP サービスに関する詳細は下記の公開情報をご確認ください。 SQL Server の使用状況および診断データの収集を構成する (CEIP) https://docs.microsoft.com/ja-jp/sql/sql-server/usage-and-diagnostic-data-configuration-for-sql-server?view=sql-server-ver15 ■注意事項 SQL Server CEIP サービスを停止/無効化している環境や、SQL Server CEIP サービスが"telemetry_xevents"の定義を変更する前に、SQL Server サービスが再起動された場合は引き続きエラーが記録される可能性があります。 SQL Server CEIP サービスの無効化はサポートされないため、起動した状態にする必要があります。 なお、SQL Server CEIP サービスが起動した状態であれば拡張イベントセッションの定義変更は通常数分で完了し、定義変更後は基本的に自動で"telemetry_xevents"が起動するため特に操作は不要です。
SQL Server R Services またはSQL Server Machine Learning Servicesをオフラインでインストールまたは更新プログラムを適用するための方法
こんにちは SQL Server サポートチームです。 今回は、SQL Server R Services またはSQL Server Machine Learning Servicesをオフラインでインストールまたは更新プログラムを適用するための方法について紹介します。 日本語版のSQL Server をご利用いただいているお客様より、オフライン環境でSQL Server R Services またはSQL Server Machine Learning Servicesをインストールまたは更新プログラムを適用した際に、失敗するというお問い合わせをいただくことがあります。 これはSQL Server の不具合が原因となりますが、修正目途がたっていない状況となりますため、ブログで回避策を紹介させていただきます。 作業の流れは下記の通りとなります。 １．SQL Server R Services またはSQL Server Machine Learning Servicesをオフラインでインストールする場合 1) インターネットに接続できる環境で、リリースバージョンにあったcab ファイルをダウンロードします。 各リリースバージョンのcabファイルのダウンロード URL は、次のページをご確認ください。 SQL Server 2019 の場合： https://learn.microsoft.com/ja-jp/sql/machine-learning/install/sql-ml-component-install-without-internet-access?view=sql-server-ver15#1---download-2019-cabs SQL Server 2017 の場合： https://learn.microsoft.com/ja-jp/sql/machine-learning/install/sql-ml-component-install-without-internet-access?view=sql-server-2017#1---download-2017-cabs SQL Server 2016 の場合： https://learn.microsoft.com/ja-jp/sql/machine-learning/install/sql-ml-component-install-without-internet-access?view=sql-server-2016#1---download-2016-cabs 2) 適用対象のサーバーに、cabをコピーします。 ※ 任意のパスで結構です。ここでは例として、C:\Temp にコピーするとします。次からの手順は、C:\Temp 配下にコピーした場合の手順となります。 3) 各cabファイルの末尾が1033となっているため、1041にコピーします。 例）SQL Server 2019 の場合 SPO_4.5.12.120_1033.cab -> SPO_4.5.12.120_1041.cab SPS_9.4.7.25_1033.cab -> SPS_9.4.7.25_1041.cab SRO_3.5.2.125_1033.cab -> SRO_3.5.2.125_1041.cab SRS_9.4.7.25_103 3.cab -> SRS_9.4.7.25_1041.cab この結果C:\Temp 配下に、次のファイルが存在することになります。 SPO_4.5.12.120_1033.cab SPO_4.5.12.120_1041.cab SPS_9.4.7.25_1033.cab SPS_9.4.7.25_1041.cab SRO_3.5.2.125_1033.cab SRO_3.5.2.125_1041.cab SRS_9.4.7.25_1033.cab SRS_9.4.7.25_1041.cab 4) インストールを行います。 ※ [Microsoft Machine Learning Server コンポーネントのオフライン インストール] では [インストール パス] に、「C:\Temp」を指定します。 4-1) インストール メディアを開き、setup.exe を右クリックし、管理者として実行します。 4-2) セットアップ ウィザードで、オープンソースの R または Python コンポーネントに対するライセンスのページが表示されたら、 [同意する] をクリックします。 ライセンス条項に同意すると、次の手順に進むことができます。 4-3) [オフライン インストール] ページが表示されたら、 [インストール パス] に、以前にコピーした CAB ファイルが格納されているフォルダーを指定します。 図1．Microsoft Machine Learning Server コンポーネントのオフライン インストール画面 4-4) 画面の指示に従って続行し、インストールを完了します。 参考情報 セットアップの実行 https://docs.microsoft.com/ja-jp/sql/machine-learning/install/sql-ml-component-install-without-internet-access?view=sql-server-ver15#run-setup 2．SQL Server R Services またはSQL Server Machine Learning Servicesの更新プログラムをオフラインで適用する場合 1) インターネットに接続できる環境で、更新プログラムにあったcab ファイルをダウンロードします。 各更新プログラム用のcabファイルのダウンロード URL は、次のページをご確認ください。 SQL Server 2019 の場合： https://docs.microsoft.com/ja-jp/sql/machine-learning/install/sql-ml-cab-downloads?view=sql-server-ver15#sql-server-2019-cabs SQL Server 2017 の場合： https://docs.microsoft.com/ja-jp/sql/machine-learning/install/sql-ml-cab-downloads?view=sql-server-2017#sql-server-2017-cabs SQL Server 2016 の場合： https://docs.microsoft.com/ja-jp/sql/machine-learning/install/sql-ml-cab-downloads?view=sql-server-2016#sql-server-2016-cabs 2) 適用対象のサーバーに、cabをコピーします。 ※ 任意のパスで結構です。ここでは例として、C:\Temp にコピーするとします。次からの手順は、C:\Temp 配下にコピーした場合の手順となります。 3) 各cabファイルの末尾が1033となっているため、1041にコピーします。 例）SQL Server 2019 CU8 の場合 SPO_4.5.12.479_1033.cab -> SPO_4.5.12.479_1041.cab SPS_9.4.7.958_1033.cab -> SPS_9.4.7.958_1041.cab SRO_3.5.2.777_1033.cab -> SRO_3.5.2.777_1041.cab SRS_9.4.7.958_1033.cab -> SRS_9.4.7.958_1041.cab この結果C:\Temp 配下に、次のファイルが存在することになります。 SPO_4.5.12.479_1033.cab SPO_4.5.12.479_1041.cab SPS_9.4.7.958_1033.cab SPS_9.4.7.958_1041.cab SRO_3.5.2.777_1033.cab SRO_3.5.2.777_1041.cab SRS_9.4.7.958_1033.cab SRS_9.4.7.958_1041.cab 4) インストールを行います。 ※ [Microsoft Machine Learning Server コンポーネントのオフライン インストール] では [インストール パス] に、「C:\Temp」を指定します。 4-1) 更新プログラムのインストーラーを実行します。ライセンス条項に同意し、[機能の選択] ページで、累積的な更新プログラムが適用される機能を確認します。 機械学習機能を含む、現在のインスタンスにインストールされているすべての機能が表示されます。 図2. 機能の選択画面 4-2) ウィザードを続行し、R および Python ディストリビューションのライセンス条項に同意します。 [オフライン インストール] ページが表示されたら、 [インストール パス] に、以前にコピーした CAB ファイルが格納されているフォルダーを指定します。 図3. Microsoft Machine Learning Server コンポーネントのオフライン インストール画面 参考情報 累積的な更新プログラムの適用 https://docs.microsoft.com/ja-jp/sql/machine-learning/install/sql-ml-component-install-without-internet-access?view=sql-server-ver15#apply-cumulative-updates ※ 本Blogの内容は、2021年5月現在の内容となっております。イメージのランダム化を強制する(必須ASLR) に「既定でオンにする」を設定した場合、Express Edition の日本語版のインストーラの起動に失敗します
こんにちは。日本マイクロソフト SQL Server サポートチームです。 事象： イメージのランダム化を強制する(必須ASLR) に「既定でオンにする」を設定した場合、SQL Server 2016 ならびにSQL Server 2019 のExpress Edition の日本語版のインストーラ(SQLEXPR_x64_JPN.exe) の起動に失敗します。 なお、イメージのランダム化を強制する(必須ASLR) の規定値は「既定でオフにする」であり、既定値では発生しません。 また、SQL Server 2014、SQL Server 2017、SQL Server 2022 のExpress Edition の日本語版のインストーラー(SQLEXPR_x64_JPN.exe) では発生しません。 ※ 公開時点 イメージのランダム化を強制する(必須ASLR)の設定手順は以下となります。 スタートメニューより[設定] -> [更新とセキュリティ] -> [Windows セキュリティ] -> [アプリとブラウザーの制御] -> [Exploit Protection の設定] -> [システム設定] -> [イメージのランダム化を強制する (必須ASLR)] 図．Windows セキュリティ画面(ご参考) 原因： SQL Server のセットアップは、イメージのランダム化を強制する(必須ASLR) を想定しておらず、SQL Server 2016 ならびにSQL Server 2019 のExpress Edition の日本語版のインストーラ(SQLEXPR_x64_JPN.exe) では、対応が行われていません。 イメージのランダム化を強制する(必須ASLR) に「既定でオンにする」を設定した環境で、インストーラ(SQLEXPR_x64_JPN.exe) の起動に失敗する以外の問題はありません。 回避策： 恐れ入りますが、SQL Server 2016 ならびにSQL Server 2019 のExpress Edition の日本語版のインストーラ(SQLEXPR_x64_JPN.exe) を変更し、再リリースする予定はありません。 そのため、イメージのランダム化を強制する(必須ASLR) に「既定でオンにする」を設定している環境では、次のように一時的に「既定でオフにする」に変更して展開し、SQL Server をインストールします。 1) イメージのランダム化を強制する(必須ASLR)を、「既定でオフにする」に変更します。 2) SQL Server 2016 またはSQL Server 2019 のExpress Edition の日本語版のインストーラー(SQLEXPR_x64_JPN.exe) を起動してファイル群を展開します。 3) イメージのランダム化を強制する(必須ASLR)を、「既定でオンにする」に変更します。 4) SQL Server のインストールを進めます。 なお、SQL Server Express を再配布されている場合、現時点でパッケージを展開して再配布することは、モジュールの変更とはみなされないことを確認しています。Effectively troubleshoot latency in SQL Server Transactional replication: Part 1
Are you struggling with latency issues in SQL Server Transactional replication? This article provides clear, step-by-step instructions to effectively troubleshoot and resolve these challenges. Dive into proven techniques and best practices that will help you enhance your SQL Server's performance and ensure seamless data replication. Don't let latency slow you down—master the art of SQL Server troubleshooting today! I hope you find this teaser engaging! If you need any adjustments or additional content, feel free to let me know. Thanks to Collin Benkler, Senior Escalation Engineer in Microsoft for SQL Server for his valuable feedbacks.PolyBase Error: TCP Provider: An existing connection was forcibly closed by the remote host
In this blog we are sharing details about an issue which can be seen while querying external table created in SQL 2019 with data source pointing to SQL Server 2014. The error message which comes back is “TCP Provider: An existing connection was forcibly closed by the remote host”SQL Backup using Azure File Share
SQL Server limits the maximum backup size supported using a page blob to 1 TB. The maximum backup size supported using block blobs is limited to approximately 200 GB (50,000 blocks * 4 MB MAXTRANSFERSIZE). In order to get over the above limitation, we can opt for Azure File Share. SQL Backup is more than 12TiB, you can choose to backup using Azure File Share Standard file shares can span up to 100 TiB, however this feature is not enabled by default. If you need a file share that is larger than 5 TiB, you will need to enable the large file share feature for your storage account. Premium file shares can span up to 100 TiB without any special setting, however premium file shares are provisioned, rather than pay as you go like standard file shares. This means that provisioning file share much larger than what you need will increase the total cost of storage. In local and zone redundant storage accounts, Azure file shares can span up to 100 TiB, however in geo- and geo-zone redundant storage accounts, Azure file shares can span only up to 5 TiB. Prerequisites Storage Account Azure PowerShell Storage Module https://www.powershellgallery.com/packages/Az.Storage/3.7.0 Steps 1. Storage Account with Premium FileShare Enable Large File Share 2. Register for the SMB Multichannel preview with the following commands. Connect-AzAccount # Setting your active subscription to the one you want to register for the preview. # Replace the <subscription-id> placeholder with your subscription id. $context = Get-AzSubscription -SubscriptionId <your-subscription-id> Set-AzContext $context Register-AzProviderFeature -FeatureName AllowSMBMultichannel -ProviderNamespace Microsoft.Storage Register-AzResourceProvider -ProviderNamespace Microsoft.Storage You can also verify if the feature registration is complete Get-AzProviderFeature -FeatureName AllowSMBMultichannel -ProviderNamespace Microsoft.Storage 3. Enable SMB Multichannel Once you have created a File Storage account, you can follow the instructions to update SMB Multichannel settings for your storage account Note: If the SMB Multichannel option is not visible under File share settings or you get a failed to update setting error while updating the configuration, please make sure that your subscription is registered, and your account is in one of the supported regions with supported account type and replication. 4. Create a file share You can set max capacity up to 100TB 5. Connect to FileShare from Window either using Active Directory or Storage Account Connecting to a share using the storage account key is only appropriate for admin access. But mounting the Azure file share with the Active Directory identity of the user is preferred. $connectTestResult = Test-NetConnection -ComputerName testsmbfileshare.file.core.windows.net -Port 445 if ($connectTestResult.TcpTestSucceeded) { # Save the password so the drive will persist on reboot cmd.exe /C "cmdkey /add:`"testsmbfileshare.file.core.windows.net`" /user:`"localhost\testsmbfileshare`" /pass:`"SxbRsNuwc1*******/8lk1TyUkqC+2+************==`"" # Mount the drive New-PSDrive -Name Z -PSProvider FileSystem -Root "\\testsmbfileshare.file.core.windows.net\sqlbackup" -Persist } else { Write-Error -Message "Unable to reach the Azure storage account via port 445. Check to make sure your organization or ISP is not blocking port 445, or use Azure P2S VPN, Azure S2S VPN, or Express Route to tunnel SMB traffic over a different port." } Copy this script and run this in PowerShell to map this as a network drive locally. This script will check to see if this storage account is accessible via TCP port 445, which is the port SMB uses. If port 445 is available, your Azure file share will be persistently mounted. Note: The script will only work on Windows Server 2012 and above Once we had the above script is executed, we could see the Z drive as network Drive in My computer / This PC 6. On the SQL Server you need to first enable XP_cmdshell so we can configure backups to this file share. Enable the Advance SQL Configuration EXECUTE sp_configure 'show advanced options', 1; GO -- To update the currently configured value for advanced options. RECONFIGURE; GO -- To enable the feature. EXECUTE sp_configure 'xp_cmdshell', 1; GO -- To update the currently configured value for this feature. RECONFIGURE; GO We must mount the Z Drive in SQL server and opt for it to be available for backups. Therefore, we map it using the script below xp_cmdshell 'net use Z: \\testsmbfileshare.file.core.windows.net\sqlbackup /u:localhost\testsmbfileshare SxbRsNuwc1*******/8lk1TyUkqC+2+************==`' Get the storage account, username and access key from Step 5 7. Backup the database now to the file share subdirectory using the below command BACKUP DATABASE [AdventureWorks2019] TO DISK = 'Z:\AdventureWorks2019.bak' with stats = 5 Reference (optional) SMB file shares in Azure Files | Microsoft Docs Create an Azure file share - Azure Files | Microsoft Docs https://technet.microsoft.com/en-us/library/dn435916(v=sql.120).aspx#limitationsConfigure multiple-subnet AlwaysOn Availability Group by modifying CIB
In the Windows world, a Windows Server Failover Cluster (WSFC) natively supports multiple subnets and handles multiple IP addresses via an OR dependency on the IP address. On Linux, there is no OR dependency, but there is a way to achieve a proper multi-subnet natively with Pacemaker, as shown by the following. You cannot do this by simply using the normal Pacemaker command line to modify a resource. You need to modify the cluster information base (CIB). The CIB is an XML file with the Pacemaker configuration. Here is an example to create a SQL Server Linux Availability group in 4 nodes in 3 subnets in RHEL 7.6 If you are already familiar with the AG Group setup process, please just jump to step 16. 1.Register your subscription on for all servers (red1,red2,red3 and red4 in this case) subscription-manager register 2.List all available subscription, pick the one with High Availabiilty , notedown the pool id subscription-manager list --available --all 3.Register the subscription for all nodes (red1,red2,red3 and red4 in this case) sudo subscription-manager attach --pool=xxxxx 4.Enable the repository(red1,red2,red3 and red4 in this case) sudo subscription-manager repos --enable=rhel-ha-for-rhel-7-server-rpms 5.Install Pacemaker packages on all nodes. (red1,red2,red3 and red4 in this case) sudo yum install pacemaker pcs fence-agents-all resource-agents 6.Install SQL Server resource agent (red1,red2,red3 and red4 in this case) sudo yum install mssql-server-ha 7.Set the password for the default user that is created when installing Pacemaker and Corosync packages. All the password should be exactly same (red1,red2,red3 and red4 in this case) sudo passwd hacluster 8.Update /etc/hosts file in all servers, add IP and node name. All the servers should have the same entries. 192.168.2.103 red1 192.168.2.104 red2 192.168.4.100 red3 192.168.5.101 red4 9.Run following commands to Enable and start pcsd service and Pacemaker in all nodes. (red1,red2 and red3 and red4 in this case) sudo systemctl enable pcsd sudo systemctl start pcsd sudo systemctl enable pacemaker 10.Run following commands to Create Cluster in primary replica node (red1 in this case) sudo pcs cluster auth red1 red2 red3 red4 -u hacluster -p YouPasswordUsedinStep7 sudo pcs cluster setup --name sqlcluster1 red1 red2 red3 red4 sudo pcs cluster start --all sudo pcs cluster enable --all 11.Run following command to Enable cluster feature in all nodes(red1,red2 , red3 and red4 in this case) sudo /opt/mssql/bin/mssql-conf set hadr.hadrenabled 1 sudo systemctl restart mssql-server Create AG and Listener 1.Run following queries in red1 to create certificate use master go CREATE MASTER KEY ENCRYPTION BY PASSWORD = '**<Master_Key_Password>**'; go CREATE CERTIFICATE dbm_certificate WITH SUBJECT = 'dbm'; go BACKUP CERTIFICATE dbm_certificate TO FILE = '/var/opt/mssql/data/dbm_certificate.cer' WITH PRIVATE KEY ( FILE = '/var/opt/mssql/data/dbm_certificate.pvk', ENCRYPTION BY PASSWORD = '**<Private_Key_Password>**' ); 2.Run following commands in red1 to copy the certificate to rest of the servers(red2,red3 and red4 in this case) cd /var/opt/mssql/data scp dbm_certificate.* root@red2:/var/opt/mssql/data/ scp dbm_certificate.* root@red3:/var/opt/mssql/data/ scp dbm_certificate.* root@red4:/var/opt/mssql/data/ 3.Give permission to the mssql user to access the certificate files in rest of the servers(red2,red3 and red4 in this case) cd /var/opt/mssql/data chown mssql:mssql dbm_certificate.* 4.Run following T-SQL queries to create the certificate in rest of the nodes by restoring the certificate backup file (red2,red3 and red4 in this case) use master go CREATE MASTER KEY ENCRYPTION BY PASSWORD = '**<Master_Key_Password>**' go CREATE CERTIFICATE dbm_certificate FROM FILE = '/var/opt/mssql/data/dbm_certificate.cer' WITH PRIVATE KEY ( FILE = '/var/opt/mssql/data/dbm_certificate.pvk', DECRYPTION BY PASSWORD = '**<Private_Key_Password>**' ) 5.Create endpoint in all servers (red1,red2,red3 and red4) CREATE ENDPOINT [Hadr_endpoint] AS TCP (LISTENER_PORT = 5022) FOR DATABASE_MIRRORING ( ROLE = ALL, AUTHENTICATION = CERTIFICATE dbm_certificate, ENCRYPTION = REQUIRED ALGORITHM AES ); ALTER ENDPOINT [Hadr_endpoint] STATE = STARTED; 6.Run following query in primary replica (red1) to create Availability group(Please note, it works for SQL 2019. If you are using SQL 2017, you need to change AVAILABILITY_MODE of one the replica to ASYNCHRONOUS_COMMIT) CREATE AVAILABILITY GROUP [ag1] WITH (DB_FAILOVER = ON, CLUSTER_TYPE = EXTERNAL) FOR REPLICA ON N'red1' WITH ( ENDPOINT_URL = N'tcp://red1:5022', AVAILABILITY_MODE = SYNCHRONOUS_COMMIT, FAILOVER_MODE = EXTERNAL, SEEDING_MODE = AUTOMATIC) , N'red2' WITH ( ENDPOINT_URL = N'tcp://red2:5022', AVAILABILITY_MODE = SYNCHRONOUS_COMMIT, FAILOVER_MODE = EXTERNAL, SEEDING_MODE = AUTOMATIC), N'red3' WITH ( ENDPOINT_URL = N'tcp://red3:5022', AVAILABILITY_MODE = SYNCHRONOUS_COMMIT, FAILOVER_MODE = EXTERNAL, SEEDING_MODE = AUTOMATIC), N'red4' WITH ( ENDPOINT_URL = N'tcp://red4:5022', AVAILABILITY_MODE = SYNCHRONOUS_COMMIT, FAILOVER_MODE = EXTERNAL, SEEDING_MODE = AUTOMATIC) ALTER AVAILABILITY GROUP [ag1] GRANT CREATE ANY DATABASE;--grant create any database permission Join the AG group, run the following T-SQL queries in all the secondary servers (red2,red3 and red4 in this case) ALTER AVAILABILITY GROUP [ag1] JOIN WITH (CLUSTER_TYPE = EXTERNAL); ALTER AVAILABILITY GROUP [ag1] GRANT CREATE ANY DATABASE 8.Run following T-SQL Queries to create database and add it to AG group in primary replica (red1 in this case). CREATE DATABASE [db1]; ALTER DATABASE [db1] SET RECOVERY FULL; BACKUP DATABASE [db1] TO DISK = N'/var/opt/mssql/data/db1.bak'; BACKUP log [db1] TO DISK = N'/var/opt/mssql/data/db1.trn'; GO ALTER AVAILABILITY GROUP [ag1] ADD DATABASE [db1]; 9.Create SQL login pacemaker in all servers (red1,red2,red3 and red4 in this case). CREATE LOGIN [pacemakerLogin] with PASSWORD= N'ComplexP@$$w0rd!' GO ALTER SERVER ROLE [sysadmin] ADD MEMBER [pacemakerLogin] 10.Run following bash command in red1 sudo pcs property set stonith-enabled=false In all SQL Server Linux servers , run following bash commands to save the credentials for the SQL Server login.(red1,red2,red3 and red4) (The password is as same as the one used in step 9) echo 'pacemakerLogin' >> ~/pacemaker-passwd echo 'ComplexP@$$w0rd!' >> ~/pacemaker-passwd sudo mv ~/pacemaker-passwd /var/opt/mssql/secrets/passwd sudo chown root:root /var/opt/mssql/secrets/passwd sudo chmod 400 /var/opt/mssql/secrets/passwd # Only readable by root 12.Create availability group resource at cluster level, run following command on any one of the nodes (just in one server and run just one time). sudo pcs resource create ag_cluster1 ocf:mssql:ag ag_name=ag1 meta failure-timeout=60s master notify=true ##check the status 13.Run following bash command in primary replica red1 to create one virtual IP resources. The resource name is 'vip1', and IP address is 192.168.2.111 sudo pcs resource create vip1 ocf:heartbeat:IPaddr2 ip=192.168.2.111 ##check the status Create Availability group listener for Availability group ag1. Run following T-SQL query in primary replica (red1 in this case). ALTER AVAILABILITY GROUP [ag1] ADD LISTENER 'aglistener' (WITH IP ( ('192.168.2.111','255.255.255.0'), ('192.168.4.111','255.255.255.0'), ('192.168.5.111','255.255.255.0') ),PORT = 1433); Run following bash commands to create constraints: sudo pcs constraint colocation add vip1 ag_cluster1-master INFINITY with-rsc-role=Master sudo pcs constraint order promote ag_cluster1-master then start vip1 16.Run following bash command to export the CIB.(you can run the command in any node) sudo pcs cluster cib <filename> 17.You will find following similar entries <primitive class="ocf" id="vip1" provider="heartbeat" type="IPaddr2"> <instance_attributes id="vip1-instance_attributes"> <nvpair id="vip1-instance_attributes-ip" name="ip" value="192.168.2.111"/> </instance_attributes> <operations> <op id="vip1-monitor-interval-10s" interval="10s" name="monitor" timeout="20s"/> <op id="vip1-start-interval-0s" interval="0s" name="start" timeout="20s"/> <op id="vip1-stop-interval-0s" interval="0s" name="stop" timeout="20s"/> </operations> </primitive> 18.Here is the modified version <primitive class="ocf" id="vip1" provider="heartbeat" type="IPaddr2"> <instance_attributes id="vip1-instance_attributes"> <rule id="Subnet1-IP" score="INFINITY" boolean-op="or"> <expression id="Subnet1-Node1" attribute="#uname" operation="eq" value="red1"/> <expression id="Subnet1-Node2" attribute="#uname" operation="eq" value="red2"/> </rule> <nvpair id="vip1-instance_attributes-ip" name="ip" value="192.168.2.111"/> </instance_attributes> <instance_attributes id="vip1-instance_attributes2"> <rule id="Subnet2-IP" score="INFINITY"> <expression id="Subnet2-Node1" attribute="#uname" operation="eq" value="red3"/> </rule> <nvpair id="vip1-instance_attributes-ip2" name="ip" value="192.168.4.111"/> </instance_attributes> <instance_attributes id="vip1-instance_attributes3"> <rule id="Subnet3-IP" score="INFINITY"> <expression id="Subnet3-Node1" attribute="#uname" operation="eq" value="red4"/> </rule> <nvpair id="vip1-instance_attributes-ip3" name="ip" value="192.168.5.111"/> </instance_attributes> <operations> <op id="vip1-monitor-interval-10s" interval="10s" name="monitor" timeout="20s"/> <op id="vip1-start-interval-0s" interval="0s" name="start" timeout="20s"/> <op id="vip1-stop-interval-0s" interval="0s" name="stop" timeout="20s"/> </operations> </primitive> Run following command to import the modified CIB and reconfigure Pacemaker. sudo pcs cluster cib-push <filename> Here are the takeaway points: 1).All nodes in same subnet should be in the same <Instance_attributes> 2).If there are more than one servers in the subnet, the keyword ‘boolean-op="or"’ is a must 3).The IP address of Alwayson Listener is addressed in <nvpair> . 4).The value of id property does not matter, you can specify any value as long as the value is unique. Optional, you can create three entries for the three IP addresses in the DNS server. Here is an screenshot of using SQLCMD to connect the AGListener
