대용량 사이트를 위해 데이터베이스 아키텍처를 최적화하는 방법은 무엇입니까?

28

질문은 특정 MySQL 구성 항목에 대한 것이 아니라 여러 데이터베이스를 처리하고 여러 데이터베이스 서버, 마스터 + 마스터로 읽기 및 쓰기를 나누는 것에 관한 것입니까? 마스터 + 멀티 슬레이브?

사람들은 무엇을 가장 잘 경험했으며이를 달성하는 방법에 대한 예가 있습니까?

database  mysql  performance  architecture 
— Vaskoism
소스

답변:

18

우리는 MySQL 클러스터에 대해 상당히 광범위한 경험을 가지고 있으며 Percona는 복잡한 구성의 경계를 넓힐 때 여러 번 우리와 함께 작업했습니다.

Magento는 기본적으로 읽기 전용 슬레이브를 처리 할 수 ​​있습니까

Magento 는 기본적으로 다른 데이터베이스 서버로 읽기 / 쓰기를 분리 할 수 ​​있습니다 (예 : EE 1.11과 같이 몇 가지 릴리스 된 경우 제외)- select추가 (또는 그 이상의) 서버로로드를 오프셋 할 수 있습니다 . 모든 update/write쿼리를 단일 마스터로 전달합니다 .

언제해야합니까

이것은 더 적절한 질문입니다. MageStack 과 같은 전용 Magento 운영 체제에서는 내장 된 서버 측 고급 캐싱 기술을 사용하고 쉽게 사용할 수있게되었습니다 (예 : Varnish 프론트 엔드 캐싱 및 Redis 백엔드 캐싱).

역사적으로 Magento는 MySQL이 아니라 PHP에 구속 된 적이 있습니다. 그러나 니스 및 전체 페이지 캐싱 (FPC)이 더 자주 사용됨에 따라 반복되는 작업 (카테고리 / 제품로드, 빈번한 검색)의 부담이 갑자기 흡수되고 PHP는 부담이 줄어 듭니다. 실제로 콘텐츠를 처음에 생성하거나 캐싱 할 수없는 시나리오를 완료하는 것 (장바구니에 추가, 주문 완료 등) 만 실제로 작동합니다. 설명을 위해 의도적으로 관리로드를 무시하고 있습니다.

우리는 여기 와 여기 모두 에서 볼 수 있듯이 MySQL이 대부분의 소매점에서 관심 분야가 아니라는 사실에 항상 섰 습니다 . 그러나 한 자리 또는 두 자리 숫자가 아닌 시간당 수백 개의 주문을 처리하는 지역에서 곧 최적화 영역이 될 것입니다.

더 작은 매장에 적합 (매일 25 만 명 미만의 순 방문자)

오프셋에서 올바른 하드웨어를 제안 할 수 있고 매장에 가장 적합한 방식으로 기계를 구성한 적절한 호스트를 찾는 데 더 중점을 둘 것입니다 . 마스터 / 슬레이브 또는 마스터 / 마스터 구성을 추구하는 데 시간을 낭비하지 마십시오. 성능상의 이점이 없으며 궁극적으로 지속적인 관심과 고급 MySQL 지식이 필요합니다.

궁극적으로 하드웨어 크기 및 선택은 MySQL 최적화보다 더 큰 역할을합니다.

그러나 더 큰 매장의 경우

상점이 커지기 시작하면서 변환 또는 트랜잭션로드는 복잡 inserts하고 완료하는 반복 된 작업으로 인해 더 많은 부담이됩니다 updates. 각각의 새로운 주문을 추가하면 카탈로그 재고가 감소하고, 지불 게이트웨이에서 콜백되고, EPOS / ERP 시스템에서 업데이트됩니다. 이를 각 제품 / 카테고리의 관련 캐시 제거와 결합하면 곧 MySQL로드가 불균형 적으로 증가하는 것을 볼 수 있습니다.

다중 마스터는 우리가 실행 가능한 옵션으로 권장하거나 고려하지 않는 솔루션은 아니지만 마스터 / 슬레이브는 읽기로드를 2 차 / 3 차 노드로 상쇄함으로써 이점을 얻을 수 있습니다 (엔터프라이즈 규모의 상점에서 스트레스를 줄 수 있습니다).

하지만 난 아직도하고 싶어

먼저 슬레이브를 구성하십시오. 우리는 Percona 유틸리티와 MySQL 브랜치를 지지합니다. 기존 DB의 innobackupex 를 핫 백업 하는 데 이상적인 툴입니다 . 여기에 좋은 글이 있습니다 .

마스터

$ TIMESTAMP를 바꾸거나 탭을 완료하십시오.

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

노예에서

/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;

그런 다음 슬레이브가 작동하면 실제로 몇 줄의 코드 만 추가하면됩니다.

에서 ./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>

출처

— 벤 레 사니-소나시
소스
"역사적으로, Magento는 MySQL에 구속 된 적이 없으며 PHP가 아닙니다." Magento에 대해 말한 것이 확실하지 않지만 EAV는 항상 성능 문제였습니다. :)
— B00MER
1
글쎄, 우리가 관리하는 400 + Magento 서버를 언급하고 있습니다 ... 대부분의 규칙으로 MySQL을 고려하기 전에 다른 병목 현상이 있습니다. 실제로, 가장 좋은 예는 12 월 동안의 고객 중 하나입니다. 시간당 15k 명의 고유 방문자 수로 단일 서버 설정 (32 코어, 64GB RAM)에서 시간당 200 개의 주문을 처리합니다. 이 질문의 일반적인 독자에게는이 책을 다룰 가능성이 거의 없습니다. 따라서 트래픽 및 트랜잭션 수준에서 발생할 수있는 MySQL은 병목 현상이 아닙니다.
— 벤 레 사니-Sonassi
1
@ 브랜든 나는 단지 추가하는 것을 의미한다. 나는 MySQL 튜닝이 필요하지 않다는 것을 부정하지는 않는다-분명히 그렇다. 그러나 실제로 특정 티핑 포인트에 도달 할 때까지 성능을 향상시키기 위해 Master / Master 또는 Master / Slave 설정을 구성 할 필요가 없습니다. 또한 성능 병목 현상이나 데이터 무결성 위험을 유발하여 이러한 작업을 시도하는 것이 훨씬 더 가능합니다.
— 벤 레 사니-Sonassi
5

일반적으로 Magento는 데이터베이스 바운드가 아니라 CPU 바운드이며 대부분의 CPU 활동을 캐시 할 수 있으므로 varnish / nginx 설정에 대한 많은 자습서를 찾을 수 있습니다. 여기에 설명 된대로 관리자를 별도의 웹 노드로 이동할 수도 있습니다 .

일반적인 견고성을 위해 벅을위한 최고의 성능은 관리 형 MySQL 서비스입니다.

Amazon RDS에 대한 경험이 있지만 장애 조치, 백업, 업그레이드, 확장 / 축소 및 읽기 전용 복제본 생성을 자동화합니다. 따라서 자동 장애 조치 기능이있는 고 가용성 마스터 노드를 사용할 수 있습니다. Amazon은 슬레이브를 동기화 상태로 유지하기 위해 사용자 지정 바이너리 로그 복제를 사용하고 장애 조치는 일반적으로 2 분 미만으로 걸리며 읽기 복제본을 여러 개 만들 수 있습니다 보고 / 통합 요구에 맞게 확장해야합니다.

Magento의 아키텍처에서 매우 유용한 읽기 / 쓰기 분할을 살펴 보았지만 데이터베이스는 사용 사례에서 병목 현상이 없습니다. 최적화해야 할 것을 추측하는 대신 xhprof / xhgui 와 같은 프로파일 링을 사용하는 것이 좋습니다 . 프로파일 링의 첫 번째 규칙은 측정하는 것입니다.

— 랄프 타이스
소스
링크가 포함 된 질문에 대한 답변이있는 책갈피 웹 사이트를 작성하지 않았습니다. 여기에 답변의 필수 부분을 포함시키고 참조 할 수있는 링크를 제공하십시오.
— j0k
@ j0k 링크는 참조 용으로 제공되며 답변은 자체적으로 제공됩니다. 동의하지 않을 경우 더 구체적으로 작성하십시오.
— Ralph Tice
네, 적어도 당신의 대답은 다른 것보다 낫습니다. 내 말은, OP는 구성에 대해 더 많은 기술적 내용이 필요할 수 있습니다. 아키텍처 스키마 등은 어떻습니까? 경험이 많더라도!
— j0k
5

나는이 어떤 생산 경험하지 않은,하지만 일부 파고 후 내가 발견 한 이 기사를. 이 기사에서는 누군가가 Magento에 대한 마스터-슬레이브 복제를 설정하는 방법을 설명하므로 유용 할 것입니다.

가장 중요한 비트 :

/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>

마스터 MySQL 서버 (/etc/mysql/my.cnf)의 구성은 파일의 아래 내용을 추가합니다 :

[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

슬레이브 MySQL 서버 (/etc/mysql/my.cnf)에 대한 구성은 파일의 아래 내용을 추가합니다 :

[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

나중에 두 MySQL 서버를 다시 시작하십시오.

— 케니
소스
1
론 링크는 그 자체로는 무의미하고 목표 자원이 미래에 살아 있다고 보장되지 않기 때문에 나쁜 대답 으로 간주됩니다 . 하는 것이 바람직 할 것이다 여기에 대한 대답의 본질적인 부분을 포함하고 참조 할 수 있도록 링크를 제공합니다.
— j0k
@ j0k, 요청에 따라 완료;)
— Kenny
3

dns round-robin을 사용 하여 카탈로그 읽기를 슬레이브 서버로 분할 할 수 있습니다 .

따라서 MySQL에서 일반 마스터-> 슬레이브 복제를 설정하십시오.

그런 다음 Magento 설정에서 라운드 로빈 구성 dns 호스트에서 읽기를 수행하도록 카탈로그를 구성 할 수 있습니다. 쓰기는 마스터 데이터베이스에 유지됩니다.

당신은 이것을 할 수 있습니다 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>

동일한 방식으로 다른 MySQL 인스턴스를 사용하도록 모든 코어 (및 타사) 모듈을 리디렉션 할 수 있습니다.

— 프록시 블루
소스
1
DNS 라운드 로빈은 어떤 종류의 솔루션도 아닙니다. MySQL 프록시 또는 HAProxy는 MySQL 읽기로드 균형 조정을위한 훨씬 정교한 솔루션입니다.
— Ben Lessani-Sonassi
당사 사이트를 사용함과 동시에 당사의 쿠키 정책과 개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.