Bagikan melalui

Kelangsungan bisnis dan pemulihan database - SQL Server di Linux

  • Artikel

Berlaku untuk: SQL Server

Artikel ini memberikan gambaran umum tentang solusi kelangsungan bisnis untuk ketersediaan tinggi dan pemulihan bencana di SQL Server, di Windows dan Linux.

Salah satu tugas umum yang harus diperhitungkan semua orang yang menyebarkan SQL Server adalah memastikan bahwa semua instans SQL Server penting misi dan database di dalamnya tersedia ketika pengguna bisnis dan akhir membutuhkannya, apakah itu 9 hingga 5 atau sekitar jam. Tujuannya adalah untuk menjaga bisnis tetap aktif dan berjalan dengan gangguan minimal atau tanpa gangguan. Konsep ini juga dikenal sebagai kelangsungan bisnis.

SQL Server 2017 (14.x) memperkenalkan banyak fitur atau penyempurnaan baru untuk yang sudah ada, beberapa di antaranya untuk ketersediaan. Penambahan terbesar untuk SQL Server 2017 (14.x) adalah dukungan untuk SQL Server pada distribusi Linux. Untuk daftar lengkap fitur baru di SQL Server, lihat artikel berikut ini:

Artikel ini difokuskan untuk membahas skenario ketersediaan di SQL Server 2017 (14.x) dan versi yang lebih baru, serta fitur ketersediaan baru dan yang ditingkatkan. Skenario ini termasuk yang hibrid yang akan dapat menjangkau penyebaran SQL Server di Windows Server dan Linux, dan yang dapat meningkatkan jumlah salinan database yang dapat dibaca.

Meskipun artikel ini tidak mencakup opsi ketersediaan di luar SQL Server, seperti yang disediakan oleh virtualisasi, semua yang dibahas di sini berlaku untuk penginstalan SQL Server di dalam komputer virtual tamu baik di cloud publik atau dihosting oleh server hypervisor lokal.

Skenario SQL Server menggunakan fitur ketersediaan

Grup ketersediaan AlwaysOn, instans kluster failover AlwaysOn, dan pengiriman log, dapat digunakan dengan berbagai cara, dan tidak selalu hanya untuk tujuan ketersediaan. Ada empat cara utama fitur ketersediaan dapat digunakan:

  • Ketersediaan tinggi
  • Pemulihan dari bencana
  • Migrasi dan peningkatan
  • Menskalakan salinan yang dapat dibaca dari satu atau beberapa database

Bagian berikut membahas fitur relevan yang dapat digunakan untuk skenario tertentu tersebut. Satu fitur yang tidak tercakup adalah replikasi SQL Server. Meskipun tidak secara resmi ditetapkan sebagai fitur ketersediaan di bawah payung AlwaysOn, replikasi SQL Server sering digunakan untuk membuat data redundan dalam skenario tertentu. Replikasi penggabungan tidak didukung untuk SQL Server di Linux. Untuk informasi selengkapnya, lihat Replikasi SQL Server di Linux.

Penting

Fitur ketersediaan SQL Server tidak menggantikan persyaratan untuk memiliki strategi pencadangan dan pemulihan yang kuat dan teruji dengan baik, blok penyusun paling mendasar dari solusi ketersediaan apa pun.

Ketersediaan tinggi

Penting untuk memastikan bahwa instans atau database SQL Server tersedia dalam kasus masalah yang bersifat lokal ke pusat data atau wilayah tunggal di cloud. Bagian ini akan membahas bagaimana fitur ketersediaan SQL Server dapat membantu tugas tersebut. Semua fitur yang dijelaskan tersedia baik di Windows Server maupun di Linux.

Grup ketersediaan

Diperkenalkan di SQL Server 2012 (11.x), grup ketersediaan (AG) memberikan perlindungan tingkat database dengan mengirim setiap transaksi database ke instans lain, atau replika, yang berisi salinan database tersebut dalam keadaan khusus. AG dapat disebarkan pada edisi Standar atau Perusahaan. Instans yang berpartisipasi dalam AG dapat berupa instans kluster mandiri atau failover (FCI, yang dijelaskan di bagian berikutnya). Karena transaksi dikirim ke replika saat terjadi, AG direkomendasikan di mana ada persyaratan untuk titik pemulihan yang lebih rendah dan tujuan waktu pemulihan. Pergerakan data antar replika dapat sinkron atau asinkron, dengan edisi Enterprise memungkinkan hingga tiga replika (termasuk yang utama) sebagai sinkron. AG memiliki satu salinan database baca/tulis sepenuhnya yang ada di replika utama, sementara semua replika sekunder tidak dapat menerima transaksi langsung dari pengguna akhir atau aplikasi.

Catatan

Always On adalah istilah payung untuk fitur ketersediaan di SQL Server dan mencakup AG dan FCI. Always On bukan nama fitur AG.

Sebelum SQL Server 2022 (16.x), AG hanya menyediakan tingkat database, dan bukan perlindungan tingkat instans. Apa pun yang tidak diambil dalam log transaksi atau dikonfigurasi dalam database perlu disinkronkan secara manual untuk setiap replika sekunder. Beberapa contoh objek yang harus disinkronkan secara manual adalah login di tingkat instans, server tertaut, dan pekerjaan SQL Server Agent.

Dimulai dengan SQL Server 2022 (16.x), Anda dapat mengelola objek metadata termasuk pengguna, login, izin, dan pekerjaan SQL Server Agent di tingkat AG selain tingkat instans. Untuk informasi selengkapnya, lihat Grup ketersediaan yang terkandung.

AG juga memiliki komponen lain yang disebut listener, yang memungkinkan aplikasi dan pengguna akhir untuk terhubung tanpa perlu mengetahui instans SQL Server mana yang menghosting replika utama. Setiap AG akan memiliki pendengarnya sendiri. Meskipun implementasi listener sedikit berbeda di Windows Server versus Linux, fungsionalitas yang disediakannya dan cara penggunaannya sama. Diagram di bawah ini menunjukkan AG berbasis Windows Server yang menggunakan Kluster Failover Windows Server (WSFC). Kluster yang mendasar pada lapisan OS diperlukan untuk ketersediaan apakah itu di Linux atau Windows Server. Contoh menunjukkan konfigurasi sederhana dengan dua server, atau simpul, dengan WSFC sebagai kluster yang mendasar.

Diagram grup ketersediaan sederhana.

Edisi Standar dan Perusahaan memiliki maksimum yang berbeda dalam hal replika. AG dalam edisi Standar, yang dikenal sebagai grup ketersediaan dasar, mendukung dua replika (satu primer dan satu sekunder) hanya dengan satu database di AG. Edisi perusahaan tidak hanya memungkinkan beberapa database dikonfigurasi dalam satu AG, tetapi juga dapat memiliki hingga sembilan total replika (satu primer, delapan sekunder). Edisi perusahaan juga memberikan manfaat opsional lainnya seperti replika sekunder yang dapat dibaca, kemampuan untuk membuat cadangan dari replika sekunder, dan banyak lagi.

Catatan

Pencerminan database, yang tidak digunakan lagi di SQL Server 2012 (11.x), tidak tersedia di SQL Server versi Linux, juga tidak akan ditambahkan. Pelanggan yang masih menggunakan pencerminan database harus berencana untuk bermigrasi ke AG, yang merupakan pengganti pencerminan database.

Dalam hal ketersediaan, AG dapat menyediakan failover otomatis atau manual. Failover otomatis dapat terjadi jika pergerakan data sinkron dikonfigurasi dan database pada replika primer dan sekunder dalam keadaan disinkronkan. Selama pendengar digunakan dan aplikasi menggunakan versi .NET Framework yang lebih baru (3.5 dengan pembaruan, atau 4.0 ke atas), failover harus ditangani dengan minimal hingga tidak berpengaruh pada pengguna akhir jika pendengar digunakan. Mengalihkan ke replika sekunder untuk menjadikannya replika utama baru dapat dikonfigurasi agar otomatis atau manual, dan umumnya diukur dalam hitungan detik.

Daftar di bawah ini menyoroti beberapa perbedaan dengan AG di Windows Server versus Linux:

  • Karena perbedaan dalam cara kerja kluster yang mendasar di Linux dan Windows Server, semua failover (manual atau otomatis) AG dilakukan melalui kluster di Linux. Pada penyebaran AG berbasis Windows Server, failover manual harus dilakukan melalui SQL Server. Failover otomatis ditangani oleh kluster yang mendasar di Windows Server dan Linux.
  • Untuk SQL Server di Linux, konfigurasi yang direkomendasikan untuk AG adalah minimal tiga replika. Hal ini disebabkan oleh cara kerja pengklusteran yang mendasar.
  • Di Linux, nama umum yang digunakan oleh setiap pendengar didefinisikan dalam DNS dan bukan di kluster seperti di Windows Server.

Dimulai dengan SQL Server 2017 (14.x), ada beberapa fitur dan peningkatan baru untuk AG:

  • Jenis kluster
  • REQUIRED_SECONDARIES_TO_COMMIT
  • Dukungan Koordinator Transaksi Distributor Microsoft (DTC) yang ditingkatkan untuk konfigurasi berbasis Windows Server
  • Skenario peluasan skala tambahan untuk database baca-saja (dijelaskan nanti dalam artikel ini)

Jenis kluster grup ketersediaan

Bentuk ketersediaan bawaan pengklusteran di Windows Server diaktifkan melalui fitur bernama Pengklusteran Failover. Ini memungkinkan Anda untuk membangun WSFC untuk digunakan dengan AG atau FCI. Integrasi untuk AG dan FCI disediakan oleh DLL sumber daya sadar kluster yang dikirim oleh SQL Server.

SQL Server di Linux mendukung beberapa teknologi pengklusteran. Microsoft mendukung komponen SQL Server, sementara mitra kami mendukung teknologi pengklusteran yang relevan. Misalnya, bersama dengan Pacemaker, SQL Server di Linux mendukung HPE Serviceguard dan DH2i DxEnterprise sebagai solusi kluster.

