SQL Server 2019 빅 데이터 클러스터 플랫폼의 알려진 문제

아티클
04/01/2024

적용 대상: SQL Server 2019(15.x)

중요

Microsoft SQL Server 2019 빅 데이터 클러스터 추가 기능이 사용 중지됩니다. SQL Server 2019 빅 데이터 클러스터에 대한 지원은 2025년 2월 28일에 종료됩니다. Software Assurance를 사용하는 SQL Server 2019의 모든 기존 사용자는 플랫폼에서 완전히 지원되며, 소프트웨어는 지원 종료 시점까지 SQL Server 누적 업데이트를 통해 계속 유지 관리됩니다. 자세한 내용은 공지 블로그 게시물 및 Microsoft SQL Server 플랫폼의 빅 데이터 옵션을 참조하세요.

알려진 문제

임의 오류가 있는 azdata를 사용하는 대용량 파일의 HDFS 복사본

영향을 받는 릴리스: CU14
문제 및 고객 효과: HDFS 경로 간의 azdata bdc cp 명령에 대해 임의 오류가 발생하는 버그였습니다. 이 버그는 더 큰 파일 복사본에 더 자주 영향을 줍니다.
해결 방법: 누적 업데이트 15(CU15)로 업데이트합니다.

Log4j 보안

영향을 받는 릴리스: 없음
문제 및 고객 효과: SQL Server 2019 빅 데이터 클러스터 코드베이스를 철저히 평가한 후 12월에 보고된 log4j 취약성과 관련된 위험이 확인되지 않았습니다. CU15에는 빅 데이터 클러스터 컨테이너의 정적 코드 분석에 의해 이미지 검사 경고가 트리거되지 않도록 컨트롤 플레인의 ElasticSearch 인스턴스에 대한 log4j(2.17) 업데이트된 버전이 포함되어 있습니다.
해결 방법: 항상 빅 데이터 클러스터를 최신 릴리스로 업데이트합니다.

CU8 및 이전 릴리스에서 CU9 이후 릴리스로 클러스터를 업그레이드할 수 없음

영향을 받는 릴리스: CU8 및 이전 릴리스
문제 및 고객에게 미치는 영향: CU8 또는 이전 릴리스의 클러스터를 CU9 이후 릴리스로 직접 업그레이드하는 경우 모니터링 단계에서 업그레이드가 실패합니다.
해결 방법: 먼저 CU9로 업그레이드합니다. 그런 다음, CU9에서 최신 릴리스로 업그레이드합니다.

Kubernetes API 버전 1.21 이상을 사용하는 Kubernetes 플랫폼

영향을 받는 릴리스: 모든 릴리스
이슈 및 고객에게 미치는 영향: Kubernetes API 1.21 또는 상위 버전은 SQL Server 빅 데이터 클러스터 CU12의 테스트된 구성이 아닙니다.

SQL Server Machine Learning Services의 MicrosoftML 패키지

영향을 받는 릴리스: CU10, CU11, CU12 및 CU13
문제 및 고객에게 미치는 영향: SQL Server Machine Learning Services의 일부 MicrosoftML R/Python 패키지가 작동하지 않습니다. 모든 SQL Server 마스터 인스턴스에 영향을 줍니다.

SQL Server 2016 및 이전 버전의 원격 인스턴스에 연결할 수 없음

영향을 받는 릴리스: CU10
이슈 및 고객에게 미치는 영향: SQL Server 2019 빅 데이터 클러스터 CU10의 PolyBase를 사용하여, SHA1 알고리즘을 사용하여 만든 채널 암호화를 위해 인증서를 사용하는 기존 SQL Server 인스턴스에 연결하는 경우, 다음과 같은 오류가 발생할 수 있습니다.

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 .

