Logo Море(!) аналитической информации!
IT-консалтинг Software Engineering Программирование СУБД Безопасность Internet Сети Операционные системы Hardware
VPS в 21 локации

От 104 рублей в месяц

Безлимитный трафик. Защита от ДДоС.

🔥 VPS до 5.7 ГГц под любые задачи с AntiDDoS в 7 локациях

💸 Гифткод CITFORUM (250р на баланс) и попробуйте уже сейчас!

🛒 Скидка 15% на первый платеж (в течение 24ч)

Скидка до 20% на услуги дата-центра. Аренда серверной стойки. Colocation от 1U!

Миграция в облако #SotelCloud. Виртуальный сервер в облаке. Выбрать конфигурацию на сайте!

Виртуальная АТС для вашего бизнеса. Приветственные бонусы для новых клиентов!

Виртуальные VPS серверы в РФ и ЕС

Dedicated серверы в РФ и ЕС

По промокоду CITFORUM скидка 30% на заказ VPS\VDS

2004 г

Новое в СУБД ЛИНТЕР 6.1

Петр Лысачев, Виталий Максимов, Михаил Ермаков,
Научно-производственное предприятие РЕЛЭКС

В начало

Настройка и работа

В только что созданной базе данных таблицы $$$CHARSET и $$$TRANSL отсутствуют, и для работы базы данных используется интегрированная кодовая страница 20127(US-ASCII), имеющая имя «DEFAULT» и содержащая 127 символов. После создания системного словаря эта кодовая страница может быть подменена любой другой, носящей то же имя. Таким образом, кодовая страница «DEFAULT» является первой кодовой страницей по умолчанию в базе данных. Кодовая страница по умолчанию используется в двух случаях:

•  в символах этой кодовой страницы хранится системный словарь (названия таблиц, столбцов, триггеров, процедур и т. д.);

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

В настоящее время кодовая страница по умолчанию может быть только однобайтовой. Сменить кодовую страницу по умолчанию можно с помощью SQL- команды «SET DATABASE NAMES …;». Например команда «SET DATABASE NAMES CP866;» устанавливает по умолчанию кодовую страницу 866. Если вслед за этим подать команду «CREATE TABLE A (B CHAR(5));», то для таблицы A и столбца B будет установлена кодовая страница 866. Если же, например, подать команду «CREATE TABLE A (B CHAR(5) CHARACTER SET CP1251);», то для столбца B будет установлена кодовая страница 1251.

Для нормальной работы с кодовой страницей рекомендуется явно задать ее на клиентской части. Это проще всего сделать, задав переменную окружения:

set LINTER_CP=CP932

Этот пример для случая, если мы хотим работать с японской SJIS-кодовой страницей CP932.

Данные в столбцах в произвольной национальной кодовой странице могут храниться двумя способами:

•  в текстовых столбцах таблиц с заданной национальной кодовой страницей;

•  в UNICODE-столбцах таблиц.

В качестве длин текстовых полей указывается их размер в байтах.

Проиллюстрируем оба этих способа на примере японской кодовой страницы CP932 (эта японская кодовая страница содержит как однобайтовые, так и двухбайтовые символы.):

CREATE TABLE TBL_JP( JSTR CHAR( 30 ) CHARACTER SET CP932 );
INSERT INTO TBL_JP VALUES ('???1');
INSERT INTO TBL_JP VALUES ('???2');
 
CREATE TABLE TBL_JP1( JSTR1 NCHAR( 30 ));
INSERT INTO TBL_JP1 VALUES (N'???1N');
INSERT INTO TBL_JP1 VALUES (N'???2N');

На рисунке 1 показано, как будет представлена выборка из данной таблицы в утилите LinDesk :

Рисунок 1. Отображение национальных символов.

Следует отметить еще один важный момент. Поскольку хранение многобайтовых кодовых страниц требует существенного объема оперативной памяти, то внутри СУБД такие страницы хранятся в отдельной очереди, которая по умолчанию не инициализирована. Ее инициализация происходит только в результате занесения в таблицу $$$CHARSET первой многобайтовой кодовой страницы и последующего перезапуска базы данных.

В заключение следует сказать, что реализованная в шестой версии СУБД ЛИНТЕР система многоязыковой поддержки обладает рядом существенных преимуществ: простота реализации, возможность гибкой настройки, расширяемость данной системы по мере необходимости. В то же время следует обратить внимание, что для полноценного использования всех этих возможностей следует очень серьезно подойти к проектированию базы данных, а также внимательно изучить примеры, прилагаемые к документации СУБД.

Асинхронная репликация

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

Один из способов удовлетворения этой потребности – реализация в СУБД механизма асинхронной репликации. Основная идея репликации заключается в том, что вместо одной базы данных, с которой должны работать все клиенты, создается несколько одинаковых (по крайней мере, частично) баз данных на разных машинах. Клиенты имеют доступ к некоторому распределяющему устройству (реализованному аппаратно или каким-либо программным методом), которое при появлении нового клиента оценивает загрузку каждого сервера и направляет клиента на наименее загруженный, с которым он (клиент) и будет работать до отсоединения.

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

