Skip to content

docs: explain Arc SQL MI configuration and platform differences - #598

Open
skiddder wants to merge 1 commit into
microsoft:mainfrom
skiddder:fix/challenge04-dashboard-password
Open

skiddder wants to merge 1 commit into
microsoft:mainfrom
skiddder:fix/challenge04-dashboard-password

Conversation

@skiddder

@skiddder skiddder commented Nov 2, 2026

Copy link
Copy Markdown
Contributor

Summary

  • Add an appendix to the Azure Arc-enabled Kubernetes Challenge 04 walkthrough explaining contained availability groups and server-scoped configuration.
  • Document instance-endpoint port forwarding, sp_configure examples, and Windows client notes.
  • Describe system database, storage, backup/restore, and TDE differences with Microsoft Learn references.

Validation

  • Documentation-only change; no infrastructure or executable code changed.
  • git diff --check passed.
  • Restored appendix verified against the original stashed content; upstream navigation links preserved.

Context

The original dashboard/template fix from this branch was already merged in #353. This branch has been rebased onto current upstream main; this PR contains only the new documentation appendix.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🟡 Changes recommended

Unresolved walkthrough errors can produce invalid SQL and failed recovery through incorrect BACPAC restore instructions, incomplete TDE key exports, and missing replica configuration and storage prerequisites.

5 open issues
What changed in this PR

Adds a documentation-only appendix to the Azure Arc-enabled Kubernetes Challenge 04 walkthrough, explaining how Arc-enabled SQL Managed Instance differs from standalone SQL Server. The previously merged dashboard/template changes remain outside this PR.

Changes:

  • Explains contained availability groups and instance-level configuration through port forwarding.
  • Adds SQL configuration examples and Windows client guidance.
  • Documents storage, recovery, and TDE behavior with Microsoft Learn references.
File Description
03-Azure/​01-03-Infrastructure/​03_Hybrid_Azure_Arc_Kubernetes/​walkthrough/​challenge-04/​solution-04.md Adds the platform-differences appendix while preserving challenge navigation.

Review effort: Balanced

> **Windows / PowerShell jump box notes**
> * If `sqlcmd` is missing, install go-sqlcmd with `winget install sqlcmd` and open a **new** shell so the updated `PATH` is picked up (or call it via its full path, e.g. `& "C:\Program Files\sqlcmd\sqlcmd.exe" ...`).
> * The legacy .NET Framework `System.Data.SqlClient` may fail the TLS pre-login handshake against SQL Server on Linux. Use **go-sqlcmd** (`-C` to trust the self-signed certificate) or the **VS Code mssql extension** (ODBC Driver 18) with **Trust Server Certificate = Yes** — connect it to `127.0.0.1,15330` through the same tunnel.
> * When creating `config.sql` from PowerShell, use a **double-quoted here-string** (`@" ... "@ | Set-Content -Encoding ascii`) so the single quotes in `N'...'` stay intact. A single-quoted here-string requires doubling every SQL quote (`''`) and, if written to the file un-collapsed, produces `Msg 102 Incorrect syntax near 'show'`.
```bash
kubectl delete pod ${sqlmi_name}-0 -n $namespace # the operator recreates it automatically
```
* These settings are stored in the instance and persist across pod restarts/failover, but **not** across deleting and re-creating the SQL MI. For reproducible environments, keep `config.sql` as a post-deployment step.

Because the system databases are platform-managed, you **cannot back up or restore `master` / `model` / `msdb`** yourself (no on-prem style `RESTORE DATABASE master`). Two failure scenarios matter:

1. **Pod / node failure (most common) → automatic recovery, no action.** Kubernetes starts a new pod that **re-attaches to the same persistent volumes**, including `master.mdf`. System DBs, logins and instance config survive. (*"a new SQL Managed Instance will start up and re-attach to the persistent volume containing your data"* — see [features](https://learn.microsoft.com/azure/azure-arc/data/managed-instance-features).)
Important restore caveat for scenario 2:

* Point-in-time restore (PITR) **only restores to the same Arc-enabled SQL MI** where the backups were taken — it can't restore to a *new* instance (see [limitations](https://learn.microsoft.com/azure/azure-arc/data/limitations-managed-instance)).
* To move user DBs to a new instance, keep your **own native backups** (`BACKUP ... TO URL` to Azure Blob, `COPY_ONLY`) or BACPACs, and `RESTORE FROM URL` there.

Backup/restore caveats:

* **Back up the TDE certificate** (`BACKUP CERTIFICATE ... TO FILE` in `master`, then `kubectl cp` it out of the pod) — otherwise encrypted backups can't be restored elsewhere.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants