SQL Server 2017 dengan 500 basis data - Frequent AG terputus sejak CU9

Hai semuanya dan terima kasih sebelumnya atas bantuan Anda. Kami mengalami tantangan dengan Grup Ketersediaan SQL Server 2017.

Latar Belakang

Perusahaan adalah perangkat lunak B2B ritel back-end. Sekitar 500 basis data penyewa tunggal, dan 5 basis data bersama yang digunakan oleh semua penyewa. Karakteristik beban kerja banyak dibaca, dan sebagian besar database memiliki aktivitas yang sangat rendah.

Server produksi fisik yang dihosting di lokasi bersama baru-baru ini ditingkatkan dari SQL Server 2014 Enterprise pada Windows Server 2012 dalam konfigurasi SAN / FCI bersama, ke SQL Server 2017 Enterprise pada Windows Server 2016 pada RAM 2 socket / 32 core / 768 GB dan lokal Drive SSD menggunakan AlwaysOn AG. Lalu lintas AG menggunakan port NIC 10G khusus dengan koneksi kabel silang.

Persyaratan mereka adalah agar semua database gagal bersama, sehingga mereka harus menempatkan semuanya dalam AG tunggal. Ini adalah satu, replika sinkron yang tidak dapat dibaca pada server yang identik.

Server baru telah diproduksi sejak Juni 2018. CU terbaru (CU7 saat itu) dan pembaruan windows diinstal, dan sistem bekerja dengan baik. Sekitar sebulan kemudian, setelah memperbarui server dari CU7 ke CU9, mereka mulai memperhatikan tantangan-tantangan berikut, yang tercantum dalam urutan prioritas.

Kami telah memantau server menggunakan SQL Sentry dan tidak menemukan hambatan fisik. Semua indikator utama tampak bagus. CPU rata-rata 20%, IO kali biasanya kurang dari 1ms, RAM tidak sepenuhnya digunakan, dan jaringan <1%.

Tantangan

Gejala-gejalanya tampak membaik setelah kegagalan, tetapi kembali dalam beberapa hari, terlepas dari server mana yang utama - gejalanya identik pada kedua server.

1. Batas waktu klien sporadis dan kegagalan konektivitas seperti

   ... kesalahan terjadi saat membuat koneksi ...

   atau

   Batas waktu eksekusi berakhir

   Kadang-kadang ini akan berlangsung hingga 40 detik, dan kemudian mereda.

2. Pekerjaan pencadangan log transaksi membutuhkan waktu 10X lebih lama untuk diselesaikan daripada sebelumnya. Sebelumnya butuh 2 - 3 menit untuk membuat cadangan log dari semua 500 database, sekarang butuh 15-25. Kami telah memverifikasi bahwa Cadangan itu sendiri berjalan dengan baik dengan throughput yang baik. Namun, ada sedikit keterlambatan setelah menyelesaikan cadangan satu log, dan sebelum memulai berikutnya. itu dimulai sangat rendah, tetapi dalam satu atau dua hari sampai 2-3 detik. Dikalikan dengan 500 basis data, dan ada perbedaannya.

3. Kadang-kadang, beberapa database yang tampaknya acak terjebak dalam keadaan "Tidak menyinkronkan" setelah kegagalan manual. Satu-satunya cara untuk menyelesaikan ini adalah memulai kembali Layanan SQL Server pada replika sekunder, atau menghapus dan bergabung kembali dengan basis data ini ke AG.

4. Masalah lain yang diperkenalkan oleh CU10 (dan tidak diselesaikan di CU11): Koneksi ke batas waktu sekunder pada pemblokiran pada master.sys.databases dan bahkan tidak dapat menggunakan objek penjelajah SSMS untuk replika sekunder. Penyebab root tampaknya akan diblokir oleh penulis Microsoft SQL Server VSS mengeluarkan pertanyaan berikut:

   select name, 
          recovery_model_desc, 
          state_desc, 
          CONVERT(integer, is_in_standby), 
          ISNULL(source_database_id,0) 
     from master.sys.databases

