Gunakan kelas Recovery Manager untuk memperbaiki masalah peta shard

Berlaku untuk: Azure SQL Database

Kelas RecoveryManager memberikan aplikasi ADO.NET kemampuan untuk dengan mudah mendeteksi dan memperbaiki inkonsistensi antara peta shard global (GSM) dan peta shard lokal (LSM) dalam lingkungan database yang terpecah.

GSM dan LSM melacak pemetaan setiap database dalam lingkungan yang terpecah. Kadang-kadang, pemutusan terjadi antara GSM dan LSM. Dalam hal ini, gunakan kelas RecoveryManager untuk mendeteksi dan memperbaiki pemutusan.

Kelas RecoveryManager adalah bagian dari pustaka klien Elastic Database.

Untuk definisi istilah, lihat glosarium alat Elastic Database. Untuk memahami bagaimana ShardMapManager digunakan untuk mengelola data dalam solusi shard, lihat Manajemen peta shard.

Alasan menggunakan manajer pemulihan

Dalam lingkungan database terpecah, ada satu penyewa per database, dan banyak database per server. Mungkin juga ada banyak server di lingkungan. Setiap database dipetakan dalam peta shard, sehingga panggilan dapat dirutekan ke server dan database yang benar. Database dilacak sesuai dengan kunci sharding, dan setiap shard diberi rentang nilai kunci. Misalnya, kunci pemecahan dapat mewakili nama pengguna dari "D" hingga "F." Pemetaan semua pecahan (juga dikenal dengan database) serta rentang pemetaan mereka disertakan dalam peta pecahan global (GSM). Setiap database juga berisi peta rentang yang terkandung pada shard yang dikenal sebagai peta shard lokal (LSM). Saat aplikasi terhubung ke shard, pemetaan di-cache dengan aplikasi untuk pengambilan cepat. LSM digunakan untuk memvalidasi data cache.

GSM dan LSM mungkin tidak sinkron karena alasan berikut:

1. Penghapusan shard yang jangkauannya diyakini tidak lagi digunakan, atau mengganti nama shard. Menghapus shard menghasilkan pemetaan shard tanpa sumber. Demikian pula, database yang berganti nama dapat menyebabkan pemetaan shard tanpa sumber. Tergantung pada niat perubahan, shard mungkin perlu dihapus atau lokasi shard perlu diperbarui. Untuk memulihkan database yang dihapus, lihat Pulihkan database yang dihapus.
2. Peristiwa kegagalan lokasi geografis terjadi. Untuk melanjutkan, harus ada yang memperbarui nama server, dan nama database manajer peta shard dalam aplikasi dan kemudian memperbarui detail pemetaan shard untuk semua shard dalam peta shard. Jika ada kegagalan lokasi geografis, logika pemulihan tersebut harus diotomatisasi dalam alur kerja kegagalan. Mengotomatiskan tindakan pemulihan mengaktifkan pengelolaan tanpa gesekan untuk database berkemampuan geografis dan menghindari tindakan manusia manual. Untuk mempelajari tentang opsi untuk memulihkan database jika ada ketidaktersediaan pusat data, lihat Kelangsungan Bisnis dan Pemulihan Bencana.
3. Baik shard atau database ShardMapManager dipulihkan ke titik waktu sebelumnya. Untuk mempelajari tentang titik waktu pemulihan menggunakan cadangan, lihat Pemulihan menggunakan cadangan.

Untuk informasi selengkapnya tentang alat Azure SQL Database Elastic Database, replika lokasi geografis dan Pemulihan, lihat berikut ini:

• Gambaran umum: Kelangsungan bisnis cloud dan pemulihan bencana database dengan SQL Database
• Memulai alat database elastis
• ShardMap Management

Mengambil RecoveryManager dari ShardMapManager

Langkah pertama adalah membuat instans RecoveryManager. Metode GetRecoveryManager mengembalikan manajer pemulihan untuk instans ShardMapManager saat ini. Untuk mengatasi inkonsistensi apa pun di peta shard, Anda harus terlebih dahulu mengambil RecoveryManager untuk peta shard tertentu.

 ShardMapManager smm = ShardMapManagerFactory.GetSqlShardMapManager(smmConnectionString,  
          ShardMapManagerLoadPolicy.Lazy);
          RecoveryManager rm = smm.GetRecoveryManager();

Dalam contoh ini, RecoveryManager diinisialisasi dari ShardMapManager. ShardMapManager yang berisi ShardMap juga sudah diinisialisasi.

