Здравствуйте. Работают два инстанса. mysql  Ver 15.1 Distrib 10.2.26-MariaDB, for debian-linux-gnu (x86_64) using readline 5.2 Debian 9.11. Один из них (ram_db порт 3307) реплиципровался на прежнем сервере (10.0.32-MariaDB, Debian 8). На новом железе и софте реплика не запускается. (сервер реплики тоже новый и с тем же софтом, старого уже нет совсем).

Сейчас состояние Seconds_Behind_Master: NULL, т. е. репликция не началась. При этом: Slave_SQL_Running_State: Slave has read all relay log; waiting for the slave I/O thread to update it

Slave_IO_State: NULL

Slave_IO_Running: Preparing Slave_SQL_Running: Yes

На slave сервере в master.err пишет:
…

2019-12-25 10:10:05 140098672510144 [Note] Plugin 'FEEDBACK' is disabled.
2019-12-25 10:10:06 140098672510144 [Note] Server socket created on IP: '0.0.0.0'.
2019-12-25 10:10:06 140098672510144 [Note] Reading of all Master_info entries succeeded
2019-12-25 10:10:06 140098672510144 [Note] Added new Master_info " to hash table
2019-12-25 10:10:06 140098672510144 [Note] /usr/sbin/mysqld: ready for connections.
Version: '10.2.26-MariaDB-10.2.26+maria~stretch-log'  socket: '/var/run/mysqld/mysqld1.sock'  port: 3307  mariadb.org binary distribution
2019-12-25 10:10:06 140091111847680 [Note] Slave SQL thread initialized, starting replication in log 'ram_db_binlog.000692' at position 346, relay log './master-relay-bin.000001' position: 4
2019-12-25 10:10:07 140091112154880 [Note] Slave I/O thread: connected to master 'vasy@192.168.102.74:3307',replication started in log 'ram_db_binlog.000692' at position 346
2019-12-25 10:10:53 140091129861888 [Note] InnoDB: Buffer pool(s) load completed at 191225 10:10:53

Позиция правильная ('ram_db_binlog.000692' at position 346). Не понятно только при чем тут relay log './master-relay-bin.000001' position: 4.
При попытке сделать stop slave консоль зависает. При попытке остановить инстанс не стопится. До того как на машине выполняешь start slave, т. е. пока она master, все стопится и стартует номально.
Если не было конекта к master серверу ( например не было создано пользователя или просто не было связи по сети) все также стопилось и стартовало номально.

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

Здраствуйте. Работали два инстанса ([mysqld1] и [mysqld2]) на Debian 8 и
mysql Ver 15.1 Distrib 10.0.32-MariaDB, for debian-linux-gnu (x86_64) using readline 5.2.
Стартовал и смотрел состояние через mysqld_multi (start, stop, report).

После переноса базы на другой сервер с Debian 9.9 и mysql Ver 15.1 Distrib 10.2.26-MariaDB, for debian-linux-gnu (x86_64) using readline 5.2
все запустилось номально.
Насколько помню, была только ошибка на параметр «innodb_additional_mem_pool_size». Его похоже убрали и я тоже убрал.
И было предупреждение
Wide character in print at /usr/bin/mysqld_multi line 618. Т.е. на строку
print LOGFILE strftime «%a %b %e %H:%M:%S %Y», localtime if ($date_flag);
Но лог писался и чтобы не расстраиваться, строка была закоментарена.

После обновления c 10.2.26 всего лишь до
mysql Ver 15.1 Distrib 10.2.27-MariaDB, for debian-linux-gnu (x86_64) using readline 5.2
mysql стартует, т.е. на 3306 я захожу.
А инстансы на 3307 и 3308 не стартуют.
mysqld_multi сначала ругалось, что в строке 352 elseif должно быть elsif (до этого я в этом файле ничего не писал сам). Исправил. Ругаться перестало, но не стартуют ни первый, ни второй. Т.е. ни mysqld_multi start, ни start 1, ни start 2. Не получается. В логах ошибки
[ERROR] /usr/sbin/mysqld: unknown variable 'defaults-group-suffix=mysqld1'

Кстати, этот параметр в троке 352 присутствует
elsif ("--defaults-group-suffix=" eq substr($options[$j], 0, 24))

Пробовал откатить (виртуалка). Все работает пока не обновишь. При этом не важно только upgrade, upgrade и dist-upgrade или обновляешь только «apt-get install mariadb-server» после обновления до 10.2.27 стабильно не запускаются.

Тема не особо мне знакома. Потому google не помог. Поделитесь мыслями, что мне делать.

Здравствуйте. Xeon(R) X3430 @ 2.40GHz перестал справляться со своей задачей. Переполнились очереди обработки трафика (сетевые Intel Corporation 82574L). Нужно больше ядер.

Хочу перенести машину на Ryzen 7 1700X или Ryzen 7 1700. Поделитесь своими мыслями по этому поводу, а точнее получится ли у меня увеличить производительность.

И порекомендуйте пожалуйста материнскую плату подешевле (или хотябы чипсет) под этот процессор. Особых требований нет. Видео нужно встроенное, лишь бы консоль была. Ну а пара PCI-e слотов под сетевые, наверное, на любой плате найдется. Под память (ECC) слотов лучше 4, чтобы если что добавить. Пока с запасом хватит 8Гб.

Ну и главное, чтобы все это завелось под Debian GNU/Linux 8.1 (jessie) 3.16.0-4-amd64.

Здравствуйте. Решил перенести Debian 7 без графики на новое железо. (3.13-0.bpo.1-amd64 #1 SMP Debian 3.13.10-1~bpo70+1 (2014-04-23) x86_64 GNU/Linux)

А точнее на компьютер на материнке ASUS J3455M-E с интегрированным четырехядерным Celeron J3455 (памяти 8Гб, но это не существенно, так как она свободна). Передэдэшил на почти новый черный WD. Стартуем нормально. Ядра почти не нагружены. Скорость копирования файлов более чем хорошая. При этом машина дико залипает. Не то чтобы на каждом символе. Выглядит так: запустил mc - залипло на пару секунд, зашел в каталог - залипло, печатал-печатал в консоли - снова.

Я понимаю, что первая мысль, которая напрашивается, это медленное железо. Но на этом же железе я ставил 9-й debian. Нагружал пару ядер процентов на 70, гнал через него трафик туда/обратно больше 600Мегабит (не с родной сетевой). При этом стояла графика с KDE. И я сидел в графике в Интернете, открывал кучу консолек, работал в них и ничего не замечал.

А здесь остановил все что можно, вытащил сетевые, отключил сеть и ни чем не нагруженная система так залипает.

Есть ли какие-нибудь соображения, господа?

Здравствуйте. Появилось у меня 3 задачи. И куча вопросов...

Сначала задачи. Первая задача. Объединить несколько приходящих ко мне vlan-ов в единую сеть с единым адресным пространством. Т.е., образно выражаясь, «воткнуть» их в один коммутатор.

В общем есть интерфейсы eth1.3000, eth1.3001, eth1.3002 и т. д. Где eth1.3001, eth1.3002… - это приходящие vlan. А eth1.3000 это, так сказать, центральная сеть, где находится DHCP-сервер и маршрутизатор.

Решилось все просто, а именно созданием бриджа br0. В него были добавлены все перечисленные выше интерфейсы. Ip-адреса у него нет, ибо не нужен.

Вторая задача чуть сложнее. Сделать так, чтобы пользователи в vlan-ах, т.е за интерфейсами eth1.3001 … 1.300n, не видели друг друга, а видели только «центральный» vlan eth1.3000. Другими словами изолировать порты нашего виртуального ком-ра друг от друга и сделать так, чтобы они видели только условный uplink. На ком-рах D-Link это реализуется через traffic_segmentation, у Cisco - switchport protected, а у SNR- port isolation. Сначала я нашел в просторах Интернета такое:
ebtables -A FORWARD --logical-in br0 --logical-out br0 -j DROP.
Ходить-то между интерфейсами перестало, но я потом долго думал как разрешить хождение пакетов на eth1.3000.

В итоге сделал иначе. Сначала просто ebtables -P FORWARD DROP

А затем:
ebtables -A FORWARD --logical-out br0 -i eth1.3000 -j ACCEPT
ebtables -A FORWARD --logical-out br0 -o eth1.3000 -j ACCEPT

Работать то работает, но правильно ли я сделал? И не будет ли у меня трафик внутри железа лишние «круги нарезать»? Подскажите, пожалуйста, новичку.

Задача третья. Сделать на одной железке несколько таких бриджей, у каждого из которых свой «uplink» и свои «порты». Адресное пространство у каждого, соответственно, своё. Пересекаться пользователи с этих бриджей будут, только через маршрутизацию на другом железе… а может и на этом.

И вот вопрос: а сработает ли такая настройка ebtables с несколькими бриджами, т. е. если просто для каждого бриджа добавлять правила
ebtables -A FORWARD --logical-out brX -i ethX -j ACCEPT
ebtables -A FORWARD --logical-out brX -o ethX -j ACCEPT

И будет ли подобное работать, если в качестве «uplink» к бриджу добавить bond интерфейс? Например, brctl addif br0 bond0
А на ebtables:
ebtables -A FORWARD --logical-out br0 -i bond0 -j ACCEPT
ebtables -A FORWARD --logical-out br0 -o bond0 -j ACCEPT
Или есть какие-то тонкости в ebtables, например?

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

1) Насколько безопасна такая схема в плане обеспечения стабильной работы сети. (Т.е. защиты ее от колец, штормов, хакеров, вирусов и т. п.) На конечных коммутаторах, куда подключены пользователи, включена защита от колец на порту и настроен storm control. Порты пользователей на ком-рах изолированы друг от друга. Размер одной сети (в одном бридже) до /19, хотя была мысль, все же уменьшить размер сети до /22 или /23.

Нужны ли текущей схеме какие-либо настройки ещё и на iptables, если ни у бриджей, ни у входящих в них интерфейсов нет ip-адресов. По логике я понимаю, что нет... Но мало ли, я совсем не имею опыта работы с ebtables.

2)Какая предположительно будет нагрузка на железо (процессор, память) при пропуске трафика 6-7 Гбит/с. Пользователей во всех бриджах будет 7-8 тысяч.

И при 15-20 Гбит/с (пользователей 20 тысяч)? Как Вы думаете, можно ли будет для этого использовать Intel Celeron J3455 4x1.5 ГГц?

И как вырастет нагрузка, если все же добавить ip адреса и настроить маршрутизацию между сетями прямо на этой машине? Т.е. если прогонять трафик не просто на канальном уровне, а еще что-то маршрутизировать. Трафик между сетями ожидается небольшой. Как минимум на порядок ниже, чем на uplink.