Масштабирование и эластичность базы данных жизненно важны для успешной работы любого программного приложения. Отсутствие адекватного масштабирования может привести к ухудшению бизнеса, поскольку приложения работают медленно или недоступны. Базы данных должны быть в сети и работать, чтобы защитить бизнес. Ниже мы поговорим о масштабировании базы данных в MySQL.
Масштабирование производственной базы данных становится важным, когда количество клиентов, выполняющих операции чтения-записи в любой конкретный момент времени (секунды, минуты), внезапно превышает возможности вашей базы данных. Если у вас только одна база данных, внезапный всплеск операций создания, чтения, обновления и удаления (CRUD) может вызвать узкое место и привести к остановке вашей системы.
Чтобы ваша система могла обрабатывать растущий объем работы или ее потенциал для выполнения большего объема работы за то же время, вам необходимо увеличить вычислительную мощность, чтобы обеспечить рост этого роста за счет масштабирования. Существуют различные способы масштабирования базы данных, например создание баз данных с независимыми таблицами для выполнения операций CRUD. Альтернативный метод - это копия реплики Master-Slave. Для целей этой статьи мы подробно рассмотрим концепцию «ведущий-ведомый» и покажем несколько примеров этого в действии.
Для простоты мы просто создадим одну главную базу данных и одну подчиненную базу данных. Операции записи будут обрабатываться в главной базе данных, а операции чтения - из подчиненной базы данных.
Во-первых, мы должны создать два экземпляра с использованием любого поставщика облачной инфраструктуры, такого как Azure, AWS, GCP и т. Д., И настроить главный экземпляр и подчиненную реплику.
Затем мы устанавливаем клиент и сервер MySQL в обоих экземплярах. Да, нам нужно установить клиент и сервер на обоих экземплярах. Поскольку мы используем Ubuntu 18.04, все команды bash / будут специфичными для Ubuntu (Apt вместо YUM). Если вам нужна помощь, обратитесь к руководству по установке здесь.
sudo apt update sudo apt install mysql-client sudo apt install mysql-server sudo mysql_secure_installation
После завершения установки мы генерируем ключ SSH и настраиваем аутентификацию ключа для права доступа на обоих серверах (в некоторых случаях только для ведомого узла).
ssh-keygenПосле того, как ключ сгенерирован, мы копируем его и вставляем в файл на любом из серверов.
~ / .ssh / authorized_keys
В этом примере использования мы будем использовать не общедоступный IP-адрес, а кластерный IP-адрес. Мы можем найти IP-адрес кластера каждого сервера, введя
имя хоста -I
в терминале.
У нас будет два IP-адреса, как для главного узла, так и для ведомого узла.
главный 172.31.17.41
подчиненный 172.31.0.127
Теперь мы настроим главный узел. Давайте сначала отредактируем файл конфигурации MySQL. (Примечание: если вы не можете найти файл конфигурации, вероятно, вы неправильно установили MySQL-сервер).
ubuntu@ip:~$ sudo nano /etc/mysql/mysql.conf.d/mysqld.cnf
Перейдите к следующим строкам, внесите указанные ниже изменения и сохраните файл:
bind-address = 172.31.17.41 # use your own cluster_ip server-id = 1 # can gave any id log_bin = /var/log/mysql/mysql-bin.log
Затем войдите на сервер MySQL с помощью
`mysql -u root -p`
и введите пароль root в приглашении MySQL.
mysql> GRANT REPLICATION SLAVE ON *.* TO 'root'@'%' IDENTIFIED BY 'root_user_password'; mysql> FLUSH PRIVILEGES;
Наконец, выйдите из MySQL, перезапустите службу MySQL и проверьте статус, чтобы убедиться, что она перезапущена успешно.
sudo systemctl restart mysql sudo systemctl status mysql
Мы должны быть осторожны, чтобы заблокировать чтение базы данных, чтобы запретить любые изменения.
FLUSH TABLES WITH READ LOCK; We shall go to the slave node, and do some configuration similar to what we did in the master node.
Здесь мы покажем, как проверить состояние главного узла.
mysql> show master status; +------------------+----------+--------------+------------------+-------------------+ | File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set | +------------------+----------+--------------+------------------+-------------------+ | mysql-bin.025471 | 154 | | | | +------------------+----------+--------------+------------------+-------------------+ 1 row in set (0.00 sec)
Обратите внимание на поля «Файл» и «Позиция» в полях основного статуса. Мы будем использовать эти значения, чтобы указать ведомому узлу создать реплику.
Поскольку нам нужно экспортировать базу данных как дамп БД, нам нужно сначала экспортировать базу данных, используя следующую команду:
$ mysqldump -u root -p --all-databases --lock-all-tables --events > mysqldb_bump.sql
После экспорта дампа мы переходим к MySQL, чтобы разблокировать таблицы и проверить состояние главного узла.
mysql -u root -p mysql> unlock tables; show master status\G
Если все в порядке, вы должны увидеть что-то похожее на это:
Не забудьте указать позицию.
Теперь мы можем скопировать дамп с главного узла на подчиненный узел во временном каталоге. В этом случае, поскольку мы используем облачные экземпляры, мы будем использовать общедоступный IP-адрес.
~$ scp -i slavekey.pem mysqldb_bump.sql [email protected]:/tmp/
Затем мы перейдем к подчиненному узлу и выполним некоторые настройки, аналогичные тем, что мы сделали с главным узлом. Вот как это выглядит:
ubuntu@ip:~$ sudo nano /etc/mysql/mysql.conf.d/mysqld.cnf bind-address = 172.31.0.127 # use your own cluster_ip server-id = 1 # can gave any id log_bin = /var/log/mysql/mysql-bin.log [Add these lines at buttom] read_only = 1 report_host = 172.31.17.41
После этого сохраните файл и перезапустите службу MySQL. Как и в случае с мастером, проверьте статус службы MySQL, чтобы убедиться, что все работает нормально.
Поскольку мы только что скопировали все данные с главного узла, у нас должен быть файл дампа SQL в каталоге / tmp подчиненного узла, который мы можем импортировать в MySQL следующим образом:
~$ mysql -u root -p < /tmp/mysqldb_bump.sql
Затем мы переходим к MySQL и вносим некоторые изменения в конфигурацию ведомого устройства следующим образом:
mysql> CHANGE MASTER TO MASTER_HOST='172.31.17.41',MASTER_USER='root', MASTER_PASSWORD='root_user_password', MASTER_LOG_FILE='mysql-bin.025469', MASTER_LOG_POS= 154;
После того, как указанная выше конфигурация установлена, мы можем запустить подчиненный узел и, конечно же, проверить состояние подчиненного узла, войдя в MySQL.
mysql> start slave mysql> show slave status\G
Статус должен выглядеть примерно так, как показано на скриншоте ниже.
Затем создайте базу данных на главном узле, просто войдя в MySQL и создав команду базы данных следующим образом:
mysql> create database delvifydb
Затем выйдите из MySQL и выйдите из системы.
Теперь мы подтвердим, что базу данных, созданную в Master Node, также можно увидеть в Slave Node. Мы делаем это, перейдя к подчиненному узлу и набрав команду show databases.
Бинго! Теперь у нас есть база данных, созданная в главном узле, реплицируемая в подчиненном узле.
Чтобы убедиться, давайте проверим, работает ли он так, как мы его настроили.
Сначала войдите в MySQL и выберите базу данных для использования. Создайте таблицу и напишите запись от мастера. Затем мы можем проверить, реплицируется ли он в подчиненном узле.
Этот тест прошел успешно, и вы можете подтвердить, что операция записи с главного узла была реплицирована на подчиненный узел. Поскольку это асинхронный процесс, при работе с очень большой базой данных может возникнуть очень небольшая задержка. Однако задержка почти всегда незначительна и составляет 1/10 секунды.
Сегодня мы обсудили простой метод создания масштабируемости в MySQL. Его можно расширить для решения многих проблем, с которыми вы можете столкнуться. База данных должна быть масштабируемой, чтобы быть доступной в любое время. Также существует проблема эластичности ваших рабочих нагрузок, о которой мы поговорим позже.
Готовы узнать больше?
Свяжитесь с нашей командой экспертов, чтобы узнать, как мы можем помочь вам в создании интеллектуальных решений для прогнозирования вашего бизнеса. Также приветствуем любые отзывы и комментарии!