Karena kode aplikasi ini memanipulasi peta shard itu sendiri, informasi masuk yang digunakan dalam metode pabrik (dalam contoh sebelumnya, smmConnectionString) harus menjadi informasi masuk yang memiliki izin baca-tulis pada database GSM yang dirujuk oleh string koneksi. Informasi masuk ini biasanya berbeda dari informasi masuk yang digunakan untuk membuka koneksi ke perutean yang bergantung pada data. Untuk informasi selengkapnya, lihat Menggunakan informasi masuk di klien database elastis.

Menghapus shard dari ShardMap setelah shard dihapus

Metode DetachShard mencopot shard yang diberikan dari peta shard dan menghapus pemetaan yang terkait dengan shard.

• Parameter lokasi adalah lokasi shard, khususnya nama server dan nama database, dari shard yang dicopot.
• Parameter shardMapName adalah nama peta shard. Ini hanya diperlukan ketika beberapa peta shard dikelola oleh manajer peta shard yang sama. Opsional.

Penting

Gunakan teknik ini hanya jika Anda yakin bahwa rentang untuk pemetaan yang diperbarui kosong. Metode di atas tidak memeriksa data untuk rentang yang dipindahkan, jadi yang terbaik adalah menyertakan cek masuk dalam kode Anda.

Contoh ini menghapus shard dari peta shard.

rm.DetachShard(s.Location, customerMap);

Peta shard mencerminkan lokasi shard di GSM sebelum penghapusan shard. Karena shard dihapus, diasumsikan kesengajaan, dan rentang kunci sharding tidak lagi digunakan. Jika tidak, Anda dapat menjalankan pemulihan titik waktu. untuk memulihkan shard dari titik waktu sebelumnya. (Dalam hal ini, ulas bagian berikut untuk mendeteksi inkonsistensi shard.) Untuk memulihkan, lihat Pemulihan titik waktu.

Karena diasumsikan penghapusan database disengaja, tindakan penghapusan administratif akhir adalah menghapus entri ke shard di manajer peta shard. Ini mencegah aplikasi secara tidak sengaja menulis informasi ke rentang yang tidak diharapkan.

Untuk mendeteksi perbedaan pemetaan

Metode DetectMappingDifferences memilih dan mengembalikan salah satu peta shard (baik lokal atau global) sebagai sumber kebenaran dan menyesuaikan pemetaan pada peta shard (GSM dan LSM).

rm.DetectMappingDifferences(location, shardMapName);

• Lokasi menentukan nama server dan nama database.
• Parameter shardMapName adalah nama peta shard. Ini hanya diperlukan ketika beberapa peta shard dikelola oleh manajer peta shard yang sama. Opsional.

Untuk mengatasi perbedaan pemetaan

Metode DetectMappingDifferences memilih salah satu peta shard (baik lokal atau global) sebagai sumber kebenaran dan menyesuaikan pemetaan pada peta shard (GSM dan LSM).

ResolveMappingDifferences (RecoveryToken, MappingDifferenceResolution.KeepShardMapping);

• Parameter RecoveryToken mengenumerasi perbedaan dalam pemetaan antara GSM dan LSM untuk shard tertentu.
• Enumerasi MappingDifferenceResolution digunakan untuk menunjukkan metode untuk menyelesaikan perbedaan antara pemetaan shard.
• MappingDifferenceResolution.KeepShardMapping direkomendasikan bahwa ketika LSM berisi pemetaan yang akurat dan oleh karena itu pemetaan dalam shard harus digunakan. Ini biasanya terjadi jika ada kegagalan: shard sekarang berada di server baru. Karena shard harus terlebih dahulu dihapus dari GSM (menggunakan metode RecoveryManager.DetachShard), pemetaan tidak lagi ada pada GSM. Oleh karena itu, LSM harus digunakan untuk membuat kembali pemetaan shard.

Melampirkan shard ke ShardMap setelah shard dipulihkan

Metode AttachShard melampirkan shard yang diberikan ke peta shard. Kemudian mendeteksi inkonsistensi peta shard dan memperbarui pemetaan agar sesuai dengan shard pada titik pemulihan shard. Diasumsikan bahwa database juga diubah namanya untuk mencerminkan nama database asli (sebelum shard dipulihkan), karena default pemulihan titik waktu ke database baru ditambahkan dengan tanda waktu.

rm.AttachShard(location, shardMapName)

• Parameter lokasi adalah nama server dan nama database, dari shard yang dilampirkan.
• Parameter shardMapName adalah nama peta shard. Ini hanya diperlukan ketika beberapa peta shard dikelola oleh manajer peta shard yang sama. Opsional.