해결 방법: 이전 기본 이미지 버전보다 Ubuntu 20.04의 보안 요구 사항이 더 엄격하기 때문에 SHA1 알고리즘을 사용하는 인증서의 경우 원격 연결이 허용되지 않습니다. SQL Server 릴리스 2005~2016의 기본 자체 서명된 인증서는 SHA1 알고리즘을 사용했습니다. 이 변경에 대한 자세한 내용은 SQL Server 2017의 자체 서명된 인증서에 적용된 변경 내용을 참조하세요. 원격 SQL Server 인스턴스에서, 최소 112비트 보안을 사용하는 알고리즘(예: SHA256)으로 만든 인증서를 사용하세요. 프로덕션 환경에서는 신뢰할 수 있는 인증서를 인증 기관에서 발급받는 것이 좋습니다. 테스트 목적으로 자체 서명된 인증서를 사용할 수도 있습니다. 자체 서명된 인증서를 만들려면 PowerShell Cmdlet New-SelfSignedCertificate 또는 certreq 명령을 참조하세요. 원격 SQL Server 인스턴스에 새 인증서를 설치하는 방법은 Enable encrypted connections to the Database Engine(데이터베이스 엔진에 대한 암호화된 연결 사용 설정)을 참조하세요.

롤백 시 ElasticSearch에 수집된 로그의 일부가 손실됨

영향을 받는 릴리스: CU9으로 업그레이드하지 못하여 롤백이 발생하거나 사용자가 이전 릴리스로 다운그레이드하는 경우 기존 클러스터에 영향을 줍니다.
이슈 및 고객에게 미치는 영향: ElasticSearch에 사용되는 소프트웨어 버전이 CU9으로 업그레이드되었지만 새 버전이 이전 로그 형식/메타데이터와 호환되지 않습니다. ElasticSearch 구성 요소를 성공적으로 업그레이드하더라도 이후 롤백이 트리거되면 ElasticSearch 업그레이드와 롤백 사이에 수집된 로그가 영구적으로 손실됩니다. 이전 버전의 SQL Server 2019 빅 데이터 클러스터로 다운그레이드를 실행하는 경우(권장하지 않음) ElasticSearch에 저장된 로그가 손실됩니다. 다시 CU9로 업그레이드하면 데이터가 복원됩니다.
해결 방법: 필요한 경우 azdata bdc debug copy-logs 명령을 통해 수집된 로그를 사용하여 문제를 해결할 수 있습니다.

누락된 Pod 및 컨테이너 메트릭

영향을 받는 릴리스: CU9으로 업그레이드 시 기존 클러스터와 새 클러스터에 영향
문제 및 고객에게 미치는 영향: CU9에서 모니터링 구성 요소에 사용되는 Telegraf 버전을 업그레이드할 경우 클러스터를 CU9 릴리스로 업그레이드하면 Pod 및 컨테이너 메트릭이 수집되지 않습니다. 소프트웨어 업그레이드의 결과로 Telegraf에 사용되는 클러스터 역할의 정의에 추가 리소스가 필요하기 때문입니다. 클러스터를 배포하거나 업그레이드를 수행하는 사용자에게 충분한 권한이 없는 경우에는 경고와 함께 배포/업그레이드가 진행되고 작업이 성공하지만 Pod 및 노드 메트릭은 수집되지 않습니다.
해결 방법: 배포/업그레이드 전에 또는 후에 관리자에게 역할 및 해당 서비스 계정을 만들거나 업그레이드해 달라고 요청하면 됩니다. 그러면 빅 데이터 클러스터가 이 역할 및 서비스 계정을 사용합니다. 이 문서에서는 필요한 아티팩트를 만드는 방법을 설명합니다.

azdata bdc copy-logs를 실행해도 로그가 복사되지 않음

영향을 받는 릴리스: Azure Data CLI(azdata) 버전 20.0.0
이슈 및 고객에게 미치는 영향: copy-logs 명령의 구현은 명령이 실행되는 클라이언트 머신에 kubectl 클라이언트 도구 버전 1.15 이상이 설치되어 있다고 가정합니다. kubectl 버전 1.14를 사용하는 경우 azdata bdc debug copy-logs 명령이 실패 없이 완료되지만 로그는 복사되지 않습니다. --debug 플래그를 사용하여 실행하는 경우 출력에 source '.' is invalid 오류가 표시됩니다.
해결 방법: 동일한 클라이언트 머신에 kubectl 버전 1.15 이상 도구를 설치하고 azdata bdc copy-logs 명령을 다시 실행합니다. kubectl을 설치하는 방법에 대한 지침은 여기를 참조하세요.

SQL Server 마스터 인스턴스에서 MSDTC 기능을 사용하도록 설정할 수 없습니다.

영향을 받는 릴리스: 릴리스에 관계없이 모든 빅 데이터 클러스터 배포 구성입니다.
이슈 및 고객에게 미치는 영향: 빅 데이터 클러스터 내에 SQL Server 마스터 인스턴스로 배포된 SQL Server에서는 MSDTC 기능을 활성화할 수 없습니다. 이 문제를 해결하는 방법은 없습니다.

HA SQL Server 데이터베이스 암호화 키 암호기 회전

영향을 받는 릴리스: CU8까지 모든 버전입니다. CU9에서 문제가 해결되었습니다.
이슈 및 고객에게 미치는 영향: HA를 사용하여 배포된 SQL Server에서는 암호화된 데이터베이스에 대한 인증서 회전이 실패합니다. 마스터 풀에서 다음 명령을 실행하면 오류 메시지가 표시됩니다.
```
ALTER DATABASE ENCRYPTION KEY
ENCRYPTION BY SERVER
CERTIFICATE <NewCertificateName>;
```
영향은 전혀 없으며 명령이 실패하고 대상 데이터베이스 암호화는 이전 인증서를 사용하여 유지됩니다.

CU8에서 HDFS 암호화 영역 지원 사용 설정

영향을 받는 릴리스: 특히 CU6 이하에서 CU8로 업그레이드하는 경우 이 시나리오가 나타납니다. CU8 이상의 새 배포에서 또는 CU9로 직접 업그레이드하는 경우에는 이 문제가 발생하지 않습니다. CU10 또는 상위 릴리스는 영향을 받지 않습니다.
이슈 및 고객에게 미치는 영향: HDFS 암호화 영역 지원은 이 시나리오에서 기본적으로 사용할 수 없으며 구성 가이드에 제공된 단계에 따라 구성해야 합니다.

누적 업데이트를 적용하기 전의 빈 Livy 작업

영향을 받는 릴리스: CU6까지의 모든 버전. CU8에서 문제가 해결되었습니다.
이슈 및 고객에게 미치는 영향: 업그레이드하는 동안 sparkhead가 404 오류를 반환합니다.
해결 방법: 빅 데이터 클러스터를 업그레이드하기 전에 활성 Livy 세션 또는 일괄 처리 작업이 없는지 확인합니다. 이 문제를 방지하려면 지원되는 릴리스에서 업그레이드의 지침을 따르세요.

업그레이드 프로세스 중에 Livy에서 404 오류를 반환하는 경우 두 sparkhead 노드에서 모두 Livy 서버를 다시 시작합니다. 예를 들어:
```
kubectl -n <clustername> exec -it sparkhead-0/sparkhead-1 -c hadoop-livy-sparkhistory -- exec supervisorctl restart livy
```

빅 데이터 클러스터 생성 서비스 계정의 암호 만료

영향을 받는 릴리스: 릴리스에 관계없이 Active Directory 통합을 사용한 모든 빅 데이터 클러스터 배포
이슈 및 고객에게 미치는 영향: 빅 데이터 클러스터를 배포하는 동안 워크플로에서 서비스 계정 세트를 생성합니다. 도메인 컨트롤러에 설정된 암호 만료 정책에 따라 이 계정의 암호는 만료될 수 있습니다(기본값은 42일). 이때 빅 데이터 클러스터의 모든 계정에 대한 자격 증명을 회전하는 메커니즘이 없으므로 만료 기간이 경과하면 클러스터가 작동하지 않게 됩니다.
해결 방법: 도메인 컨트롤러에서 빅 데이터 클러스터의 서비스 계정 만료 정책을 “암호 사용 기간 제한 없음”으로 업데이트합니다. 이러한 계정의 전체 목록은 자동 생성 Active Directory 개체를 참조하세요. 이 작업은 만료 이전 또는 이후에 수행할 수 있습니다. 후자의 경우 만료된 암호를 Active Directory가 다시 활성화합니다.

게이트웨이 엔드포인트를 통해 서비스에 액세스하기 위한 자격 증명

영향을 받는 릴리스: CU5부터 새 클러스터가 배포됩니다.
이슈 및 고객에게 미치는 영향: SQL Server 빅 데이터 클러스터 CU5를 사용하여 배포된 새로운 빅 데이터 클러스터의 경우 게이트웨이 사용자 이름은 root가 아닙니다. 게이트웨이 엔드포인트에 연결하는 데 사용된 애플리케이션에서 잘못된 자격 증명을 사용하는 경우 인증 오류가 표시됩니다. 이런 변경은 루트가 아닌 사용자로 빅 데이터 클러스터 내에서 애플리케이션을 실행한 결과입니다(SQL Server 빅 데이터 클러스터 CU5 릴리스부터 새로운 기본 동작, CU5를 사용하여 새 빅 데이터 클러스터를 배포할 때 게이트웨이 엔드포인트의 사용자 이름은 AZDATA_USERNAME 환경 변수를 통해 전달된 값을 기반으로 함). 이때 사용자 이름은 컨트롤러 및 SQL Server 엔드포인트에 사용되는 것과 동일합니다. 이는 새 배포에만 영향을 줍니다. 이전 릴리스와 함께 배포된 기존 빅 데이터 클러스터는 root를 계속 사용합니다. Active Directory 인증을 사용하도록 클러스터를 배포하는 경우 자격 증명에는 영향이 없습니다.
해결 방법: Azure Data Studio는 게이트웨이 연결에 대해 자격 증명 변경을 투명하게 처리하여 개체 탐색기에서 HDFS 검색 환경을 사용하도록 설정합니다. 이 사용 사례를 처리하는 데 필요한 변경 내용이 포함된 최신 Azure Data Studio 릴리스를 설치해야 합니다. 게이트웨이를 통해 서비스에 액세스하기 위해 자격 증명을 제공해야 하는 다른 시나리오(예: Azure Data CLI(azdata)를 사용하여 로그인, Spark용 웹 대시보드 액세스)의 경우 올바른 자격 증명을 사용해야 합니다. CU5 이전에 배포된 기존 클러스터를 대상으로 하는 경우 클러스터를 CU5로 업그레이드한 후에도 계속 root 사용자 이름을 사용하여 게이트웨이에 연결합니다. CU5 빌드를 사용하여 새 클러스터를 배포하는 경우 AZDATA_USERNAME 환경 변수에 해당하는 사용자 이름을 제공하여 로그인합니다.

Pod 및 노드 메트릭이 수집되지 않음

영향을 받는 릴리스: CU5 이미지를 사용하는 새 클러스터 및 기존 클러스터
이슈 및 고객에게 미치는 영향: telegraf에서 메트릭 Pod 및 호스트 노드 메트릭을 수집하는 데 사용한 API와 관련된 보안 수정의 결과, 고객은 메트릭이 수집되지 않는 것을 경험했을 수도 있습니다. 이런 현상은 (CU5로 업그레이드한 후) SQL Server 2019 빅 데이터 클러스터의 새 배포와 기존 배포 모두에서 일어날 수 있습니다. 수정 결과로, 이제 Telegraf에서 클러스터 수준의 역할 권한이 있는 서비스 계정을 요구합니다. 배포에서 필요한 서비스 계정 및 클러스터 역할을 만들려고 시도하지만 클러스터를 배포하거나 업그레이드를 수행하는 사용자에게 충분한 권한이 없는 경우에는 배포/업그레이드가 진행되고 경고가 나타나며 성공하지만 Pod 및 노드 메트릭은 수집되지 않습니다.
해결 방법: 배포/업그레이드 전이나 후에 관리자에게 해당 역할 및 서비스 계정을 만들도록 요청하면 됩니다. 그러면 빅 데이터 클러스터가 이 역할 및 서비스 계정을 사용합니다. 이 문서에서는 필요한 아티팩트를 만드는 방법을 설명합니다.

azdata bdc copy-logs 명령 실패

영향을 받는 릴리스: Azure Data CLI(azdata) 버전 20.0.0
이슈 및 고객에게 미치는 영향: copy-logs 명령의 구현은 명령이 실행되는 클라이언트 머신에 kubectl 클라이언트 도구가 설치되어 있다고 가정합니다. oc 도구만 설치된 클라이언트에서 OpenShift에 설치된 빅 데이터 클러스터에 대해 명령을 실행하는 경우 An error occurred while collecting the logs: [WinError 2] The system cannot find the file specified 오류가 발생합니다.
해결 방법: 동일한 클라이언트 머신에 kubectl 도구를 설치하고 azdata bdc copy-logs 명령을 다시 실행합니다. kubectl을 설치하는 방법에 대한 지침은 여기를 참조하세요.

프라이빗 리포지토리를 사용하여 배포

영향을 받는 릴리스: GDR1, CU1, CU2. CU3에서 문제가 해결되었습니다.
이슈 및 고객에게 미치는 영향: 프라이빗 리포지토리에서 업그레이드하는 경우 특정 요구 사항이 있습니다.
해결 방법: 프라이빗 리포지토리를 사용하여 빅 데이터 클러스터를 배포하거나 업그레이드하기 위해 이미지를 미리 가져오는 경우 현재 빌드 이미지와 대상 빌드 이미지가 프라이빗 리포지토리에 있는지 확인합니다. 이렇게 하면 필요한 경우 성공적으로 롤백할 수 있습니다. 또한 원래 배포 이후 프라이빗 리포지토리의 자격 증명을 변경한 경우 업그레이드하기 전에 Kubernetes에서 해당 비밀을 업데이트합니다. Azure Data CLI(azdata)는 AZDATA_PASSWORD 및 AZDATA_USERNAME 환경 변수를 통한 자격 증명 업데이트를 지원하지 않습니다. kubectl edit secrets를 사용하여 암호를 업데이트합니다.

현재 및 대상 빌드에 다른 리포지토리를 사용하여 업그레이드할 수 없습니다.

시간 초과로 인해 업그레이드에 실패할 수 있음

영향을 받는 릴리스: GDR1, CU1, CU2. CU3에서 문제가 해결되었습니다.
이슈 및 고객에게 미치는 영향: 시간 제한으로 인해 업그레이드가 실패할 수 있습니다.

다음 코드는 오류가 어떻게 표시되는지 보여 줍니다.
```
> 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.
```
이 오류는 AKS(Azure Kubernetes Service)에서 SQL Server 2019 빅 데이터 클러스터를 업그레이드할 때 발생할 가능성이 높습니다.

해결 방법: 업그레이드 시간 제한을 늘립니다.

업그레이드에 대한 시간 제한을 늘리려면 업그레이드 구성 맵을 편집합니다. 업그레이드 구성 맵을 편집하려면 다음을 수행합니다.

다음 명령 실행:

kubectl edit configmap controller-upgrade-configmap

다음 필드를 편집합니다.

controllerUpgradeTimeoutInMinutes 컨트롤러 또는 컨트롤러 db의 업그레이드가 완료될 때까지 대기할 시간(분)을 지정합니다. 기본값은 5입니다. 20 이상으로 업데이트합니다.

