Обсуждение настройки и работы сервисов, резервирования, сетевых настроек и вопросов безопасности ОС для молодых и начинающих системных администраторов.
...
Slave_IO_Running: No
Slave_SQL_Running: Yes
...
Last_IO_Errno: 1236
Last_IO_Error: Got fatal error 1236 from master when reading data from binary log: 'Client requested master to start replication from impossible position; the first event 'mysql-bin.000009' at 910191424, the last event read from './mysql-bin.000009' at 4, the last byte read from './mysql-bin.000009' at 4.'
...
Пробывал разные параметры my.cnf - не помогает. Сейчас такие
...[mysqld]
datadir=/var/lib/mysql
port = 3306
socket = /var/lib/mysql/mysql.sock
skip-external-locking
key_buffer_size = 16M
max_allowed_packet = 2M
sort_buffer_size = 2M
net_buffer_length = 8K
read_buffer_size = 2M
read_rnd_buffer_size = 2M
myisam_sort_buffer_size = 8M
character_set_server = utf8
default-storage-engine = InnoDB
memlock
#tmpfs
tmpdir = /tmp/mysqltmp
innodb_thread_concurrency = 17
thread_concurrency = 17
# Don't listen on a TCP/IP port at all. This can be a security enhancement,
# if all processes that need to connect to mysqld run on the same host.
# All interaction with mysqld must be made via Unix sockets or named pipes.
# Note that using this option without enabling named pipes on Windows
# (via the "enable-named-pipe" option) will render mysqld useless!
#
#skip-networking
binlog_format=mixed
server-id = 64026
log-bin=mysql-bin
max_binlog_size=3G
expire_logs_days=14
# Uncomment the following if you are using InnoDB tables
#innodb_data_home_dir = /var/lib/mysql
#/innodb_data_file_path = ibdata1:10M:autoextend
#innodb_log_group_home_dir = /var/lib/mysql
# You can set .._buffer_pool_size up to 50 - 80 %
# of RAM but beware of setting memory usage too high
innodb_buffer_pool_size = 12G
innodb_buffer_pool_instances = 3
innodb_additional_mem_pool_size = 16M
# Set .._log_file_size to 25 % of buffer pool size
innodb_log_file_size = 256M
innodb_log_buffer_size = 8M
innodb_log_files_in_group = 4
innodb_flush_log_at_trx_commit = 2
#innodb_lock_wait_timeout = 50
innodb_file_per_table = 1
query_cache_type = OFF
query_cache_size = 0
innodb_flush_method = O_DIRECT
max_heap_table_size = 1G
tmp_table_size = 1G
table_open_cache = 8196
open_files_limit = 8196
thread_cache_size = 128
max_connection = 128
innodb_write_io_threads = 8
innodb_read_io_threads = 8
...
На сервере реплицируется две базы - заббикс (большая) и teampass (очень маленькая). Скорее всего "вылетает" заббикс, т.к. в тимпас изменения вносятся очень редко.
Как этого можно избежать? Надоело каждый раз slave перенастраивать...
Подозреваю что проблему можно решить следующими способами:
1) Обеспечить бесперебойное питание мастера, слэйва и сети между ними. А так-же корректную остановку mysql при длительном отключении питания (если ИБП не тянут).
2) Наваять какой-то скрипт автоматически чинящий слэйв.
3) Использовать синхронную репликацию (как минимум уменьшит производительность записи в БД).
Впрочем я не специалист, а репликация дело тонкое.
...
Slave_IO_Running: No
Slave_SQL_Running: Yes
...
Last_IO_Errno: 1236
Last_IO_Error: Got fatal error 1236 from master when reading data from binary log: 'Client requested master to start replication from impossible position; the first event 'mysql-bin.000009' at 910191424, the last event read from './mysql-bin.000009' at 4, the last byte read from './mysql-bin.000009' at 4.'
...
Написано вполне чёрным по-белому: binlog из-за отключения питания фактически не записался на диск.
Это же фактически означает, что не записалось и ещё что-то. И это повод поднимать реплику заново(т.к. на ней данные отличаются от мастера).
Избежать очень просто: выключать систему штатно, а не отключением питания.
3) Использовать синхронную репликацию (как минимум уменьшит производительность записи в БД).
Не поможет -- часть данных всё равно не будет записана на диск перезагружаемого по питанию сервера со всеми вытикающими последствиями(разные данные на разных серверах).
Не поможет -- часть данных всё равно не будет записана на диск перезагружаемого по питанию сервера со всеми вытикающими последствиями(разные данные на разных серверах).
Может я чего-то путаю, но, если говорить о сферической синхронной репликации в вакууме, коммит не будет подтверждёт пока все ноды не подтвердят его сохранение.
Правда это замедляет запись и работает приемлемо только далеко не всегда и не везде.
Может я чего-то путаю, но, если говорить о сферической синхронной репликации в вакууме
IRL если делать в "вакууме", то это будет тупить по чёрному. В MySQL выбран некоторый баланс, из расчёта, что связь может оборваться, но не сам сервер.
А тут получается, что коммит принят(по сети), подтверждение отправлено, СУБД начинает его в БД пихать, и тут ВНЕЗАПНО всё вырубается.
В мускуле вроде вообще нет синхронной репликации из коробки.
Ещё от хранилища зависит, когда оно рапортует о том что коммит принят. В принципе хранилище может синкаться на диск при каждом коммите, только это будет дико медленно.