Kluster failover berbasis Windows dan solusi kluster Linux lebih mirip dari yang berbeda. Keduanya menyediakan cara untuk mengambil server individual dan menggabungkannya dalam konfigurasi untuk menyediakan ketersediaan, dan memiliki konsep hal-hal seperti sumber daya, batasan (bahkan jika diimplementasikan secara berbeda), failover, dan sebagainya.

Misalnya, untuk mendukung Pacemaker untuk konfigurasi AG dan FCI termasuk hal-hal seperti failover otomatis, Microsoft menyediakan mssql-server-ha paket, yang mirip dengan, tetapi tidak persis sama dengan DLL sumber daya di WSFC, untuk Pacemaker. Salah satu perbedaan antara WSFC dan Pacemaker adalah bahwa tidak ada sumber daya nama jaringan di Pacemaker, yang merupakan komponen yang membantu mengabstraksi nama pendengar (atau nama FCI) pada WSFC. DNS menyediakan resolusi nama tersebut di Linux.

Karena perbedaan dalam tumpukan kluster, beberapa perubahan perlu dilakukan untuk AG karena SQL Server harus menangani beberapa metadata yang ditangani secara asli oleh WSFC. Salah satu perubahan signifikan tersebut adalah pengenalan jenis kluster untuk grup ketersediaan. Ini disimpan dalam sys.availability_groups cluster_type kolom dan cluster_type_desc . Ada tiga jenis kluster:

  • WSFC
  • Eksternal
  • Tidak

Semua AG yang memerlukan ketersediaan tinggi harus menggunakan kluster yang mendasar, yang dalam kasus SQL Server 2017 (14.x) dan versi yang lebih baru berarti WSFC atau agen pengklusteran Linux. Untuk AG berbasis Windows Server yang menggunakan WSFC yang mendasar, jenis kluster default adalah WSFC dan tidak perlu diatur. Untuk AG berbasis Linux, saat membuat AG, jenis kluster harus diatur ke Eksternal. Integrasi dengan solusi kluster eksternal di Linux dikonfigurasi setelah AG dibuat, sedangkan pada WSFC, itu dilakukan pada waktu pembuatan.

Jenis kluster Tidak Ada dapat digunakan dengan Windows Server dan Linux AG. Mengatur jenis kluster ke Tidak Ada berarti bahwa AG tidak memerlukan kluster yang mendasar. Ini berarti SQL Server 2017 (14.x) adalah versi pertama SQL Server yang mendukung AG tanpa kluster, tetapi tradeoff adalah bahwa konfigurasi ini tidak didukung sebagai solusi ketersediaan tinggi.

Penting

Dimulai dengan SQL Server 2017 (14.x), Anda tidak dapat mengubah jenis kluster untuk AG setelah dibuat. Ini berarti bahwa AG tidak dapat dialihkan dari Tidak Ada ke Eksternal atau WSFC, atau sebaliknya.

Bagi mereka yang hanya ingin menambahkan salinan database baca-saja tambahan, atau seperti apa yang disediakan AG untuk migrasi/peningkatan tetapi tidak ingin terikat dengan kompleksitas tambahan dari kluster yang mendasar atau bahkan replikasi, AG dengan jenis kluster Tidak Ada adalah solusi yang sempurna. Untuk informasi selengkapnya, lihat bagian Migrasi dan Peningkatan dan skala baca.

Cuplikan layar di bawah ini menunjukkan dukungan untuk berbagai jenis jenis kluster di SQL Server Management Studio (SSMS). Anda harus menjalankan versi 17.1 atau yang lebih baru. Cuplikan layar di bawah ini berasal dari versi 17.2.

Cuplikan layar opsi SSMS AG.

REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT

SQL Server 2016 (13.x) meningkatkan dukungan untuk jumlah replika sinkron dari dua menjadi tiga di edisi Enterprise. Namun, jika satu replika sekunder disinkronkan tetapi yang lain mengalami masalah, tidak ada cara untuk mengontrol perilaku untuk memberi tahu primer untuk menunggu replika yang salah tingkah laku atau memungkinkannya untuk melanjutkan. Ini berarti bahwa replika utama pada titik tertentu akan terus menerima lalu lintas tulis meskipun replika sekunder tidak akan dalam keadaan disinkronkan, yang berarti bahwa ada kehilangan data pada replika sekunder. Dimulai dengan SQL Server 2017 (14.x), Anda dapat mengontrol perilaku apa yang terjadi ketika ada replika sinkron dengan REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT. Opsi ini berfungsi sebagai berikut:

  • Ada tiga nilai yang mungkin: 0, 1, dan 2
  • Nilainya adalah jumlah replika sekunder yang harus disinkronkan, yang memiliki implikasi untuk kehilangan data, ketersediaan AG, dan failover
  • Untuk WSFC dan jenis kluster Tidak Ada, nilai defaultnya adalah 0, dan dapat diatur secara manual ke 1 atau 2
  • Untuk jenis kluster Eksternal, secara default, mekanisme kluster akan mengatur nilai ini, dan dapat ditimpa secara manual. Untuk tiga replika sinkron, nilai defaultnya adalah 1.

Di Linux, nilai untuk REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT dikonfigurasi pada sumber daya AG di kluster. Di Windows, diatur melalui Transact-SQL.

Nilai yang lebih tinggi dari 0 memastikan perlindungan data yang lebih tinggi, karena jika jumlah replika sekunder yang diperlukan tidak tersedia, replika utama tidak akan tersedia hingga diselesaikan. REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT juga memengaruhi perilaku failover karena failover otomatis tidak dapat terjadi jika jumlah replika sekunder yang tepat tidak dalam keadaan yang tepat. Di Linux, nilai 0 tidak akan mengizinkan failover otomatis, jadi di Linux, saat menggunakan sinkron dengan failover otomatis, nilai harus diatur lebih tinggi daripada 0 mencapai failover otomatis. 0 pada Windows Server adalah perilaku di SQL Server 2016 (13.x) dan versi yang lebih lama.

Dukungan Koordinator Transaksi Terdistribusi Microsoft yang Ditingkatkan

Sebelum SQL Server 2016 (13.x), satu-satunya cara untuk mendapatkan ketersediaan di SQL Server untuk aplikasi yang memerlukan transaksi terdistribusi, yang menggunakan DTC di bawah sampul adalah dengan menyebarkan FCI. Transaksi terdistribusi dapat dilakukan dengan salah satu dari dua cara:

  • Transaksi yang mencakup lebih dari satu database dalam instans SQL Server yang sama
  • Transaksi yang mencakup lebih dari satu instans SQL Server atau mungkin melibatkan sumber data non-SQL Server

SQL Server 2016 (13.x) memperkenalkan dukungan parsial untuk DTC dengan AG yang mencakup skenario terakhir. SQL Server 2017 (14.x) menyelesaikan cerita dengan mendukung kedua skenario dengan DTC.

Di SQL Server 2017 (14.x) dan versi yang lebih baru, dukungan DTC juga dapat ditambahkan ke AG setelah dibuat. Di SQL Server 2016 (13.x), mengaktifkan dukungan untuk DTC ke AG hanya dapat dilakukan ketika AG dibuat.

Instans kluster failover

Penginstalan terkluster telah menjadi fitur SQL Server sejak versi 6.5. FCI adalah metode yang terbukti untuk menyediakan ketersediaan untuk seluruh penginstalan SQL Server, yang dikenal sebagai instans. Ini berarti bahwa semua yang ada di dalam instans, termasuk database, pekerjaan SQL Server Agent, server tertaut, dan sebagainya, akan berpindah ke server lain jika server yang mendasar mengalami masalah. Semua FCI memerlukan semacam penyimpanan bersama, bahkan jika disediakan melalui jaringan. Sumber daya FCI hanya dapat berjalan dan dimiliki oleh satu simpul pada waktu tertentu. Dalam diagram di bawah ini, simpul pertama kluster memiliki FCI, yang juga berarti memiliki sumber daya penyimpanan bersama yang terkait dengannya yang ditandai oleh garis solid ke penyimpanan.

Diagram Instans Kluster Failover.

Setelah failover, kepemilikan berubah seperti yang terlihat pada diagram di bawah ini.

Diagram Instans Kluster Failover, pasca failover.

Tidak ada kehilangan data dengan FCI, tetapi penyimpanan bersama yang mendasar adalah satu titik kegagalan karena ada satu salinan data. FCI sering dikombinasikan dengan metode ketersediaan lain, seperti AG atau pengiriman log, untuk memiliki salinan database yang berlebihan. Metode tambahan yang disebarkan harus menggunakan penyimpanan yang terpisah secara fisik dari FCI. Ketika FCI gagal ke node lain, FCI berhenti pada satu simpul dan dimulai pada node lain, tidak seperti mematikan server dan menyalakannya. FCI melalui proses pemulihan normal, yang berarti setiap transaksi yang perlu digulirkan ke depan akan, dan setiap transaksi yang tidak lengkap akan digulirkan kembali. Oleh karena itu, database konsisten dari titik data hingga waktu kegagalan atau failover manual, sehingga tidak ada kehilangan data. Database hanya tersedia setelah pemulihan selesai, sehingga waktu pemulihan akan bergantung pada banyak faktor, dan umumnya akan lebih lama daripada failover pada AG. Tradeoff adalah bahwa ketika Anda gagal atas AG, mungkin ada tugas tambahan yang diperlukan untuk membuat database dapat digunakan, seperti mengaktifkan pekerjaan SQL Server Agent.

Seperti AG, FCI mengabstraksi simpul mana dari kluster yang mendasar yang menghostingnya. FCI selalu mempertahankan nama yang sama. Aplikasi dan pengguna akhir tidak pernah terhubung ke simpul; nama unik yang ditetapkan ke FCI digunakan. FCI dapat berpartisipasi dalam AG sebagai salah satu instans yang menghosting replika primer atau sekunder.

Daftar di bawah ini menyoroti beberapa perbedaan dengan FCI di Windows Server versus Linux:

  • Di Windows Server, FCI adalah bagian dari proses penginstalan. FCI di Linux dikonfigurasi setelah menginstal SQL Server.
  • Linux hanya mendukung satu penginstalan SQL Server per host, sehingga semua FCI akan menjadi instans default. Windows Server mendukung hingga 25 FCI per WSFC.
  • Nama umum yang digunakan oleh FCI di Linux didefinisikan dalam DNS, dan harus sama dengan sumber daya yang dibuat untuk FCI.

Pengiriman log

Jika tujuan titik pemulihan dan waktu pemulihan lebih fleksibel, atau database tidak dianggap sangat penting untuk misi, pengiriman log adalah fitur ketersediaan lain yang terbukti di SQL Server. Berdasarkan cadangan asli SQL Server, proses pengiriman log secara otomatis menghasilkan cadangan log transaksi, menyalinnya ke satu atau beberapa instans yang dikenal sebagai siaga hangat, dan secara otomatis menerapkan pencadangan log transaksi ke siaga tersebut. Pengiriman log menggunakan pekerjaan SQL Server Agent untuk mengotomatiskan proses pencadangan, penyalinan, dan penerapan pencadangan log transaksi.

Diagram Pengiriman Log.

Bisa dibilang keuntungan terbesar menggunakan pengiriman log dalam beberapa kapasitas adalah bahwa itu menyumbang kesalahan manusia. Penerapan log transaksi dapat ditunda. Oleh karena itu, jika seseorang mengeluarkan sesuatu seperti PEMBARUAN tanpa klausul WHERE, siaga mungkin tidak memiliki perubahan sehingga Anda dapat beralih ke itu saat Anda memperbaiki sistem utama. Meskipun pengiriman log mudah dikonfigurasi, beralih dari primer ke siaga hangat, yang dikenal sebagai perubahan peran, selalu manual. Perubahan peran dimulai melalui Transact-SQL, dan seperti AG, semua objek yang tidak ditangkap dalam log transaksi harus disinkronkan secara manual. Pengiriman log juga perlu dikonfigurasi per database, sedangkan satu AG dapat berisi beberapa database.

Tidak seperti AG atau FCI, pengiriman log tidak memiliki abstraksi untuk perubahan peran, aplikasi mana yang harus dapat ditangani. Teknik seperti alias DNS (CNAME) dapat digunakan, tetapi ada pro dan kontra, seperti waktu yang diperlukan AGAR DNS di-refresh setelah pengalihan.

Pemulihan dari bencana

Ketika lokasi ketersediaan utama Anda mengalami peristiwa bencana seperti gempa atau banjir, bisnis harus siap untuk memiliki sistemnya online di tempat lain. Bagian ini akan membahas bagaimana fitur ketersediaan SQL Server dapat membantu kelangsungan bisnis.

Grup ketersediaan

Salah satu manfaat AG adalah ketersediaan tinggi dan pemulihan bencana dapat dikonfigurasi menggunakan satu fitur. Tanpa persyaratan untuk memastikan bahwa penyimpanan bersama juga sangat tersedia, jauh lebih mudah untuk memiliki replika yang lokal dalam satu pusat data untuk ketersediaan tinggi, dan yang terpencil di pusat data lain untuk pemulihan bencana masing-masing dengan penyimpanan terpisah. Memiliki salinan tambahan database adalah tradeoff untuk memastikan redundansi. Contoh AG yang mencakup beberapa pusat data ditunjukkan di bawah ini. Satu replika utama bertanggung jawab untuk menjaga semua replika sekunder tetap sinkron.

Diagram grup ketersediaan yang mencakup pusat data.

Di luar AG dengan jenis kluster yang tidak ada, AG mengharuskan semua replika adalah bagian dari kluster yang mendasar yang sama apakah itu WSFC atau solusi kluster eksternal. Ini berarti bahwa dalam diagram di atas, WSFC direntangkan untuk bekerja di dua pusat data yang berbeda, yang menambah kompleksitas. terlepas dari platform (Windows Server atau Linux). Membentangkan kluster di seluruh jarak menambah kompleksitas.

Diperkenalkan di SQL Server 2016 (13.x), grup ketersediaan terdistribusi memungkinkan AG untuk menjangkau AG yang dikonfigurasi pada kluster yang berbeda. AG terdistribusi memisahkan persyaratan untuk membuat semua simpul berpartisipasi dalam kluster yang sama, yang membuat konfigurasi pemulihan bencana jauh lebih mudah. Untuk informasi selengkapnya tentang AG terdistribusi, lihat Grup ketersediaan terdistribusi.

Diagram Grup Ketersediaan Terdistribusi.

Instans kluster failover

FCI dapat digunakan untuk pemulihan bencana. Seperti halnya AG normal, mekanisme kluster yang mendasar juga harus diperluas ke semua lokasi, yang menambah kompleksitas. Ada pertimbangan tambahan untuk FCI: penyimpanan bersama. Disk yang sama harus tersedia di situs utama dan sekunder. Metode eksternal seperti fungsionalitas yang disediakan oleh vendor penyimpanan di lapisan perangkat keras, atau menggunakan Replika penyimpanan di Windows Server, diperlukan untuk memastikan bahwa disk yang digunakan oleh FCI ada di tempat lain.

Diagram FCI yang mencakup pusat data.

Pengiriman log

Pengiriman log adalah salah satu metode tertua untuk menyediakan pemulihan bencana untuk database SQL Server. Pengiriman log sering digunakan dengan AG dan FCI untuk memberikan pemulihan bencana yang hemat biaya dan lebih sederhana di mana opsi lain mungkin menantang karena lingkungan, keterampilan administratif, atau anggaran. Mirip dengan cerita ketersediaan tinggi untuk pengiriman log, banyak lingkungan akan menunda pemuatan log transaksi untuk memperhitungkan kesalahan manusia.

Migrasi dan peningkatan

Saat menyebarkan instans baru atau meningkatkan instans lama, bisnis tidak dapat mentolerir pemadaman yang lama. Bagian ini akan membahas bagaimana fitur ketersediaan SQL Server dapat digunakan untuk meminimalkan waktu henti dalam perubahan arsitektur yang direncanakan, pengalihan server, perubahan platform (seperti Windows Server ke Linux atau sebaliknya), atau selama patching.

Catatan

Metode lain, seperti menggunakan cadangan dan memulihkannya di tempat lain, juga dapat digunakan untuk migrasi dan peningkatan. Mereka tidak dibahas dalam artikel ini.

Grup ketersediaan

Instans yang ada yang berisi satu atau beberapa AG dapat ditingkatkan ke versi SQL Server yang lebih baru. Meskipun ini akan membutuhkan beberapa waktu henti, dengan jumlah perencanaan yang tepat, ini dapat diminimalkan.

Jika tujuannya adalah untuk bermigrasi ke server baru dan tidak mengubah konfigurasi (termasuk sistem operasi atau versi SQL Server), server tersebut dapat ditambahkan sebagai simpul ke kluster yang mendasar yang ada dan ditambahkan ke AG. Setelah replika atau replika berada dalam status yang tepat, failover manual dapat terjadi ke server baru, dan kemudian yang lama dapat dihapus dari AG, dan pada akhirnya, dinonaktifkan.

AG terdistribusi juga merupakan metode lain untuk bermigrasi ke konfigurasi baru atau meningkatkan SQL Server. Karena AG terdistribusi mendukung AG yang mendasar yang berbeda pada arsitektur yang berbeda, misalnya, Anda dapat mengubah dari SQL Server 2016 (13.x) yang berjalan di Windows Server 2012 R2 ke SQL Server 2017 (14.x) yang berjalan di Windows Server 2016.

Diagram grup ketersediaan terdistribusi yang mencampur WSFC dan Pacemaker.

Terakhir, AG dengan jenis kluster Tidak Ada juga dapat digunakan untuk migrasi atau peningkatan. Anda tidak dapat mencampur dan mencocokkan jenis kluster dalam konfigurasi AG biasa, sehingga semua replika harus menjadi jenis Tidak Ada. AG terdistribusi dapat digunakan untuk menjangkau AG yang dikonfigurasi dengan jenis kluster yang berbeda. Metode ini juga didukung di berbagai platform OS.

Semua varian AG untuk migrasi dan peningkatan memungkinkan bagian pekerjaan yang paling memakan waktu untuk dilakukan dari waktu ke waktu - sinkronisasi data. Ketika tiba saatnya untuk memulai peralihan ke konfigurasi baru, cutover akan menjadi pemadaman singkat versus satu periode waktu henti yang panjang di mana semua pekerjaan, termasuk sinkronisasi data, perlu diselesaikan.

AG dapat memberikan waktu henti minimal selama patching OS yang mendasarinya dengan melakukan failover secara manual pada replika primer ke sekunder saat patching sedang diselesaikan. Dari perspektif sistem operasi, melakukan ini akan lebih umum di Windows Server sejak sering, tetapi tidak selalu, melayani OS yang mendasarinya mungkin memerlukan hidupkan ulang. Patching Linux terkadang memerlukan hidupkan ulang, tetapi jarang terjadi.

Patching instans SQL Server yang berpartisipasi dalam grup ketersediaan juga dapat meminimalkan waktu henti tergantung pada seberapa kompleks arsitektur AG. Untuk menambal server yang berpartisipasi dalam AG, replika sekunder di-patch terlebih dahulu. Setelah jumlah replika yang tepat di-patch, replika utama secara manual di-failover ke node lain untuk melakukan peningkatan. Replika sekunder yang tersisa pada saat itu juga dapat ditingkatkan.

Instans kluster failover

FCI sendiri tidak dapat membantu migrasi atau peningkatan tradisional; AG atau pengiriman log harus dikonfigurasi untuk database di FCI dan semua objek lain yang diperhitungkan. Namun, FCI di bawah Windows Server masih merupakan opsi populer ketika Windows Server yang mendasar perlu di-patch. Failover manual dapat dimulai, yang berarti pemadaman singkat alih-alih tidak tersedia instans selama seluruh waktu Windows Server sedang di-patch. FCI dapat ditingkatkan ke versi SQL Server yang lebih baru. Untuk informasi, lihat Meningkatkan Instans Kluster Failover SQL Server.

Pengiriman log

Pengiriman log masih merupakan opsi populer untuk memigrasikan dan meningkatkan database. Mirip dengan AG, tetapi kali ini menggunakan log transaksi sebagai metode sinkronisasi, penyebaran data dapat dimulai dengan baik sebelum pengalihan server. Pada saat pengalihan, setelah semua lalu lintas dihentikan di sumbernya, log transaksi akhir perlu diambil, disalin, dan diterapkan ke konfigurasi baru. Pada saat itu, database dapat dibawa secara online. Pengiriman log sering lebih toleran terhadap jaringan yang lebih lambat, dan sementara sakelar mungkin sedikit lebih lama daripada yang dilakukan menggunakan AG atau AG terdistribusi, biasanya diukur dalam hitungan menit - bukan jam, hari, atau minggu.

Mirip dengan AG, pengiriman log dapat menyediakan cara untuk beralih ke server lain jika terjadi patching.

Metode dan ketersediaan penyebaran SQL Server lainnya

Ada dua metode penyebaran lainnya untuk SQL Server di Linux: kontainer dan menggunakan Azure (atau penyedia cloud publik lainnya). Kebutuhan umum akan ketersediaan seperti yang disajikan di seluruh makalah ini ada terlepas dari bagaimana SQL Server disebarkan. Kedua metode ini memiliki beberapa pertimbangan khusus dalam hal membuat SQL Server sangat tersedia.

Kontainer SQL Server dan opsi HA/DR

Penyebaran kontainer SQL Server adalah cara baru untuk menyebarkan SQL Server di Linux. Kontainer adalah gambar lengkap SQL Server yang siap dijalankan.

Bergantung pada platform kontainer yang Anda gunakan, misalnya saat menggunakan orkestrator kontainer seperti Kubernetes, jika kontainer hilang, kontainer dapat disebarkan lagi dan dilampirkan ke penyimpanan bersama yang digunakan. Meskipun ini memberikan beberapa ketahanan, akan ada beberapa waktu henti yang terkait dengan pemulihan database, dan tidak benar-benar tersedia seperti jika menggunakan grup ketersediaan atau FCI.

Jika Anda ingin mengonfigurasi ketersediaan tinggi untuk kontainer SQL Server yang disebarkan pada platform Kubernetes atau non-Kubernetes, Anda dapat menggunakan DH2i DxEnterprise sebagai salah satu solusi pengklusteran, di atasnya Anda dapat mengonfigurasi AG dalam mode ketersediaan tinggi. Opsi ini memberi Anda tujuan titik pemulihan (RPO) dan tujuan waktu pemulihan (RTO) yang diharapkan dari solusi ketersediaan tinggi.

Penyebaran IaaS berbasis Linux

Komputer virtual IaaS Linux dapat disebarkan dengan SQL Server yang diinstal menggunakan Azure. Seperti halnya penginstalan berbasis lokal, penginstalan yang didukung memerlukan penggunaan STONITH (Shoot the Other Node in the Head) yang berada di luar agen kluster itu sendiri. STONITH disediakan melalui agen ketersediaan anggar. Beberapa distribusi mengirimkannya sebagai bagian dari platform, sementara yang lain mengandalkan vendor perangkat keras dan perangkat lunak eksternal. Periksa dengan distribusi Linux pilihan Anda untuk melihat bentuk STONITH apa yang disediakan sehingga solusi yang didukung dapat disebarkan di cloud publik.

Panduan untuk menginstal SQL Server di Linux tersedia untuk distribusi berikut:

Skala baca

Sejak diperkenalkan di SQL Server 2012 (11.x), replika sekunder telah memiliki kemampuan untuk digunakan untuk kueri baca-saja. Ada dua cara yang dapat dicapai dengan AG: dengan mengizinkan akses langsung ke sekunder, dan mengonfigurasi perutean baca saja, yang memerlukan penggunaan pendengar. SQL Server 2016 (13.x) memperkenalkan kemampuan untuk memuat keseimbangan koneksi baca-saja melalui pendengar menggunakan algoritma round robin, memungkinkan permintaan baca-saja tersebar di semua replika yang dapat dibaca.

Catatan

Replika sekunder yang dapat dibaca hanya merupakan fitur di edisi Enterprise, dan setiap instans yang menghosting replika yang dapat dibaca memerlukan lisensi SQL Server.

Penskalaan salinan database yang dapat dibaca melalui AG pertama kali diperkenalkan dengan AG terdistribusi di SQL Server 2016 (13.x). Ini akan memungkinkan perusahaan untuk memiliki salinan database baca-saja tidak hanya secara lokal, tetapi secara regional dan global dengan jumlah konfigurasi minimal dan mengurangi lalu lintas dan latensi jaringan dengan memiliki kueri yang dijalankan secara lokal. Setiap replika utama AG dapat menyemai dua AG lainnya meskipun bukan salinan baca/tulis sepenuhnya, sehingga setiap AG terdistribusi dapat mendukung hingga 27 salinan data yang dapat dibaca.

Diagram memperlihatkan grup ketersediaan terdistribusi yang terkait dengan skala baca.

Dimulai dengan SQL Server 2017 (14.x), Dimungkinkan untuk membuat solusi yang hampir real time dan baca-saja dengan AG yang dikonfigurasi dengan jenis kluster Tidak Ada. Jika tujuannya adalah untuk menggunakan AG untuk replika sekunder yang dapat dibaca dan bukan ketersediaan, melakukan ini menghilangkan kompleksitas menggunakan WSFC atau solusi kluster eksternal di Linux, dan memberikan manfaat yang dapat dibaca dari AG dalam metode penyebaran yang lebih sederhana.