totalUpgradeTimeoutInMinutes: 컨트롤러와 컨트롤러 db 모두가 업그레이드(controller + controllerdb 업그레이드)를 완료하는 데 걸리는 시간을 합한 값을 지정합니다. 기본값은 10입니다. 40 이상으로 업데이트합니다.

componentUpgradeTimeoutInMinutes : 업그레이드의 각 후속 단계를 완료해야 하는 기간을 지정합니다. 기본값은 30입니다. 45로 업데이트합니다.
저장한 후 종료합니다.

다음 Python 스크립트는 시간 제한을 설정하는 또 다른 방법입니다.

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)

ADS(Azure Data Studio) 또는 curl에서 Livy 작업 제출 시 500 오류가 발생하고 제출이 실패함

이슈 및 고객에게 미치는 영향: HA 구성에서는 Spark 공유 리소스 sparkhead가 여러 복제본으로 구성되어 있습니다. 이 경우 ADS(Azure Data Studio) 또는 curl에서 Livy 작업을 제출할 때 제출에 실패할 수 있습니다. 확인하려면 거부된 연결의 sparkhead pod 결과로 curl해 보세요. 예를 들어, curl https://sparkhead-0:8998/이나 curl https://sparkhead-1:8998은 500 오류를 반환합니다.

이 문제는 다음과 같은 경우에 발생합니다.
- Zookeeper pod 또는 각 Zookeeper 인스턴스의 프로세스가 몇 차례 다시 시작된 경우
- sparkhead pod과 Zookeeper pod 사이의 네트워크 연결이 불안정한 경우

해결 방법: 두 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

마스터 인스턴스가 가용성 그룹에 있을 때 메모리 최적화 테이블 만들기

문제 및 고객에게 미치는 영향: 가용성 그룹 데이터베이스(수신기) 연결을 위해 노출된 기본 엔드포인트를 사용하여 메모리 최적화 테이블을 만들 수 없습니다.
해결 방법: SQL Server 마스터 인스턴스가 가용성 그룹 구성일 때 메모리 최적화 테이블을 만들려면 SQL Server 인스턴스에 연결하고, 엔드포인트를 노출하고, SQL Server 데이터베이스에 연결한 다음, 새 연결로 만든 세션에서 메모리 최적화 테이블을 만듭니다.

Active Directory 인증 모드에서 외부 테이블에 삽입

이슈 및 고객에게 미치는 영향: SQL Server 마스터 인스턴스가 Active Directory 인증 모드에 있을 때, 외부 테이블 중 적어도 하나 이상이 스토리지 풀에 있는 외부 테이블에서만 선택하여 다른 외부 테이블에 삽입하는 쿼리는 다음을 반환합니다.

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.

해결 방법: 다음 방법을 사용하여 쿼리를 수정합니다. 스토리지 풀 테이블을 로컬 테이블에 조인하거나 먼저 로컬 테이블에 삽입한 다음 이 로컬 테이블에서 읽어서 데이터 풀에 삽입합니다.

SQL Server 마스터 인스턴스에서 가용성 그룹의 일부인 데이터베이스에는 투명한 데이터 암호화 기능을 사용할 수 없음

이슈 및 고객에게 미치는 영향: HA 구성에서는 암호화에 사용되는 마스터 키가 각 복제본마다 다르기 때문에 암호화가 사용된 데이터베이스는 장애 조치(failover) 후에 사용할 수 없습니다.
해결 방법: 이 문제를 해결하는 방법은 없습니다. 수정될 때까지 이 구성에서 암호화를 사용하지 않는 것이 좋습니다.

SQL Server 2019 빅 데이터 클러스터에 대한 자세한 내용은 SQL Server 빅 데이터 클러스터 소개를 참조하세요.

SQL Server 2019 빅 데이터 클러스터 플랫폼의 알려진 문제

알려진 문제

