Definisi masalah

Pengguna kami membutuhkan kemampuan untuk meminta basis data yang sebagian besar mutakhir. Data dapat basi hingga 24 jam dan itu dapat diterima. Apa yang akan menjadi pendekatan biaya terendah untuk mendapatkan dan menjaga basis data kedua dengan salinan produksi? Apakah ada pendekatan yang tidak saya pikirkan?

Beban kerja

Kami memiliki aplikasi pihak ketiga yang kami gunakan untuk memantau aktivitas perdagangan saham. Pada siang hari, banyak perubahan kecil terjadi sebagai bagian dari berbagai aliran pekerjaan (ya, perdagangan ini valid. Tidak, ini mencurigakan, dll). Pada malam hari, kami melakukan operasi berbasis set yang besar (memuat perdagangan hari sebelumnya).

Solusi dan masalah saat ini

Kami menggunakan snapshot basis data . Pukul 10 malam kami turun dan membuat ulang snapshot. Pemrosesan ETL kemudian dimulai. Ini jelas membebani disk kami, tetapi memungkinkan pengguna kami kemampuan untuk query database tanpa mengunci database (mereka menggunakan ujung depan Access). Mereka menggunakannya larut malam dan dini hari sehingga mereka akan melihat waktu henti.

Masalah dengan pendekatan ini adalah dua kali lipat. Yang pertama adalah bahwa jika pemrosesan malam gagal, dan itu tidak terlalu jarang, kami bisa mengembalikan database yang mengakibatkan snapshot dijatuhkan. Masalah lainnya adalah waktu pemrosesan kami melewati SLA kami. Kami berusaha mengatasi ini dengan bekerja sama dengan vendor setelah mengidentifikasi pertanyaan yang ditulis dengan buruk dan kurangnya pengindeksan. Database snapshot juga merupakan penyebab pelambatan ini sebagaimana dibuktikan oleh perbedaan kecepatan ketika hadir versus tidak --- mengejutkan, saya tahu.

Pendekatan dipertimbangkan

Clustering

Kami memiliki pengelompokan basis data yang dihidupkan tetapi itu tidak menjawab kebutuhan membuat data tersedia dan hanya secara umum mempersulit kehidupan admin. Sejak itu dimatikan.

Replikasi SQL Server

Kami mulai melihat replikasi minggu lalu. Teori kami adalah bahwa kami dapat membuat katalog kedua berdiri dan disinkronkan dengan basis data produksi. Sebelum memulai ETL, kami akan memutuskan koneksi dan hanya mengaktifkannya kembali setelah proses ETL selesai.

Admin memulai dengan Replikasi Snapshot tetapi dia khawatir perlu beberapa hari penggunaan CPU yang tinggi untuk menghasilkan snapshot serta konsumsi disk yang diperlukan. Dia menunjukkan bahwa tampaknya untuk menulis semua data ke file fisik sebelum dikirim ke pelanggan sehingga basis data .6TB kami akan menelan biaya 1,8TB dalam biaya penyimpanan. Juga, jika perlu beberapa hari untuk menghasilkan snap, maka itu tidak akan cocok dengan SLA yang diinginkan.

Setelah membaca artikel yang bagus, sepertinya Snapshot mungkin merupakan cara untuk menginisialisasi pelanggan tetapi kemudian kami ingin beralih ke Replikasi Transaksional agar tetap sinkron setelah itu. Saya berasumsi bahwa menghidupkan / mematikan replikasi transaksional tidak akan memaksa reinisialisasi penuh? Kalau tidak, kita akan merusak jendela waktu kita

Mirroring Basis Data

Basis data kami berada dalam mode pemulihan LENGKAP sehingga mirroring basis data adalah pilihan, tetapi saya tahu lebih sedikit tentang hal itu daripada Replikasi. Saya memang menemukan jawaban SO yang mengindikasikan "Pencerminan basis data mencegah data diakses secara langsung, data pencerminan hanya dapat diakses melalui snapshot basis data."

Pengiriman Log

