Bagikan melalui

Masalah umum platform Kluster Big Data SQL Server 2019

  • Artikel

Berlaku untuk: SQL Server 2019 (15.x)

Penting

Add-on Kluster Big Data Microsoft SQL Server 2019 akan dihentikan. Dukungan untuk SQL Server 2019 Kluster Big Data akan berakhir pada 28 Februari 2025. Semua pengguna SQL Server 2019 yang ada dengan Jaminan Perangkat Lunak akan didukung sepenuhnya pada platform dan perangkat lunak akan terus dipertahankan melalui pembaruan kumulatif SQL Server hingga saat itu. Untuk informasi selengkapnya, lihat posting blog pengumuman dan Opsi big data di platform Microsoft SQL Server.

Masalah umum

Salinan HDFS file besar menggunakan azdata dengan kegagalan acak

  • Rilis yang terpengaruh: CU14

  • Masalah dan efek pelanggan: Ini adalah bug yang menyebabkan kegagalan acak pada azdata bdc cp perintah antara jalur HDFS. Bug lebih sering memengaruhi salinan file yang lebih besar.

  • Solusi: Perbarui ke Pembaruan Kumulatif 15 (CU15).

Keamanan Log4j

  • Rilis yang terpengaruh: Tidak ada

  • Masalah dan efek pelanggan: Setelah penilaian menyeluruh dari basis kode SQL Server 2019 Kluster Big Data, tidak ada risiko yang terkait dengan kerentanan log4j yang dilaporkan pada bulan Desember diidentifikasi. CU15 menyertakan versi log4j (2.17) yang diperbarui untuk instans ElasticSearch di sarana kontrol untuk memastikan bahwa pemberitahuan pemindaian gambar tidak dipicu oleh analisis kode statis kontainer Kluster Big Data.

  • Solusi: Selalu perbarui kluster big data Anda ke rilis terbaru.

Peningkatan kluster dari CU8 dan rilis sebelumnya ke rilis pasca-CU9 tidak didukung

  • Rilis yang terpengaruh: Merilis CU8 dan sebelumnya

  • Masalah dan efek pelanggan: Saat langsung meningkatkan kluster pada rilis CU8 atau sebelumnya ke rilis apa pun di atas CU9, peningkatan gagal dari Fase Pemantauan.

  • Solusi: Tingkatkan ke CU9 terlebih dahulu. Kemudian tingkatkan dari CU9 ke rilis terbaru.

Platform Kubernetes dengan API Kubernetes versi 1.21+

  • Rilis yang terpengaruh: Semua rilis

  • Masalah dan efek pelanggan: Kubernetes API 1.21 atau lebih unggul bukan konfigurasi SQL Server yang diuji Kluster Big Data pada CU12.

Paket MicrosoftML di SQL Server Pembelajaran Mesin Services

  • Rilis yang terpengaruh: CU10, CU11, CU12, dan CU13

  • Masalah dan efek pelanggan: Beberapa paket MicrosoftML R/Python di SQL Server Pembelajaran Mesin Services tidak berfungsi. Ini mempengaruhi semua instans master SQL Server.

Gagal tersambung ke instans jarak jauh SQL Server 2016 atau yang lebih lama

  • Rilis yang terpengaruh: CU10
  • Masalah dan efek pelanggan: Saat menggunakan PolyBase di SQL Server 2019 Kluster Big Data CU10 untuk menyambungkan ke instans SQL Server yang ada yang menggunakan sertifikat untuk enkripsi saluran yang dibuat menggunakan algoritma SHA1, Anda mungkin mengamati kesalahan berikut:

Msg 105082, Level 16, State 1, Line 1 105082;Generic ODBC error: [Microsoft][ODBC Driver 17 for SQL Server]SSL Provider: An existing connection was forcibly closed by the remote host. Additional error <2>: ErrorMsg: [Microsoft][ODBC Driver 17 for SQL Server]Client unable to establish connection, SqlState: 08001, NativeError: 10054 Additional error <3>: ErrorMsg: [Microsoft][ODBC Driver 17 for SQL Server] Invalid connection string attribute, SqlState: 01S00, NativeError: 0 .

  • Solusi: Karena persyaratan keamanan Ubuntu 20.04 yang lebih tinggi dari versi gambar dasar sebelumnya, koneksi jarak jauh tidak diizinkan untuk sertifikat menggunakan algoritma SHA1. Sertifikat default yang ditandatangani sendiri dari rilis SQL Server 2005-2016 menggunakan algoritma SHA1. Untuk informasi selengkapnya tentang perubahan ini, lihat perubahan yang dilakukan pada sertifikat yang ditandatangani sendiri di SQL Server 2017. Dalam instans SQL Server jarak jauh, gunakan sertifikat yang dibuat dengan algoritma yang menggunakan setidaknya 112 bit keamanan (misalnya, SHA256). Untuk lingkungan produksi, disarankan untuk mendapatkan sertifikat tepercaya dari Otoritas Sertifikat. Untuk tujuan pengujian, sertifikat yang ditandatangani sendiri juga dapat digunakan. Untuk membuat sertifikat yang ditandatangani sendiri, lihat perintah PowerShell Cmdlet New-SelfSignedCertificate atau certreq. Untuk petunjuk menginstal sertifikat baru pada instans SQL Server jarak jauh, lihat Mengaktifkan koneksi terenkripsi ke Mesin Database

Hilangnya sebagian log yang dikumpulkan di ElasticSearch saat pemutaran kembali

  • Rilis yang terpengaruh: Memengaruhi kluster yang ada, ketika peningkatan yang gagal ke CU9 menghasilkan pembatalan atau pengguna mengeluarkan penurunan tingkat ke rilis yang lebih lama.

  • Masalah dan efek pelanggan: Versi perangkat lunak yang digunakan untuk Elastic Search ditingkatkan dengan CU9 dan versi baru tidak kompatibel mundur dengan format/metadata log sebelumnya. Jika komponen ElasticSearch berhasil ditingkatkan, tetapi pembatalan kemudian dipicu, log yang dikumpulkan antara peningkatan ElasticSearch dan pembatalan hilang secara permanen. Jika Anda mengeluarkan penurunan tingkat ke versi SQL Server 2019 yang lebih lama Kluster Big Data (tidak disarankan), log yang disimpan di Elasticsearch akan hilang. Jika Anda meningkatkan kembali ke CU9, data akan dipulihkan.

  • Penanganan masalah: Jika diperlukan, Anda dapat memecahkan masalah menggunakan log yang dikumpulkan menggunakan azdata bdc debug copy-logs perintah.

Pod dan metrik kontainer yang hilang

  • Rilis yang terpengaruh: Kluster yang ada dan baru setelah peningkatan ke CU9

  • Masalah dan efek pelanggan: Sebagai hasil dari peningkatan versi Telegraf yang digunakan untuk memantau komponen di CU9, saat meningkatkan kluster ke rilis CU9, Anda akan melihat bahwa pod dan metrik kontainer tidak dikumpulkan. Ini karena sumber daya tambahan diperlukan dalam definisi peran kluster yang digunakan untuk Telegraf sebagai hasil dari peningkatan perangkat lunak. Jika pengguna yang menyebarkan kluster atau melakukan peningkatan tidak memiliki izin yang memadai, penyebaran/peningkatan berlanjut dengan peringatan dan berhasil, tetapi metrik pod & node tidak akan dikumpulkan.

  • Solusi sementara: Anda dapat meminta administrator untuk membuat atau memperbarui peran dan akun layanan yang sesuai (baik sebelum atau sesudah penyebaran/peningkatan), dan kluster big data akan menggunakannya. Artikel ini menjelaskan cara membuat artefak yang diperlukan.

Mengeluarkan azdata bdc copy-logs tidak mengakibatkan log disalin

  • Rilis yang terpengaruh: Azure Data CLI (azdata) versi 20.0.0

  • Masalah dan efek pelanggan: Implementasi perintah copy-logs dengan asumsi kubectl alat klien versi 1.15 atau yang lebih tinggi diinstal pada komputer klien tempat perintah dikeluarkan. Jika kubectl versi 1.14 digunakan, azdata bdc debug copy-logs perintah selesai tanpa kegagalan, tetapi log tidak disalin. Saat dijalankan dengan --debug bendera, Anda dapat melihat kesalahan ini dalam output: sumber '.' tidak valid.

  • Solusi sementara: Instal kubectl alat versi 1.15 atau yang lebih tinggi pada komputer klien yang sama dan terisi azdata bdc copy-logs ulang perintah. Lihat instruksi di sini cara menginstal kubectl.