임의 오류가 있는 azdata를 사용하는 대용량 파일의 HDFS 복사본

Log4j 보안

CU8 및 이전 릴리스에서 CU9 이후 릴리스로 클러스터를 업그레이드할 수 없음

Kubernetes API 버전 1.21 이상을 사용하는 Kubernetes 플랫폼

SQL Server Machine Learning Services의 MicrosoftML 패키지

SQL Server 2016 및 이전 버전의 원격 인스턴스에 연결할 수 없음

롤백 시 ElasticSearch에 수집된 로그의 일부가 손실됨

누락된 Pod 및 컨테이너 메트릭

azdata bdc copy-logs를 실행해도 로그가 복사되지 않음

SQL Server 마스터 인스턴스에서 MSDTC 기능을 사용하도록 설정할 수 없습니다.

HA SQL Server 데이터베이스 암호화 키 암호기 회전

CU8에서 HDFS 암호화 영역 지원 사용 설정

누적 업데이트를 적용하기 전의 빈 Livy 작업

빅 데이터 클러스터 생성 서비스 계정의 암호 만료

게이트웨이 엔드포인트를 통해 서비스에 액세스하기 위한 자격 증명

Pod 및 노드 메트릭이 수집되지 않음

azdata bdc copy-logs 명령 실패

프라이빗 리포지토리를 사용하여 배포

시간 초과로 인해 업그레이드에 실패할 수 있음

ADS(Azure Data Studio) 또는 curl에서 Livy 작업 제출 시 500 오류가 발생하고 제출이 실패함

마스터 인스턴스가 가용성 그룹에 있을 때 메모리 최적화 테이블 만들기

Active Directory 인증 모드에서 외부 테이블에 삽입

SQL Server 마스터 인스턴스에서 가용성 그룹의 일부인 데이터베이스에는 투명한 데이터 암호화 기능을 사용할 수 없음

피드백

피드백

추가 리소스

SQL Server 2019 빅 데이터 클러스터 플랫폼의 알려진 문제

알려진 문제

임의 오류가 있는 azdata를 사용하는 대용량 파일의 HDFS 복사본

Log4j 보안

CU8 및 이전 릴리스에서 CU9 이후 릴리스로 클러스터를 업그레이드할 수 없음

Kubernetes API 버전 1.21 이상을 사용하는 Kubernetes 플랫폼

SQL Server Machine Learning Services의 MicrosoftML 패키지

SQL Server 2016 및 이전 버전의 원격 인스턴스에 연결할 수 없음

롤백 시 ElasticSearch에 수집된 로그의 일부가 손실됨

누락된 Pod 및 컨테이너 메트릭

azdata bdc copy-logs를 실행해도 로그가 복사되지 않음

SQL Server 마스터 인스턴스에서 MSDTC 기능을 사용하도록 설정할 수 없습니다.

HA SQL Server 데이터베이스 암호화 키 암호기 회전

CU8에서 HDFS 암호화 영역 지원 사용 설정

누적 업데이트를 적용하기 전의 빈 Livy 작업

빅 데이터 클러스터 생성 서비스 계정의 암호 만료

게이트웨이 엔드포인트를 통해 서비스에 액세스하기 위한 자격 증명

Pod 및 노드 메트릭이 수집되지 않음

azdata bdc copy-logs 명령 실패

프라이빗 리포지토리를 사용하여 배포

시간 초과로 인해 업그레이드에 실패할 수 있음

ADS(Azure Data Studio) 또는 curl에서 Livy 작업 제출 시 500 오류가 발생하고 제출이 실패함

마스터 인스턴스가 가용성 그룹에 있을 때 메모리 최적화 테이블 만들기

Active Directory 인증 모드에서 외부 테이블에 삽입

SQL Server 마스터 인스턴스에서 가용성 그룹의 일부인 데이터베이스에는 투명한 데이터 암호화 기능을 사용할 수 없음

관련 콘텐츠

피드백

피드백

추가 리소스