Bagaimana cara mengoptimalkan arsitektur basis data untuk situs volume tinggi?

Pertanyaan kurang tentang item konfigurasi Mysql tertentu, tetapi lebih banyak tentang penanganan beberapa basis data, membagi baca dan tulis ke beberapa server basis data, master + master? Master + Beberapa Budak?

Apa yang orang punya pengalaman terbaik, dan adakah contoh tentang bagaimana mencapai ini?

Kami memiliki pengalaman yang cukup luas dari kluster MySQL - dan Percona telah bekerja bersama kami pada beberapa kesempatan ketika mendorong batas-batas konfigurasi yang kompleks.

Dapatkah Magento secara alami menangani budak hanya baca

Magento adalah native mampu membelah off membaca / menulis ke server database yang berbeda (dengan pengecualian dari beberapa rilis rusak, misalnya EE 1.11.) - yang memungkinkan Anda untuk mengimbangi selectbeban untuk tambahan (atau lebih) server (s); dan meneruskan semua update/writepertanyaan ke master tunggal.

Kapan saya harus melakukannya?

Ini pertanyaan yang lebih tepat. Dengan sistem operasi Magento khusus seperti MageStack - ini menjadi lebih umum untuk teknik caching canggih sisi server built-in tersedia dan mudah digunakan (seperti caching front end Varnish dan caching back end Redis).

Secara historis, Magento tidak pernah terikat oleh MySQL - melainkan PHP. Tetapi karena Varnish dan Full Page Caching (FPC) lebih sering digunakan, beban tugas berulang (kategori / produk banyak, pencarian sering) tiba-tiba diserap dan PHP menjadi kurang dari beban. Bahkan, itu hanya benar-benar berperan untuk menghasilkan konten pada awalnya, atau menyelesaikan skenario yang tidak dapat ditutup (tambahkan ke keranjang, penyelesaian pesanan dll.); untuk tujuan penjelasan, kami sengaja mengabaikan beban administrasi .

Kami selalu mendukung fakta bahwa MySQL bukan bidang perhatian bagi sebagian besar pengecer, seperti yang terlihat di sini dan di sini . Tetapi jika Anda di wilayah memproses ratusan pesanan per jam, bukan satu atau dua digit - itu akan segera menjadi area untuk optimasi.

Akhirnya untuk toko kecil (<25rb pengunjung unik setiap hari)

Upaya Anda akan jauh lebih terfokus pada hanya menemukan host yang tepat yang dapat menyarankan perangkat keras yang tepat untuk digunakan dari offset dan yang telah mengkonfigurasi mesin dengan cara yang paling optimal untuk toko Anda . Jangan buang waktu Anda mengejar konfigurasi Master / Slave atau Master / Master - yang tidak akan menghasilkan manfaat kinerja dan pada akhirnya akan membutuhkan perhatian terus-menerus dan pengetahuan MySQL tingkat lanjut.

Pada akhirnya ukuran dan pemilihan perangkat keras akan memiliki peran yang lebih besar daripada optimasi MySQL.

Tetapi untuk toko yang lebih besar

Ketika toko Anda mulai tumbuh, konversi atau beban transaksional menjadi lebih menjadi beban dengan tugas berulang untuk menyelesaikan kompleks insertsdan updates. Penambahan setiap pesanan baru akan memicu penurunan stok katalog, panggilan balik dari gateway pembayaran dan pembaruan dari sistem EPOS / ERP. Gabungkan ini dengan pembersihan cache terkait dari masing-masing produk / kategori dan Anda akan segera melihat MySQL load meningkat secara tidak proporsional.

Multi-master tidak pernah merupakan solusi yang kami sarankan atau pertimbangkan sebagai opsi yang layak, tetapi Master / Slave dapat menghasilkan keuntungan (kami menekankan, pada toko ukuran Perusahaan) dengan mengimbangi beban baca ke node sekunder / tersier.

Tetapi saya masih ingin melakukannya

Pertama konfigurasikan budak Anda. Kami adalah pendukung besar utilitas Percona dan cabang MySQL - mereka memiliki alat yang ideal untuk mengambil cadangan panas dari DB - innobackupex yang ada. Ada tulisan bagus di sini .

Di master

Ganti $ TIMESTAMP atau tab selesai.

mysql
> GRANT REPLICATION SLAVE ON *.*  TO 'repl'@'$slaveip' IDENTIFIED BY '$slavepass';
> quit;
innobackupex --user=username --password=password /path/to/backupdir
innobackupex --user=username --password=password /
       --apply-log /path/to/backupdir/$TIMESTAMP/

rsync -avprP -e ssh /path/to/backupdir/$TIMESTAMP TheSlave:/path/to/mysql/
scp /etc/mysql/my.cnf TheSlave:/etc/mysql/my.cnf

Di budak

/etc/init.d/mysql stop
mv /path/to/mysql/datadir /path/to/mysql/datadir_bak
mv /path/to/mysql/$TIMESTAMP /path/to/mysql/datadir
chown -R mysql:mysql /path/to/mysql/datadir
sed -i 's#server-id=1#server-id=2#g' /etc/mysql/my.cnf
/etc/init.d/mysql start
cat /var/lib/mysql/xtrabackup_binlog_info
> TheMaster-bin.000001     481

mysql
> CHANGE MASTER TO MASTER_HOST='$masterip', MASTER_USER='repl', MASTER_PASSWORD='$slavepass', MASTER_LOG_FILE='TheMaster-bin.000001', MASTER_LOG_POS=481;
> START SLAVE;

Kemudian setelah budak Anda beroperasi, dalam praktiknya, hanya dibutuhkan beberapa baris kode tambahan untuk mencapainya.

Di ./app/etc/local.xml

<default_read>
  <connection>
    <use/>
    <host><![CDATA[host]]></host>
    <username><![CDATA[username]]></username>
    <password><![CDATA[password]]></password>
    <dbname><![CDATA[dbname]]></dbname>
    <type>pdo_mysql</type>
    <model>mysql4</model>
    <initStatements>SET NAMES utf8</initStatements>
    <active>1</active>
  </connection>
</default_read>

Sumber

Secara umum Magento terikat CPU, bukan basis data terikat, dan sebagian besar aktivitas CPU dapat di-cache, itulah sebabnya Anda akan menemukan banyak tutorial tentang pengaturan pernis / nginx. Anda juga dapat memindahkan admin Anda ke webnode terpisah seperti yang dijelaskan di sini .

Untuk ketahanan umum, pilihan terbaik untuk uang adalah layanan MySQL yang dikelola.

Saya hanya memiliki pengalaman dengan Amazon RDS, tetapi mereka mengotomatiskan failover, cadangan, peningkatan, peningkatan / penurunan, serta membaca pembuatan replika. Jadi Anda dapat memiliki node master ketersediaan tinggi yang memiliki failover otomatis - Amazon menggunakan replikasi log biner yang disesuaikan untuk menjaga slave dalam sinkronisasi, biasanya failover membutuhkan waktu kurang dari 2 menit, dan kemudian Anda dapat membuat replika baca sebanyak yang Anda bisa perlu ditingkatkan untuk kebutuhan pelaporan / integrasi Anda.

Saya melihat pemisahan membaca / menulis yang sangat bisa dilakukan dengan arsitektur Magento, tetapi database bukan hambatan dalam kasus penggunaan saya. Saya sangat merekomendasikan menggunakan profil seperti xhprof / xhgui daripada menebak apa yang perlu dioptimalkan. Aturan pertama pembuatan profil adalah mengukur.

Saya belum memiliki pengalaman produksi dengan ini, tetapi setelah penggalian saya menemukan artikel ini . Dalam artikel ini seseorang menjelaskan cara mengatur replikasi master-slave untuk Magento, jadi mungkin berguna bagi Anda.

Bit paling penting:

/app/etc/local.xml

<default_setup>
    <connection>
        <host><![CDATA[Master-host]]></host>
        <username><![CDATA[user]]></username>
        <password><![CDATA[pass]]></password>
        <dbname><![CDATA[magentodb]]></dbname>
        <active>1</active>
    </connection>
</default_setup>
<default_read>
    <connection>
        <use/>
        <host><![CDATA[Slave-host]]></host>
        <username><![CDATA[user]]></username>
        <password><![CDATA[pass]]></password>
        <dbname><![CDATA[magento]]></dbname>
        <type>pdo_mysql</type>
        <model>mysql4</model>
        <initStatements>SET NAMES utf8</initStatements>
        <active>1</active>
    </connection>
</default_read> 

Konfigurasi untuk server master MySQL (/etc/mysql/my.cnf) tambahkan konten di bawah ini dalam file:

[mysqld]
server-id       = 1
log_bin         = /var/log/mysql/mysql-bin.log
expire_logs_days    = 10
max_binlog_size     = 100M
binlog_do_db        = magento_demo
binlog_ignore_db    = mysql 

Konfigurasi untuk server MySQL slave (/etc/mysql/my.cnf) tambahkan konten di bawah ini dalam file:

[mysqld]
server-id=2
log-bin=mysql-bin
master-host=192.168.1.2
master-user=username
master-password=111111
master-port=3306
replicate-do-db=magento_demo
replicate-ignore-db=mysql
master-connect-retry=60 

Mulai ulang kedua server MySQL setelahnya

Satu ide adalah Anda dapat membagi katalog Anda menjadi server slave menggunakan dns round-robin .

Jadi atur master normal -> slave (s) replikasi di MySQL.

Kemudian dalam pengaturan Magento Anda, Anda dapat mengonfigurasi katalog Anda untuk melakukan pembacaan dari host dns yang dikonfigurasi dengan sistem round-robin. Menulis akan tetap di database master Anda.

Anda dapat melakukannya di app/etc/local.xml

<catalog_read_setup>
   <connection>
      <host><![CDATA[round.robbin.dns.host]]></host>
      <username><![CDATA[USERNAME]]></username>
      <password><![CDATA[password]]></password>
      <dbname><![CDATA[DATABASE]]></dbname>
      <initStatements><![CDATA[SET NAMES utf8]]></initStatements>
      <model><![CDATA[mysql4]]></model>
      <type><![CDATA[pdo_mysql]]></type>
      <pdoType><![CDATA[]]></pdoType>
      <active>1</active>
   </connection>
</catalog_read_setup>
<catalog_read>
   <connection>
     <use>catalog_read_setup</use>
   </connection>
 </catalog_read>

Anda dapat mengarahkan ulang setiap modul inti (dan pihak ketiga) untuk menggunakan instance MySQL yang berbeda dengan cara yang sama.