Kemampuan MSDTC tidak dapat diaktifkan untuk instans master SQL Server

  • Rilis yang terpengaruh: Semua konfigurasi penyebaran kluster big data, terlepas dari rilis.

  • Masalah dan efek pelanggan: Dengan SQL Server yang disebarkan dalam kluster big data sebagai instans master SQL Server, fitur MSDTC tidak dapat diaktifkan. Tidak ada solusi untuk masalah ini.

Rotasi enkripsi kunci Enkripsi Database HA SQL Server

  • Rilis yang terpengaruh: Semua versi hingga CU8. Diselesaikan untuk CU9.

  • Masalah dan efek pelanggan: Dengan SQL Server yang disebarkan dengan HA, rotasi sertifikat untuk database terenkripsi gagal. Saat perintah berikut dijalankan pada kumpulan master, pesan kesalahan muncul:

    ALTER DATABASE ENCRYPTION KEY
ENCRYPTION BY SERVER
CERTIFICATE <NewCertificateName>;

    Tidak ada efek, perintah gagal, dan enkripsi database target dipertahankan menggunakan sertifikat sebelumnya.

Mengaktifkan dukungan Zona Enkripsi HDFS di CU8

  • Rilis yang terpengaruh: Skenario ini muncul saat meningkatkan secara khusus ke rilis CU8 dari CU6 atau sebelumnya. Ini tidak akan terjadi pada penyebaran baru CU8+ atau saat meningkatkan langsung ke CU9. RILIS CU10 atau superior tidak terpengaruh.

  • Masalah dan efek pelanggan: Dukungan Zona Enkripsi HDFS tidak diaktifkan secara default dalam skenario ini dan perlu dikonfigurasi menggunakan langkah-langkah yang disediakan dalam panduan konfigurasi.

Pekerjaan Livy kosong sebelum Anda menerapkan pembaruan kumulatif

  • Rilis yang terpengaruh: Semua versi hingga CU6. Diselesaikan untuk CU8.

  • Masalah dan efek pelanggan: Selama peningkatan, sparkhead mengembalikan kesalahan 404.

  • Solusi sementara: Sebelum meningkatkan kluster big data, pastikan bahwa tidak ada sesi Livy aktif atau pekerjaan batch. Ikuti instruksi di bawah Tingkatkan dari rilis yang didukung untuk menghindari hal ini.

    Jika Livy mengembalikan kesalahan 404 selama proses peningkatan, mulai ulang server Livy pada kedua sparkhead simpul. Contohnya:

    kubectl -n <clustername> exec -it sparkhead-0/sparkhead-1 -c hadoop-livy-sparkhistory -- exec supervisorctl restart livy

Kedaluwarsa kata sandi untuk akun layanan yang dihasilkan kluster big data

  • Rilis yang terpengaruh: Semua penyebaran kluster big data dengan integrasi Direktori Aktif, terlepas dari rilis

  • Masalah dan efek pelanggan: Selama penyebaran kluster big data, alur kerja menghasilkan sekumpulan akun layanan. Bergantung pada kebijakan kedaluwarsa kata sandi yang ditetapkan di Pengendali Domain, kata sandi untuk akun ini dapat kedaluwarsa (defaultnya adalah 42 hari). Saat ini, tidak ada mekanisme untuk memutar kredensial untuk semua akun di kluster big data, sehingga kluster menjadi tidak dapat dioperasikan setelah periode kedaluwarsa terpenuhi.

  • Solusi sementara: Perbarui kebijakan kedaluwarsa untuk akun layanan di kluster big data menjadi "Kata sandi tidak pernah kedaluwarsa" di Pengendali Domain. Untuk daftar lengkap akun ini, lihat Objek Direktori Aktif yang dibuat secara otomatis. Tindakan ini dapat dilakukan sebelum atau sesudah waktu kedaluwarsa. Dalam kasus terakhir, Active Directory mengaktifkan kembali kata sandi yang kedaluwarsa.

Kredensial untuk mengakses layanan melalui titik akhir gateway

  • Rilis yang terpengaruh: Kluster baru yang disebarkan dimulai dengan CU5.

  • Masalah dan efek pelanggan: Untuk kluster big data baru yang disebarkan menggunakan SQL Server Kluster Big Data CU5, nama pengguna gateway bukan root. Jika aplikasi yang digunakan untuk menyambungkan ke titik akhir gateway menggunakan kredensial yang salah, Anda akan melihat kesalahan autentikasi. Perubahan ini adalah hasil dari menjalankan aplikasi dalam kluster big data sebagai pengguna non-root (perilaku default baru yang dimulai dengan rilis SQL Server Kluster Big Data CU5, ketika Anda menyebarkan kluster big data baru menggunakan CU5, nama pengguna untuk titik akhir gateway didasarkan pada nilai yang diteruskan melalui AZDATA_USERNAME variabel lingkungan. Ini adalah nama pengguna yang sama yang digunakan untuk pengontrol dan titik akhir SQL Server. Ini hanya memengaruhi penyebaran baru. Kluster big data yang ada yang disebarkan dengan salah satu rilis sebelumnya terus menggunakan root. Tidak ada efek pada kredensial ketika kluster disebarkan untuk menggunakan autentikasi Direktori Aktif.

  • Solusi sementara: Azure Data Studio menangani perubahan kredensial secara transparan agar koneksi yang dibuat ke gateway untuk mengaktifkan pengalaman penjelajahan HDFS di Object Explorer. Anda harus menginstal rilis Azure Data Studio terbaru yang menyertakan perubahan yang diperlukan yang menangani kasus penggunaan ini. Untuk skenario lain di mana Anda harus memberikan kredensial untuk mengakses layanan melalui gateway (misalnya, masuk dengan Azure Data CLI (azdata), mengakses dasbor web untuk Spark), Anda harus memastikan kredensial yang benar digunakan. Jika Anda menargetkan kluster yang ada yang disebarkan sebelum CU5, Anda akan terus menggunakan root nama pengguna untuk terhubung ke gateway, bahkan setelah meningkatkan kluster ke CU5. Jika Anda menyebarkan kluster baru menggunakan build CU5, masuk dengan memberikan nama pengguna yang AZDATA_USERNAME sesuai dengan variabel lingkungan.

Metrik pod dan simpul tidak dikumpulkan

  • Rilis yang terpengaruh: Kluster baru dan yang sudah ada yang menggunakan gambar CU5

  • Masalah dan efek pelanggan: Sebagai hasil dari perbaikan keamanan yang terkait dengan API yang telegraf digunakan untuk mengumpulkan metrik pod metrik dan metrik node host, pelanggan mungkin melihat bahwa metrik tidak dikumpulkan. Ini dimungkinkan dalam penyebaran SQL Server 2019 baru dan yang sudah ada Kluster Big Data (setelah peningkatan ke CU5). Sebagai hasil dari perbaikan, Telegraf sekarang memerlukan akun layanan dengan izin peran di seluruh kluster. Penyebaran mencoba membuat akun layanan dan peran kluster yang diperlukan, tetapi jika pengguna yang menyebarkan kluster atau melakukan peningkatan tidak memiliki izin yang memadai, penyebaran/peningkatan berlanjut dengan peringatan dan berhasil, tetapi metrik pod dan simpul tidak akan dikumpulkan.

  • Solusi sementara: Anda dapat meminta administrator untuk membuat peran dan akun layanan (baik sebelum atau sesudah penyebaran/peningkatan), dan kluster big data akan menggunakannya. Artikel ini menjelaskan cara membuat artefak yang diperlukan.

kegagalan perintah azdata bdc copy-logs

  • Rilis yang terpengaruh: Azure Data CLI (azdata) versi 20.0.0

  • Masalah dan efek pelanggan: Implementasi perintah copy-logs dengan asumsi kubectl alat klien diinstal pada komputer klien tempat perintah dikeluarkan. Jika Anda mengeluarkan perintah terhadap kluster big data yang diinstal di OpenShift, dari klien tempat hanya oc alat yang diinstal, Anda akan mendapatkan kesalahan: An error occurred while collecting the logs: [WinError 2] The system cannot find the file specified.

  • Solusi sementara: Instal kubectl alat pada komputer klien yang sama dan terisi azdata bdc copy-logs ulang perintah. Lihat instruksi di sini cara menginstal kubectl.

Penyebaran dengan repositori privat

  • Rilis yang terpengaruh: GDR1, CU1, CU2. Diselesaikan untuk CU3.

  • Masalah dan efek pelanggan: Peningkatan dari repositori privat memiliki persyaratan khusus

  • Solusi sementara: Jika Anda menggunakan repositori privat untuk melakukan pra-tarik gambar untuk menyebarkan atau meningkatkan kluster big data, pastikan bahwa gambar build saat ini, dan gambar build target, berada di repositori privat. Ini memungkinkan pemutaran kembali yang berhasil, jika perlu. Selain itu, jika Anda mengubah kredensial repositori privat sejak penyebaran asli, perbarui rahasia yang sesuai di Kubernetes sebelum Anda meningkatkan. Azure Data CLI (azdata) tidak mendukung pembaruan kredensial melalui AZDATA_PASSWORD variabel lingkungan dan AZDATA_USERNAME . Perbarui rahasia menggunakan kubectl edit secrets.

Peningkatan menggunakan repositori yang berbeda untuk build saat ini dan target tidak didukung.

Peningkatan mungkin gagal karena waktu habis

  • Rilis yang terpengaruh: GDR1, CU1, CU2. Diselesaikan untuk CU 3.

  • Masalah dan efek pelanggan: Peningkatan mungkin gagal karena waktu habis.

    Kode berikut menunjukkan seperti apa kegagalannya:

    > azdata.EXE bdc upgrade --name <mssql-cluster>
Upgrading cluster to version 15.0.4003

NOTE: Cluster upgrade can take a significant amount of time depending on
configuration, network speed, and the number of nodes in the cluster.

Upgrading Control Plane.
Control plane upgrade failed. Failed to upgrade controller.

    Kesalahan ini lebih mungkin terjadi ketika Anda meningkatkan SQL Server 2019 Kluster Big Data di Azure Kubernetes Service (AKS).

  • Solusi sementara: Tingkatkan batas waktu untuk peningkatan.

    Untuk meningkatkan batas waktu peningkatan, edit peta konfigurasi peningkatan. Untuk mengedit peta konfigurasi peningkatan:

    1. Jalankan perintah berikut:

      kubectl edit configmap controller-upgrade-configmap

    2. Edit bidang berikut:

      controllerUpgradeTimeoutInMinutes Menunjuk jumlah menit untuk menunggu pengontrol atau pengontrol db selesai meningkatkan. Defaultnya adalah 5. Perbarui ke setidaknya 20.

      totalUpgradeTimeoutInMinutes: Menunjuk jumlah waktu gabungan untuk pengontrol dan pengontrol db untuk menyelesaikan peningkatan (controller + controllerdb peningkatan). Default-nya adalah 10. Perbarui ke setidaknya 40.

      componentUpgradeTimeoutInMinutes: Menunjuk jumlah waktu yang harus diselesaikan setiap fase peningkatan berikutnya. Defaultnya adalah 30. Perbarui ke 45.

    3. Simpan dan keluar.

    Skrip python berikut adalah cara lain untuk mengatur batas waktu:

    from kubernetes import client, config
import json

def set_upgrade_timeouts(namespace, controller_timeout=20, controller_total_timeout=40, component_timeout=45):
     """ Set the timeouts for upgrades

     The timeout settings are as follows

     controllerUpgradeTimeoutInMinutes: sets the max amount of time for the controller
         or controllerdb to finish upgrading

     totalUpgradeTimeoutInMinutes: sets the max amount of time to wait for both the
         controller and controllerdb to complete their upgrade

     componentUpgradeTimeoutInMinutes: sets the max amount of time allowed for
         subsequent phases of the upgrade to complete
     """
     config.load_kube_config()

     upgrade_config_map = client.CoreV1Api().read_namespaced_config_map("controller-upgrade-configmap", namespace)

     upgrade_config = json.loads(upgrade_config_map.data["controller-upgrade"])

     upgrade_config["controllerUpgradeTimeoutInMinutes"] = controller_timeout

     upgrade_config["totalUpgradeTimeoutInMinutes"] = controller_total_timeout

     upgrade_config["componentUpgradeTimeoutInMinutes"] = component_timeout

     upgrade_config_map.data["controller-upgrade"] = json.dumps(upgrade_config)

     client.CoreV1Api().patch_namespaced_config_map("controller-upgrade-configmap", namespace, upgrade_config_map)

Pengiriman pekerjaan Livy dari Azure Data Studio (ADS) atau curl gagal dengan kesalahan 500

  • Masalah dan efek pelanggan: Dalam konfigurasi KETERSEDIAAN TINGGI, sumber daya sparkhead bersama Spark dikonfigurasi dengan beberapa replika. Dalam hal ini, Anda mungkin mengalami kegagalan dengan pengiriman pekerjaan Livy dari Azure Data Studio (ADS) atau curl. Untuk memverifikasi, curl ke pod apa pun sparkhead menghasilkan koneksi yang ditolak. Misalnya, curl https://sparkhead-0:8998/ atau curl https://sparkhead-1:8998 mengembalikan kesalahan 500.

    Ini terjadi dalam skenario berikut:

    • Pod Zookeeper, atau proses untuk setiap instans zookeeper, dimulai ulang beberapa kali.
    • Ketika konektivitas jaringan tidak dapat diandalkan antara sparkhead pod dan pod Zookeeper.

  • Solusi sementara: Memulai ulang kedua server Livy.

    kubectl -n <clustername> exec sparkhead-0 -c hadoop-livy-sparkhistory supervisorctl restart livy

    kubectl -n <clustername> exec sparkhead-1 -c hadoop-livy-sparkhistory supervisorctl restart livy

Membuat tabel yang dioptimalkan memori saat instans master dalam grup ketersediaan

  • Masalah dan efek pelanggan: Anda tidak dapat menggunakan titik akhir utama yang diekspos untuk menyambungkan ke database grup ketersediaan (listener) untuk membuat tabel yang dioptimalkan memori.

  • Solusi sementara: Untuk membuat tabel yang dioptimalkan memori saat instans master SQL Server adalah konfigurasi grup ketersediaan, sambungkan ke instans SQL Server, ekspos titik akhir, sambungkan ke database SQL Server, dan buat tabel memori yang dioptimalkan dalam sesi yang dibuat dengan koneksi baru.

Sisipkan ke tabel eksternal mode autentikasi Direktori Aktif

  • Masalah dan efek pelanggan: Saat instans master SQL Server berada dalam mode autentikasi Direktori Aktif, kueri yang hanya memilih dari tabel eksternal, di mana setidaknya salah satu tabel eksternal berada di kumpulan penyimpanan, dan dimasukkan ke tabel eksternal lain, kueri mengembalikan:

Msg 7320, Level 16, State 102, Line 1 Cannot execute the query "Remote Query" against OLE DB provider "SQLNCLI11" for linked server "SQLNCLI11". Only domain logins can be used to query Kerberized storage pool.

  • Solusi sementara: Ubah kueri dengan salah satu cara berikut. Gabungkan tabel kumpulan penyimpanan ke tabel lokal, atau sisipkan ke tabel lokal terlebih dahulu, lalu baca dari tabel lokal untuk menyisipkan ke dalam kumpulan data.

Kemampuan Enkripsi Data Transparan tidak dapat digunakan dengan database yang merupakan bagian dari grup ketersediaan dalam instans master SQL Server

  • Masalah dan efek pelanggan: Dalam konfigurasi HA, database yang mengaktifkan enkripsi tidak dapat digunakan setelah failover karena kunci master yang digunakan untuk enkripsi berbeda pada setiap replika.

  • Solusi sementara: Tidak ada solusi untuk masalah ini. Kami menyarankan untuk tidak mengaktifkan enkripsi dalam konfigurasi ini hingga perbaikan diberlakukan.

Konten terkait

Untuk informasi selengkapnya tentang Kluster Big Data SQL Server 2019, lihat Memperkenalkan Kluster Big Data SQL Server.