SIOS SANless clusters

SIOS SANless clusters High-availability Machine Learning monitoring

  • Home
  • Produk
    • SIOS DataKeeper for Windows
    • SIOS Protection Suite for Linux
  • Berita dan acara
  • Cluster server penyederhanaan
  • Kisah sukses
  • Hubungi kami
  • English
  • 中文 (中国)
  • 中文 (台灣)
  • 한국어
  • Bahasa Indonesia
  • ไทย

Mengatasi Masalah Kinerja Dengan Grup Alwayson SQL Server

Februari 5, 2018 by Jason Aw Leave a Comment

Asynchronous vs synchronous replication on AlwaysOn

Dari menghadiri sesi di PASS Summit minggu ini, sudah menjadi jelas bahwa AlwaysOn adalah topik hangat dengan sekitar enam sesi yang didedikasikan untuk solusi ini. Satu hal yang saya pelajari adalah bahwa walaupun solusinya tentu memiliki aplikasinya, sebagian besar penerapan yang berhasil didasarkan pada penggunaan AlwaysOn secara asinkron. Alasan orang menghindari opsi replikasi sinkron adalah bahwa overhead terlalu besar. Selama replikasi sinkron, menulis harus dilakukan pada replika sebelum dilakukan pada sumbernya. Dalam pengujian yang telah saya lakukan, overhead ini bisa dikenalkan sebanyak 68%.

Sebagai contoh, dalam sebuah tes dimana saya memiliki database yang menyisipkan sekitar 1.000.000 baris per detik dan kita mengukur throughput pada file log, kita melihat bahwa tanpa mirroring di tempat kita menulis sekitar 400 MBps. Begitu kita mulai mereplikasi database itu dengan AlwaysOn Availability Groups di LAN 10 Gbps, kita melihat penurunan kinerja sebesar 68%, dengan database khusus ini melambat menjadi sekitar 250.000 sisipan per detik.

Asynchronous vs synchronous replication on AlwaysOn
Gambar 1 – MBps ditulis ke database SQL Server sebelum dan sesudah AlwaysOn Synchronous Mirroring

Jika Anda mempertimbangkan solusinya sebagai pengganti cluster failover Anda, drop off ini harus menjadi perhatian utama Anda. Untuk mencapai failover otomatis yang biasa Anda gunakan dalam failover clustering, Anda harus menggunakan mirroring sinkron, yang berarti Anda harus hidup dengan hit kinerja ini. Umumnya ini tidak akan dapat diterima, yang mungkin mengapa Anda tidak mendengar para ahli merekomendasikan konfigurasi semacam itu secara teratur.

Jadi apa yang harus kamu lakukan?

Jika Anda tetap dengan Anda cluster failover tradisional dan SAN? Bagaimana jika Anda ingin memanfaatkan fast, high speed storage seperti Fusion-io? Kalau begitu, Anda tidak bisa menggunakan cluster tradisional … atau bisa?

Kabar baiknya adalah Anda bisa membangun cluster tanpa SAN dan melakukan semuanya tanpa biaya, keterbatasan dan biaya overhead dengan AlwaysOn Availability Groups (lebih pada keterbatasan dan biaya di posting blog saya berikutnya). Dengan menggunakan DataKeeper Cluster Edition Anda dapat membangun cluster tanpa penyimpanan bersama DAN overhead yang terkait dengan replikasi Synchronous mendekati 10% vs mendekati 70% yang kita lihat dengan AlwaysOn Availability Groups.

Datang ke stan 351 di #SQLPASS dan saya akan dengan senang hati menunjukkan bagaimana solusinya bekerja.

Direproduksi dengan izin dari https://clusteringformeremortals.com/2012/11/09/how-to-overcome-the-performance-problems-with-sql-server-alwayson-availability-groups-sqlpass/

Filed Under: Cluster server penyederhanaan Tagged With: Asinkron, selalu, Sinkronis

Tulisan Terbaru

  • Demo SIOS LifeKeeper: Cara Rolling Update dan Failover Melindungi PostgreSQL di AWS
  • Cara Menilai Apakah Kartu Jaringan Saya Perlu Diganti
  • Teknologi SIOS Akan Mendemonstrasikan Perangkat Lunak Pengelompokan Ketersediaan Tinggi untuk Aplikasi Misi-Kritis di Red Hat Summit, Milestone Technology Day dan XPerience Day, serta SQLBits 2025
  • Kecerdasan Aplikasi Terkait dengan Ketersediaan Tinggi
  • 10 Pertimbangan dalam Memilih Solusi Ketersediaan Tinggi di Lingkungan Nutanix

Posting Terpopuler

Bergabunglah dengan Milis Kami

Copyright © 2025 · Enterprise Pro Theme on Genesis Framework · WordPress · Log in