Akina

не могу пинговать с ПК на телевизор.

А вот с телевизора на компьютер пинг должен проходить при описанной схеме подключения.

И поневоле охота спросить - а зачем может понадобиться пинговать телевизор?

В настройках сети виртуальной машины стоит Сетевой мост. Доступ в интернет на хостовой машине прописан через статику.

Я думаю, вам надо внимательно почитать мануал по организации сетевой подсистемы VB. https://www.virtualbox.org/manual/topics/networkin...

Сетевой мост - это считай независимое подключение непосредственно к реальному сетевому адаптеру системы. То есть с точки зрения ОС в виртуалке она установлена на соседнем компьютере и подключена в тот же физический коммутатор, в какой подключена и реальная машина, а сетевые настройки базовой ОС не влияют на виртуальную ОС вообще никак.. Кто, спрашивается, должен дать ей адрес? у вас есть внешний по отношению к хостовой машине (или на самОй хостовой ОС) DHCP-сервер?

но в интернет не ходит, нет пинга до 8.8.8.8.

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

Может ли мобильный оператор блокировать интернет при подключении компьютера?

Технически - да, может.
С правовой точки зрения - изучай договор. Если запрет не прописан явно - блокирование неправомочно.

Destination Host Unreacheable, если перевести с буржуинского, означает "Хост назначения недостижим".
Если переводить дальше - на обывательский, то это означает "У меня нет маршрута (адреса шлюза), через который я должен послать пакет узлу назначения".

Следовательно, хост 192.168.0.108 не имеет необходимого для общения с указанным адресом 52.43.49.19 дефолтного либо частного маршрута.

А с узлами своей подсети он общается напрямую, без шлюза. То есть виртуальный коммутатор функционирует нормально.

PostgreSQL: Identifiers and Key Words
MySQL: Identifier Case Sensitivity
Прочитать и изучить ОЧЕНЬ внимательно - от этих ссылок и всё вокруг. Особое внимание - различиям между квотированными и неквотированными идентификаторами.

Данные импортируются с названием колонок заглавными буквами.

Ну, значит, так импортируешь. По-любому, это твой косяк.

Будет ли разница в результате между двумя вариантами

Да. См. fiddle

CREATE TABLE a SELECT 'a' x UNION SELECT 'b';
CREATE TABLE b SELECT 'a' x UNION SELECT 'c';
CREATE TABLE c SELECT 'b' x UNION SELECT 'c';

select a.*, b.*, c.*
from a left join b using (x) left join c using (x)

x	x	x
a	a	null
b	null	b

select a.*, b.*, c.*
from a left join (b left join c using (x))  using (x)

x	x	x
a	a	null
b	null	null

Есть ли какое-то правило, которое определяет порядок связывания таблиц?

Да. Порядок связывания определяется требуемой логикой.

PS. В качестве самостоятельного задания - найди истинную причину разницы.

PPS. При абсолютной эквивалентности обеих форм - разницы нет.

NOTIFY
LISTEN
Хотя как по мне, один запрос в 10 минут - это ни о чём.

Я бы

1. Убрал неуправляемый коммутатор и соединил серверы напрямую (необязательно, но зачем лишняя фигня в сети?)
   
2. Поставил на обоих серверах гигабитные интерфейсы в автополучение адреса
   
3. Отключил на 100-мегабитных картах NetBIOS over TCP/IP (хотя это уже зависит от того, какие ресурсы и через какие пространства имён нужны в сети)
   
4. Дождался бы самовыделения APIPA-адресов (169.254) на обоих серверах
   
5. Прописал перекрёстно полученные адреса и соответствующие им имена серверов в HOSTS и в LMHOSTS
   

Итоги:

1. Серверы доступны друг другу по имени
   
2. При обращении по имени связь будет устанавливаться через этот канал (через гигабитные карты), а не через 100-мегабитные карты
   
3. Гарантированно не будет пересечения по диапазону адресов с другими системами в сети
   

Я в упор не понимаю, зачем тут вообще маршрутизация.

Все интерфейсы 10G - NAS, компьютер и Mikrotik,- помещаем в одну подсеть.
Интерфейс 1G - компьютер и Mikrotik,- помещаем в другую подсеть.
Для исключения L3-петли в файрволе Микротика блокируем любой трафик от и на адрес 10G интерфейса компьютера.

На компе дефолтным шлюзом адрес 1G интерфейса Mikrotik.
На NAS дефолтным шлюзом адрес 10G интерфейса Mikrotik.

Микрот - с компьютером и NAS общается напрямую, ибо одна подсеть, а в Инет идёт через свой WAN.
NAS - с компьютером и Микротом общается напрямую, ибо одна подсеть, а в Инет идёт через Микрот.
Компьютер - с NAS и Микротом общается напрямую, ибо одна подсеть, а в Инет идёт через Микрот.

Т.е. никакие маршруты, кроме маршрутов по умолчанию, в системе вообще не требуются.

Хотя согласен с предыдущими ораторами - дополнительный 1G линк явно избыточен.

Keenetic / Руководство пользователя / Управление
Режим "Усилитель/Ретранслятор"

А уж может ли это конкретно ваша модель - смотрите на практике...

Обратите внимание. Режим ретранслятора и режим NAT-роутера - несовместимы.

Это верно или нет???

В общем случае нет. Точнее, зависит от настроек при установке/конфигурировании. ЕМНИП при использовании предопределённого профиля разработчика сервер настраивается только на использование socks/shared memory, соответственно сетевой интерфейс (даже локалхост) не слушается и внешние подключения невозможны.

Смотрите настройки. skip_networking, bind_address и т.п.

Server Option, System Variable, and Status Variabl...

столкнулся с ошибкой

ERROR 1064 (42000): You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'IDENTIFIED BY '123' WITH GRANT OPTION' at line 1

Позорище... вот что мешает читать не всякую срань в интернете, а официальную документацию, причём для именно той версии ПО, которая используется?

хотелось бы больше подробностей

Если коротко.

Из Инета можно обратиться только к "белому" адресу. На NAS - "серый" адрес. Значит, нужен посредник (NAT-роутер). На нём будет работать port forwarding.

Работает оно так. На роутере-посреднике два интерфейса - внешний белый и внутренний серый. Создаётся правило: "Если что-то пришло на внешний адрес на порт XXX, переслать это на внутренний адрес YYY на порт ZZZ". В соответствии с этим правилом клиент снаружи стучится на внешний белый адрес на порт XXX, роутер от своего имени шлёт этот пакет с внутреннего адреса на адрес YYY (NAS) порт ZZZ. То есть с точки зрения самого NAS к нему обращается не внешний клиент, а роутер. Он отвечает роутеру. Роутер по запомненным характеристикам соединения делает обратное преобразование и шлёт ответ NAS клиенту от своего имени.

Если внутренний сервис требует для работы более одного порта - для каждого будет создано своё правило преобразования.

Да, избавиться от снапшота в условиях нехватки места не получится. Необходимо любыми способами изыскать том минимум на 14Т свободного пространства на время выполнения операции слияния. Если нет такого накопителя - собрать несколько штук в страйп.

Если гипервизор не единственный, придётся на рабочем выполнить экспорт, потом перенести накопитель на другой, там импортировать по месту и затем сливать. Если же гипервизор единственный, или придётся собирать страйп, понадобится 18Т пространства (или два тома - 9 для экспорта и 14 для импорта и слияния), потому что нужно будет делать импорт с созданием нового идентификатора и, соответственно, с копированием.

К слову, все эти операции можно проводить и на примонтированной шаре. Только сетевушку желательно на 10Г, или это будет очень долго.

Конечно, не исключено, что слияние даст суммарно финальный том не 5+4=9, а меньше... но я бы на это не рассчитывал. А если в процессе кончится место, и слияние оборвётся по ошибке, то виртуалка, скорее всего, умрёт. Именно поэтому операцию следует выполнять на экспортированной и реимпортированной копии.

Есть и ещё вариант. Выполнить внутри виртуалки бэкап тома с данными на подключенный третий диск. А потом пересоздать рабочий диск и восстановить.

Либо подключить ещё один, пустой, образ, и внутри виртуалки собрать и синхронизировать софт-mirror, потом развалить, оставив только том-копию, убрать том-оригинал и мигрировать на его место копию. Тогда получится обойтись дополнительным томом на 9Г, но геморроя куда как больше. Зато плюс этого способа - он допускает выполнение всех операций без остановки виртуалки.

Пинг гарантированно увеличится. Но при полностью исправном, неперегруженном и правильно настроенном оборудовании зарегистрировать эту разницу не получится.

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

Соответственно два вопроса.

1. Объявлено ли указанное поле в структуре указанной таблицы уникальным? Если нет - то почему? Добавьте требование уникальности.

2. Что мешает выполнить обычный INSERT IGNORE или, если надо обновлять существующую запись введёнными значениями, то INSERT ODKU или REPLACE INTO?

PS. INSERT {table} .. WHERE EXISTS ( {table} ) - вообще-то недопустимый синтаксис.

мне необходимо удалить строку из одной таблицы и эту же строку добавить в другую таблицу.

В PostgreSQL это вообще элементарная операция. Можно удалить запись в CTE и вставить её во внешнем запросе, можно наоборот. То, как выполнять, определяется возможными зависимостями и интерференциями.

WITH cte AS (
    DELETE
    FROM table1
    WHERE {criteria}
    RETURNING *
)
INSERT 
INTO table2
SELECT *
FROM cte;

-- или 

WITH cte AS (
    INSERT 
    INTO table2
    SELECT *
    FROM table1
    WHERE {criteria}
    RETURNING id
)
DELETE
FROM table1
WHERE id IN (
    SELECT id
    FROM cte
);

Sample fiddle

Само собой, вместо звёзд может быть (даже правильнее сказать - должен быть) перечень определённых полей и выражений.

PS. Хотя намного разумнее оставить одну таблицу и выполнять "мягкое удаление". Внимательнейшим образом прочитайте ответ alexalexes. При очень большом количестве записей, влияющем на производительность, такую таблицу можно и секционировать.