Satu-satunya peringatan utama adalah bahwa karena tidak ada kluster yang mendasar dengan jenis kluster Tidak Ada, mengonfigurasi perutean baca-saja sedikit berbeda. Dari perspektif SQL Server, pendengar masih diperlukan untuk merutekan permintaan meskipun tidak ada kluster. Alih-alih mengonfigurasi listener tradisional, alamat IP atau nama replika utama digunakan. Replika utama kemudian digunakan untuk merutekan permintaan baca-saja.

Siaga hangat pengiriman log secara teknis dapat dikonfigurasi untuk penggunaan yang dapat dibaca dengan memulihkan database DENGAN SIAGA. Namun, karena log transaksi memerlukan penggunaan eksklusif database untuk pemulihan, itu berarti bahwa pengguna tidak dapat mengakses database saat itu terjadi. Ini membuat pengiriman log menjadi solusi yang kurang ideal - terutama jika data mendekati real-time diperlukan.

Satu hal yang harus dicatat untuk semua skenario skala baca dengan AG adalah bahwa tidak seperti menggunakan replikasi transaksional di mana semua data ditayangkan, setiap replika sekunder tidak dalam keadaan di mana indeks unik dapat diterapkan, replika adalah salinan yang tepat dari primer. Jika ada indeks yang diperlukan untuk pelaporan atau data perlu dimanipulasi, indeks harus dibuat pada database pada replika utama. Jika Anda membutuhkan fleksibilitas tersebut, replikasi adalah solusi yang lebih baik untuk data yang dapat dibaca.

Interoperabilitas distribusi lintas platform dan Linux

Dengan SQL Server sekarang didukung di Windows Server dan Linux, bagian ini mencakup skenario bagaimana mereka dapat bekerja sama untuk ketersediaan selain tujuan lain, dan cerita untuk solusi yang akan menggabungkan lebih dari satu distribusi Linux.

Catatan

Tidak ada skenario di mana FCI atau AG berbasis WSFC akan bekerja dengan FCI atau AG berbasis Linux secara langsung. WSFC tidak dapat diperpanjang oleh simpul Pacemaker dan sebaliknya.

Grup ketersediaan terdistribusi

AG terdistribusi dirancang untuk mencakup konfigurasi AG, apakah kedua kluster yang mendasar di bawah AG adalah dua WSFC yang berbeda, distribusi Linux, atau satu di WSFC dan yang lainnya di Linux. AG terdistribusi akan menjadi metode utama untuk memiliki solusi lintas platform. AG terdistribusi juga merupakan solusi utama untuk migrasi seperti mengonversi dari infrastruktur SQL Server berbasis Windows Server ke infrastruktur berbasis Linux jika itulah yang ingin dilakukan perusahaan Anda. Seperti disebutkan di atas, AG, dan terutama AG terdistribusi, akan meminimalkan waktu aplikasi tidak akan tersedia untuk digunakan. Contoh AG terdistribusi yang mencakup WSFC dan Pacemaker ditunjukkan di bawah ini.

Diagram memperlihatkan grup ketersediaan terdistribusi yang mencakup WSFC dan Pacemaker.

Jika AG dikonfigurasi dengan jenis kluster Tidak Ada, AG dapat mencakup Windows Server dan Linux, serta beberapa distribusi Linux. Karena ini bukan konfigurasi ketersediaan tinggi yang sebenarnya, konfigurasi tersebut tidak boleh digunakan untuk penyebaran misi penting, tetapi untuk skenario skala baca atau migrasi/peningkatan.

Pengiriman log

Karena pengiriman log didasarkan pada pencadangan dan pemulihan, dan tidak ada perbedaan dalam database, struktur file, dll., untuk SQL Server di Windows Server versus SQL Server di Linux. Ini berarti bahwa pengiriman log dapat dikonfigurasi antara penginstalan SQL Server berbasis Windows Server dan yang Linux, serta antara distribusi Linux. Segala sesuatu yang lain tetap sama. Satu-satunya peringatan adalah pengiriman log itu, sama seperti AG, tidak dapat berfungsi ketika sumber berada di versi utama SQL Server yang lebih tinggi terhadap target yang berada pada versi SQL Server yang lebih rendah.

Ringkasan

Instans dan database SQL Server 2017 (14.x) dan versi yang lebih baru dapat dibuat sangat tersedia menggunakan fitur yang sama di Windows Server dan Linux. Selain skenario ketersediaan standar ketersediaan tinggi lokal dan pemulihan bencana, waktu henti yang terkait dengan peningkatan dan migrasi dapat diminimalkan dengan fitur ketersediaan di SQL Server. AG juga dapat menyediakan salinan tambahan database sebagai bagian dari arsitektur yang sama untuk menskalakan salinan yang dapat dibaca. Baik Anda menyebarkan solusi baru atau mempertimbangkan peningkatan, SQL Server memiliki ketersediaan dan keandalan yang Anda butuhkan.

Konten terkait