Мы так же в классе можем добавить дополнительные проверки для значения и ограничить число возможных инвариант предоставляемых типом. Но есть одно но!
Если мы произвели некоторую проверку внутри класса и возвращаем тип с большим числом инвариант, то у нас возникает та же самая проблема, что и в Haskell: мы не сохранили информацию об этих проверках в системе типов, поэтому при последующем использовании значения и добавлении новых инвариант, система типов нам ничем не поможет и не сообщит о возможной ошибке.
Подумали, что этому легиону статей нужна свежая кровь!
А, если серьезно, мы планируем сделать продолжение, поэтому в этой статье дали самые основы, с чего начать разработку. В следующих частях расскажем о реализации тёмной темы, мультиязычности, настройке PWA и SEO (в том числе об автогенерации Sitemap и robots.txt) и другом. Надеемся, что этот контент как раз будет уникальным и полезным.
Что касается количества пакетов, то большинство из них, в том числе и nuxtjs/stylelint-module, устанавливаются автоматически при выполнении команды npx create-nuxt-app в той конфигурации, что мы использовали. К пакетам, которые ставили дополнительно, старались дать пояснения.
В этой статье действительно нет подробных объяснений, так как мы хотели поделиться опытом работы с клиентом в формате мини-инструкции.
Указанный тест мы выбрали за доступность и простоту: такой тест будет понятен клиенту, и он легко сможет его воспроизводить.
Будем благодарны, если вы сможете поделиться другими более удобными способами измерения производительности взаимодействия портала Bitrix24 и служб, которые он использует.
Выключить или включить Query_cache — непростой момент. Всё зависит от ситуации! Нам кажется, нельзя сказать на 100%, что это идеальное решение для каждого.
innodb_buffer_pool_instances указан для удобства чтения следующему человеку, который будет разбираться с этими настройками. Да, значение 1 является значением по умолчанию, но кому-то может быть удобнее это видеть, чем вспоминать.
Есть два вида серверов: клиентский и бэкапный. Файловая система, на которых находятся клиентские данные, — ZFS.
На клиентском сервере работают клиентские приложения. На бэкапном сервере хранятся бэкапы.
Снапшоты делаются на клиентском сервере и копируются на бэкапный сервер.
Схема бэкапа достаточно проста:
1. На клиентском сервере есть снапшот 1.
2. Перед копированием создается снапшот 2.
3. Снапшот 1 копируется / импортируется на бэкапный сервер. Для этого могут использоваться разные средства: ssh, scp, netcat и др. В нашем случае используется приложение, построенное на базе ssh.
4. По окончании успешного копирования снапшот 1 мержится / удаляется с основными данными, его место занимает снапшот 2.
5. При бэкапе переходим к пункту 1.
Восстановление отдельных файлов или директорий работает через копирование данных с сервера бэкапов из снапшота на клиентский сервер.
Восстановление целого сервера возможно из последнего снапшота, но по времени быстрее переставить диски в новую платформу.
Выход дисков из строя отслеживается. Все данные обязательно зеркалируются на разные диски.
Все ли понятно объясняли? На все ли вопросы ответили?
А почему не завести NAS с множеством zfs пулов и не делать zfs send | ssh backup@nas zfs recv, выбирая пул на NAS по каким-то признакам, например по группе серверов или имени кластера, если их несколько. И потом слать инкрементальные копии между 2-я snapshot-ами: старым (который уже отправлен) и новым (выполненным сейчас) через тот же send/recv. Для целей автоматизации старый, после передачи, можно грохнуть а новый переименовать в старый…
Вы правы, это основная схема работы системы резервного копирования. Поскольку статей на эту тему достаточно много, как и обзоров крутых инструментов для автоматизации типа ZREPL, мы решили осветить немного другую сторону вопроса.
Евгений, поскольку мы рассказываем про опыт Timeweb, то подразумевали, что на нашем хостинге хранятся сайты пользователей, базы данных.
Мы считаем, что тема про восстановление достойна отдельной статьи. В ней бы начали с выбора протокола сетевого доступа к файловым системам, далее рассказали про способ защиты пользовательских данных при подключении и копировании и закончили системой снятия дампов mysql.
А требования к оперативной памяти разных ФС сравнивали? Про ZFS говорят, что ей нужно много ОЗУ — у вас такое было?
Размер потребляемой ОЗУ на ARK кэш задается в параметрах модуля zfs_arc_max. В нашем случае он вычислялся эмпирически, чтобы не мешать работе основных сервисов, но при этом давать файловую производительность.
И ещё по поводу бекапов мне в приниципе интересно, как народ решает вопрос о объеме дисковой системы для бекапов: для каждого условного 1Тб данных, сколько Тб дискового пространства вы резервируете на бекап-сервере?
Тут все очень индивидуально, так как размер снапшота в ZFS зависит от размера добавленных данных. У нас это 1 к 2 для хранения сроком в 30 дней. То есть на 1 терабайт данных приходится 2 терабайта на бэкап-сервере.
В этой статье мы сделали, скорее, обзор различных подходов к резервному копированию. Постарались осветить плюсы и минусы каждого из них.
Создание бэкапов и их восстановление, как нам кажется, хорошая тема для отдельной статьи. Если вы с нами согласны, дайте знать :) Соберем материал и поделимся подробностями в следующей статье.
По pillarstack — с какими проблемами столкнулись? Не было тяжело осознать этот механизм?
C изучением pillarstack проблем не возникло, а вот на этапе тестирования стало сюрпризом, что он в отличие от ванильного пиллара не может рекурсивно инклюдить каталоги. Также поменялось дефолтное поведение мержа списков.
Приходилось перепроверить все пиллары, где были списки, иначе можно получить совсем не те данные, которые ожидаешь.
Удобен в работе?
Очень гибкий, и стратегии позволяют выкрутиться из любой ситуации.
Нет ли тормозов (все таки мерж 100500 элементов может занимать прилично времени)? Или может с кэшированием и обновлением элементов?
Какого-либо заметного изменения производительности нет, всё просто работает!
Мы так же в классе можем добавить дополнительные проверки для значения и ограничить число возможных инвариант предоставляемых типом. Но есть одно но!
Если мы произвели некоторую проверку внутри класса и возвращаем тип с большим числом инвариант, то у нас возникает та же самая проблема, что и в Haskell: мы не сохранили информацию об этих проверках в системе типов, поэтому при последующем использовании значения и добавлении новых инвариант, система типов нам ничем не поможет и не сообщит о возможной ошибке.
А, если серьезно, мы планируем сделать продолжение, поэтому в этой статье дали самые основы, с чего начать разработку. В следующих частях расскажем о реализации тёмной темы, мультиязычности, настройке PWA и SEO (в том числе об автогенерации Sitemap и robots.txt) и другом. Надеемся, что этот контент как раз будет уникальным и полезным.
Что касается количества пакетов, то большинство из них, в том числе и nuxtjs/stylelint-module, устанавливаются автоматически при выполнении команды npx create-nuxt-app в той конфигурации, что мы использовали. К пакетам, которые ставили дополнительно, старались дать пояснения.
Главной целью этой статьи было показать именно разработку приложения, поэтому теме деплоя не было уделено много времени.
В нашей команде есть эксперты в этой области. Постараемся в следующих статьях осветить эту тему более подробно.
В этой статье действительно нет подробных объяснений, так как мы хотели поделиться опытом работы с клиентом в формате мини-инструкции.
Указанный тест мы выбрали за доступность и простоту: такой тест будет понятен клиенту, и он легко сможет его воспроизводить.
Будем благодарны, если вы сможете поделиться другими более удобными способами измерения производительности взаимодействия портала Bitrix24 и служб, которые он использует.
innodb_buffer_pool_instances указан для удобства чтения следующему человеку, который будет разбираться с этими настройками. Да, значение 1 является значением по умолчанию, но кому-то может быть удобнее это видеть, чем вспоминать.
Мы не нашли ни одного обзора этого продукта на русском языке, поэтому решили перевести статью и опубликовать ее на «Хабре».
Попробуем ответить подробно на ваш комментарий.
Есть два вида серверов: клиентский и бэкапный. Файловая система, на которых находятся клиентские данные, — ZFS.
На клиентском сервере работают клиентские приложения. На бэкапном сервере хранятся бэкапы.
Снапшоты делаются на клиентском сервере и копируются на бэкапный сервер.
Схема бэкапа достаточно проста:
1. На клиентском сервере есть снапшот 1.
2. Перед копированием создается снапшот 2.
3. Снапшот 1 копируется / импортируется на бэкапный сервер. Для этого могут использоваться разные средства: ssh, scp, netcat и др. В нашем случае используется приложение, построенное на базе ssh.
4. По окончании успешного копирования снапшот 1 мержится / удаляется с основными данными, его место занимает снапшот 2.
5. При бэкапе переходим к пункту 1.
Восстановление отдельных файлов или директорий работает через копирование данных с сервера бэкапов из снапшота на клиентский сервер.
Восстановление целого сервера возможно из последнего снапшота, но по времени быстрее переставить диски в новую платформу.
Выход дисков из строя отслеживается. Все данные обязательно зеркалируются на разные диски.
Все ли понятно объясняли? На все ли вопросы ответили?
Вы правы, это основная схема работы системы резервного копирования. Поскольку статей на эту тему достаточно много, как и обзоров крутых инструментов для автоматизации типа ZREPL, мы решили осветить немного другую сторону вопроса.
Да, на Linux.
Мы считаем, что тема про восстановление достойна отдельной статьи. В ней бы начали с выбора протокола сетевого доступа к файловым системам, далее рассказали про способ защиты пользовательских данных при подключении и копировании и закончили системой снятия дампов mysql.
Размер потребляемой ОЗУ на ARK кэш задается в параметрах модуля zfs_arc_max. В нашем случае он вычислялся эмпирически, чтобы не мешать работе основных сервисов, но при этом давать файловую производительность.
Тут все очень индивидуально, так как размер снапшота в ZFS зависит от размера добавленных данных. У нас это 1 к 2 для хранения сроком в 30 дней. То есть на 1 терабайт данных приходится 2 терабайта на бэкап-сервере.
В этой статье мы сделали, скорее, обзор различных подходов к резервному копированию. Постарались осветить плюсы и минусы каждого из них.
Создание бэкапов и их восстановление, как нам кажется, хорошая тема для отдельной статьи. Если вы с нами согласны, дайте знать :) Соберем материал и поделимся подробностями в следующей статье.
Немного подправили, чтобы перевод звучал более корректно.
Отличная тема для следующей статьи!
Удачи с написанием курсовой!
Проверили репорты. Ваш не нашли, к сожалению! Очень жаль, что ребята так долго реагировали.
Будем благодарны за новые репорты!
C изучением pillarstack проблем не возникло, а вот на этапе тестирования стало сюрпризом, что он в отличие от ванильного пиллара не может рекурсивно инклюдить каталоги. Также поменялось дефолтное поведение мержа списков.
Приходилось перепроверить все пиллары, где были списки, иначе можно получить совсем не те данные, которые ожидаешь.
Очень гибкий, и стратегии позволяют выкрутиться из любой ситуации.
Какого-либо заметного изменения производительности нет, всё просто работает!
можно гибко настраивать, используя pillar, grains, opts.
В reclass не увидели что-то похожее на стратегии merge. Судя по всему, нет возможности использовать pillar и grains. Поправьте нас, если это не так.
Кажется, что pillarstack более популярен. Например, он часто обсуждается в этом Telegram-канале, где всегда можно посоветоваться с коллегами.
Действительно вставили задержку в py-код. Решили, что так будет нагляднее, иначе слишком много вывода и он очень быстро идет.
И на второй Ваш вопрос: да, съедается всё ядро.