moby Денис, мы тоже заинтересовались и нашли такую информацию. Звучит очень правдоподобно!
У многих народов существовала традиция давать имена полнолуниям, в древности люди внимательно следили за лунным календарем. В данной статье рассмотрена американская (имеются в виду коренные жители) и европейская традиция. Полный список названий был составлен журналом «Farmers' Almanac».
Полнолуние Червя (Full Worm Moon) — мартовское полнолуние, когда из-за повышения температуры и потепления начинают выползать червяки.
Розовое Полнолуние (Full Pink Moon) — первое полнолуние после весеннего равноденствия, вероятно, в честь первых весенних полевых цветов — флоксов.
Цветочное Полнолуние (Full Flower Moon) — полнолуние в мае, связанное с бурным цветением в это время.
Клубничное Полнолуние (Full Strawberry Moon) — полнолуние в июне, когда начинали собирать клубнику.
Мы так же в классе можем добавить дополнительные проверки для значения и ограничить число возможных инвариант предоставляемых типом. Но есть одно но!
Если мы произвели некоторую проверку внутри класса и возвращаем тип с большим числом инвариант, то у нас возникает та же самая проблема, что и в 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 терабайта на бэкап-сервере.
В этой статье мы сделали, скорее, обзор различных подходов к резервному копированию. Постарались осветить плюсы и минусы каждого из них.
Создание бэкапов и их восстановление, как нам кажется, хорошая тема для отдельной статьи. Если вы с нами согласны, дайте знать :) Соберем материал и поделимся подробностями в следующей статье.
Действительно потерялась часть предложения в начале статьи. Спасибо за замечания, постарались всё исправить.
У многих народов существовала традиция давать имена полнолуниям, в древности люди внимательно следили за лунным календарем. В данной статье рассмотрена американская (имеются в виду коренные жители) и европейская традиция. Полный список названий был составлен журналом «Farmers' Almanac».
Полнолуние Червя (Full Worm Moon) — мартовское полнолуние, когда из-за повышения температуры и потепления начинают выползать червяки.
Розовое Полнолуние (Full Pink Moon) — первое полнолуние после весеннего равноденствия, вероятно, в честь первых весенних полевых цветов — флоксов.
Цветочное Полнолуние (Full Flower Moon) — полнолуние в мае, связанное с бурным цветением в это время.
Клубничное Полнолуние (Full Strawberry Moon) — полнолуние в июне, когда начинали собирать клубнику.
В списке есть еще много любопытных названий.
Энцелад действительно достоин целой серии статей! :)
Мы так же в классе можем добавить дополнительные проверки для значения и ограничить число возможных инвариант предоставляемых типом. Но есть одно но!
Если мы произвели некоторую проверку внутри класса и возвращаем тип с большим числом инвариант, то у нас возникает та же самая проблема, что и в 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 терабайта на бэкап-сервере.
В этой статье мы сделали, скорее, обзор различных подходов к резервному копированию. Постарались осветить плюсы и минусы каждого из них.
Создание бэкапов и их восстановление, как нам кажется, хорошая тема для отдельной статьи. Если вы с нами согласны, дайте знать :) Соберем материал и поделимся подробностями в следующей статье.
Немного подправили, чтобы перевод звучал более корректно.
Отличная тема для следующей статьи!
Удачи с написанием курсовой!