Как разделить sql файл на части

Обновлено: 04.07.2024

В прошлых статьях мы уже говорили о подходах к разработке и обслуживанию базы данных, которые позволяют использовать индексы произвольной структуры и даже секционирование для баз 1С. Казалось бы, тема исчерпана и для высоконагруженных баз может наступить светлое будущее, не смотря на то, что платформа 1С пока так и не поддерживает эти возможности из "коробки".

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

Сегодня мы более детально рассмотрим их использование, а также нюансы, с которыми нужно считаться при обслуживании базы данных, реструктуризациях и других моментах.

Для чего вообще может понадобиться разбивать базу данных на отдельные файлы? Самые распространенные кейсы:

Есть регистр сведений, в котором хранятся двоичные данные файлов. Необходимо вынести хранение файлов на отдельный диск / хранилище, чтобы освободить место на быстрых дисках.
Есть старые архивные таблицы, которые уже редко используются, но удалять данные нельзя. Почему бы такие таблицы также не перенести на отдельные диски, которые для этого и предназначены. Тем более такие файловые группы можно сделать только для чтения.
Ускорить бэкапирование базы, т.к. архивные файловые группы можно не бэкапировать каждый раз. Они ведь не меняются!
Улучшение производительности, за счет распределения файлов базы данных на отдельные носители.

Тему ускорения бэкапирования и производительности сейчас мы рассматривать не будем, но Вы можете прочитать об этом в публикации про секционирование. Сосредоточимся на описании настроек для файловых групп и их сопровождении. Все примеры ниже будут сделаны для SQL Server, но и для PostgreSQL это будет работать с некоторыми модификациями.

Стандартный подход

Любая база, будь то для 1С или любого другого приложения, поддерживает разбиение базы на несколько файлов (конечно, если это поддерживает СУБД). В контексте SQL Server это реализуется с помощью файловых групп.

По умолчанию база содержит лишь одну файловую группу "PRIMARY", которую 1С и использует для своих целей. Кроме таблиц и индексов в этой предопределенной группе хранится служебная информация о базе, различные заголовки и др., поэтому полностью заменить эту группу на другую нельзя, она всегда будет присутствовать.

Однако, мы можем добавить собственные файловые группы и использовать их для 1С'ных таблиц, причем сама платформа об этом не узнает.

Возьмем для примеров демобазу БСП и создадим в ней две новых файловых группы.

Но просто добавить файловые группы недостаточно. Еще нужно добавить файлы данных, для которых эти файловые группы будут задействованы.

Отлично, у нас есть две файловые группы "FILEGROUP_2" и "FILEGROUP_3", осталось их задействовать. Есть несколько основных вариантов:

Мы можем вручную изменить основную файловую группу базы и сделать реструктуризацию средствами 1С.
Мы можем пересоздать кластерный или другие индексы средствами T-SQL, указав для использования нужную файловую группу.
Ничего не делать.

По третьему варианту написано довольно много примеров в сети, поэтому рассмотрим только первые два пункта. Все примеры будем делать на регистре сведений "История адресных объектов", который на стороне базы представлен таблицей "_InfoRg4683" с несколькими индексами.

И так, для начала установим основную файловой группой - одну из тех, что добавили выше.

То же самое можно сделать через T-SQL.

Кому как больше нравится.

Теперь нужно сделать реструктуризацию средствами платформы. Нормального способа вызвать ее для нашего случая нет, но мы можем:

Добавить временно реквизит в таблицу, а потом запустить реструктуризацию.
Полностью реструктуризировать базу через "Тестирование и исправление".

Оба варианта выглядят "не очень", и Вам повезет, если необходимость реструктуризации появится как-раз в этот момент для других задач. При использовании инструмента "Тестирование и исправление" Вы вообще переведете все таблицы и индексы в установленную файловую группу, поэтому этот случай мы вообще рассматривать не будем. А вот пример с добавлением временного реквизита - пожалуйста.

С помощью этих скриптов можно узнать как изменилась структура базы в части использования файловых групп. Вот какие изменения мы получили.

