Cara untuk skala otomatis server MySQL?

Saya menjalankan situs yang memiliki lonjakan lalu lintas tinggi dan karena itu solusi penskalaan otomatis sangat menguntungkan untuk kasus ini. Saat ini server web dapat secara otomatis skala otomatis tetapi bottleneck ada di server MySQL.

• Saya sudah mencoba dengan Amazon RDS Multi-AZ tetapi butuh 15 menit untuk meng-upgrade basis data 12 GB dengan beberapa menit downtime. Ini sangat membantu ketika saya sudah tahu bahwa lonjakan lalu lintas akan terjadi pada saat-saat tertentu.
• Saya juga mempertimbangkan Xeround. Ini mungkin solusi terbaik walaupun cukup mahal untuk database sebesar ini. Pokoknya itu bukan pilihan karena saya secara hukum membutuhkan database untuk berada di Uni Eropa.
• Saya telah membaca tentang Scalr tetapi tidak yakin apakah itu bisa membantu dan bagaimana caranya.
• Saya telah melihat bahwa banyak penyedia cloud hosting menawarkan solusi penskalaan vertikal yang saya pikir memiliki 0 downtime (tidak yakin apakah itu benar-benar mungkin, sejauh yang saya tahu mereka menggunakan Xen hypervisor). Itu bisa menjadi solusi tapi saya bertanya-tanya apakah itu tidak downtime dan bagaimana konfigurasi MySQL (dan banyak hal lain pada OS) dapat meningkatkan juga tanpa downtime.
• Saya sudah mencoba dengan server MySQL slave tetapi tidak membantu sama sekali.
• Saya menggunakan memcache yang banyak membantu tetapi tidak cukup. Saya perlu memutakhirkan karena menulis, bukan hanya karena membaca.

Ada saran? Terima kasih sebelumnya

Sebenarnya, solusi yang lebih sederhana adalah dengan mencoba menambahkan Memcached ke stack Anda untuk menghemat beban DB. Ini secara drastis dapat menghemat beban, dan jauh lebih sederhana daripada mencoba memecahkan masalah berdiri server dengan cepat (kesulitan rendah), dan kemudian mencari sinkronisasi MySQL yang cepat (kesulitan yang jauh lebih tinggi.)

http://toblender.com/?s=memcached

Untuk mengatasi masalah terlalu banyak menulis, perbaikan yang paling umum adalah menambahkan memori ke server (sa set kerja yang lebih besar dapat disimpan dalam RAM), menempatkan DB Anda pada disk lebih cepat (SSD adalah solusi yang baik, tetapi mahal), atau sharding (yang mahal di server tambahan dan kompleksitas).

Cara lain untuk mengurangi beban penulisan DB adalah menggabungkan penyimpanan data dalam-memori (seperti Redis) untuk menangani data yang sering berubah, dan jika perlu secara berkala, tulis kembali ke DB utama Anda.

Anda harus mempertimbangkan menggunakan Topologi Star

Inilah yang saya usulkan

• One Write Master (alias WM)
• One Distribution Master (alias DM)
• Lima (5) Baca Slave Server (alias RSS)

Persiapkan Topologi Seperti Ini

Langkah 01: Setup 5 RSS dengan opsi-opsi umum ini

[mysqld]
skip-innodb
key_buffer_size=1G

Ini akan menyebabkan semua tabel dibuat dimuat sebagai MyISAM Storage Engine

Langkah 02: Atur DM dan semua Server RS

• mysqldump skema semua tabel dari WM ke file schemadump
• memuat file schemadump ke DM dan semua 5 RSS
• jalankan ALTER TABLE tblname ROW_FORMAT=Fixed;pada semua tabel di RSS
• jalankan ALTER TABLE tblname ENGINE=BLACKHOLE;pada semua tabel di DM
• hanya data mysqldump (menggunakan --no-create-info) ke datadump
• memuat datadump di semua 5 RSS

Langkah 03: Setup Replikasi Dari DM ke semua 5 RSS

Langkah 04: Setup Replikasi Dari WM ke DM

AKHIR SETUP

Inilah cara kerja mekanisme Baca / Tulis Anda

• Semua tulisan Anda (INSERT, UPDATE, DELETEs) muncul di WM
• SQL direkam dalam log biner dari DM (Tidak ada data aktual berada di DM)
• Setiap RSS adalah Read Slave untuk DM
• Semua bacaan Anda muncul di RSS

Sekarang di sini adalah tangkapan ...

• Anda menggunakan RSS 1-4 untuk dibaca pada awalnya
• Gunakan RSS ke-5 untuk memutar RSS lain
  • Anda menjalankan service mysql stopRSS ke-5
  • Putar RSS lain
  • Salin / var / lib / mysql dan /etc/my.cnf dari RSS ke-5 ke RSS yang baru diputar
  • Anda menjalankan service mysql stopRSS ke-5
  • Anda menjalankan service mysql stopRSS baru

Anda dapat menggunakan RSS # 5 untuk memutar server baru berulang kali

Pada sidenote, jangan gunakan XEROUND untuk WM atau DM karena mereka tidak mendukung mesin penyimpanan InnoDB atau BLACKHOLE.

Saya harap ide-ide ini membantu.

Jika Anda menggunakan Innodb, Anda harus mempertimbangkan multi-master Mysql yang dikelola oleh Galera . Itu membuat pengaturan multi-master mysql lebih mudah, dan seharusnya membuat Anda lebih mudah untuk "semi" skala otomatis.

Jika ini adalah aplikasi yang Anda atau perusahaan Anda sedang tulis, Anda dapat mempertimbangkan untuk pindah ke desain (dipartisi) sharded untuk aplikasi tersebut. Tapi pecahan bisa menjadi rumit. Berikut ini tautan untuk membantu Anda memulai.

Saya berasumsi Anda telah "menyetel" file konfigurasi mysql, seperti dalam memori yang sesuai dialokasikan dll.

Apakah ini di rak yang Anda kendalikan, atau di awan? 12GB adalah basis data yang sangat kecil relatif terhadap ukuran disk yang tersedia. Letakkan di RAID1 atau RAID10 array SSD SLC kecil dan latensi penulisan Anda akan hilang.

The Intel 311 series 20GB SLC SSD ($ 120 masing-masing) akan melakukan pekerjaan cemerlang.

Jika database lebih besar, Anda dapat mencapai hasil yang sama spektakulernya dengan memindahkan database Anda ke target iSCSI pada server ZFS SAN (dibangun di perangkat keras server komoditas menggunakan Nexenta, OpenIndiana, FreeNAS, atau apa pun) dan menyiapkan cermin SSD serupa untuk cache tulis ZIL Anda. Dalam semua keadaan kecuali yang paling luar biasa, Gigabit Ethernet lebih dari cukup untuk memindahkan lalu lintas basis data iSCSI.