Как сделать репликацию базы данных sql

Обновлено: 06.07.2024

Расскажите друзьям о статье.

MySQL репликация Master-Slave используется для обеспечения отказоустойчивости приложений и позволяет распределить нагрузку на базу данных между несколькими серверами.
Настроим репликации базы данных на примере из 2 серверов:
1. Master-server, 192.168.100.1
2. Slave-server, 192.168.100.2

Часть 1. Настройка Master-server для репликации базы данных.

1.Откроем для редактирования файл конфигурации базы данных командой:

2. Перезапускаем службу Mysql:

3. Подключаемся к БД и создаем пользователя replication, под которым будет происходить репликация.

4. Блокируем все таблицы базы данных от изменений:

5. Вводим команду для просмотра статуса мастер:

Вывод примерный в табличном виде:

Запомним данные значения, для дальнейшей настройки.

Часть 2. Дамп базы данных.

1. Переносим базу данных в новое окно с помощью mysqldump:

2.снова входим в БД и разблокируем базу:

Часть 3. Настройка Slave-server для репликации базы данных.

1.Откроем для редактирования файл конфигурации базы данных командой:

2. Перезапускаем службу Mysql:

3. Настроим в консоли mysql:

4. Активируем репликацию на slave-сервере:

смотрим состояние репликации командой:

в выводе ищем строки, которые говорят об успешном запуске репликации:

Расскажите друзьям о статье.

Добавить комментарий Отменить ответ

Этот сайт использует Akismet для борьбы со спамом. Узнайте, как обрабатываются ваши данные комментариев.

В наши дни база данных MySQL используется уже практически везде, где только можно. Невозможно представить сайта, который бы работал без MySQL. Конечно, есть некоторые исключения, но основную часть рынка занимает именно эта система баз данных. И самая популярная из реализаций — MariaDB. Когда проект небольшой, для его работы достаточно одного сервера, на котором расположены все службы: веб-сервер, сервер баз данных и почтовый сервер. Но когда проект становится более большим может понадобится выделить для каждой службы отдельный сервер или даже разделить одну службу на несколько серверов, например, MySQL.

Для того чтобы поддерживать синхронное состояние баз данных на всех серверах одновременно нужно использовать репликацию. В этой статье мы рассмотрим как настраивается репликация MySQL с помощью MariaDB Galera Cluster.

Что такое MariaDB Galera?

MariaDB Galera — это кластерная система для MariaDB типа master-master. Начиная с MariaDB 10.1 программное обеспечение Galera Server и MariaDB Server поставляются в одном пакете, так что вы получаете все необходимое программное обеспечение сразу. На данный момент MariaDB Galera может работать только с движками баз данных InnoDB и XtraDB. Из преимуществ использования репликации можно отметить добавление избыточности для базы данных сайта. Если одна из баз данных, даст сбой, то вы сразу же сможете переключиться на другой. Все сервера поддерживают синхронизированное состояние между собой и гарантируют отсутствие потерянных транзакций.

Основные возможности MariaDB Galera:

Репликация с постоянной синхронизацией;
Автоматическое объединение узлов;
Возможность подключения нескольких узлов master;
Поддержка записи на любой из узлов;
Прозрачная параллельная репликация;
Масштабируемость чтения и записи, минимальные задержки;
Давшие сбой ноды автоматически отключаются от кластера;
Нельзя блокировать доступ к таблицам.

Дальше перейдем ближе к настройке MariaDB Galera.

Настройка репликации MySQL

В этой инструкции мы будем использовать для примера Ubuntu 16.04 и MariaDB версии 10.1. Перед тем, как начать полностью обновите систему:

sudo apt update -y
sudo apt upgrade -y

Поскольку мы будем развертывать нашу конфигурацию на нескольких узлах, нужно выполнить операции обновления на всех них. Если сервер баз данных MariaDB еще не установлен, его нужно установить. Сначала добавьте репозиторий и его ключ:

sudo apt update -y

Когда обновление списка пакетов завершено, установите MariaDB командой:

sudo apt install mariadb-server rsync -y

Пакет rsync нам понадобится для выполнения непосредственно синхронизации. Когда установка будет завершена, вам необходимо защитить базу данных с помощью скрипта mysql_secure_installation:

Enter current password for root (enter for none):
Change the root password? [Y/n] n
Remove anonymous users? [Y/n] Y
Disallow root login remotely? [Y/n] Y
Remove test database and access to it? [Y/n] Y
Reload privilege tables now? [Y/n] Y

Когда все будет готово, можно переходить к настройке нод, между которыми будет выполняться репликация баз данных mysql. Сначала рассмотрим настройку первой ноды. Можно поместить все настройки в my.cnf, но лучше будет создать отдельный файл для этих целей в папке /etc/mysql/conf.d/.

sudo vi /etc/mysql/conf.d/galera.cnf

Добавьте такие строки:

Здесь адрес 192.168.56.101 — это адрес текущей ноды. Дальше перейдите на другой сервер и создайте там такой же файл:

sudo vi /etc/mysql/conf.d/galera.cnf

Аналогично тут адрес ноды — 192.168.0.103. Остановимся на примере с двумя серверами, так как этого достаточно чтобы продемонстрировать работу системы, а добавить еще один сервер вы можете, прописав дополнительный IP адрес в поле wsrep_cluster_address. Теперь рассмотрим что означают значения основных параметров и перейдем к запуску:

binlog_format — формат лога, в котором будут сохраняться запросы, значение row сообщает, что там будут храниться двоичные данные;
default-storage-engine — движок SQL таблиц, который мы будем использовать;
innodb_autoinc_lock_mode — режим работы генератора значений AUTO_INCREMENT;
bind-address — ip адрес, на котором программа будет слушать соединения, в нашем случае все ip адреса;
wsrep_on — включает репликацию;
wsrep_provider — библиотека, с помощью которой будет выполняться репликация;
wsrep_cluster_name — имя кластера, должно соответствовать на всех нодах;
wsrep_cluster_address — список адресов серверов, между которыми будет выполняться репликация баз данных mysql, через запятую;
wsrep_sst_method — транспорт, который будет использоваться для передачи данных;
wsrep_node_address — ip адрес текущей ноды;
wsrep_node_name — имя текущей ноды.

Настройка репликации MySQL почти завершена. Остался последний штрих перед запуском — это настройка брандмауэра. Сначала включите инструмент управления правилами iptables в Ubuntu — UFW:

sudo ufw enable

Затем откройте такие порты:

sudo ufw allow 3306/tcp
sudo ufw allow 4444/tcp
sudo ufw allow 4567/tcp
sudo ufw allow 4568/tcp
sudo ufw allow 4567/udp

ЗАПУСК MARIADB GALERA

После успешной настройки всех нод нам останется только запустить кластер Galera на первой ноде. Перед тем как мы сможем запустить кластер, вам нужно убедиться, что сервис MariaDB остановлен на всех серверах:

sudo systemctl stop mysql

Дальше запустите скрипт создания нового кластера:

Проверить запущен ли кластер и сколько к нему подключено машин можно командой:

mysql -u root -p -e "show status like 'wsrep_cluster_size'"

Сейчас там только одна машина, теперь перейдите на другой сервер и запустите ноду там:

sudo systemctl start mysql

Вы можете проверить прошел ли запуск успешно и были ли какие-либо ошибки командой:

sudo systemctl status mysql

Затем, выполнив ту же команду, вы убедитесь, что новая нода была автоматически добавлена к кластеру:

mysql -u root -p -e "show status like 'wsrep_cluster_size'"

Чтобы проверить как работает репликация просто создайте базу данных на первой ноде:

MariaDB [(none)]> create database test_db;
MariaDB [(none)]> show databases;

Затем посмотрите действительно ли она была добавлена на всех других:

MariaDB [(none)]> show databases;

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

ВЫВОДЫ

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

Репликация MySQL позволяет синхронизировать данные между несколькими БД для повышения эффективности, безопасности и скорости работы. СУБД MySQL поддерживает репликацию "из коробки", но перед её использованием каждый раз требуется конфигурировать параметры базы. Программа Handy Backup обеспечивает репликацию MySQL с помощью последовательно созданных задач бэкапа и восстановления базы.

Попробовать бесплатно

Версия 8.3.3 от 28 ноября 2021. 112 MB
30-дневный полнофункциональный пробный период

Обеспечение репликации данных MySQL

Решение Handy Backup может оказаться очень удобным при выполнении следующих операций:

MySQL репликация Master-Master для СУБД MySQL
До того как произвести репликацию, вы можете переместить базы данных основного сервера на физический или виртуальный сервер, поддерживающий работу в подчинённом (Slave) режиме с копией БД.
Обеспечение для MySQL Master-Slave репликации сервера
Для увеличения производительности вашего веб-сайта или приложения рекомендуется установить несколько подчинённых (Slave) баз данных: это увеличивает доступность и скорость доступа к данным за счёт использования другого механизма хранения данных.
Сохранение важных данных на подчинённых (Slave) серверах
Важно понимать, что репликация MySQL не может заменить регулярного резервного копирования: эффективным путём здесь является комбинирование обоих подходов – резервное копирование данных со slave-серверов MySQL.

Организация репликации MySQL

При конфигурировании репликации MySQL в режиме mater-slave важно понимать принципы работы соответствующего механизма. В MySQL существуют два основных механизма репликации данных:

Операторная репликация (Statement-based replication) записывает все запросы SQL, сделанные к главной (Master) БД, и воспроизводит их на подчинённых (Slave) серверах. Этот метод быстр, но не очень точен: например, если вы вставляете в поле таблицы случайное значение, полученное с помощью функции MySQL RAND(), результат, хранимый в разных копиях БД, будет различаться.
Построчная репликация (Row-based replication) подсчитывает все изменения в главной (Master) БД и автоматически изменяет записи в таблицах подчинённой (Slave) БД всякий раз при обнаружении новых данных. Этот подход значительно медленнее, чем операторная репликация MySQL, но предоставляет высокую мобильность данных и намного эффективнее влияет на производительность Slave серверов.

Как можно заметить, оба типа репликации предполагают, что у вас есть две версии БД, которые поддерживаются в синхронизированном состоянии. С Handy Backup вы можете легко синхронизировать ваши базы данных, сохранив их на главном (Master) сервере и восстановив на Slave-сервере. Узнать подробнее о бэкапе MySQL.

Рекомендуемое решение
9200 ₽ за лицензию

Handy Backup Office Expert

Решение Office Expert идеально подходит для репликации баз данных MySQL. Бесплатная полнофункциональная пробная версия - 30 дней!

Конфигурирование дополнительных (Slave) баз данных MySQL

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

Конфигурирование репликации MySQL

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

MyISAM – быстрый и нетребовательный к ресурсам алгоритм, но он не поддерживает транзакции и имеет блокировку доступа на уровне таблиц. До версии MySQL 5.5 это был основной механизм хранения данных. Его основной недостаток в том, что он не позволяет производить множество одновременных операций при обновлении таблиц.
InnoDB – безопасный по транзакциям механизм хранения, поддерживающий блокировку на уровне отдельных строк, подтверждения и откаты транзакций, кэширование индекса и многие другие полезные функции. Во многих аспектах он превосходит по производительности все остальные механизмы хранения данных СУБД MySQL.

Конфигурирование репликации Master-to-Slave подразумевает, что вы собираетесь использовать БД на Slave-серверах только для чтения. Для этой цели MyISAM привлекательнее, поэтому ваши Slave-серверы должны использовать именно его.

Схема репликации MySQL с основного на подчиненный сервер

Конфигурирование Slave-серверов в Handy Backup может производиться так:

Плагин MySQL создаёт набор дамп-файлов, по одному на каждую таблицу MySQL. Каждый дамп-файл содержи все SQL-запросы, необходимые для создания и заполнения данными каждой конкретной таблицы.
Формат дамп-файлов легко читается и модифицируется вручную, как текстовые файлы. Найдите оператор CREATE TABLE в начале каждого файла и измените параметр ENGINE=InnoDB на ENGINE=MyISAM.
Теперь вы можете восстановить БД из дамп-файлов на Slave-сервере.

Попробовать бесплатно

Версия 8.3.3 от 28 ноября 2021. 112 MB
30-дневный полнофункциональный пробный период

Важно запомнить или записать, какие механизмы хранения использовались в оригинале в таблицах Master-сервера. Если Master-сервер упадёт, вам будет необходимо восстановить данные на нём в обратном порядке (детали описаны в нижеприведённом разделе "Проблемы восстановления").

После восстановления таблиц на Slave-сервере вам понадобится запустить его в режиме MySQL Slave. Это может быть сделано с помощью оператора CHANGE MASTER TO, информацию о котором вы можете прочесть в официальном руководстве.

Настройка резервного копирования на Slave-сервере

Общая проблема резервного копирования MySQL заключается в том, что процесс бэкапа отрицательно влияет на производительность. В этом случае репликация MySQL весьма выгодна: она не только разгружает основную БД, но также ускоряет и упрощает резервное копирование.

При конфигурировании репликации в режиме Master-to-Slave, Slave-серверы настраиваются для обеспечения максимально быстрого доступа к ним. Поскольку резервное копирование является операцией чтения, бэкап БД на Slave-сервере может быть выполнен без нагрузки Master-сервера.

Резервное копирование MySQL на Slave-сервере

Проблемы восстановления

Восстановление баз данных MySQL в режиме репликации Master-to-Slave может представлять известные трудности. Эта операция отличается от типичного восстановления MySQL тем, что работает с множеством БД вместо одной.

Восстановление после сбоя Slave сервера

Если Slave-сервер подвергся аварийной остановке, вам необходимо просто повторить на нём настройку БД в Slave-режиме, описанную ранее. Сделайте копию базы данных на Master-сервере, смените механизм хранения, восстановите БД на Slave-сервере и разрешите репликацию; этого будет достаточно.

Восстановление Master сервера

Гораздо сложнее восстановление в случае аварии или падения Master-сервера. Во многих случаях вы не сможете использовать ваши БД в режиме "только для чтения", поэтому просто переключите один из Slave-серверов в режим Master. Чтобы сделать это, выполните следующие операции:

Выберите Slave-сервер MySQL для перевода в Master-режим.
Используйте операторы STOP SLAVE и RESET MASTER, чтобы запустить выбранную базу в автономном режиме.
На всех остальных Slave-серверах используйте оператор STOP SLAVE IO_THREAD, чтобы завершить необработанные операции синхронизации с предыдущим Master-сервером.
Далее используйте оператор CHANGE MASTER TO с верными параметрами, и выполните операцию START SLAVE, чтобы запустить процесс репликации с нового Master-сервера на Slave-серверы.

Внимание! Использование Slave-сервера в качестве Master-сервера является временной мерой, так как механизм хранения данных MyISAM оптимизирован для чтения и очень медленно исполняет операции изменения и добавления данных. Поэтому рекомендуется восстановить функциональность предыдущего Master-сервера так быстро, как только возможно.

Сделайте заново копию одного из Slave-серверов MySQL. По соображениям производительности, не следует использовать для этого временный Master-сервер (но если он остался единственным работающим сервером, такое падение производительности всё же лучше, чем остановка операций системы).

Совет: Для эффективного сохранения копий MySQL попробуйте наше ПО – скачайте Handy Backup прямо сейчас!

Модифицируйте дамп-файл, созданный программой, изменив механизм хранения данных в таблицах на тот, что использовался в базе данных Master-сервера.
Выполните процедуру восстановления.
Повторите шаги 1-4, как если бы Master-сервер (предыдущий Slave) упал и у вас возникла бы необходимость установить восстановленную БД в качестве новой Master.

Информация о продукте

Для резервного копирования, восстановления и репликации баз данных MySQL вам понадобится одно из решений Handy Backup, предназначенных для использования в коммерческих целях:

Handy Backup Office Expert

Решение Office Expert подходит для репликации базы MySQL на одном сервере.

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

Что такое репликация

Репликация — это дублирование данных, когда данные с одного сервера полностью повторяются на других. Приложения пишут данные в одну базу данных PostgreSQL, а изменения автоматически синхронизируются на другие базы.
Репликация используется для достижения двух целей:

Повышение отказоустойчивости. Если один из серверов выйдет из строя, то остальные продолжат работу.
Повышение производительности. Распределение данных по серверам в разных частях страны или мира повышает скорость доступа к данным для местных пользователей.

Виды репликации в PostgreSQL

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

Когда PostgreSQL получает команду на изменение данных, она не сразу изменяет их на диске. Сначала она записывает изменения в WAL. Этот журнал нужен для того, чтобы в случае сбоя сервера можно было восстановить незафиксированные данные. Также WAL используется и для репликации данных.

Итак, в PostgreSQL есть несколько видов репликации:

Потоковая репликация (Streaming Replication). Это репликация, при которой от основного сервера PostgreSQL на реплики передается WAL. И каждая реплика затем по этому журналу изменяет свои данные. Для настройки такой репликации все серверы должны быть одной версии, работать на одной ОС и архитектуре. Потоковая репликация в Postgres бывает двух видов — асинхронная и синхронная.

Асинхронная репликация. В этом случае PostgreSQL сначала применит изменения на основном узле и только потом отправит записи из WAL на реплики. Преимущество такого способа — быстрое подтверждение транзакции, т.к. не нужно ждать пока все реплики применят изменения. Недостаток в том, что при падении основного сервера часть данных на репликах может потеряться, так как изменения не успели продублироваться.
Синхронная репликация. В этом случае изменения сначала записываются в WAL хотя бы одной реплики и только после этого фиксируются на основном сервере. Преимущество — более надежный способ, при котором сложнее потерять данные. Недостаток — операции выполняются медленнее, потому что прежде чем подтвердить транзакцию, нужно сначала продублировать ее на реплике.

Логическая репликация (Logical Replication). Логическая репликация оперирует записями в таблицах PostgreSQL. Этим она отличается от потоковой репликации, которая оперирует физическим уровнем данных: биты, байты, и адреса блоков на диске. Возможность настройки логической репликации появилась в PostgreSQL 10.
Этот вид репликации построен на механизме публикации/подписки: один сервер публикует изменения, другой подписывается на них. При этом подписываться можно не на все изменения, а выборочно. Например, на основном сервере 50 таблиц: 25 из них могут копироваться на одну реплику, а 25 — на другую.
Также есть несколько ограничений, главное из которых — нельзя реплицировать изменения структуры БД. То есть если на основном сервере добавится новая таблица или столбец — эти изменения не попадут в реплики автоматически, их нужно применять отдельно.
В отличие от потоковой репликации, логическая может работать между разными версиями PostgreSQL, ОС и архитектурами.

Облачные базы данных

Установить PostgreSQL

Перейдем к практике: настроим потоковую асинхронную репликацию в режиме Master-Replica: один сервер — основной, в него можно писать данные, другой — реплика, из него можно только читать.

На примере платформы Selectel создадим два отдельных сервера PostgreSQL, один из которых будет основным (Master), а второй — репликой (Replica).

Укажем имя сервера — Master. Так нам будет проще ориентироваться в серверах. Выберем ОС — Ubuntu 20.04, конфигурацию — 2 vCPU, 8 ГБ оперативной памяти и 10 ГБ диска.

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

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

Теперь нужно подключиться к каждому серверу по SSH. Рекомендуем открыть 2 окна терминала и держать их открытыми, потому что мы будем часто переключаться между серверами.

Итак, подключаемся к серверам и устанавливаем PostgreSQL на каждом из них:

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

Настроить Master-сервер

Репликацию будем выполнять под пользователем postgres, который автоматически создается после установки PostgreSQL. Установим ему пароль, он нам понадобится позже:

Далее нужно разрешить этому пользователю подключаться из Replica-сервера в Master. Для этого мы отредактируем файл /etc/postgresql/12/main/pg_hba.conf.
Обратите внимание, что мы показываем настройку репликации на примере PostgreSQL 12, поэтому в пути к файлу есть номер — 12. Если у вас другая версия PostgreSQL, то вам нужно поменять путь к файлу.

Итак, откроем файл:

Так мы разрешаем пользователю postgres подключаться к этому серверу из Replica.

Обратите внимание, что мы используем приватные адреса, потому что виртуальные машины находятся в одной сети. При этом нам не нужно открывать порты, настраивать Firewall и так далее. Если ваши машины будут находиться в разных сетях или вы хотите, чтобы они общались друг с другом по публичным адресам — скорее всего вам придется настроить Firewall.
Далее нужно указать настройки репликации. Открываем конфигурационный файл PostgreSQL:

Находим в нем эти параметры, раскомментируем их и подставляем указанные значения.

Все, Master настроен. Чтобы применить настройки, перезапускаем сервер:

Настроить Replica-сервер

Переключаемся в окно терминала Replica-сервера. Перед началом настройки нужно остановить PostgreSQL-сервер:

Аналогично Master-серверу отредактируем файл pg_hba.conf. В то же самое место вставим ту же самую строчку, но только теперь укажем IP-адрес мастера.

Добавляем в него строчку:

Затем правим файл postgresql.conf. Настройки те же самые, как и у Master, только нужно поменять IP-адрес. Открываем файл на редактирование:

Находим в нем эти параметры, раскомментируем их и подставляем указанные значения:

Сейчас настройки обоих серверов одинаковые, отличаются только IP-адреса. Это потому, что при необходимости реплики могут становиться мастером, а вся разница будет в наличии одного лишь файла. О нем расскажем далее.
Прежде чем Replica-сервер сможет начать реплицировать данные, нужно создать новую БД, идентичную Master-серверу. Для этого воспользуемся утилитой pg_basebackup. Она создаст бэкап с Master-сервера и скачает его на Replica-сервер. Эту операцию нужно выполнять от имени пользователя postgres, поэтому логинимся от него:

Далее переходим в каталог с базой данных:

Удалим каталог с дефолтной БД и снова его создадим, но уже пустой:

Теперь выгрузим БД с мастера. Для выполнения этой команды нужно будет ввести пароль от пользователя postgres, который мы задавали в самом начале настройки Master-сервера.

В этой команде есть важный параметр -R. Он означает, что PostgreSQL-сервер также создаст пустой файл standby.signal. Несмотря на то, что файл пустой, само наличие этого файла означает, что этот сервер — реплика.

Файл standby.signal появился только в PostgreSQL версии 12. Раньше вместо него создавался файл recovery.conf, в котором хранились настройки для подключения к Master-серверу. Имейте это ввиду, если вы используете более ранние версии PostgreSQL.

Возвращаемся в root-пользователя и запускаем PostgreSQL-сервер:

Проверить репликацию

Теперь нужно протестировать репликацию и убедиться, что мы все правильно настроили. На Master-сервере создадим таблицу и вставим в нее одну строчку:

Переключимся в терминал Replica-сервера и проверим, что таблица с данными появилась:

Еще одна проверка — попробуем создать новую таблицу на сервере Replica. Если мы все сделали правильно, то сервер не должен позволить нам этого сделать, потому что он настроен только на репликацию с основной БД.
На Replica-сервере выполняем команду:

Значит репликация настроена правильно.
Теперь покажем, как можно из Replica-сервера сделать Master. Сымитируем ситуацию, что основной сервер вышел из строя. Для этого в консоли управления платформой Selectel просто выключим сервер Master.

Чтобы перевести Replica-сервер в режим записи, выполните команду:

Проверяем, снова пробуем создать новую таблицу:

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

Заключение

Читайте также: