Я Kite, официальный аккаунт "Ancient Kite", простой программист-поощритель. Статьи будут включены вJavaNewBeeТакже есть карта знаний Java back-end, и в ней путь от Xiaobai до Daniel.
Интервьюер: Я вижу, что база данных вашей компании, указанная в вашем резюме, — это разделение чтения и записи MySQL?
Сяо Хуа: Ну да.
Интервьюер: Тогда вы сказали, как настроить базу данных как master-slave?
Сяо Хуа: Ну, DBA помог нам сделать это, мы можем просто использовать его напрямую.
Интервьюер: Сталкивались ли вы с какими-либо сбоями в вашей структуре master-slave, такими как сбой подчиненной библиотеки или главной библиотеки, как это решить?
Сяо Хуа: Этим также занимается администратор баз данных.
Интервьюер: (улыбается) Хорошо, я буду здесь сегодня, вернуться и ждать уведомления.
Теперь не ждите администратора баз данных, сами настраивайте MySQL master-slave, сделайте свою собственную панель администратора баз данных.
справочная информация
Предполагая, что все установили базу данных MySQL, в этой операции используется версия MySQL 5.7.16. Просто есть Mac, который простаивает, поэтому я просто использую две физические машины для прямой работы.Те, у кого нет простаивающих машин, могут работать таким же образом в виртуальной машине.
С простейшей конфигурацией один мастер-один ведомый.
Главный сервер: 192.168.0.101
Ведомый сервер: 192.168.0.108
Несколько режимов уровня базы данных
В системной архитектуре уровень базы данных в основном основан на следующих режимах: именованном, резервном и ведущем-ведомом.
одноточечный режим
Одноточечный режим — это самый простой режим, в котором используется только один сервер базы данных и который проще всего развернуть. Но есть один риск: когда сервер выходит из строя, вся система выходит из строя.
Активно-резервный режим
Чтобы устранить риск одноточечного режима, генерируется активно-резервный режим. В настоящее время режим «активный-резервный» должен быть минимальной конфигурацией каждой системы онлайн-сервиса.Например, сервисы баз данных, которые вы приобретаете на каждой облачной платформе, обычно имеют включенную функцию резервного копирования. Если на основном узле возникла проблема, его также можно переключить на резервный узел, чтобы вся система не была парализована.
Мастер и резервная копия далее делятся на одну основную и одну резервную, а также одну основную с несколькими резервными копиями. Несколько резервных копий используются для обеспечения большей безопасности.Если есть проблема с основным узлом, бывает, что проблема возникает и с резервным узлом.
Когда у основного узла возникает проблема, ему необходимо переключиться на резервный узел.Методы переключения делятся на ручное переключение и автоматическое переключение. Ручное переключение имеет определенную задержку, при возникновении проблемы с мастер-узлом можно только ждать, пока ее обнаружит оперативный и обслуживающий персонал или получит системное уведомление.
режим ведущий-ведомый
Конфигурация ведущий-ведомый обычно сочетается с разделением чтения и записи.Главный сервер отвечает за запись данных, а подчиненный сервер отвечает за чтение данных и обеспечивает своевременную синхронизацию данных главного сервера с подчиненным сервером. .
Режим ведущий-ведомый далее делится на один ведущий и один ведомый, один ведущий и несколько ведомых, а также несколько ведущих и несколько ведомых Чем дальше развертывание, тем оно сложнее, и в то же время стабильность системы выше. Режим ведущий-ведомый может лучше распределять нагрузку на базу данных, отделять операцию вставки обновления от операции запроса и повышать общую производительность системы.
Цель этой статьи — представить конфигурацию и принцип простой архитектуры «один главный — подчиненный».
принцип «хозяин-раб»
главный узел
1. Когда на главном узле выполняются операции вставки, обновления и удаления, они будут записываться в binlog в хронологическом порядке; 2. Когда подчиненный узел подключен к главному узлу, главный узел создаст поток, называемый дампом binlog;
3, будет создан главный узел от количества узлов, будет создан нить сброса числа бинлога;
4. При изменении бинлога главного узла, то есть при выполнении операции изменения, поток дампа бинлога уведомит подчиненный узел (режим Push) и отправит соответствующее содержимое бинлога подчиненному узлу;
подчиненный узел
Когда синхронизация master-slave включена, подчиненный узел создаст два потока для завершения работы по синхронизации данных.
Поток ввода-вывода:Этот поток подключается к главному узлу, и поток дампа binlog на главном узле отправляет содержимое binlog этому потоку. После того, как этот поток получает содержимое binlog, он записывает содержимое в локальный журнал ретрансляции.
SQL-поток:Поток читает I/relay log O поток пишет, и по содержимому релейного журнала операций, сделанных из соответствующей базы данных.
Конфигурация ведущий-ведомый обычно сочетается с разделением чтения и записи.Главный сервер отвечает за запись данных, а подчиненный сервер отвечает за чтение данных и обеспечивает своевременную синхронизацию данных главного сервера с подчиненным сервером. .
Конфигурация главного сервера
Включить удаленное подключение
Используйте командную строку или клиентский инструмент, чтобы войти в MySQL и выполнить команду:
GRANT REPLICATION SLAVE ON *.* to 'root'@'192.168.0.108' identified by 'P@ssw0rd';
FLUSH PRIVILEGES;
После выполнения приведенного выше оператора используйте клиент или командную строку подчиненного сервера, чтобы проверить, действует ли он.
mysql -h 192.168.0.101 -uroot -p
Включить bin-log и установить идентификатор сервера
Его необходимо изменить в конфигурационном файле MySQL.По умолчанию конфигурационный файл MySQL расположен следующим образом, и приоритет уменьшается сверху вниз:
-
/etc/my.cnf -
/etc/mysql/my.cnf -
/usr/local/etc/my.cnf -
~/.my.cnf
Конфигурация выглядит следующим образом:
[mysqld]
log-bin=mysql-bin
server-id=101
Другие параметры
Помимо двух вышеперечисленных необходимых параметров, есть еще несколько параметров.
binlog_format
Формат журнала bin-log поддерживает следующие три, и рекомендуется использовать смешанный формат . оператор: будет записывать операторы SQL для операций с базой данных в binlog. row: изменение каждых данных будет записано в binlog. смешанный: сочетание оператора и строки. MySQL решает, когда записывать формат оператора и когда записывать формат строки.
binlog-do-db
Настройте базу данных для синхронизации, если она не настроена, по умолчанию используются все базы данных.
binlog-do-db=db1
binlog-do-db=db2
binlog-ignore-db
Настройте базы данных, не требующие синхронизации.
binlog-ignore-db=db3
expire-logs-days
Количество дней, которые хранятся журналы BIN-LOG. Чем дольше количество дней, тем больше места, которое требуется.
Затем перезапустите службу MySQL
mysql.server restart
Используйте следующую команду, чтобы увидеть, вступит ли в силу конфигурация:
show variables like 'log_bin';
show variables like 'server_id';
Используйте следующую инструкцию для просмотра главного состояния.
show master status;
Настроить с сервера
1. Откройте конфигурационный файл подчиненного сервера и добавьте в него следующую конфигурацию:
server-id=108
2. Перезапустите службу MySQL.
mysql.server restart
3, настроить мастер от синхронизации
change master to master_host='192.168.0.101',master_user='root',master_password='P@ssw0rd',master_log_file='mysql-bin.000001' ,master_log_pos=154;
вmaster_hostпредставляет IP-адрес главного сервера,master_userиmaster_passwordлогин и пароль главного сервера соответственно,master_log_fileиmaster_log_posПроход на основной серверshow master statusфразы можно найти.
4. Запустите процесс синхронизации.
start slave
5. Проверьте состояние синхронизации.
show slave status;
возможные проблемы
Fatal error: The slave I/O thread stops because master and slave have equal MySQL server UUIDs; these UUIDs must be different for replication to work.
После MySQL 5.6 была введена концепция uuid, и server_uuid в каждой структуре master-slave репликации должен быть разным. Поскольку мой новый Mac был перенесен со старой машины с помощью «помощника по миграции», который поставляется вместе с системой, все программное обеспечение и конфигурации точно такие же.
Используйте следующую инструкцию для просмотра значения server_uuid и пути к auto.cnf. Значение server_uuid сохраняется в auto.cnf.
show variables like '%server_uuid%';
show variables like '%datadir%';
Я обнаружил, что каталог datadir на подчиненном сервере — /usr/local/var/mysql, измените значение server-uuid в файле auto.cnf в каталоге
Измените значение server-uuid в файле auto.cnf в каталоге datadir.
Затем перезапустите службу и посмотрите, есть ли эта проблема.
пройти тест
После завершения настройки синхронизации я создаю базу данных на главном сервере, создаю таблицу, а затем добавляю, изменяю и удаляю данные, чтобы проверить, синхронизирован ли подчиненный сервер и изменен ли он соответствующим образом.
В обычных условиях после завершения операции на главном сервере подчиненный сервер сразу же увидит соответствующие данные.
Запрос статуса ведущий-ведомый
статус основного сервиса
Используйте следующую инструкцию для просмотра состояния основных служб:
show master status\G;
использоватьshow processlistОператор может просматривать состояние потока.Вы можете видеть, что состояние первого потока — «Главный отправил все бинарные журналы подчиненному; ожидание дополнительных обновлений», что указывает на то, что поток синхронизации запущен.
mysql> show processlist\G; *************************** 1. row *************************** Id: 20 User: root Host: 192.168.0.108:57815 db: NULL Command: Binlog Dump Time: 11702 State: Master has sent all binlog to slave; waiting for more updates Info: NULL *************************** 2. row *************************** Id: 21 User: root Host: localhost db: NULL Command: Query Time: 0 State: starting Info: show processlist 2 rows in set (0.03 sec)
ERROR: No query specified
Из статуса службы
пройти черезshow slave status;Вы можете просмотреть состояние ведомой службы, из которой вы можете увидеть информацию о ведущей службе и состоянии потоков Slave_IO и Slave_SQL и т. д.
mysql> show slave status\G;
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 192.168.0.101
Master_User: root
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: mysql-bin.000001
Read_Master_Log_Pos: 1393
Relay_Log_File: 192-relay-bin.000005
Relay_Log_Pos: 1284
Relay_Master_Log_File: mysql-bin.000001
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Replicate_Do_DB:
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Exec_Master_Log_Pos: 1393
Relay_Log_Space: 1930
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Master_SSL_Allowed: No
Master_SSL_CA_File:
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
Seconds_Behind_Master: 0
Master_SSL_Verify_Server_Cert: No
Last_IO_Errno: 0
Last_IO_Error:
Last_SQL_Errno: 0
Last_SQL_Error:
Replicate_Ignore_Server_Ids:
Master_Server_Id: 101
Master_UUID: 220919a2-9690-11e6-9c9b-9d406b577440
Master_Info_File: /usr/local/var/mysql/master.info
SQL_Delay: 0
SQL_Remaining_Delay: NULL
Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates
Master_Retry_Count: 86400
Master_Bind:
Last_IO_Error_Timestamp:
Last_SQL_Error_Timestamp:
Master_SSL_Crl:
Master_SSL_Crlpath:
Retrieved_Gtid_Set:
Executed_Gtid_Set:
Auto_Position: 0
Replicate_Rewrite_DB:
Channel_Name:
Master_TLS_Version:
1 row in set (0.00 sec)
ERROR:
No query specified
также черезshow processlistПросмотр ситуации на потоке ведомого обслуживания.
mysql> show processlist\G;
*************************** 1. row ***************************
Id: 1
User: system user
Host:
db: NULL
Command: Connect
Time: 84003
State: Slave has read all relay log; waiting for more updates
Info: NULL
*************************** 2. row ***************************
Id: 2
User: system user
Host:
db: NULL
Command: Connect
Time: 123734
State: Waiting for master to send event
Info: NULL
*************************** 3. row ***************************
Id: 9
User: root
Host: localhost
db: NULL
Command: Query
Time: 0
State: starting
Info: show processlist
3 rows in set (0.00 sec)
ERROR:
No query specified
Как возобновить синхронизацию после отбоя от библиотеки
Где годы тихие, просто кто-то помог тебе горшок выдержать. Время простоя службы обычно непреднамеренное, что делать, если служба подчиненной библиотеки зависает.
Когда поток дампа binlog главной службы отправляет указанную информацию binlog подчиненной службе, в дополнение к содержимому журнала он также включает информацию об имени и расположении файла журнала bin-log на главном сервере с содержимым, отправленным этим время.
После получения информации от потока ввода-вывода службы запишите содержимое журнала в конец файла реального журнала (mysql-relay-bin.xxxxxx) и запишите имя прочитанного файла и местоположение файла bin-log. основного сервера в мастер-инфо (черезshow slave statusсерединаMaster_Info_Fileполе, чтобы увидеть, где сохраняется master.info), чтобы при следующем чтении мастер мог указать, где начать синхронизацию.
Post-Test Services от Threade SQL для реально-журнала Добавлен контент, анализ файлов журналов сгенерировал соответствующее оператор SQL, а также применить эту базу данных SQL, чтобы обеспечить согласованность данных от Master.
Поэтому, если ведомая библиотека зависает во времени, поскольку master.info записывает позицию последней синхронизации, пока служба синхронизации запускается снова, инкрементная синхронизация может продолжаться с позиции последней синхронизации.
Тем не менее, что делать, если основная библиотека не работает?Это еще одна грустная история.Это не так просто,как время простоя подчиненной библиотеки.Если ее запустить сразу,это лучшее решение. Если нет возможности перезапустить сразу из-за аппаратных или более сложных проблем, необходимо выбрать ведомую библиотеку для обновления до главной библиотеки.Критерий выбора - данные, наиболее близкие к основной библиотеке, то есть последние время синхронизации самое последнее. Если есть возможность (например, БД не может быть запущена в основном сервисе, а машина все еще там), для синхронизации следует подтянуть последний бин-лог из основного сервиса. Наконец, выполняется ряд настроек, чтобы изменить выбранную подчиненную библиотеку на конфигурацию главной библиотеки. (Я не буду расширять его, потому что, если я его снова раскрою, он раскроет свое содержимое, и я тоже не раскрою)
ShardingSphere-JDBC реализует разделение чтения и записи
После разделения master-slave необходимо разделить чтение и запись системы, операция записи идет на главный узел, а операция чтения — на подчиненный узел. Для этого требуется помощь промежуточного программного обеспечения базы данных.Сейчас более популярными промежуточными программами являются Atlas, Cobar, Mycat и Sharding-Sphere.Какое из них выбрать или разработать самостоятельно, зависит от стандартов каждой компании.
Sharding-Sphere включает ShardingSphere-JDBC и ShardingSphere-Proxy.
ShardingSphere-JDBC позиционируется как облегченная платформа Java, предоставляющая дополнительные услуги на уровне JDBC Java. Он использует клиент для прямого подключения к базе данных и предоставляет услуги в виде пакетов jar без дополнительного развертывания и зависимостей.Его можно понимать как расширенную версию драйвера JDBC, полностью совместимую с JDBC и различными ORM-фреймворками.
- Работает с любой инфраструктурой ORM на основе JDBC, такой как: JPA, Hibernate, Mybatis, Spring JDBC Template или с использованием JDBC напрямую.
- Поддержка любого стороннего пула подключений к базе данных, например: DBCP, C3P0, BoneCP, Druid, HikariCP и т. д.
- Поддерживает любую базу данных, реализующую спецификацию JDBC, в настоящее время поддерживает MySQL, Oracle, SQLServer, PostgreSQL и любую базу данных, соответствующую стандарту SQL92.
Текущая версия ShardingSphere — 4.x, адрес официального сайта: https://shardingsphere.apache.org/index_zh.html
Далее я кратко продемонстрирую, как ShardingSphere-JDBC + Spring Boot + MyBatis реализует простое разделение чтения-записи.
Выходные данные
JDK:1.8
Весенняя ботинка: 2.3.2.release (текущая последняя версия)
mybatis-spring-boot-starter:2.1.3 (последняя версия)
ShardingSphere-JDBC:4.1.1 (последняя версия)
Создайте проект Spring Boot
1. Перейдите в Spring Initializr (https://start.spring.io/), чтобы создать структуру проекта, выберите JDK версии 8, Spring Boot — 2.3.2 (последняя версия на данный момент) и введите информацию, связанную с проектом.
2. Представьте зависимости, связанные со Spring Boot, включая spring-boot-starter-web, mybatis-spring-boot-starter, mysql-connector-java и lombok.
3. Наконец, загрузите созданную структуру каталогов напрямую и импортируйте ее в IDEA, после чего maven сможет обновить пакет зависимостей.
4. Ввести пакет зависимостей ShardingSphere-JDBC специально для Spring Boot.
<dependency>
<groupId>org.apache.shardingsphere</groupId>
<artifactId>sharding-jdbc-spring-boot-starter</artifactId>
<version>4.1.1</version>
</dependency>
5. Настройте базу данных «главный-подчиненный», чтобы гарантировать, что запрос на чтение направляется на подчиненный узел, а запрос на запись — на главный узел.Используемый пул соединений — это hikari по умолчанию для Spirng Boot 2.x. Обратите внимание, что если используются другие пулы соединений, такие как Druid, атрибут jdbcUrl следует изменить на url.
spring:
shardingsphere:
datasource:
master:
type: com.zaxxer.hikari.HikariDataSource
driverClassName: com.mysql.cj.jdbc.Driver
jdbcUrl: jdbc:mysql://localhost:3306/master-slave?useUnicode=true&characterEncoding=utf8&tinyInt1isBit=false&useSSL=false&serverTimezone=GMT
username: root
password: password
slave0:
type: com.zaxxer.hikari.HikariDataSource
driverClassName: com.mysql.cj.jdbc.Driver
jdbcUrl: jdbc:mysql://192.168.0.108:3306/master-slave?useUnicode=true&characterEncoding=utf8&tinyInt1isBit=false&useSSL=false&serverTimezone=GMT
username: root
password: password
names: master,slave0
props:
sql.show: true
masterslave:
load-balance-algorithm-type: round_robin
sharding:
master-slave-rules:
master:
master-data-source-name: master
slave-data-source-names: slave0
Если есть несколько подчиненных узлов, вы можете продолжитьspring.shardingsphere.datasourceДобавьте под него slave1, slave2 и т.д.
Наконец, правила master-slave (правила master-slave) должны быть настроены для обеспечения разделения чтения и записи.Если эта конфигурация не добавлена, алгоритм маршрутизации round_robin будет использоваться для обработки главных и подчиненных узлов без разбора. Запросы на запись могут попасть на подчиненный узел, что приведет к невозможности синхронизации с главным узлом.
6. Настройте связанный с MyBatis mapper.xml, интерфейсы dao, сущности и т. д., не вводя слишком много.
7, добавьте службу, контроллер, добавьте метод запроса, выберите соответствующую базу данных. Добавьте новый метод, соответствующую вставку базы данных.
@RestController
@RequestMapping("user")
public class UserController {
@Autowired
private IUserService userService;
@GetMapping(value = "list")
public Object list() {
List<User> users = userService.list();
return users;
}
@PostMapping(value = "add")
public Object add(@RequestBody UserDto userDto) {
User user = new User();
BeanUtils.copyProperties(userDto, user);
return userService.addUser(user);
}
}
8. Наконец, запрашивая интерфейс списка и интерфейса «Добавить», вы можете увидеть через журнал, выберите «Пусть на маршруте из узла» вставьте настроить основной узел.
Исходный код находится на github, и студенты, которым он нужен, могут получить его на github.
Адрес склада: https://github.com/huzhicheng/play, в которомsharding-jdbc-write-read-splitПроект является образцом исходного кода для этой статьи.
Суммировать
Конфигурация ведущий-ведомый + разделение чтения-записи может в значительной степени обеспечить высокую доступность системы и общую производительность, а также является базовой конфигурацией начального уровня для интернет-приложений. MySQL может использовать bin-log для достижения синхронизации ведущий-ведомый.Главный узел отправляет журнал, сформированный операцией записи, на подчиненный узел в методе push.Подчиненный узел сначала записывает журнал в локальный ретрансляционный журнал, а затем записать его в базу данных.Файл master.info также обновляется во время процесса, чтобы записать местоположение локальной синхронизации для следующей инкрементной синхронизации.
Слой базы данных конфигурации и, наконец, для чтения и записи конфигурации в приложении конкретные конфигурации могут быть использованы или разработаны внутренне стабильные рамки с открытым исходным кодом, используемые в данном документе - это Shadingsphere-JDBC, только прокси-клиент, принцип - это принцип анализа SQL Письменное заявление, которое распространяется на разные узлы.
Если вам нужны более сложные операции, такие как соединение между базами данных, вам потребуется ПО промежуточного слоя прокси, такое как ShardingSphere-Proxy.
Не жди сильного мужика, сначала поставь лайк, меня вечно трахают зря, и мое тело этого не выдерживает!
Публичный аккаунт «Воздушный змей в Древние времена», Java-разработчик, full-stack инженер, известный как опоздавший маленький принц, убийца ошибок, хорошо решающий проблемы. Программист-поощритель с глубиной и широтой, пастырский фермер-кодировщик, который планировал писать стихи, но написал код! Придерживайтесь оригинального выхода галантереи, вы можете подписаться на меня сейчас или посмотреть исторические статьи, а затем обратить внимание. Нажмите и удерживайте QR-код, чтобы подписаться и стать лучше вместе со мной!