Contoh ini menambahkan shard ke peta shard yang baru-baru ini dipulihkan dari titik waktu sebelumnya. Karena shard (yaitu pemetaan untuk shard di LSM) telah dipulihkan, hal tersebut berpotensi tidak konsisten dengan entri shard di GSM. Di luar kode contoh ini, shard dipulihkan dan diganti namanya menjadi nama asli database. Karena telah dipulihkan, diasumsikan pemetaan di LSM adalah pemetaan tepercaya.

rm.AttachShard(s.Location, customerMap);
var gs = rm.DetectMappingDifferences(s.Location);
   foreach (RecoveryToken g in gs)
    {
    rm.ResolveMappingDifferences(g, MappingDifferenceResolution.KeepShardMapping);
    }

Memperbarui lokasi shard setelah kegagalan lokasi geografi (pemulihan) shard

Jika ada kegagalan lokasi geografi, database sekunder dibuat agar dapat ditulis dan menjadi database utama baru. Nama server, dan berpotensi database (tergantung pada konfigurasi Anda), mungkin berbeda dari primer asli. Oleh karena itu entri pemetaan untuk shard di GSM dan LSM harus diperbaiki. Demikian pula, jika database dipulihkan ke nama atau lokasi yang berbeda, atau ke titik waktu sebelumnya, ini dapat menyebabkan inkonsistensi dalam peta shard. Shard Map Manager menangani distribusi koneksi terbuka ke database yang benar. Distribusi didasarkan pada data dalam peta shard dan nilai kunci sharding yang menjadi target permintaan aplikasi. Setelah kegagalan lokasi geografis, informasi ini harus diperbarui dengan nama server yang akurat, nama database, dan pemetaan shard database yang dipulihkan.

Praktik terbaik

Kegagalan lokasi geografis dan pemulihan adalah operasi yang biasanya dikelola oleh admin cloud aplikasi yang dengan sengaja menggunakan fitur kelangsungan bisnis Azure SQL Database. Perencanaan kelangsungan bisnis memerlukan proses, prosedur, dan langkah-langkah untuk memastikan bahwa operasi bisnis dapat dilanjutkan tanpa gangguan. Metode yang tersedia sebagai bagian dari kelas RecoveryManager harus digunakan dalam alur kerja ini untuk memastikan GSM dan LSM tetap diperbarui berdasarkan tindakan pemulihan yang diambil. Ada lima langkah dasar untuk memastikan GSM dan LSM mencerminkan informasi yang akurat setelah peristiwa kegagalan. Kode aplikasi untuk menjalankan langkah-langkah ini dapat diintegrasikan ke dalam alat dan alur kerja yang ada.

1. Mengambil RecoveryManager dari ShardMapManager.
2. Mencopot shard lama dari peta shard.
3. Melampirkan shard baru ke peta shard, termasuk lokasi shard baru.
4. Mendeteksi inkonsistensi dalam pemetaan antara GSM dan LSM.
5. Menyelesaikan perbedaan antara GSM dan LSM, memercayai LSM.

Contoh ini melakukan langkah-langkah berikut:

1. Menghapus shard dari Peta Shard yang mencerminkan lokasi shard sebelum peristiwa kegagalan.

2. Melampirkan shard ke Peta Shard yang mencerminkan lokasi shard baru (parameter "Configuration.SecondaryServer" adalah nama server baru tetapi dengan nama database yang sama).

3. Mengambil token pemulihan dengan mendeteksi perbedaan pemetaan antara GSM dan LSM untuk setiap shard.

4. Menyelesaikan inkonsistensi dengan memercayai pemetaan dari LSM masing-masing shard.

   var shards = smm.GetShards();
   foreach (shard s in shards)
   {
     if (s.Location.Server == Configuration.PrimaryServer)
         {
          ShardLocation slNew = new ShardLocation(Configuration.SecondaryServer, s.Location.Database);
          rm.DetachShard(s.Location);
          rm.AttachShard(slNew);
          var gs = rm.DetectMappingDifferences(slNew);
          foreach (RecoveryToken g in gs)
            {
               rm.ResolveMappingDifferences(g, MappingDifferenceResolution.KeepShardMapping);
            }
        }
    }
   

Konten terkait

Belum menggunakan alat database elastis? Lihat Panduan Memulai kami. Jika memiliki pertanyaan, hubungi kami di halaman pertanyaan Tanya Jawab Microsoft untuk SQL Database dan untuk permintaan fitur, tambahkan ide-ide baru atau ambil suara terbanyak untuk ide yang sudah ada di forum umpan balik SQL Database.