Kedengarannya seperti pengiriman log mungkin juga menjadi pilihan tetapi ini adalah hal lain yang tidak saya ketahui. Apakah ini akan menjadi solusi biaya yang lebih rendah (implementasi dan pemeliharaan) daripada yang lain? Berdasarkan komentar Remus, "Pengiriman log memungkinkan akses hanya baca ke salinan replika, tetapi akan memutuskan koneksi semua pengguna saat menerapkan log cadangan berikutnya yang diterima (mis. Setiap 15-30 menit)." Saya tidak yakin berapa lama waktu henti itu akan diterjemahkan sehingga dapat menyebabkan pengguna cemas.

Sinkronisasi MS

Saya hanya mendengar tentang menggunakan Sinkron pekan terakhir ini dan belum menyelidikinya. Aku benci untuk memperkenalkan teknologi baru untuk sesuatu dengan visibilitas tinggi seperti masalah ini, tetapi jika itu pendekatan terbaik, biarlah.

SSIS

Kami melakukan banyak SSIS di sini sehingga menghasilkan beberapa ratus paket SSIS untuk menjaga sinkronisasi sekunder adalah pilihan bagi kami, meskipun yang jelek . Saya bukan penggemar melakukan ini karena itu banyak overhead pemeliharaan Saya lebih suka tim saya tidak mengambil.

Snapshot "ajaib" SAN

Di masa lalu, saya pernah mendengar admin kami menggunakan beberapa teknologi SAN untuk membuat cadangan instan seluruh disk. Mungkin ada beberapa sihir EMC yang dapat digunakan untuk membuat salinan uberquick dari mdf / ldf dan kita kemudian dapat melepaskan / melampirkan database target.

Cadangkan dan pulihkan

Saya pikir kami mengambil backup penuh seminggu sekali, diferensial setiap malam dan tlog setiap 15 menit. Jika pengguna bisa hidup dengan pemadaman 3-4 jam untuk pengembalian penuh, saya kira ini mungkin pendekatan.

Kendala

Windows 2008 R2, SQL Server 2008 R2 (Edisi Perusahaan), VMWare v5 Edisi Enterprise, penyimpanan EMC SAN dengan drive yang dipetakan ke file vmdk, cadangan penanganan cadangan, dan .6TB data dalam katalog sumber. Ini adalah aplikasi pihak ketiga yang kami sediakan di rumah. Memodifikasi struktur mereka umumnya disukai. Para pengguna tidak dapat pergi tanpa menanyakan database dan menolak untuk dibatasi dengan secara proaktif mengidentifikasi tabel yang mereka monitor untuk melakukan pekerjaan mereka.

DBA kami adalah kontraktor murni saat ini. Full-timer telah berlayar dan kami belum menggantinya. Admin aplikasi tidak berpengalaman dalam masalah SQL Server dan kami memiliki tim admin Storage / VM yang dapat membantu / menghambat upaya ini. Tim pengembangan saat ini tidak terlibat tetapi dapat didaftar berdasarkan pendekatan. Jadi lebih mudah untuk mengimplementasikan dan memelihara solusi akan lebih disukai.

Saya, saya berada di sisi pengembangan rumah sakit sehingga saya hanya dapat mengusulkan pendekatan dan tidak harus berurusan dengan sisi administrasi hal-hal. Jadi tanpa waktu di pelana admin, saya ragu untuk mengatakan satu pendekatan akan lebih unggul dari yang lain --- semuanya tampak hebat menurut surat kabar. Saya sepenuhnya bersedia untuk menjalankan segala arah yang Anda sarankan karena seperti yang saya lihat, itu hanya akan membuat saya lebih berharga sebagai seorang profesional DB. Saya memiliki gerobak dorong tetapi tidak ada jubah holocaust yang tersedia .

Pertanyaan-pertanyaan Terkait

Suntingan

Untuk menjawab pertanyaan @ onpnt

Penerimaan latensi data

Pengguna saat ini melihat data yang tertinggal hingga 24 jam. Data hanya terkini pada 2200

Jumlah data berubah dalam menit, jam, dan hari tertentu. Tidak yakin bagaimana mengukurnya. Jam kerja, mungkin ratusan perubahan per jam. Pemrosesan setiap malam, jutaan baris per hari kerja