Таблица	Индекс	Файловая группа	Файл
_InfoRg4683	_InfoRg4683_ByDims_NNNNNNNNNNBN	FILEGROUP_2	D:\DBs\bsl_fg_2.mdf
_InfoRg4683	_InfoRg4683_ByResource4705_SNNNNNNNNNNBN	FILEGROUP_2	D:\DBs\bsl_fg_2.mdf
_InfoRg4683	_InfoRg4683_ByResource4706_SNNNNNNNNNNBN	FILEGROUP_2	D:\DBs\bsl_fg_2.mdf
_InfoRg4683	_InfoRg4683_ByMainFilter_NNNNNNNNNNNB	FILEGROUP_2	D:\DBs\bsl_fg_2.mdf

Таким образом, мы перевели таблицу регистра сведений "История адресных объектов" и все ее индексы в файловую группу "FILEGROUP_2".

Подведем итог по данному способу.

Плюсы:

Минусы:

Нужен вызов платформенной реструктуризации, что не всегда оптимально.
После реструктуризации надо обратно настраивать основную файловую группу.
Необходимость проводить реструктуризацию таблиц в разных файловых группах отдельно друг от друга, что не всегда возможно.

Вообщем, способ неэффективный, но требует минимальных действий на стороне СУБД.

Скриптуем

Более эффективный и гибкий подход - это перенос таблиц и индексов в другую файловую группу с помощью скриптов. Вот так будет выглядеть скрипт для переноса всех индексов регистра сведений "История адресных объектов" в третью файловую группу.

Перенос всех индексов таблицы в другую файловую группу

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

Для того, чтобы сгенерировать скрипты создания индексов, можно воспользоваться стандартными возможностями SQL Managment Studio по созданию скриптов для базы данных.

Все, теперь мы счастливые обладатели регистра сведений, который находится в дополнительной файловой группе. Смотрим итог с помощью этих скриптов.

Таблица	Индекс	Файловая группа	Файл
_InfoRg4683	_InfoRg4683_ByDims_NNNNNNNNNNBN	FILEGROUP_3	D:\DBs\bsl_fg_3.mdf
_InfoRg4683	_InfoRg4683_ByResource4705_SNNNNNNNNNNBN	FILEGROUP_3	D:\DBs\bsl_fg_3.mdf
_InfoRg4683	_InfoRg4683_ByResource4706_SNNNNNNNNNNBN	FILEGROUP_3	D:\DBs\bsl_fg_3.mdf
_InfoRg4683	_InfoRg4683_ByMainFilter_NNNNNNNNNNNB	FILEGROUP_3	D:\DBs\bsl_fg_3.mdf

Как итог, определим плюсы и минусы.

Плюсы:

Быстрый и эффективный способ работы с файловыми группами.
Нет необходимости каких-либо действий на стороне 1С.

Нет связи с платформой 1С, даже призрачной как в прошлом примере.

Конечно, предпочтительнее использовать этот способ, если Вы бережете время, нервы и деньги.

Сложности для 1С

Все выглядит просто, но есть нюансы.

Во-первых, лицензионное соглашение 1С запрещает так работать с СУБД, т.к. эти возможности недокументированы. Начиная использовать файловые группы, Вы должны осознавать риски нарушения этого соглашения. Минимальные последствия - это отказ в технической поддержке решений на платформе 1С.

В пункте 65 лицензионного соглашения сказано следующее:

Лицензионное соглашение не позволяет использовать недокументированные фирмой "1С" средства для построения решений на платформе "1С:Предприятие". Это означает, что средства СУБД (или любые другие внесистемные средства) можно использовать только в том случае, если документация по продуктам линейки "1С:Предприятие" (включая 1С:ИТС) содержит явную рекомендацию использовать данное средство для решения данной задачи.

Во всех остальных случаях лицензионное соглашение позволяет использовать для построения решений только штатные средства платформы. В частности, можно обращаться к данным информационной базы только при помощи объектов "1С:Предприятия", специально предназначенных для работы с данными (запросы, справочники, документы и т. д.). Нельзя обращаться к данным информационной базы напрямую, минуя уровень объектов работы с данными "1С:Предприятия", например при помощи средств СУБД или при помощи внешних компонент, которые реализуют прямой доступ к СУБД. Это ограничение распространяется на любые действия с данными, в том числе на изменение их структуры, а так же на чтение или изменение самих данных информационной базы или служебных данных "1С:Предприятия".

Данное ограничение необходимо для обеспечения стабильности работы механизмов системы, осуществления поддержки и возможности перехода на новые версии "1С:Предприятия".

Вы должны четко понимать плюсы и минусы данного шага. Все, что Вы сделаете будет на Вашей совести!

