Câu hỏi ít hơn về các mục cấu hình Mysql cụ thể, nhưng nhiều hơn về việc xử lý nhiều cơ sở dữ liệu, phân tách đọc và ghi vào nhiều máy chủ cơ sở dữ liệu, master + master? Bậc thầy + nhiều nô lệ?
Mọi người đã có trải nghiệm tốt nhất với điều gì, và có ví dụ nào về cách đạt được điều này?
Câu trả lời:
Chúng tôi đã có một trải nghiệm khá rộng lớn về các cụm MySQL - và Percona đã làm việc với chúng tôi trong một số trường hợp khi vượt qua các ranh giới của các cấu hình phức tạp.
Magento là natively có khả năng tách ra đọc / ghi vào các máy chủ cơ sở dữ liệu khác nhau (ngoại trừ một vài phiên bản bị hỏng, ví dụ như EE 1.11.) - cho phép bạn để bù đắp selecttải để bổ sung (hoặc nhiều hơn) một máy chủ (s); và chuyển tiếp tất cả các update/writetruy vấn đến một chủ duy nhất.
Đây là một câu hỏi thích hợp hơn. Với các hệ điều hành Magento chuyên dụng như MageStack - nó trở nên phổ biến hơn đối với các kỹ thuật bộ đệm nâng cao phía máy chủ được xây dựng để có sẵn và dễ dàng sử dụng (như bộ đệm ẩn mặt trước Varnish và bộ đệm ẩn phía sau Redis).
Trong lịch sử, Magento chưa bao giờ bị ràng buộc bởi MySQL - mà là PHP. Nhưng khi Varnish và Bộ nhớ đệm toàn trang (FPC) được sử dụng thường xuyên hơn, gánh nặng của các tác vụ lặp đi lặp lại (tải danh mục / sản phẩm, tìm kiếm thường xuyên) đột nhiên được hấp thụ và PHP trở nên ít gánh nặng hơn. Trên thực tế, nó chỉ thực sự phát huy tác dụng để tạo nội dung ban đầu hoặc hoàn thành các tình huống không lưu trong bộ nhớ cache (thêm vào giỏ hàng, hoàn thành đơn hàng, v.v.); với mục đích giải thích, chúng tôi cố tình bỏ qua tải hành chính .
Chúng tôi luôn luôn đứng trước thực tế rằng MySQL không phải là lĩnh vực quan tâm của hầu hết các nhà bán lẻ, như đã thấy cả ở đây và ở đây . Nhưng nếu bạn ở trong khu vực xử lý hàng trăm đơn hàng mỗi giờ, không phải là một hoặc hai chữ số - nó sẽ sớm trở thành một lĩnh vực để tối ưu hóa.
Cuối cùng cho các cửa hàng nhỏ hơn (<25k khách truy cập hàng ngày)
Những nỗ lực của bạn sẽ tập trung tốt hơn nhiều vào việc đơn giản là tìm một máy chủ phù hợp có thể đề xuất phần cứng phù hợp từ phần bù và điều đó đã cấu hình máy theo cách tối ưu nhất cho cửa hàng của bạn . Đừng lãng phí thời gian của bạn để theo đuổi các cấu hình Master / Slave hoặc Master / Master - sẽ không mang lại lợi ích hiệu suất và cuối cùng sẽ đòi hỏi sự chú ý liên tục và kiến thức nâng cao của MySQL.
Cuối cùng, kích thước và lựa chọn phần cứng sẽ có phần lớn hơn so với tối ưu hóa MySQL.
Nhưng đối với các cửa hàng lớn hơn
Khi cửa hàng của bạn bắt đầu phát triển, việc chuyển đổi hoặc tải giao dịch trở thành gánh nặng nhiều hơn với nhiệm vụ lặp đi lặp lại là hoàn thành phức tạp insertsvà updates. Việc bổ sung mỗi đơn hàng mới sẽ kích hoạt sự sụt giảm của cổ phiếu danh mục, các cuộc gọi lại từ các cổng thanh toán và cập nhật từ các hệ thống EPOS / ERP. Kết hợp điều này với việc lọc bộ nhớ cache liên quan của các sản phẩm / danh mục tương ứng và bạn sẽ sớm thấy tải của MySQL tăng không tương xứng.
Multi-master không bao giờ là giải pháp mà chúng tôi đề xuất hoặc coi là một lựa chọn khả thi, nhưng Master / Slave có thể mang lại lợi ích (chúng tôi nhấn mạnh, trên các cửa hàng quy mô Doanh nghiệp) bằng cách bù đắp tải đọc cho các nút thứ cấp / cấp ba.
Đầu tiên cấu hình nô lệ của bạn. Chúng tôi là những người ủng hộ lớn cho các tiện ích Percona và các chi nhánh MySQL - họ có một công cụ lý tưởng để thực hiện các bản sao lưu nóng của DB hiện tại của bạn - innobackupex. Có một bài viết tốt ở đây .
Trên chủ
Thay thế hoàn toàn $ TIMESTAMP hoặc tab.
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.cnfTrên nô lệ
/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;Sau đó, một khi nô lệ của bạn hoạt động, trong thực tế, chỉ cần thêm một vài dòng mã để đạt được.
Trong ./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>Nguồn
Nói chung Magento bị ràng buộc CPU, không bị ràng buộc cơ sở dữ liệu và hầu hết các hoạt động của CPU có thể được lưu trong bộ nhớ cache, đó là lý do tại sao bạn sẽ tìm thấy rất nhiều hướng dẫn về thiết lập véc ni / nginx. Bạn cũng có thể di chuyển quản trị viên của mình sang một mã web riêng biệt như chi tiết ở đây .
Đối với sự mạnh mẽ nói chung, bang tốt nhất tuyệt đối cho buck sẽ là một dịch vụ MySQL được quản lý.
Tôi chỉ có kinh nghiệm với Amazon RDS, nhưng họ tự động chuyển đổi dự phòng, sao lưu, nâng cấp, tăng / giảm tỷ lệ, cũng như đọc tạo bản sao. Vì vậy, bạn có thể có một nút chính khả dụng cao có khả năng chuyển đổi dự phòng tự động - Amazon sử dụng bản sao nhật ký nhị phân tùy chỉnh để giữ nô lệ đồng bộ hóa, chuyển đổi dự phòng thường mất ít hơn 2 phút và sau đó bạn có thể tạo nhiều bản sao đọc như bạn cần mở rộng ra cho nhu cầu báo cáo / tích hợp của bạn.
Tôi đã xem xét phân tách đọc / ghi rất khả thi với kiến trúc của Magento, nhưng cơ sở dữ liệu không phải là nút cổ chai trong trường hợp sử dụng của tôi. Tôi đặc biệt khuyên bạn nên sử dụng hồ sơ như xhprof / xhgui thay vì đoán những gì cần được tối ưu hóa. Nguyên tắc đầu tiên của hồ sơ là đo lường.
Tôi đã không có bất kỳ kinh nghiệm sản xuất với điều này, nhưng sau khi một số digging Tôi đã tìm thấy này bài viết. Trong bài viết này, ai đó giải thích cách thiết lập sao chép master-Slave cho Magento, vì vậy nó có thể hữu ích cho bạn.
Bit quan trọng nhất:
/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> Cấu hình cho máy chủ MySQL chính (/etc/mysql/my.cnf) thêm nội dung bên dưới vào tệp:
[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 Cấu hình cho máy chủ MySQL nô lệ (/etc/mysql/my.cnf) thêm nội dung bên dưới vào tệp:
[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 Khởi động lại cả hai máy chủ MySQL sau đó
Một ý tưởng là bạn có thể phân chia danh mục của bạn đọc cho (các) máy chủ nô lệ bằng cách sử dụng vòng tròn dns .
Do đó, thiết lập bản sao chính chủ -> nô lệ (s) trong MySQL.
Sau đó, trong thiết lập Magento của bạn, bạn có thể định cấu hình danh mục của mình để đọc từ máy chủ dns được cấu hình vòng tròn của bạn. Viết sẽ ở lại cơ sở dữ liệu chủ của bạn.
Bạn có thể làm điều này trong 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>Bạn có thể chuyển hướng bất kỳ mô-đun lõi (và bên thứ 3) nào để sử dụng một phiên bản MySQL khác theo cách tương tự.