Konektivitas ke sekunder

Jaringan internal, host virtual terpisah dan penyimpanan khusus

Baca persyaratan pada instance sekunder

Grup Windows akan memiliki akses baca ke tabel sekunder, semua

Up-waktu dari instance sekunder

Tidak ada definisi yang kuat tentang persyaratan up-time. Pengguna ingin selalu tersedia tetapi apakah mereka bersedia membayar untuk itu, mungkin tidak begitu banyak. Secara realistis, saya katakan 23 jam sehari sudah cukup.

Perubahan skema yang ada dan semua objek

Modifikasi yang jarang, mungkin sekali per kuartal untuk objek tabel. Mungkin sebulan sekali untuk objek kode.

Keamanan

Tidak ada kebutuhan keamanan khusus. Izin produksi akan cocok dengan izin salinan. Meskipun ketika saya memikirkannya, kita bisa mencabut pengguna membaca akses ke prod dan hanya membolehkan mereka membaca salinannya ... Bukan keharusan.

Selat @darin

Mengembalikan ke snapshot bisa menjadi pilihan tapi saya pikir ada beberapa alasan mereka tidak mengejar itu. Saya akan periksa dengan admin

@cfradenburg

Asumsi saya adalah bahwa kami hanya akan menggunakan salah satu dari pendekatan ini tetapi itu adalah poin yang baik bahwa mengembalikan akan merusak teknologi sinkronisasi "lainnya". Mereka sedang menyelidiki melakukan menggunakan sihir snapshot EMC. Seperti yang dijelaskan admin, mereka akan mengambil snapshot pada 1900 dan memigrasikan gambar ke zona sekunder. Itu harus selesai pada 2200 dan kemudian mereka akan melakukan detach dan reattach dari database sekunder.

Bungkus

2012-10-29 Kami mengevaluasi sihir snapshot EMC dan beberapa opsi replikasi lainnya, tetapi DBA memutuskan bahwa mereka dapat menentukan Mirroring yang terbaik. Terpilih jawabannya karena mereka semua membantu dan memberi saya banyak pilihan serta "pekerjaan rumah" untuk diselidiki.

sql-server sql-server-2008-r2 replication

— billinkc
sumber

Apakah mungkin bagi Anda untuk mengembalikan snapshot database ketika ada masalah? Itu akan membawamu kembali ke tempat db berada ketika snapshot diambil. Anda kemudian dapat mengambil snapshot baru, memperbaiki masalah pemrosesan Anda dan melanjutkan. Dengan pengiriman log W / R / T, Anda tidak harus mengembalikan cadangan log ke salinan Anda sepanjang hari, pada saat yang sama saat Anda membawanya. Anda bisa membiarkannya menumpuk, lalu mengembalikannya dalam banyak. Ini meminimalkan gangguan pengguna pada salinan karena Anda dapat memilih waktu yang lambat untuk melakukannya, dan itu berarti bahwa salinan tidak akan berubah sepanjang hari.

— Selat darin

Jika Anda perlu mengembalikan database secara berkala, setiap metode yang cepat akan perlu diinisialisasi ulang. Jika Anda mengembalikan cadangan DIFF atau LOG, pemulihan penuh perlu dilakukan untuk menyinkronkan lagi DB. Hal yang sama dengan mirroring dan saya tidak yakin tentang replikasi. Taruhan terbaik Anda mungkin untuk melihat apa yang bisa dilakukan EMC untuk Anda. Saya tahu ketika saya berbicara dengan NetApp mereka memiliki solusi yang akan melakukan apa yang Anda cari tetapi itu adalah alat tambahan.

— cfradenburg

6

Memodifikasi struktur mereka umumnya disukai

Replikasi kemungkinan besar keluar dan saya akan membuang Sync sebelum itu. (dari tes transacitonal tinggi kehidupan nyata pada Sync Framework)

Jika 3-4 jam merupakan pengecualian latensi data Anda, pengiriman log mungkin akan menjadi taruhan terbaik Anda di sini hanya pada salinan read-only. Tetapi berapa banyak perubahan yang terjadi di log? temukan bahwa memantau itu untuk melihat seberapa cepat dan seberapa banyak Anda perlu mendorong.

Jika Anda tidak dapat pergi ke Mirroring atau meningkatkan ke perusahaan 2012, itu sudah keluar meskipun itu akan menjadi strategi yang baik jika Anda dapat pergi Enterprise jika tidak di dalamnya.

SSIS tidak dimaksudkan untuk hanya membuang data tetapi dapat melakukannya. Anda melihat terlalu banyak dalam hal transformasi pencarian dan tugas akan mahal dalam waktu dan sumber daya. Meskipun, seperti yang saya katakan, itu bisa melakukannya.

Sungguh, akan ada penyempitan pilihan yang berbeda berdasarkan menjawab beberapa pertanyaan

Penerimaan latensi data
Jumlah data berubah dalam satu menit, jam dan hari tertentu Konektivitas ke sekunder
Baca persyaratan pada instance sekunder
Up-waktu dari instance sekunder
Perubahan skema yang ada dan semua objek
Keamanan

— onpnt
sumber

4

Ini akan menjadi salah satu hal yang perlu Anda coba sendiri untuk menemukan yang terbaik. Replikasi bisa rumit sehingga sementara mungkin tidak ada biaya moneter langsung akan ada biaya administrasi untuk mempertahankannya.

Untuk memperluas Pengiriman Log, Anda tidak perlu mengembalikan log setiap 15-30 menit. Jika Anda memilih, Anda bisa melakukannya setiap empat jam atau sekali sehari. Solusi yang mirip dengan ini yang telah saya terapkan adalah melakukan pencadangan penuh mingguan dan mengembalikan ke DB pelaporan (yang dapat memakan waktu cukup lama dan terjadi pada akhir pekan). Selama minggu ini, cadangan diferensial diambil dan dikembalikan ke database pelaporan setiap malam. Pengguna harus mendapatkan boot sebelum pemulihan tetapi karena DB pelaporan adalah aplikasi jam kerja, tidak ada masalah dengan itu. Data berumur satu hari yang seharusnya tidak menjadi masalah berdasarkan kebutuhan Anda.

Untuk menggunakan mirroring basis data untuk ini, Anda perlu membeli Enterprise untuk dapat menggunakan snapshot jika Anda belum menjalankan Enterprise. Itu juga tidak akan membuat data 100% up to date karena snapshot perlu dihapus (artinya semua pengguna harus keluar) dan kemudian diciptakan kembali untuk mendapatkan data baru. Namun, ini akan lebih sedikit waktu daripada mengembalikan log atau metode yang saya jelaskan di atas.

Jika memutakhirkan ke SQL 2012 merupakan opsi, dimungkinkan untuk menyiapkan sekunder hanya-baca yang akan terus diperbarui dengan basis data primer. Saya hanya menyebutkan ini karena itu kemungkinan akan menjadi solusi paling lancar.

— cfradenburg
sumber

4

Seperti halnya orang yang menggunakan replikasi transaksional, itu kedengarannya cocok untuk situasi Anda. Beberapa catatan:

Anda tidak perlu menginisialisasi pelanggan dengan snapshot. Anda dapat mengambil cadangan penerbit dan menginisialisasi dengan itu.
Anda dapat menjeda pengiriman perintah ke pelanggan hanya dengan menghentikan pekerjaan distribusi (itu hanya pekerjaan SQL Agent baik di distributor atau pelanggan tergantung pada apakah Anda telah mengaturnya sebagai push atau pull berlangganan, masing-masing). Berhati-hatilah dengan retensi Anda di distributor sehingga Anda memiliki cukup sejarah sehingga Anda dapat mengejar ketinggalan.
Anda dapat mengubah pengindeksan pada pelanggan untuk mengakomodasi beban kerja yang akan dilakukan di sana (mungkin tipe pelaporan) daripada harus menerima pengindeksan dari penerbit Anda (mungkin tipe OLTP) jika Anda mau.

— Ben Thul
sumber

Sinkronisasi basis data SQL Server