Pengamatan

Saya percaya saya menemukan pistol merokok di log kesalahan. Log kesalahan penuh dengan pesan AG, yang dilabeli sebagai 'hanya informasi', tetapi sepertinya mereka tidak normal sama sekali, dan ada korelasi yang sangat kuat dari frekuensi mereka dengan kesalahan aplikasi.

Kesalahan ada beberapa jenis, dan muncul secara berurutan:

• DbMgrPartnerCommitPolicy :: SetSyncState: GUID

• DbMgrPartnerCommitPolicy :: SetSyncAndRecoveryPoint: GUID

• Koneksi AlwaysOn Availability Groups dengan basis data sekunder diakhiri untuk basis data primer 'XYZ' pada replika ketersediaan 'DB' dengan ID Replika: {GUID}. Ini hanya pesan informasi. Tidak diperlukan tindakan pengguna.

• Koneksi AlwaysOn Availability Groups dengan basis data sekunder yang dibuat untuk basis data primer 'ABC' pada replika ketersediaan 'DB' dengan ID Replica: {GUID}. Ini hanya pesan informasi. Tidak diperlukan tindakan pengguna.

Beberapa hari ada 10 dari ribuan itu.

Artikel ini membahas jenis urutan kesalahan yang sama pada SQL 2016 dan di sana dikatakan tidak normal. Ini juga menjelaskan fenomena 'non-sinkronisasi' setelah kegagalan. Masalah yang dibahas adalah untuk 2016 dan telah diperbaiki awal tahun ini dalam CU. Namun, itu adalah satu-satunya referensi yang relevan yang dapat saya temukan untuk 2 jenis pesan pertama, selain referensi ke pesan penyemaian awal otomatis yang seharusnya tidak menjadi masalah di sini karena AG sudah dibuat.

Berikut ringkasan kesalahan harian minggu lalu, untuk hari-hari yang memiliki> 10 ribu kesalahan per jenis pada PRIMARY (acara sekunder 'kehilangan koneksi dengan primer ...'):

Date        Message Type (First 50 characters)                  Num Errors
10/8/2018   DbMgrPartnerCommitPolicy::SetSyncAndRecoveryPoint:  61953
10/3/2018   DbMgrPartnerCommitPolicy::SetSyncAndRecoveryPoint:  56812
10/4/2018   DbMgrPartnerCommitPolicy::SetSyncAndRecoveryPoint:  27951
10/2/2018   DbMgrPartnerCommitPolicy::SetSyncAndRecoveryPoint:  24158
10/7/2018   DbMgrPartnerCommitPolicy::SetSyncAndRecoveryPoint:  14904
10/8/2018   Always On Availability Groups connection with seco  13301
10/3/2018   DbMgrPartnerCommitPolicy::SetSyncState: 783CAF81-4  11057
10/3/2018   Always On Availability Groups connection with seco  10080

Kami juga sesekali melihat pesan "aneh" seperti:

Basis data grup ketersediaan "DB" mengubah peran dari "SECONDARY" menjadi "SECONDARY" karena sesi mirroring atau grup ketersediaan gagal karena sinkronisasi peran. Ini hanya pesan informasi. Tidak diperlukan tindakan pengguna.

... di antara sejumlah negara yang berubah dari "SECONDARY" menjadi "RESOLVING".

Setelah kegagalan manual, sistem dapat berjalan selama beberapa hari tanpa satu pesan dari jenis ini, dan tiba-tiba, tanpa alasan yang jelas, kita akan mendapatkan ribuan sekaligus, yang pada gilirannya menyebabkan server menjadi tidak responsif, dan menyebabkan aplikasi batas waktu koneksi. Ini adalah bug penting karena beberapa aplikasi mereka tidak memasukkan mekanisme coba lagi, dan karenanya dapat kehilangan data. Ketika ledakan kesalahan seperti itu terjadi, jenis menunggu berikut ini roket. Ini menunjukkan menunggu tepat setelah AG tampaknya kehilangan koneksi ke semua database sekaligus:

Sekitar 30 detik kemudian, semuanya kembali normal dalam hal menunggu, tetapi pesan AG terus membanjiri log kesalahan pada berbagai tingkat dan selama waktu yang berbeda dalam sehari, tampaknya waktu acak termasuk di luar jam sibuk. Peningkatan beban kerja yang terjadi secara bersamaan selama kesalahan ini tentu saja memperburuk keadaan. Jika hanya beberapa basis data yang terputus, biasanya tidak menyebabkan koneksi ke waktu habis karena diselesaikan dengan cepat sendiri.

Kami mencoba memverifikasi bahwa memang CU9 yang memulai masalah, tetapi kami dapat menurunkan versi kedua node hanya menjadi CU9. Upaya untuk menurunkan versi salah satu node ke CU8, mengakibatkan simpul tersebut terjebak dalam status 'Menyelesaikan' yang menunjukkan kesalahan yang sama di log:

Tidak dapat membaca konfigurasi yang ada dari grup Ketersediaan Selalu Di dengan ID sumber daya yang sesuai… Konfigurasi tetap ditulis oleh SQL Server versi yang lebih tinggi yang menampung replika ketersediaan utama. Upgrade contoh SQL Server lokal untuk memungkinkan replika ketersediaan lokal menjadi replika sekunder.

Ini berarti kami harus memperkenalkan down time untuk dapat menurunkan versi kedua node ke CU8 secara bersamaan. Ini juga menunjukkan ada beberapa pembaruan besar untuk AG yang mungkin menjelaskan apa yang kita alami.

Kami sudah mencoba menyesuaikan max_worker_threads dari defaultnya 0 (= 960 pada kotak kami berdasarkan artikel ini ) secara bertahap hingga 2.000 tanpa dampak yang diamati pada kesalahan.

Apa yang bisa kita lakukan untuk mengatasi terputusnya AG ini? Adakah orang di luar sana yang mengalami masalah serupa? Bisakah orang lain dengan sejumlah besar database di AG mungkin melihat pesan serupa di log kesalahan SQL dimulai dengan CU9 atau CU8?

Terima kasih sebelumnya atas bantuannya!

Memperbarui:

1. Pemutusan Kelompok Ketersediaan yang Sering dikonfirmasi sebagai regresi yang diperkenalkan oleh CU9 dan diselesaikan setelah menginstal CU12.

2. Masalah pemblokiran pada replika sekunder dikonfirmasi sebagai masalah dengan pembaruan kode penulis VSS yang diperkenalkan di CU10. Mudah-mudahan itu akan diatasi dalam CU 13. Solusi sementara adalah untuk secara manual mengganti penulis VSS DLL dengan DLL Pra-CU10 ...

   BEGIN RANT-SACTION;

   Sayangnya, Microsoft tampaknya berulang kali gagal untuk QA dengan benar tidak hanya pembaruan Windows 10, tetapi juga perangkat lunak misi penting perusahaan seperti SQL Server.

   Saya lebih suka strategi paket layanan mereka sebelumnya, setidaknya mereka punya cukup waktu untuk mengujinya dengan benar sebelum menimbulkan krisis produksi dan kehilangan data kepada pelanggan mereka dengan rilis setengah-setengah pembaruan yang dipanggang secara ceroboh.

   COMMIT RANT-SACTION;

Apakah Anda memeriksa utas pekerja? Biasanya selalu menggunakan lebih banyak pekerja thread untuk bekerja dan pada dasarnya nilai default tidak cukup. Saya memiliki masalah yang sama dengan 600 database di selalu aktif, Jadi kami menambahkan lebih banyak utas pada instance paramater dan itu memperbaiki masalah kami. Semoga ini membantu!