Такое построение позволяет значительно (в идеальном случае, прямо пропорционально количеству серверов) увеличить производительность системы и наращивать её по мере роста нагрузки (увеличения количества клиентов или размеров базы данных) простым прибавлением серверов в систему репликации.

Правила репликации

Для управления системой на логическом уровне в СУБД ЛИНТЕР используются правила репликации, которые создаются обычным SQL-запросом и представляют собой описание того, какие объекты, куда и каким образом реплицировать. В ЛИНТЕР создание правила репликации выглядит так:

CREATE REPLICATION RULE имя_правила
       FOR [ имя_пользователя. ] имя_таблицы
       [ TO имя_удаленной_таблицы ]
       ON NODE имя_сервера
       [ USER имя_пользователя ] [ PASSWORD 'пароль' ]
       [ ENABLE / DISABLE ] 
           [ SYNC / ASYNC ]
           [ IGNORE OLD VALUE / CHECK OLD VALUE / CORRECT NUMBERS  ];

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

Есть три модели поведения системы при возникновении рассогласования между значениями записей в базах данных реплицируемых серверов. Если такая ситуация возникла во время выполнения операции ( update , delete ), можно предпринять следующие действия:

•  IGNORE OLD VALUE – игнорировать несовпадение старого значения

•  CHECK OLD VALUE – обязательно проверить старое состояние и вернуть ошибку, если нет полного совпадения.

•  CORRECT NUMBERS – если не совпадают числовые значения, сохранить разницу между старым и новым значением.

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

Сервер репликации СУБД ЛИНТЕР

В системе асинхронной репликации участвуют два или более серверов, на каждом из которых работает ЛИНТЕР и два процесса репликации , In и Out (они представляют собой отдельные потоки в Windows или процессы в UNIX). Объектами репликации являются таблицы базы данных, список которых вместе с правилами и адресами рассылки хранится в БД.

Сервер репликации ( СР ) представляет собой специальный процесс, который получает данные об измененных данных от СУБД ЛИНТЕР и сохраняет эти данные в очередях репликации в хранилище данных репликации (ХДР), которое представляет собой соответствующим образом «урезанное» ядро. Оно же будет использоваться процессами In и Out для получения данных, подлежащих репликации и рассылке.

Функции компонентов:

•  ЛИНТЕР – основное ядро, работает независимо от остальных компонентов. Должно обеспечивать только одну дополнительную функцию: выдавать для СР измененные записи.

•  Сервер репликации – запускается отдельно и независимо от СУБД, он в свою очередь запускает ХДР, In и Out ; формирует структуру данных в ХДР, запрашивает и получает данные от ЛИНТЕР , сохраняет их в ХДР, формирует очередь рассылки в ХДР.

•  Хранилище данных репликации – это ЛИНТЕР, который хранит данные для рассылки. К этим данным имеют доступ СР , процессы In , Out и мониторы.

•  Процесс In – получает от удаленного Out информацию об измененных записях, после получения информации о подтверждении транзакции выполняет транзакцию, отсылая код возврата отправителю. Получаемые данные хранятся в ХДР в виде приемной очереди.

•  Процесс Out – ожидает завершения транзакций (хранящихся в ХДР) и рассылает данные по назначению. Получает и заносит в ХДР коды возврата от удаленных серверов.

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

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

В качестве идентификатора кортежа используется первичный ключ (для очереди рассылки это OPER_DATE (дата операции, она уникальна), на приемной очереди это уже не первичный ключ, там идентификация происходит по OPER_DATE и SERVER_SRC (передающий сервер)), описание которого передается от Out к In и сохраняется в таблицах сервера репликации.

Если один из процессов (ЛИНТЕР или СР ) завершается некорректно, этот процесс стартует заново, восстанавливается и работа продолжается. Повторное прохождение одного и того же блока отслеживается с помощью времени операции (OPER_DATE).

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

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

содержание       назад       вперед

VPS/VDS серверы. 30 локаций на выбор

Серверы VPS/VDS с большим диском

Хорошие условия для реселлеров

4VPS.SU - VPS в 17-ти странах

2Gbit/s безлимит

Современное железо!

Бесплатный конструктор сайтов и Landing Page

Хостинг с DDoS защитой от 2.5$ + Бесплатный SSL и Домен

SSD VPS в Нидерландах под различные задачи от 2.6$

✅ Дешевый VPS-хостинг на AMD EPYC: 1vCore, 3GB DDR4, 15GB NVMe всего за €3,50!

🔥 Anti-DDoS защита 12 Тбит/с!

Новости мира IT:

Архив новостей

IT-консалтинг Software Engineering Программирование СУБД Безопасность Internet Сети Операционные системы Hardware

Информация для рекламодателей PR-акции, размещение рекламы — adv@citforum.ru,
тел. +7 495 7861149
Пресс-релизы — pr@citforum.ru
Обратная связь
Информация для авторов
Rambler's Top100 TopList liveinternet.ru: показано число просмотров за 24 часа, посетителей за 24 часа и за сегодня This Web server launched on February 24, 1997
Copyright © 1997-2000 CIT, © 2001-2019 CIT Forum
Внимание! Любой из материалов, опубликованных на этом сервере, не может быть воспроизведен в какой бы то ни было форме и какими бы то ни было средствами без письменного разрешения владельцев авторских прав. Подробнее...