Репликация MySQL Простая репликация Master / Slave - PullRequest
Новая
       37

Репликация MySQL Простая репликация Master / Slave

4 голосов
/ 19 мая 2011

У меня простая конфигурация Master / Slave. У меня 8 ГБ ОЗУ на обеих моих производственных коробках. Я использовал Мастер только для записи и Раб только для чтения. Но в выходные я выполнил одно задание, которое заключалось в том, чтобы вставить данные на master, которые должны быть скопированы на slave. Из-за этого мой раб оставался позади мастера почти 15-16 часов, и это доставляло мне немало хлопот, когда я читал его с раба, а у раба не было обновленной информации.

В связи с этим у меня есть несколько запросов:

  1. Существуют ли какие-либо обоснованные причины, по которым следует использовать ведомое устройство для чтения, а не ведущее. (Мой мастер записывает через 5 минут), а некоторые задания планируются для чтения ведомым устройством.

  2. У меня есть таблица на 100 ГБ, и каждый день я вставляю миллион записей в одну и ту же таблицу. Все выделения и вставки происходят на этой таблице. Я выбрал способ разделения данных по годам из этой таблицы на несколько таблиц, чтобы оптимизировать эту таблицу, есть ли другой способ, которым я могу воспользоваться, чтобы оптимизировать и ускорить выполнение этой таблицы.

Пожалуйста, дайте мне знать, если я оставил что-то неясным.

Ниже приведен дизайн таблицы: 

+----------------+------------------+------+-----+---------------------+----------------+
| Field          | Type             | Null | Key | Default             | Extra          |
+----------------+------------------+------+-----+---------------------+----------------+
| test_id        | int(11) unsigned | NO   | PRI | NULL                | auto_increment |
| prime_id       | int(11) unsigned | NO   | MUL | 0                   |                |
| prime2_id      | int(11) unsigned | NO   | MUL | 0                   |                |
| timestamp      | datetime         | NO   | MUL | 0000-00-00 00:00:00 |                |
| test_time      | int(11)          | NO   |     | 0                   |                |
| status         | int(11)          | NO   |     | 0                   |                |
| component      | int(11) unsigned | NO   |     | 0                   |                |
| c_component    | int(11) unsigned | NO   |     | 0                   |                |
| C2_component   | int(11) unsigned | NO   |     | 0                   |                |
| C3_component   | int(11) unsigned | NO   |     | 0                   |                |
| rt_component   | int(11) unsigned | NO   |     | 0                   |                |
| code           | int(11) unsigned | NO   |     | 0                   |                |
| ip             | int(11) unsigned | YES  |     | 0                   |                |
| step_id        | int(11) unsigned | YES  |     | NULL                |                |
+----------------+------------------+------+-----+---------------------+----------------+
This is the index information of the table:

| Table | Non_unique | Key_name              | Seq_in_index | Column_name | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment |
+-------+------------+-----------------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+
| tests |          0 | PRIMARY               |            1 | test_id     | A         |   629448388 |     NULL | NULL   |      | BTREE      |         |
| tests |          1 | ixf_prime_id          |            1 | prime_id    | A         |          14 |     NULL | NULL   |      | BTREE      |         |
| tests |          1 | ixf_prime2_id         |            1 | prime2_id   | A         |          14 |     NULL | NULL   |      | BTREE      |         |
| tests |          1 | ix_timestamp          |            1 | timestamp   | A         |   157362097 |     NULL | NULL   |      | BTREE      |         |
| tests |          1 | ix_prime_id_timestamp |            1 | prime_id    | A         |          14 |     NULL | NULL   |      | BTREE      |         |
| tests |          1 | ix_prime_id_timestamp |            2 | timestamp   | A         |   629448388 |     NULL | NULL   |      | BTREE      |         |

1 Ответ

2 голосов
/ 19 мая 2011

У нас была похожая ситуация, но наш раб иногда отставал от хозяина на 3 или 4 дня, а в других был полностью обновлен.

Для решения этой проблемы мы должны были проверитьстатус ведомого в верхней части каждой сгенерированной страницы (или сценария для запланированных заданий), и если «секунд позади мастера» было больше, чем произвольная сумма, которую мы определили, мы запускали все запросы для этой страницы / задания в мастере.Если секунды позади мастера находились в пределах нашего допустимого временного предела (часто равного нулю), мы тогда знали, что было безопасно запускать запросы на ведомом устройстве.

Затем оно было расширено для определения , какого подчиненногозапускать запросы, когда у нас было более одного (что-то вроде программного балансировщика нагрузки!).

В конце концов, мы переработали архитектуру и запросы на вставку, чтобы убедиться, что ведомое отставание оказалось очень незначительной проблемой....

Одна вещь, которую вы могли бы сделать, это попытаться разделить ваши вставки на более мелкие партии, чтобы одна вставка не заняла слишком много времени, позволяя ведомому запустить эту вставку, пока мастер занят наследующий.

Надеюсь, это поможет.

Дейв

...