Во-вторых, это усложнение сопровождения, т.к. при обновлении базы данных необходимо учитывать тот факт, что некоторые таблицы находятся в других файловых группах или дисковых носителях.

Зачем это учитывать? Например, у Вас в базе есть регистр сведений "Присоединенные файлы" (в базе представлен таблицей "_InfoRg2133"), в котором хранятся двоичные данные разнотипных документов. Для экономии места в основном хранилище данных был выполнен перенос этих документов в отдельную файловую группу. Файл данных для нее находится на отдельном диске.

Перенос данных документов в отдельную файловую группу

Платформа 1С хранит двоичные данные документов в LOB-типах данных (image или varbinary(max) в зависимости от версии платформы). Для переноса LOB-данных в отдельную файловую группу не обязательно переносить всю таблицу и индексы. Достаточно перенести только сами LOB-данные, указав основную файловую группу для таких типов. Именно так мы и сделаем в примере ниже.

Теперь все LOB-данные перенесены в файловую группу "FILEGROUP_3". При необходимости основной файл данных, где ранее хранились перемещенные документы, можно уменьшить операцией Shrink. В нашем случае мы это рассматривать не будем.

P.S. Не забудьте сделать бэкап перед такими операциями.

P.P.S. Этот скрипт не является готовым решением. Его можно улучшить за счет различных проверок, транзакций и т.д.

Все отлично сработало, мы освободили 1 ТБ данных в основном хранилище. НО! В один прекрасный день разработчики 1С внесли изменения в систему, добавив новый ресурс к регистру сведений "Присоединенные файлы". В тестовых базах все проверено, ведь там никто не держит полную копию рабочей базы. Изменение ушло в релиз, но при развертывании возникли следующие проблемы:

В итоге, если такая ситуация произойдет и добрые администраторы не смогут выделить дополнительное место да дисках, то может произойти остановка работы системы. Но это не точно и полностью зависит от Вашей инфраструктуры!

Но есть ли способ избавиться от такой проблемы? Да, есть! Вот несколько рекомендаций:

Проверять перечень таблиц для реструктуризации перед каждым релизом.
В случае, если изменения затронули тяжелые таблицы, для которых применены нестандартные файловые группы, то один из вариантов:
- Отказаться от изменения на этой таблице. Вместо этого использовать внешние таблицы. Например, вместо добавления реквизита в справочник можно добавить его как доп. свойство или в дополнительный регистр сведений. Включите воображение!
- Если изменения все же очень нужны, то необходимо делать реструктуризацию в "ручном режиме". Подробнее останавливаться на этом сейчас не будем, но на ИС уже об этом писали. Причем, чем больше изменений, тем и сложнее будет сделать это вручную.
Максимально автоматизировать настройку файловых групп для таблиц и индексов базы, а также сделать заглушки для тех таблиц, где реструктуризация автоматически проходить не должна. Об этом будет ниже.

В этом и кроются основные причины усложнения сопровождения. Поэтому стоит 7 раз подумать, прежде чем начать такое у себя использовать.

Автоматизируй это!

Выше мы упомянули про автоматизацию настроек файловых групп для таблиц и индексов. На самом деле здесь ничего нового нет и используется тот же самый подход по созданию произвольных индексов и применению настроек сжатия, что был в статье "Создаем свои индексы для баз 1С. Со своей структурой и настройками!". Он заключается в создании глобальных триггеров, в которых мы отлавливаем события создания таблицы или индекса и встраиваем свою логику для настройки базы данных.

Как пересоздать индекс с учетом новой файловой группы? Например, у нас есть таблица "_InfoRg4683" и индекс "_InfoRg4683_ByDims_NNNNNNNNNNBN" (это из примера с регистром сведений "История адресных объектов"), при этом основная файловая группа в базе это "PRIMARY". Имея уже такие данные мы можем написать такой скрипт.

Универсальный (почти) скрипт пересоздания индекса с новой файловой группой

Скрипт генерирует команду "CREATE INDEX" для уже существующего индекса, а в ней мы просто подменяем имя файловой группы.

Параметр "DROP_EXISTING = ON" позволяет избежать ошибки, что такой индекс уже существует. В этом случае СУБД удалит старый индекс и создаст новый.

Также есть несколько нюансов при пересоздании индексов с новыми файловыми группами:

При пересоздании кластерного индекса с новой файловой группой, все остальные индексы таблицы будут также созданы с этой файловой группой.
Для большей универсальности имя новой и старой файловой группы можно получать динамически, вместо явного указания в скрипте.
Пользователь СУБД, от имени которого выполняется реструктуризация, должен иметь необходимые привилегии для выполнения запросов.

А что на счет остановки реструктуризации, если она начинается на таблице, где этого происходить не должно?

В триггере проверяем имя таблицы и/или индекса и если он попадает под запрет, то выполняем:

При попытке запуска обновления информационной базы получим ошибку.

Вот такой страшный запрет!

Можно пойти дальше и не ограничиваться отдельными скриптами, а вынести все подобные ограничения и настройки в отдельный инструмент, как это было сделано здесь.

Послесловие

На первый, второй и третий взгляд все это может показаться настоящим монстром, особенно для сопровождения. Что ж, так оно и есть! Остается надеяться, что наступят светлые времена, когда платформа 1С позволит использовать возможности СУБД без таких костылей. А пока на этом все!

В sql server нет готовой функции Split, поэтому нам нужно создать пользовательскую функцию.

Посмотрите на решение таблицы чисел DelimitedSplit8K Джеффа Модена в ответе @ughai ниже. SQL 2016 и выше: SELECT * FROM STRING_SPLIT('John,Jeremy,Jack',',')

а также проверьте ссылку ниже для справки

Мне это очень нравится. CHARINDEX и SUBSTRING - беспорядок, когда вам нужно разделить более двух значений (например, 1,2,3). Большое спасибо Отличная идея. Хотя в три раза медленнее, чем CHARINDEX плюс SUBSTRING , по крайней мере, для меня. :-( Отличное решение, однако некоторые символы недопустимы в XML (например, '&'), поэтому мне пришлось заключить каждое поле в тег CDATA . CONVERT(XML,'<Names><name><![CDATA[' + REPLACE(Name,',', ']]></name><name><![CDATA[') + ']]></name></name>') AS xmlname @Tony нужно было обновить код Тони до CONVERT(XML,'<Names><name><![CDATA[' + REPLACE(address1,',', ']]></name><name><![CDATA[') + ']]></name></Names>') AS xmlname (Пропущены последние s на </Names>)

xml базовый ответ прост и понятен

Это действительно круто. Функция типа массива очень полезна, и я понятия не имел о ней. Благодарность!

Я думаю это круто

Вы также должны знать, что PARSENAME вернет NULL для элементов длиной более 128 символов. Я не могу понять, почему вам нужно добавить две запятые в конец исходной строки, чтобы это сработало. Почему не работает без "+ ',,'"? @ developer.ejay это потому, что функции Left / SubString не могут принимать значение 0? Большой! Вы можете легко скопировать / вставить 2 строки для каждого дополнительного столбца, который вам нужен - затем просто увеличивайте числа, например: выберите ParsedData. * Из MyTable mt cross apply (выберите str = mt.String + ',,') f1 cross apply (выберите p1 = charindex (',', str)) ap1 cross apply (выберите p2 = charindex (',', str, p1 + 1)) ap2 cross apply (выберите p3 = charindex (',', str, p2 + 1)) ap3 cross apply (выберите FName = substring (str, 1, p1-1), LName = substring (str, p1 + 1, p2-p1-1), Age = substring (str, p2 + 1, p3-p2-1) )) ParsedData

Есть несколько способов решить эту проблему, и многие из них уже были предложены. Проще всего было бы использовать LEFT / SUBSTRING и другие строковые функции для достижения желаемого результата.

Пример данных

Использование строковых функций вроде LEFT

Этот подход не работает, если в строке больше двух элементов. В таком сценарии мы можем использовать разделитель, а затем использовать PIVOT или преобразовать строку в XML и использовать .nodes для получения элементов строки. XML решения на основе были подробно описаны AADS и BVR в их решении.

Ответы на этот вопрос, которые используют сплиттер, все используют, WHILE который неэффективен для разделения. Проверьте это сравнение производительности . Один из лучших сплиттеров DelimitedSplit8K создан Джеффом Моденом. Вы можете прочитать об этом здесь

Разветвитель с PIVOT

Выход

DelimitedSplit8K Джефф Моден

В SQL Server 2016 мы можем использовать string_split для этого:

