Akina

Проблема миграции базы данных с mysql 8 на mariaDB 10?

Проблемы ОБЯЗАНЫ БЫТЬ. MySQL и MariaDB расфоркнулись достаточно давно, изменения и дополнения в синтаксисе они не синхронизируют, так что неудивительно, что чем дальше, тем меньше они совместимы. И соответственно всё меньше шансов. что дамп одной СУБД беспроблемно натянется на другую.

Такой перенос надо делать руками.

1. Выгружаем дамп структуры (без данных) из MySQL.
   
2. Экспортируем данные из MySQL-таблиц в CSV.
   
3. Правим дамп структуры руками, приводим к требованиям синтаксиса MariaDB.
   
4. Загружаем структуру в MariaDB, убеждаемся, что работает. Дропаем.
   
5. Делим дамп на 2 части - в одной только таблицы (и другие критично необходимые для создания таблиц объекты), в другой всё остальное (индексы, представления, триггеры-функции и прочая тряхомудия).
   
6. Грузим первую часть дампа структуры.
   
7. Импортируем данные из CSV в таблицы MariaDB.
   
8. Грузим вторую часть дампа структуры.
   

Будет что-то вроде

SELECT *,
       ( SELECT value
         FROM tablename t2
         WHERE t1.year - 1 = t2.year
         ORDER BY created_at DESC LIMIT 1 
         ) AS prev_value
FROM tablename t1;

Запустите ярлык на CLI из окна CMD и смотрите сообщения. Больше всего похоже на сбой аутентификации.

Навскидку как-то так:

1. На коммутаторе для VLAN интерфейса к pfSense прописываете статический (и не входящий в диапазон выделения на pfSense) адрес из 192.168.1.0.
   
2. На коммутаторе указываете адрес pfSense дефолтным шлюзом. Проверяете наличие связи коммутатора и pfSense в обе стороны, а также коммутатора к внешним адресам в Инете.
   
3. Для VLAN клиентских портов прописываете статический адрес из 192.168.2.0 и включаете на нём DHCP-сервер. Проверяете факт раздачи адресов и коннект коммутатора и клиента в обе стороны.
   
4. Включаете на коммутаторе маршрутизацию между подсетями.
   
5. Прописываете раздачу DHCP-сервером коммутатора своего адреса как адреса шлюза по умолчанию.
   
6. На pfSense в настройках его DHCP настраиваете раздачу адреса коммутатора из 192.168.1.0 как шлюза в подсеть 192.168.2.0/24. Проверяете. что всё работает.
   

Ну и это вроде бы всё...

Да, часть этих пунктов может, скорее всего, выполниться автоматически по факту настройки этого или предыдущих пунктов. Пункт 5 - почти наверняка.

Как обычно - берём двухинтерфейсный маршрутизатор, один к порту в одном VLAN, другой к другому, адреса из соотв. подсетей, маршрутизация, и его на узлах как шлюз в другую подсеть.
Если коммутатор уровня L2+ (а раз на нём есть DHCP-сервер, то это так), то он сам может работать маршрутизатором - прописываешь соотв. адреса внутреннего интерфейса в соотв. VLAN (один уже не надо, на нём DHCP-сервер), и указываешь их шлюзом.
Да, подсети в разных VLAN не должны пересекаться, ессно.

не до конца наверное понимаю работу vlan

VLAN в первом приближении - это не просто, а очень просто.

Первый шаг - это разделение по отдельным VLAN. Мысленно представляешь, что у тебя не один коммутатор, а несколько. Вот прям вместо коммутатора стоИт стопка один на другом. В первом - только VLANID=1, во втором VLANID=2, и так далее. Каждый коммутатор обслуживает строго один VLAN, а все остальные порты, на которых текущий VLAN отсутствует, тупо залиты цементом. Если коммутаторов несколько - то каждый в схеме размножается таким образом, а соединения между портами коммутаторов ещё и раскрашиваются, например, тегованный кабель синий, а нетегованный красный. Соответственно если у тебя есть транковая связь (гибридный или транковый порт) с каждой из сторон) - то в преобразованной схеме один кабель между такими коммутаторами размножается на несколько, каждый в схеме для своего VLAN. А если попадается случай, когда с одной стороны провода VLANID есть, а с другой стороны его нет - получается кабель, с одной стороны вставленный в порт, а с другой нет. И соответственно в схеме для именно этого VLAN связи между коммутаторами нет. Аналогично для случаев соединения "tag на untag" с одной стороны красный кабель, с другой синий, у обоих вторые концы "в воздухе", а связи нет.

Второй, дополнительный, шаг - это соединение меж собой нетегованных портов разных VLAN в преобразованной схеме, если такие соединения исходно существуют, невзирая на номера VLAN. Скажем, если на порте есть нетегованный VLANID=2 (возможно, с другими VLANID, но тегованными), и порт соединён кабелем с другим портом того же или другого коммутатора, на котором есть нетегованный VLANID=3, то в преобразованной схеме ты соединяешь соотв. порты коммутаторов разных слоёв, соответствующих этим VLAN.

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

После такого разделения ты можешь смело анализировать поведение одного VLAN, не обращая внимания на существование остальных.

Только и исключительно VBA-макросом.
Например, так:

Public Sub process_data(index_range As Range, values_range As Range)
Dim values()
Dim i As Integer
Dim coll As New Collection
Dim onecell As Range
values = values_range.Value
For i = LBound(values, 1) To UBound(values, 1)
    coll.Add Item:=values(i, 1), Key:=Left(values(i, 1), 1)
Next
For Each onecell In index_range
    onecell.Offset(0, 1).Value = coll(onecell.Value)
Next
End Sub

Sub test()
Call process_data(ThisWorkbook.Sheets(1).Range("A1:A26"), ThisWorkbook.Sheets(1).Range("B1:B3"))
End Sub

=ВЫБОР(2 * ЕПУСТО(A1) +  (A1 <> 0) + 1;"false";"publish";"")

Вот не вижу проблем.

1. Есть количество товаров, приобретённых юзером. То есть, грубо говоря, известно, что пропустить и откуда считать.
   
2. Если надо набрать указанную сумму, то по имеющимся товарам нужна сумма с накоплением. А чтобы не учитывать уже купленное - домножать на признак "ещё не куплено", являющийся результатом сравнения текущего номера товара и количества приобретённых товаров.
   
3. Отдельно вспомним, что стоимость - штука сугубо положительная. А после домножения на признак - неотрицательная. И, значит, сумма с накоплением строго неубывающая на начальных нулях, а дальше так и вообще строго возрастающая. Иными словами - сортированная.
   
4. Осталось вовремя остановиться. Но именно так работает ВПР()/ГПР() на сортированном списке при поиске ближайшего/неточного значения.
   

Как мне объяснить микротику, что на одном из портов стоит коммутатор?

Ему вообще-то похрен.
А циска пусть работает как тупой свитч. То есть абсолютно всё, кроме коммутирования - нахрен.

я докупил Cisco Catalyst WS-C2960-24TC-L

Можно было обойтись любым неуправляемым коммутатором на нужное число портов.

программа которая видит через какие маршрутизаторы и роутеры и т.д проходит отправляемый запрос

В общем случае получение полного маршрута - вообще без шансов.

Дело в том, что любой маршрутизатор в принципе-то может делать с маршрутизируемым пакетом что угодно. В том числе он запросто может и спрятаться - он просто увеличит TTL на единичку (точнее, не станет его уменьшать) и отправит дальше. Такой маршрутизатор мы в трассе просто не увидим, равно как и не увидим в этой трассе никаких иных ненормальностей.

на работе в серверной куча лапши из проводов и свичей

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

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

Функция, встроенная или определённая пользователем, при использовании в формуле ячейки НЕ МОЖЕТ ИЗМЕНЯТЬ ЗНАЧЕНИЯ ЯЧЕЕК. В принципе не может. А любая такая попытка в определённой пользователем функции немедленно приводит к ошибке и аварийному завершению работы функции.

Схематично:

WITH cte AS (
    SELECT *, ROW_NUMBER() OVER (ORDER BY id) rn
    FROM tablename
    WHERE type = @type
    )
SELECT /* DISTINCT */ t2.*
FROM cte t1
JOIN cte t2 ON t2.rn IN (t1.rn - 1, t1.rn, t1.rn + 1)
WHERE t1.status = @status
ORDER BY t2.rn