Apakah tidak bijaksana menjalankan replikasi pada server fisik yang sama?

Saya sedang merenungkan pengaturan replikasi Master-Slave untuk basis data saya. Server slave akan digunakan untuk redundansi dan mungkin server laporan. Namun, salah satu masalah terbesar yang saya hadapi adalah bahwa kita sudah memaksimalkan kekuasaan di pusat data kami. Jadi menambahkan server fisik lain bukanlah suatu pilihan.

Server database kami yang ada saat ini kurang dimanfaatkan sejauh cpu (rata-rata beban tidak pernah benar-benar mencapai di atas 1 pada quad-core). Jadi ide utamanya adalah melemparkan beberapa drive baru dan menggandakan memori (dari 8GB menjadi 16) dan menjalankan instance mysql kedua pada mesin fisik yang sama. Setiap instance akan memiliki disk terpisah untuk database.

Apakah ada yang salah dengan ide ini?

Sunting (info lebih lanjut): Saya (untungnya) tidak pernah mengalami hal yang cukup buruk untuk menjatuhkan server, tetapi saya mencoba membuat rencana ke depan. Kami tentu saja memiliki cadangan malam yang dapat kami pulihkan. Tapi saya pikir memiliki data yang berlebihan pada disk terpisah akan memberikan solusi yang lebih cepat jika drive server master gagal (jelas tidak jika seluruh mesin padam).

Sedangkan untuk aspek pelaporan, setiap tabel yang akan kami laporkan adalah MyIsam. Jadi melakukan pembacaan mahal pada tabel yang sama yang sedang ditulis untuk dapat menghambat server. Asumsi saya adalah memiliki server slave untuk dilaporkan tidak akan mempengaruhi server utama selama kita melemparkan RAM yang cukup padanya (karena beban CPU belum menjadi masalah).

Untuk redundansi dalam hal keandalan sistem dan keamanan data yang menjalankan slave pada mesin yang sama dengan master tidak menawarkan apa-apa (atau mendekati). Jika sesuatu yang cukup buruk untuk menjatuhkan tuan terjadi, itu mungkin akan menjatuhkan budak juga.

Untuk memisahkan pengguna murni untuk alasan hak akses, RDBMS yang baik akan menawarkan cara yang lebih efektif untuk melakukan itu.

Menjalankan dua database pada mesin yang sama akan membutuhkan lebih banyak RAM untuk berjalan pada efisiensi yang sama karena kedua database akan bersaing untuk mendapatkan ruang untuk menjaga mereka berbagai buffer dan cache. Mungkin ada manfaat kinerja melalui segregasi IO-load, jika datafile untuk slave berada pada drive fisik yang berbeda dari master. Dalam hal ini Anda dapat menjalankan laporan kompleks yang membutuhkan banyak pembacaan disk terhadap slave tanpa bersaing dengan master untuk drive IO bandwidth.

Sunting: seperti yang disebutkan DTest dalam komentarnya di bawah ini, satu kemungkinan manfaat lain dari DB budak (bahkan jika pada drive yang sama dengan master) adalah bahwa pertanyaan jangka panjang yang kompleks pada budak yang mungkin dapat menyebabkan masalah penguncian untuk hari berikutnya. Permintaan -hari yang berjalan pada master lebih aman. Meskipun Anda masih lebih baik memiliki budak pada drive yang berbeda karena pertanyaan signifikan seperti itu cenderung menyebabkan masalah pertentangan IO.

Tidak jelas bagi saya bagaimana ini memecahkan masalah Anda. Tidak ada redundansi karena itu pada perangkat keras fisik yang sama, kernel OS yang sama, binari MySQL yang sama, mungkin disk yang berbeda tetapi pada pengontrol penyimpanan yang sama, dll. Dan alasan untuk pelaporan DB adalah untuk membongkar permintaan dari OLTP DB dan sebagai itu semua ada di kit yang sama, dari mana kekuatan ekstra itu berasal? Atau ada hal lain yang Anda coba dapatkan dari pengaturan ini?

Salah satu kegunaan yang mungkin untuk ini adalah untuk memisahkan pengguna entah bagaimana mungkin, tapi sekali lagi, saya akan berpikir itu bisa dilakukan dengan GRANT.

Memang dianggap tidak bijaksana, apakah Anda hanya mencoba mengambil keuntungan dari lebih banyak inti? Apa tujuan dari pertimbangan desain baru?

(diposting sebagai jawaban, bukan komentar untuk membuat utas percakapan tetap fokus)

Ini bisa menjadi pedang bermata dua

Anda dapat menjalankan beberapa instance mysql sebagai read-only slave di server yang sama dengan master, asalkan setiap instance MySQL berada pada disk yang berbeda. Ini hanya diinginkan jika Anda menjalankan versi MySQL yang lebih lama yang tidak memanfaatkan banyak core (CPU). Versi terbaru dari MySQL dapat disesuaikan untuk benar-benar menggunakan Multiple CPU sehingga tidak perlu untuk mengakses banyak core dengan menjalankan beberapa instance MySQL.

Pada saat yang sama, itu juga merupakan ide yang sangat buruk. Banyak klien saya telah melakukan ini untuk menghemat uang dengan membeli server bare metal atau VM. Setiap lonjakan beban server dapat memengaruhi semua instans MySQL yang berjalan karena kueri buruk, kueri lambat, terlalu banyak koneksi, penggunaan kehabisan memori, kehabisan memori server, meronta-ronta cache, dan sebagainya, dalam salah satu instance MySQL. Ini juga menambah kompleksitas aplikasi dengan harus mengakses instance MySQL yang berbeda melalui nomor port mereka dan Anda juga akan berada di bawah kendali TCP / IP.

Saya akan memotong cross replikasi pada server yang berbeda yaitu budak A pada B dan budak B pada A. Kami menjalankan beberapa instance pada server kami dan tidak memiliki masalah karena server MySQL kami tidak pada kapasitas. Gagal menjalankan server jauh lebih cepat daripada mengembalikan dari cadangan.