Я использую SQL Server 2016, но выдает ошибку Invalid object name 'string_split' Можете ли вы проверить уровень совместимости вашей базы данных? Это должно быть 130, что является sql server 2016. Вы можете использовать этот запрос select * from sys.databases верно, я вижу 120, поэтому это должен быть только клиент (Microsoft SQL Server Management Studio), который является 2016, а не сервер базы данных как таковой, потому что, если я перейду в Help -> About, я увижу SQL Server 2016 Management Studio v13.0.15000. 23. Спасибо Может случиться так, что разработчики db установили для уровня любое меньшее значение, чтобы поддерживать совместимость db, даже если фактическая установленная версия выше. Используйте это, чтобы установить необходимый уровень до тех пор, пока db поддерживает это: DECLARE @cl TINYINT; SELECT @cl = compatibility_level FROM [sys].[databases] WHERE name = 'mydb'; IF @cl < 130 BEGIN ALTER DATABASE myDb SET COMPATIBILITY_LEVEL = 130 END; это бесполезно, если вы не переместите его обратно из строк в столбцы.

Попробуйте это (измените экземпляры '' на 'или любой другой разделитель, который вы хотите использовать)

Неудачно для меня, если одинаковые значения в одной строке.

Функция PARSENAME логически разработана для анализа четырехчастных имен объектов. Преимущество PARSENAME заключается в том, что он не ограничивается синтаксическим анализом только четырехчастных имен объектов SQL Server - он анализирует любую функцию или строковые данные, разделенные точками.

Первый параметр - это объект для анализа, а второй - целочисленное значение возвращаемой части объекта. В статье обсуждается синтаксический анализ и ротация данных с разделителями - номеров телефонов компании, но ее также можно использовать для анализа данных имени / фамилии.

В статье также описывается использование общего табличного выражения (CTE), называемого replaceChars, для запуска PARSENAME для значений, замененных разделителями. CTE полезен для возврата временного представления или набора результатов.

После этого была использована функция UNPIVOT для преобразования некоторых столбцов в строки; Функции SUBSTRING и CHARINDEX использовались для устранения несоответствий в данных, а функция LAG (новая для SQL Server 2012) была использована в конце, поскольку она позволяет ссылаться на предыдущие записи.

5 Гб), процесс импорта зависает и не возращает какой-либо результат. После изучения файлов Hex-редактором пришел к выводу, что содержимое - это один большой INSERT INTO *** VALUES()
Вопрос. Как разбить данный INSERT программно, для успешного импорта дампа.

С уважением,
Никита

Вопрос задан более трёх лет назад
1664 просмотра

Средний 2 комментария

Как заливаете сейчас?
При чем hex-editor?
Что дамп содержит?

Заливаю страндартным Импорт/Экспорт тулом.
Hex - чтобы открыть файл большого размера.
Содержание Дампа:

-- MySQL dump 10.13 Distrib 5.5.40-36.1, for Linux (x86_64).--.--
Host: ****
Database: ****
---------------------------------------------------------
Server version.5.5.40-36.1-log../*!40101 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */;./*!40101 SET @OLD_CHARACTER_SET_RESULTS=@@CHARACTER_SET_RESULTS */;./*!40101 SET @OLD_COLLATION_CONNECTION=@@COLLATION_CONNECTION */;./*!40101 SET NAMES utf8 */;./*!40103 SET @OLD_TIME_ZONE=@@TIME_ZONE */;./*!40103 SET TIME_ZONE='+00:00' */;./*!40014 SET @OLD_UNIQUE_CHECKS=@@UNIQUE_CHECKS, UNIQUE_CHECKS=0 */;./*!40014 SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0 */;./*!40101 SET @OLD_SQL_MODE=@@SQL_MODE, SQL_MODE='NO_AUTO_VALUE_ON_ZERO' */;./*!40111 SET @OLD_SQL_NOTES=@@SQL_NOTES, SQL_NOTES=0 */;
..--.-- Table structure for table `member_login`.--..

DROP TABLE IF EXISTS `member_login`;./*!40101 SET @saved_cs_client = @@character_set_client */;./*!40101 SET character_set_client = utf8 */;.

CREATE TABLE `member_login` (. `pnum` int(11) NOT NULL AUTO_INCREMENT,. `username` varchar(28) CHARACTER SET utf8 COLLATE utf8_general_mysql500_ci NOT NULL DEFAULT '',. `password` varchar(128) NOT NULL DEFAULT '',. `loginkey` varchar(36) NOT NULL DEFAULT '',. `notify` int(4) NOT NULL DEFAULT '0',. PRIMARY KEY (`pnum`),. UNIQUE KEY `username` (`username`),. KEY `loginkey_lookup` (`loginkey`).) ENGINE=InnoDB AUTO_INCREMENT=37322429 DEFAULT CHARSET=utf8;./*!40101 SET character_set_client = @saved_cs_client */;

..--.-- Dumping data for table `member_login`.--..
LOCK TABLES `member_login` WRITE;./*!40000 ALTER TABLE `member_login` DISABLE KEYS */;.

У меня на одном из проектов есть большая MySQL база.
Большая, это около 1 Тб ( 950 Гб ) и она растет.

Периодически, несколько раз в год, это чудо сыпется. Причины бывают разные, чаще всего это связано с рейдом (raid 1) - вылетают винты, а после синхронизации умирают таблицы индексов. И соответственно приходится все это дело восстанавливать, что доставляет массу неудобств.

База состоит всего из 7 таблиц формата MyISAM. Основные данные находятся в одной таблице (

От InnoDB отказались сразу же после первой попытки восстановления 300 Гб базы, это был кошмар.

Есть возможность изменить способ хранения таким образом, чтобы данную таблицу разбить по англ алфавиту, т.е. вместо 1 таблицы 850 Гб, получится 850 / 26

Это несомненно увеличит скорость восстановления в случае проблем, а так же даст возможность работать с частями базы, независимо от других частей (тут я имею ввиду, что если восстановили таблицы: "A", "B", "C", то их можно вернуть в работу).

Посещаемость (вместе с ПС) колеблется от 150к до 1кк в день, к базе попадает, около 25-50 запросов в секунду.

Вопросы:
- Какие есть подводные камни, в таком делении базы (32 табл вместо 1)?
- Каким еще образом можно делить большие базы?
- Есть ли способы избежать разделения, кроме репликации и изменения способа хранения, в частности рейда?

P.S. Если есть литература, на эту тему (хранение и управление "большими" объемами данных), прошу помочь с названиями.

Наверное, стоит лучше использовать партиционирование вместо ручного биения по таблицам

Спасибо, за ответ!

Не знал о такой возможности, буду тестировать и рассматривать.

Возможно, у Вас уже есть опыт использования партицирования и сможете подсказать, что будет, если один из файлов партиционированной таблицы посыпется? Как я понимаю, все запросы к данной таблице до восстановления посыпавшегося файла перестанут работать, до полного восстановления таблицы ( тут, написано что " [при] SELECT, INSERT, UPDATE MySQL произведет следующие манипуляции: откроет все партиции всех таблиц участвующих в запросе..". Это значит что при выходе из строя 1го файла таблицы, например файл буквы "A", таблица не может быть открыта, хотя запрос будет использовать только файл на букву "Z"). Так ли это?

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

Vitaliy Orlov: вероятность посыпавшегося файла близка к нулю, а если упал сервер то тут ничего и не поможет.

Пума Тайланд: у меня несколько раз в год сыпется файл индексов самой большой таблицы. Чаще всего это связано с такой ситуацией: вылетает один из винтов в рейде (или готовится к смерти), пул запросов к бд переполняется, т.к. база не может работать. После этого все запросы убиваются через kill, и mysql завершается с помощью service mysql stop. После замены hdd и синхронизации винтов, у таблиц появляется статус "используется" ("in use"), помогает только: myisamchk с увеличенными буферами, но на таблице в 850 Гб, никакие буфера не помогут, все очень медленно..

Т.е., да, проблема изначально не в MySQL, а в том, что при стечении обстоятельств файлы портятся, и в моем случае, к сожалению, это происходит довольно часто.

Даже если рассмотреть проблему, с упавшим сервером. Предположим что посыпались файлы используемых при падении таблиц, то правильно ли я понимаю, что при использовании партицированния, вся таблица перестанет работать, в независимости от кол-ва испорченых файлов? В случае использования отдельных таблиц, мне кажется, вероятность вылета уменьшится и при этом их можно будет быстрее вводить в строй.

М.б., Вам на вскидку приходят в голову, какие-то другие проблемы разделения данных?

Читайте также: