Bt-teh.ru

БТ Тех
0 просмотров
Рейтинг статьи
1 звезда2 звезды3 звезды4 звезды5 звезд
Загрузка...

Русские Блоги

Русские Блоги

Как добиться синхронизации репликации master-slave сервера MySQL?

Справочник статей

Предисловие

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

Один: причина и решение репликации мастер-подчиненный

1.1: Причина

  • На корпоративном веб-сайте, когда есть только одна серверная база данных MySQL, возникнут следующие проблемы:
    • Обнаружена единая точка отказа, служба недоступна
    • Невозможно обработать большое количество одновременных запросов данных
    • Потеря данных приведет к большим потерям

    1.2: Решение

    • Увеличьте сервер базы данных MySQL для резервного копирования данных, чтобы сформировать мастер / резервную копию
    • Убедитесь, что данные первичного и вторичного сервера базы данных MySQL совпадают.
    • Главный сервер не работает, сервер резервного копирования продолжает работать, и данные гарантированы
    • Репликация MySQL master-slave и разделение чтения-записи тесно связаны
    • mark

    1.3: более продвинутые решения

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

    Amoeba: это прокси, который использует MySQL в качестве основного хранилища данных и предоставляет интерфейсы протокола MySQL для приложений, по прозвищу Amoeba

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

    Главный сервер не работает, мы будем использовать MHA для решения этой проблемы (не используется в этом эксперименте)

    Разрешения учетной записи, участвующие в этом эксперименте

    • Учетная запись Master-Slave
    • Открытая учетная запись планирования узла сервера
    • Amoeba прокси аккаунт

    mark

    1.4: Типы репликации «главный-подчиненный» MySQL

    • Репликация на основе операторов (по умолчанию)
      • Оператор выполняется на главном сервере, выполняет тот же оператор на сервере.
      • Скопируйте измененный контент на подчиненный сервер
      • Как только будет установлено, что копия на основе оператора не может быть точно реплицирована, будет использована репликация на основе строки

      1.5: Рабочий процесс репликации master-slave

      • mark

      2: Практика эксперимента репликации ведущий-ведомый

      2.1: Окружающая среда

      • Четыре сервера centos7
      • Один как клиент
      • Три как серверы MySQL

      2.2: Топологическая диаграмма

      mark

      2.3: Экспериментальная цель

      • Реализация репликации мастер-подчиненный через конфигурацию

      2.4: Экспериментальный процесс

      2.4.1: настройки брандмауэра

      Все серверы закрывают брандмауэр или устанавливают правила

      2.4.2. Создание среды синхронизации времени

      Установите и настройте сервер синхронизации времени NTP на основном сервере

      Используйте yum для установки службы NTP

      Измените ntp.conf и установите главный сервер в качестве источника синхронизации времени.

      Синхронизация времени на подчиненном сервере

      Используйте yum для установки ntpdate и синхронизации времени

      2.4.3: скомпилируйте и установите mysql

      Необходимо скомпилировать и установить три базы данных mysql.

      MySQL установки см. еще один мой блог, который написал

      2.4.4. Настройка главного сервера mysql

      Измените файл конфигурации /etc/my.cnf, добавьте идентификатор сервера, настройте параметры двоичного журнала

      Войдите в службу mysql и авторизуйте все разрешения для копирования двоичных журналов с сервера.

      Синхронизация MySQL баз после ошибки репликации

      В процессе длительной работы с двумя и более MySQL баз данных, между которым происходит репликация, можно столкнуться с массой мелких ошибок, вызванных, например, конфликтами первичных ключей, повреждениями журналов и т.п. Особенно, если репликация настроена, как мастер-мастер, конфликты гарантированы. Естественно, из-за мелких ошибок никто не станет полностью заново синхронизировать две базы данных, а скорее всего, пропустит ошибку через установку SQL_SLAVE_SKIP_COUNTER или slave-skip-errors. Со временем, две БД накопят некий запас неконсистентности, благодаря таким пропущенным конфликтам. Итак, что делать, если нужно восстановить полную консистентность, или в случае, когда ошибка в репликации совсем критичная и не решается вышеописанными способами? Единственный выход — полная синхронизация двух БД «с нуля» и сброс состояния репликации.

      Порядок действий таков — на мастере:

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

      Далее, не закрывая соединения с мастер базой (т.к. это снимет режим только чтения), делаем дамп всех необходимых данных:

      Теперь можно снять режим чтения командой

      Следующий шаг — скопировать дамп на слейв сервер и выполнить там:

      Импортируем загруженный с мастер сервера дамп:

      Далее на слейве удаляем все журналы от мастера и начинаем репликацию с момента, когда на мастере был сделан дамп:

      Убеждаемся в том, что параметры Slave_IO_Running и Slave_SQL_Running установлены в Yes. В случае, если у вас мастер-мастер репликация, продолжаем на слейв сервере:

      Снова запоминаем File и Position и на мастер сервере делаем:

      Убеждаемся в том, что параметры Slave_IO_Running и Slave_SQL_Running установлены в Yes.

      На слейве снимаем лок и запускаем репликацию:

      Подробнее о настройке мастер-мастер репликации с нуля можно прочитать

      — See more at: http://www.sover.pro/blogs/54-sinhronizaciya-mysql-baz-posle-oshibki-replikacii.html#sthash.uf9cRY0w.dpu

      Ошибка «Error 1292: Incorrect date / datetime value» при синхронизации
      Суть проблемы: чаще всего такая ошибка возникает при попытке синхронизации с таблицей, в которой есть запись со значением '0000-00-00' или '0000-00-00 00:00:00' в полях типа DATE или DATETIME соответственно. В некоторых случаях настройки MySQL позволяют создавать такие записи, но не позволяют редактировать схему таблицы.

      Решение: вообще, при синхронизации или экспорте данных MySQL Workbench добавляет специальные запросы, как бы оборачивая основной SQL код:

      invalid-dates-solution

      Вчитавшись в этот код, начинаешь думать, что программа пытается решить эту проблему самостоятельно. Парадокс в том, что для решения проблемы эти строки нужно удалить:

      # Удалить эту строку из конца SQL кода

      Ошибка «Error 1005: Can't create table '. ' (errno: 150)» при синхронизации
      Суть проблемы: обычно эта ошибка касается неправильной настройки внешних ключей (вкладка «Foreign Keys» в настройках таблиц). У меня она возникала в том случае, если я делал ключом поле с меткой NOT NULL, а в поведении внешнего ключа указывал SET NULL — это абсурд, ведь InnoDB не сможет установить значение NULL в поле, где такое значение запрещено.

      Решение: внимательно следим за настройкой поведения внешних ключей. Если необходимо поведение SET NULL, у поля-ключа в дочерней таблице не должен стоять флаг NOT NULL.
      Ошибка «Field . can not be null» при выгрузке стартовых данных
      Суть проблемы: независимо от настроек таблицы, все поля в «Inserts» имеют по умолчанию значение NULL, даже если такое значение не разрешено для данного поля. Соответственно, при выгрузке на сервер может возникнуть ошибка.

      Синхронизация двух баз данных mysql на разных серверах (один и тот же провайдер)

      У меня очень мало опыта работы с MySQL/SQL в целом-всего n00b на самом деле!

      У меня есть живой сайт и dev-сайт, которые размещены на одном и том же ISP, но на разных серверах, то есть mysql1.foo.net и mysql2.foo.net.

      Я хотел бы выяснить самый простой способ синхронизации двух баз данных — без необходимости экспортировать все это, стереть базу данных dev и восстановить.

      4 ответа

      • синхронизация двух таблиц из двух разных баз данных PostgreSQL

      У меня есть две таблицы из двух разных баз данных, и я хочу, чтобы функция php синхронизировала данные, чтобы Таблица № 2 всегда могла проверить содержимое таблицы 1 и обновить ее информацию. У кого-нибудь есть хоть один пример того, как это сделать? Заранее спасибо.

      У меня следующая ситуация. У меня есть два экземпляра mongodb на разных серверах. Например Mongodb instance on server one (host1:27017) with database: test1 Mongodb instance on server two (host2:27017) with database: test2 Теперь мне нужно синхронизировать базу данных test1 с host1:27017 с test2.

      Боюсь, что решения «easy» не существует. За исключением довольно небольших баз данных для сброса производства и восстановления на dev в течение ночи. Малый определяется как взятие <12hrs для операций восстановления резервной копии, что все еще очень велико.

      Репликация, вероятно, не сократит его, так как наличие копии только для чтения имеет ограниченную ценность, и я предполагаю, что вы не хотите, чтобы изменения в базе данных dev распространялись на prod.

      Дамп — восстановление (если это возможно) имеет преимущества, хотя — вы регулярно проверяете, что резервная копия действительно работает — вам необходимо регулярно писать и тестировать сценарии миграции схем — вам нужно сделать их «hands-off», чтобы они могли работать как задание cron

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

      На больших базах данных я не думаю, что существуют простые (или дешевые!) методы.

      MySQL поддерживает репликацию master+slave и master+master, однако ваш хостинг-провайдер должен будет настроить это для вас.

      Смотрите здесь для получения дополнительной информации, если вы заинтересованы: http://www.howtoforge.com/mysql_master_master_replication

      Если вы хотите синхронизировать их время от времени, просто используйте:

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

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

      Я бы решил эту проблему, создав задание ssis, чтобы изменить ситуацию, вы можете использовать различные инструменты, но вы должны убедиться, что в ваших таблицах есть что-то, что вы можете использовать для определения новых данных. Временные метки нельзя использовать, так как процесс занимает больше секунды, и это делает его ненадежным, я бы настроил столбцы экспорта, или если таблицы достаточно малы, где ваши индексы составляют менее 3 ГБ на таблицу, вы можете использовать эти столбцы для выполнения задачи. В конечном счете, вы знаете данные лучше, чем мы, поэтому оптимальное решение.

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

      Помимо репликации, вы должны посмотреть MySQLdbcopy из утилит MySQl. Ваши базы данных могут быть достаточно малы, чтобы скопировать их с помощью MySQLdbcopy, и вы можете поместить их в задание cron для автоматизации

      • Преобразование MySQL в PostgreSQL и синхронизация данных

      У меня есть относительно большая база данных MySQL (более 300 таблиц), которую мне отчаянно нужно преобразовать в PostgreSQL и синхронизировать данные между двумя базами данных, если не в реальном времени, то что-то близкое к нему. В идеале мне нужна двунаправленная синхронизация данных или, по.

      Допустим, у нас есть таблица на двух разных серверах баз данных ( например, разработки и тестирования). Я хочу сравнить данные, хранящиеся в этой таблице. Предположим, что после выполнения таблицы на сервере базы данных dev мы получаем 10 значений и столько же данных, сколько и на тестовом сервере.

      Похожие вопросы:

      Я создал два связанных сервера-один из Mysql, а другой из удаленного MSSQL. можно ли синхронизировать таблицы в этих двух связанных серверах из разных баз данных?

      У меня есть две базы данных MySQL на двух отдельных серверах . Оба будут принимать один и тот же CMS, но один будет обслуживать общий трафик посетителей , в то время как другой — главный — доступен.

      У нас есть сайт, размещенный крупной международной компанией, и наш пакет включает в себя несколько баз данных MySQL: они находятся на разных серверах. Я хочу запустить запрос SQL для выбора.

      У меня есть две таблицы из двух разных баз данных, и я хочу, чтобы функция php синхронизировала данные, чтобы Таблица № 2 всегда могла проверить содержимое таблицы 1 и обновить ее информацию. У.

      У меня следующая ситуация. У меня есть два экземпляра mongodb на разных серверах. Например Mongodb instance on server one (host1:27017) with database: test1 Mongodb instance on server two.

      У меня есть относительно большая база данных MySQL (более 300 таблиц), которую мне отчаянно нужно преобразовать в PostgreSQL и синхронизировать данные между двумя базами данных, если не в реальном.

      Допустим, у нас есть таблица на двух разных серверах баз данных ( например, разработки и тестирования). Я хочу сравнить данные, хранящиеся в этой таблице. Предположим, что после выполнения таблицы.

      У меня есть два разных сервера баз данных на двух разных адресах IP. Скажем, SERVER_1 и SERVER_2 (SQL Server 2012). Как записать триггер в таблицу из базы данных SERVER_1 и запись insert в таблицу.

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

      Я хочу получить данные из нескольких баз данных mysql, которые находятся на нескольких серверах. Я использую phpmyadmin (mysql). Все базы данных будут mysql database (один и тот же поставщик).

      MariaDB: Настройка репликации базы данных в режиме Master-Master/Slave

      date18.10.2019
      userVyacheslavK
      directoryCentOS, Linux
      commentsкомментария 2

      Репликация в SQL базах данных это процесс копирования данных из одного источника в другой (или на несколько) и в обратнуюм сторону. Данные с одного сервера баз данных, постоянно копируются на один или несколько других серверов. С помощью репликации можно распределять нагрузку на сервера, обеспечивать отказоустойчивость и высокую доступность баз данных MariaDB. СУБД MariaDB/MySQL позволяет использовать два типа репликации БД Master-Master и Master-Slave. В данной статье мы рассмотрим, как настроить оба типа репликации MariaDB в CentOS 7. Начнем!

      Установка MariaDB.

      Ранее мы размещали статью с описанием процесса установки MariaDB на CentOS 7. Ознакомиться с ней вы можете по ссылке https://winitpro.ru/index.php/2019/08/28/ustanovka-i-optimizaciya-mariadb/. Поэтому, заострять внимание на самой установке MariaDB мы не будем, а сразу перейдем к настройке репликации.

      Настройка репликации Master-Master в MariaDB

      В схеме репликации Master-Master любой из серверов баз данных MariaDB/MySQL, может использоваться как для записи информации, так и для чтения. Многие считают данный тип репликации не совсем привлекательным. Если из строя выйдет один из серверов, с большей вероятностью потери данных будут и на других Master-серверах. Обычно данная схема используется, когда на всех серверах нужно обеспечить и запись, и чтение информации.

      Репликация основана на специально файле binlog, в который Master сервер сохраняет все операции с БД. Slave сервер подключается к мастеру и применяет команды к своим базам.

      1. MariaDB: Настройка первого мастер сервера (Master-1)

      Добавляем в наш конфигурационный файл my.cnf на первом сервере MariaDB следующие строки:

      #replication
      server-id = 1
      report_host = master
      log_bin = /var/lib/mysql/mariadb-bin
      log_bin_index = /var/lib/mysql/mariadb-bin.index
      relay_log = /var/lib/mysql/relay-bin

      mariadb настройка my.cnf на мастер сервере репликации

      service mariadb restart

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

      mysql
      create user ‘test_master’@’%’ identified by ‘test_master’;
      grant replication slave on *.* to ‘test_master’@’%’;

      Для добавления Slave нам понадобятся данные bin_log с сервера Master1.

      MariaDB [(none)]> show master status;

      mysql create user grant replication slave

      Это будет наш Master-1.

      2. MariaDB: Настройка второго мастер сервера (Master-2)

      Подключимся ко второму MariaDB серверу, открываем конфигурационный файл my.cnf и добавляем информацию:

      #replication
      server-id = 2
      report_host = master2
      log_bin = /var/lib/mysql/mariadb-bin
      log_bin_index = /var/lib/mysql/mariadb-bin.index
      relay_log = /var/lib/mysql/relay-bin
      relay_log_index = /var/lib/mysql/relay-bin.index

      mariadb настройка my.cnf второго сервера при master-master репликации

      И так же создаем пользователя на втором сервере:

      create user ‘test_master2’@’%’ identified by ‘test_master2’;
      grant replication slave on *.* to ‘test_master2’@’%’;
      Bin_log на Master-2:

      MariaDB [(none)]> show master status;

      Приступим к настройке подключения между серверами MariaDB в нашем програмном кластере:

      Добавляем Master-1 на второй сервер:

      CHANGE MASTER TO MASTER_HOST=’IP_master1′, MASTER_USER=’test_master’, MASTER_PASSWORD=’test_master’, MASTER_LOG_FILE=’mariadb-bin.000002′, MASTER_LOG_POS=664;

      mariadb: start slave

      Подключаемся на Master-1 и выполним ту же процедуру, только указав уже данные второго нашего сервера:

      STOP SLAVE;
      CHANGE MASTER TO MASTER_HOST=’183.219.19.36′, MASTER_USER=’test_master2′, MASTER_PASSWORD=’test_master2′, MASTER_LOG_FILE=’mariadb-bin.000001′, MASTER_LOG_POS=667;
      START SLAVE;

      Проверим статус второго сервера:

      show slave status G

      mariadb show slave status G

      Как видим на скриншотах, коннекты на двух серверах есть, ошибок не наблюдается.

      3. Проверка репликации между серверами MariaDB.

      Далее, чтобы проверить, что репликация между двумя серверами MariaDB работает в режиме master+master и что она вообще работает, мы создадим новую базу на Master-1 и создадим в ней таблицу.

      MariaDB [(none)]> create database master1;

      MariaDB [(none)]> use master1;

      MariaDB [master1]> CREATE TABLE hello (

      -> AuthorID INT NOT NULL AUTO_INCREMENT,

      Query OK, 0 rows affected (0.005 sec)

      mariadb проверка репликации

      Проверяем, что база автоматически появилась и на втором мастере, и в ней также присутствует наша таблица:

      MariaDB [(none)]> show databases;

      MariaDB [(none)]> use master1;

      MariaDB [master1]> show tables;

      База создалась и на втором мастере. Для полной проверки, создадим таблицу в базе данных master1 со второго мастер-сервера и проверим, передадутся ли они в обратную сторону.

      MariaDB [master1]> CREATE TABLE hello_master1 (

      -> AuthorID INT NOT NULL AUTO_INCREMENT,

      Таблица hello_master1 передалась на первый сервер:

      MariaDB [master1]> show tables;

      репликация таблицы межды базыва mariadb/mysql

      Как вы видите, новая таблица появилась на Master-1. Репликация работает так, как мы и хотели.

      Настройка Master-Slave репликации в MariaDB

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

      При настройке реплики базы данных MariaDB по типу master + slave, мастер сервера (master1) настраивается как описано выше.

      Переходим к slave серверу. Добавляем в my.cnf строки:

      #replication
      server-id = 2
      report_host = slave2
      log_bin = /var/lib/mysql/mariadb-bin
      log_bin_index = /var/lib/mysql/mariadb-bin.index
      relay_log = /var/lib/mysql/relay-bin
      relay_log_index = /var/lib/mysql/relay-bin.index

      Перезапускаем mariadb. На первом сервере берем данные bin_log.

      MariaDB [(none)]> show master status;

      На slave сервер в консоли консоли mysql выполняем следующее:

      MariaDB [(none)]> STOP SLAVE;

      MariaDB [(none)]> CHANGE MASTER TO MASTER_HOST=’IP_master’, MASTER_USER=’test_master’, MASTER_PASSWORD=’test_master’, MASTER_LOG_FILE=’mariadb-bin.000001′, MASTER_LOG_POS=664;

      MariaDB [(none)]> START SLAVE;

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

      Проверка статуса Slave: SHOW SLAVE STATUSG;

      Создаем БД на Master:

      MariaDB [(none)]> create database master_hello;

      Проверяем, что база данных создалась и на Slave сервер:

      MariaDB [(none)]> show databases;

      настройка репликации master-slave между двумя серверами mariadb

      Создадим БД на Slave и проверим, передались ли данные на наш Master.

      проверка репликации master-slave

      Как видите, базу мы создали, и она есть на Slave. Проверяем, появилась ли она на Master. Ее нет. Репликация со slave на master не идет.

      show databases

      То есть репликация MariaDB работает только в одну сторону. Сделаем еще одну проверку, удалив БД master_hello с Slave-сервера:

      drop database и проверка репликации

      И проверим, не удалилась ли она на Master-сервере:

      test replication mariadb

      Как мы видим, все в порядке и база на месте.

      P.S. При настройке реплики, вы можете столкнуться с некоторыми подводными камнями, самый частый из них — это firewall. По умолчанию на Centos 7 установлен брандмауэр firewalld, в котором закрыт порт 3306, который и использует MariaDB. Вы можете либо открыть данный порт через iptables, либо отключить ваш сетевой экран (плохой вариант).

      По-умолчанию в конфигурации my.cnf в параметре bind-address указан IP адрес, на котором ожидаются подключения к базе ( bind-address = 127.0.0.1 ). Чтобы разрешить и локальные и внешние подключения, нужно раскомментировать эту строку и добавить правило iptables, разрешающее подключения с IP адреса мастер/слейв сервера порne 3306.

      iptables -I INPUT -p tcp -s ip_address_slave_server —dport 3306 -j ACCEPT
      iptables -I INPUT -p tcp —dport 3306 -j DROP

      При первичной настройке я столкнулся с такой проблемой и она легко выявляется. Если запустить проверку статуса Slave «SHOW SLAVE STATUSG;», вы увидите ошибку:

      Last_IO_error: error connecting to master:3306 - retry time: 60 can

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

      server-id = 1 — указываем ID сервера, обычно начинаем с 1, но можно использовать любую цифру, главное чтобы она не совпадала с другими серверами, которые будут задействованы в репликации.

      report_host = master — обычно прописывается хостнейм сервера, можно указать IP-адрес

      log_bin = /var/lib/mysql/mariadb-bin — путь до журнала обновлений

      log_bin_index = /var/lib/mysql/mariadb-bin.index — позволяет узнать, какой журнал на данный момент активен и какие журналы ранее были использованы.

      relay_log_index = /var/lib/mysql/relay-bin.index — сами логи репликации

      Какие параметры еще можно использовать? Если вам нужно настроить реплику только для конкретной базы или нескольких, добавляем функцию:

      replicate-do-db = имябд — если нужно несколько БД, перечисляем через запятую.

      Исключение каких-либо БД из репликации:

      Обычно исключаются служебные базы, такие как:

      information_schema ,mysql и performance_schema

      Время хранения bin_log:

      expire_logs_days = 10 — где 10 это количество дней которые будут храниться логи.

      Так же, если данные с Master-сервера, записываются в БД не такого же названия, это тоже можно настроить в конфигурационном файле:

      На этом все наши настройки закончены. Думаю, с помощью данной статьи вы без проблем сможете настроить репликацию БД MariaDB как в режиме Master + Master, так и Master + Slave.

      Предыдущая статьяПредыдущая статья Следующая статья Следующая статья

      голоса
      Рейтинг статьи
      Читать еще:  Регулировка тока 10а в зарядном устройстве
Ссылка на основную публикацию
ВсеИнструменты
Adblock
detector