Pull to refresh
22
0
Сергей @angelsaint

User

Send message

А если говорить про обычные случаи, ненагруженые, когда на один апстрим DNS выдаёт один адрес или же бэк задан ip-адресом? Как вот в данном случае задано 4 бэка. Сколько информации хранится для одного адреса?

Статистика радует, что и говорить.

Да, с этой графаной всё взлетело. Такой вопрос. Есть upstream. Определяется так:

upstream minio-cluster {
    zone upstream-minio 256k;
    ip_hash;
    server server1;
    server server2;
    server server3;
    server server4;
}

Из документации не ясно как выбирать размер, для каких случаев какие значения? Чего там и сколько будет хранится в этой разделяемой памяти. Чем в большем количество upstream-ов будет определена указанная зона, тем больше и там данных? А сколько данных для одного сервера апстрима хранится?

какая графана минимум нужна для этого дашборда?

Отлично! Потестируем.

Как успехи? Добавьте сюда ссылку, когда будет готово.

А есть уже готовый дашборд для графаны с полным списком метрик? Хорошо бы опубликовать его на https://grafana.com/grafana/dashboards/

Любая задача может быть решена разными средствами. Выбор средств, как правило, обуславливается конкретными условиями, либо желанием пощупать ту или иную технологию. Задача клонирования может быть решена и без ZFS. С помощью, например, LVM. Или ещё какими-то средствами. Скажем, встроенными возможностями какой-то навороченной хранилки с добавлением самописных скриптов. В данном случае была необходимость проведения тестов именно на продуктивных данных, т.к. имелось большое количество взаимосвязей в данных, которые непросто повторить генерацией, а также сложной ролевой моделью доступов. DLE, в нашем случае, подходил идеально. DLE GUI был разработан из-за того, что в тот момент встроенный UI не поставлялся свободно, а когда стал поставляться, не имел возможностей разграничения доступа. Так к DLE GUI был прикручен Keycloak, как задел на будущее, т.к. он позволяет интегрироваться с большим количеством систем управления учётными записями пользователей

Весьма интересно было бы узнать подробности.

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

Можно добавить про всякие кэширующие прокси типа nexus, чтобы необходимые для ci пакеты хранились "у себя". Если зафиксировать версии пакетов, то вполне себе рабочее решение получается.

Ога. Все мало-мальски квалифицированные спецы стараются оттуда свалить по возможности. Тут как бы ИТ ж... не было

Вот какой опыт надо перенимать себе. Скиньте ссылки в думу.

В настройках можно выставить количество и объём хранимых журналов. И постгрес сам всё будет подчищать. В этом случае проблема с объёмом журналов может возникнуть только в том случае, если вы настроите реплику со слотом репликации и эта реплика перестанет работать (читай: тянуть к себе wal-ы)

Было бы хорошо добавить в статью немаловажный момент - как очищать реестр. При активных ci/cd процессах реест начинает очень быстро пухнуть, диски забиваются, на размер резервных копий без слёз не взглянешь. В гитлаб есть встроенная очистка, но её нужно не забыть активировать и её возможностей не всегда хватает и приходится браться за api.

Нашёл запрос на словари в кликхаусе — https://youtrack.jetbrains.com/issue/DBE-9813. Давно висит. Сколько нужно "голосов", чтобы задачу сделали?

Поддержку ClickHouse планируется расширять? Например, работа со словарями не поддерживается. Сами запросы выполняются, а проверка синтаксиса выдаёт ошибку


create table test1.table1
(
    id String,
    FirstName String,
    LastName String,
    AgeMin Int8,
    AgeMax Int8
)
engine = MergeTree ORDER BY id
SETTINGS index_granularity = 8192;

CREATE VIEW test1.view1
            (
             `id_hash` UInt64,
             `id` String,
             `FirstName` String,
             `LastName` String,
             `AgeMin` Int8,
             `AgeMax` Int8
                )
AS
SELECT halfMD5(id) AS id_hash,
       *
FROM test1.table1;

drop dictionary if exists test1.view1;
CREATE DICTIONARY test1.view1(
    id_hash UInt64,
    id String,
    FirstName String,
    LastName String,
    AgeMin Int8,
    AgeMax Int8
)
PRIMARY KEY id_hash
RANGE(MIN AgeMin MAX AgeMax)
SOURCE(CLICKHOUSE(host localhost port 9000 user default db test1 table view1))
LAYOUT(RANGE_HASHED())
LIFETIME(MIN 86400 MAX 150000);

Подсказка на drop: "DATABASE, TABLE or TEMPORARY expected, got 'dictionary'"
Подсказка на create: "DATABASE, LIVE, MATERIALIZED, TABLE, TEMPORARY or VIEW expected, got 'DICTIONARY'"


В статье https://habr.com/ru/company/JetBrains/blog/461725/ описана приятная возможность "Select current statement.". На MySQL, например, всё хорошо отработало, а на этом запросе произошёл "полукраш" какой-то. Сама среда не упала, но окно "Find Actions" "вылетело". Открылось окно терминала с текстом "No manual entry for select \;type\=a".


macOS 10.15.6
PyCharm 2020.2


Или описанные функции в DataGrip и PyCharm работают по-разному?

По умолчанию на маках тап отключен. Нужно зайти в настройки и включить его.
Есть ещё программа KMyMoney. Использую её уже лет 8-9, сначала под linux, теперь под macos. Есть вроде версия и под windows. Она только для десктопа, нет мобильного клиента, никаких синхронизаций, но мне, например, этого и не нужно. Вечером дома внёс данные и готово. За компов всяко удобнее вносить чем на мобильном. Хотя это спорный вопрос. Странно что мало кто о ней упоминает, т.к. программа вполне себе ничего.
В последний пару месяцев активно пользовались яндекс такси и несколько раз возникала такая ситуация: делаешь заказ, машина вроде подъехала, появляется кнопка «уже выхожу», но такси не видно. Звонишь водителю, спрашиваешь где он, а водитель толком объяснить не может. То ли не местный, то ли ещё что. И начинается эпопея «подойдите туда-то, я там-то», а человек вышел в лёгкой одежде зимой в расчёте на то, что такси будет около подъезда и он сразу туда сядет. Приходится отменять заказ и делать другой. Но т.к. к приложению привязана пластиковая карта, то при отмене заказа списывается минимальная стоимость поездки (у нас это около 63р. Раньше было списание одной суммой в конце поездки, а сейчас несколькими суммами. Одно списание как только водитель нажал кнопку, что поездка началась, второе в конце поездки. Но бывало что и 3 списания с карты за одну поездку бывало). И получается что поездки не было, а деньги списались, хотя виноват водитель. Если водитель сам отказывается от заказа, то списания не происходит. К тому же неудобно подбивать в конце месяца баланс по поездкам, сколько поездок по количеству списаний уже не определишь.
В ММ раздражает то, что нет списка файлов, которые заливали на канал. Приходится потом листать историю сообщений пока не найдёшь нужный. Поиск — это тот ещё п… ц. Например: помнишь, что присылали ссылку на пару статей на хабре. Думаешь найти их *habr*? Забудь! В 4-й версии что-то вроде стало улучшаться (хотя не всегда находится), а раньше не найти было. А бывало что что-то выдавалось, а что-то нет, хотя ключевое влово и там и там есть. Какими критериями ММ руководствуется при поиске понять не удалось. И да, у нас ММ с базой PosgreSQL работает.

Information

Rating
Does not participate
Location
Нижний Новгород, Нижегородская обл., Россия
Date of birth
Registered
Activity