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

У меня простая конфигурация 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      |         |

mysql replication master slave
person MySQL DBA    schedule 19.05.2011    source источник

Ответы (1)


arrow_upward
2
arrow_downward

У нас была аналогичная ситуация, но наш слейв иногда отставал от мастера на 3-4 дня, а иногда и вовсе был в курсе.

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

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

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

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

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

Дэйв

person Dave Rix    schedule 19.05.2011
comment
Спасибо, Дэйв. Но я не могу попросить выборы на моем подчиненном устройстве подождать.... так как мне нужно генерировать отчеты на каждый день и каждый час дня... поэтому информацию я читаю с подчиненного устройства. Я думаю, что идея проверки параметра Second Behind Master хороша и соответственно манипулирует вставками на master, поэтому не будет проблемы такой большой разницы. - person MySQL DBA; 19.05.2011
comment
Еще один вопрос, который у меня возник относительно конфигурации Master/Slave, — что произойдет, если я буду читать и писать с самого master. - person MySQL DBA; 19.05.2011
comment
Извините, я не имел в виду, что ведомым устройствам придется ждать, прежде чем запускать запросы на чтение, я имел в виду, что наша система запускала запросы на чтение непосредственно на ведущее устройство, если ведомое устройство отставало. Совершенно нормально запускать чтение и запись на мастере (тогда это всего лишь архитектура с одним сервером...) С нашей настройкой вы получаете лучшее из обоих миров. Если ведомое устройство обновлено, чтение выполняется на ведомом устройстве, в противном случае — на ведущем. Надеюсь, это прояснит ситуацию? - person Dave Rix; 19.05.2011
comment
Да в значительной степени .. Спасибо Дэйв. - person MySQL DBA; 19.05.2011