ТС обратил внимание, что нужно использовать свой мозг, а не тупо следовать "рекомендациям" даже от "топов" интернета. В данном случае, косяк в голове у разработчиков фейсбука и как следствие в "рекомендациях" от них.
Стандарты одни для всех и их нужно соблюдать.
а в mysql, что не так?
только я бы очень не советовал делать вызовы внешних программ из триггера, да и навешивать кучу второстепенного хлама внутрь триггера тоже не стоит.
для винды есть альтернатива:
tracetcp.exe hostname:port
офф. сайт, нужна либа WinPcap:
TraceTCP requires the WinPcap library which can be download below
WinPcap - http://www.winpcap.org/install/default.htm
TraceTCP - https://github.com/SimulatedSimian/tracetcp/releases
Поспешайте медленно, но надежно. :) Возможно в случае только 1С такой подход будет работать, но все-равно лучше подстилать соломку в виде полного бекапа.
Иногда лучше "потерять" данные за несколько часов, чем получить не стабильную систему(зоопарк разного софта, у нас еще был закрытый софт который не полностью поддерживал транзакции, потом похоронили его) с глюками которые будут вылазить еще несколько месяцев, т.е.
1. Принимается решение, что ситуация начинает выходить из-под контроля, оценивается время на ее гарантированное исправление.
2. Рабочие битые данные - в полный бекап, затем их в тестовую базу. Или переименовать БД.
3. На рабочей базе поднимается ночной бекап.
4. Продолжается текущая работа. По итогу это теже 15-20 минут.
5. В фоне штатными средствами экспорта/импорта или при помощи SQL возвращались "потерянные" данные. Мелочевка перебивалась руками, т.к. это оказывалось быстрее и проще.
ps: сколько букафф понаписывал, аж ностальгия взяла.
Вы говорите про технический подход(здесь и ниже про "не важно почему упало"), но к сожалению чисто технический подход тут не работает и нужен административно-технический подход. Не от хорошей жизни пришли к этому, были преценденты с подлым человеческим фактором, когда под сбои пользователи пытались списать свои ошибки. Ловили таких за руку, но приходилось делать дополнительные шаги.
Вот зависла у вас 1с на обновлении, откатили вы назад по логу. Упало "не важно почему", вы быстро восстановили по логу.
А вот теперь попробуйте доказать, что вы не слон и десяток кривых проводок(юзер/разработчик решил на вас списать свой косяк) это не результат обновления или зависания, т.е. ваш косяк. Самое неприятное, что баги могут начать появляться спустя несколько месяцев по нарастающей. Мне приходилось поднимать для разборов полетов и бекапы годовой давности.
Административно-технический подход:
1. Пишется заявка, на обновление, доработку, разработку нового функционала. Согласовывается ТЗ.
2. Владелец данных принимает решение нужно это или нет.
3. Ведеться разработка на тестовой базе на реальных данных. Или на тестовую базу разработчик ставит обновление, проверяет не повисло ли при установке, не вылезли ли кривые проводки. Если обновление серьезное, то привлекаются для тестирования и пользователи с полным прогоном всего цикла проводок. (по 1-2 проводки каждого типа)
4. Разработчик/пользователи говорят, что все ок - тут наступает их ответсвенность. Владелец данных дает добро на продакт, согласовывается время установки и процедура.
5. Тут наступает ответственность админа
5.1 Всех пользователей из базы, закрываем доступ. (в моем случае были тонкие клиенты и апликейшен сервер, который коннектился к базе. я просто останавливал службу апликейшен сервера)
5.2 Делается полный бекап (у нас было несколько связных баз)
5.3 Ставится обновление, если повисло или есть малейшее подозрение на кривизну, то восстановление из полных бекапов и снова пункт 5.3
5.4 Если все ок, то снова полный бекап.
5.5 Пускаются в базу разработчики для быстрой проверки
5.6 Пускаются все остальные, отчитываемся что все ок.
6. Владелец данных подтверждает, что все ок
Сохраняем полные бекапы до/после установки в отдельную папку, туда же сохраняем и сами обновления, которые устанавливали. Это и есть наш спасательный круг и маркер для возможных разборов полетов. Можно будет в любой момент на тестовой базе поднять состояние базы до обновления, по новой накатить обновление, сравнить результат. Таким образом отсекаются попытки списать косяки друг на друга.
Рейд значительно повышает живучесть ос/сервера бд/и самой бд. Но ничего не вечно, видел у соседей и сдохший навороченный СХД и рассыпавшиеся рейды тоже. Поэтому бекапы рулят и не только БД, но и полностью всего сервера. Кстати, для одного тестирования поднимал копию всего сервера на обычном тазике, удивительно, но завелось все сразу и без танцев с бубном. :)
Это было давно... сейчас бы я все в виртуалки засунул бы и не парился бы с "особенностями и прибабахами" серверных железок.
Начинаю вспоминать... :) на рабочих базах таки была полная модель, т.к. они реплицировались в другую локацию. При подъеме на тестовых базах я менял модель на простую. Мелко-хлам и редко меняющиеся базы были на простой модели.
После нескольких разборов полетов, это становится еще важнее, свои нервы нужно беречь, попутно берегутся и нервы окружающих. :)
сейчас сокращу и заДОС-ю. :)
кстати, этот лимит считает байты, а не символы.
strlen() vs mb_strlen()
начал сокращать свой пост, решил посчитать:
$ wc -c 1_se.txt 10039 1_se.txt$ wc -m 1_se.txt 5652 1_se.txt
кодировка utf-8, похоже форум даже перевод строки считает за два символа.---------- Добавлено 17.08.2017 в 15:47 ----------
люди просто разбивают текст на несколько постов и не парятся, точно также сделал и я.
гм...
а точно нужен этот лимит? или это защита от ДОСа текстом :)
У нас это решалось разделением прав доступа и бюрократией(в электронном виде), контора была достаточно большой и основная система была не 1С. (на 1С крутилась совсем мелочевка и человек десять на ней).
Кратко о разделении прав и ответственности:
* "Владелец данных" - все действия только с его подписи(поставить птичку на заявке в системе внутреннего документооборота), для бух. данных - это главный бухгалтер.
* "Админ данных" - это единственный человек, который может вносить внештатные изменения в рабочий набор данных. (только после подписи "владельца данных"). к внештатным изменениям относятся всевозможные обновления, изменения конфигураций, выполнение SQL запросов на изменение данных и т.д.
Важно: "Админ данных" не может быть "Разработчиком" - это должны быть разные люди.
* "Разработчики" - работают в своей копии БД, которая периодически поднимается на сервере с рабочей БД. У нас на каждую рабочую БД было две тестовые базы для разработки. (одна для мелких доработок, другая для долгосрочных разработок). Все обновления ставятся сначала на тестовую БД и проверяются, если обновления существенные, то к тестовой базе подключаются и обычные пользователи и каждый департамент прогоняет полный цикл своих проводок или действий, после этого они отчитываются "Владельцу данных", что их кусок работает нормально(в отдельных случаях брались и бумажные подписи). После этого "Владелец данных" дает отмашку "Админу данных" на выставление обновления.
Важно: "Разработчики" имеют права только на чтение в рабочей БД, они не имеет права выполнять SQL запросы на обновление данных в рабочей БД. Если нужно изменить данные, то разраб. тестирует эти изменения в тестовой базе, потом отправляет заявку с вложенным SQL запросом(пачкой запросов), владелец подписывает, админ применяет на рабочей БД.
Важно: все манипуляции с данными проводить только штатными средствами, никаких SQL запросов или правок в гриде. Исключения - только за подписью владельца БД.
Понимаю, это все звучит очень дико и как с другой планеты, но со временем привыкаешь и даже становится удобно, т.к. четко прописаны права и обязанности и четко разграничена ответственность. Также привыканию помогали ежегодные внешние аудиты и выгребание люлей после них. 😂
БД - только на аппаратных рейдах. Я еще застал несколько серверов-старичков на которых диски периодически выпадали из рейда или дохли, покупали новые(или выдергивали из соседнего сервера), меняли, фоновый ребилд и так до следующего раза. Потерь данных при таких операциях не было ни разу.
да, было дело, перегоняли данные репликацией в другую локацию, чтобы ускорить там выполнение суммарных отчетов и когда-то даже переключались на тот сервер. про модель на тех базах уже не помню.
вы сможете за 15 минут обнаружить косяк, убедиться, что это действительно косяк и никак кроме отката назад его не исправить и откатится назад? тогда снимаю шляпу :)
тут другой вопрос, почему кто то способный накосячить имеет доступ к конфигуратору? лучше лечить причину, а не следствия при помощи откатов на 15 минут. (я бы не стал сильно надеятся на такие откаты, можно одно вылечить, а другое залечить)
если нужно внести потенциально опасные изменения("в конфигураторе" или еще как-то), то желательно клацнуть пару кнопок и сделать полный бекап, по времени у ТС это занимает 20 секунд и дальше крутите, что хотите. :)
ага, как раз их и имел ввиду. :)
чтобы хозяину домена не обидно было, можно добровольно/принудительно обязывать арендаторов субдоменов проставлять безанкорку на корень домена. нет ссылки - нет аренды.
прокачивается субдомен - вес частично перетекает основному домену.
