Перейти к содержимому
Последнее обновление

JDBC Catalog

JDBC Catalog позволяет подключаться к базам данных, совместимым с протоколом JDBC, через стандартный интерфейс JDBC.

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

Примечание

Функция JDBC Catalog в Doris использует слой Java для чтения и обработки данных, поэтому её общая производительность может зависеть от версии JDK. Некоторые внутренние библиотеки в старых версиях JDK (например, JDK 8) менее эффективны и могут приводить к повышенному потреблению ресурсов. Если требуется более высокая производительность, рекомендуется использовать Doris 3.0, который по умолчанию компилируется с JDK 17 и обеспечивает более высокую общую производительность.

Сценарии применения​

JDBC Catalog подходит только для интеграции данных, например для импорта небольших объёмов данных из источника в Doris или выполнения запросов с соединением небольших таблиц в источнике JDBC. JDBC Catalog не позволяет ускорять запросы к источнику данных или получать доступ к большим объёмам данных за один раз.

Поддерживаемые базы данных​

Doris JDBC Catalog поддерживает подключение к следующим базам данных:

Поддерживаемые источники данных
MySQL
PostgreSQL
Oracle
SQL Server
IBM DB2
ClickHouse
SAP HANA
Oceanbase

Чтобы добавить поддержку новых источников JDBC, которые пока не поддерживаются, обратитесь к руководству разработчика.

Настройка Catalog​

Синтаксис​

CREATE CATALOG [IF NOT EXISTS] catalog_name PROPERTIES (
'type' = 'jdbc', -- required
{JdbcProperties},
{CommonProperties}
);
  • {JdbcProperties}

    • Обязательные свойства

      Имя параметраОписаниеПример
      userИмя пользователя источника данных
      passwordПароль источника данных
      jdbc_urlURL подключения к источнику данныхjdbc:mysql://host:3306
      driver_urlПуть к файлу драйвера JDBC. Сведения о безопасности пакетов драйверов см. в приложении.Поддерживаются три способа указания пути, см. ниже.
      driver_classИмя класса драйвера JDBC

      driver_url можно задать следующими тремя способами:

      1. Имя файла. Например, mysql-connector-j-8.3.0.jar. Файл Jar необходимо заранее разместить в подкаталоге jdbc_drivers/ каталогов развёртывания FE и BE. Система автоматически выполнит поиск в этом каталоге. Его расположение также можно изменить с помощью параметра jdbc_drivers_dir в fe.conf и be.conf.

      2. Абсолютный локальный путь. Например, file:///path/to/mysql-connector-j-8.3.0.jar. Файл Jar необходимо заранее разместить по указанному пути на всех узлах FE/BE.

      3. HTTP URL. Например: https://repo1.maven.org/maven2/com/mysql/mysql-connector-j/8.3.0/mysql-connector-j-8.3.0.jar. Система загрузит файл драйвера с этого HTTP-адреса. Поддерживаются только HTTP-сервисы без аутентификации.

      Начиная с версии 4.1.5, расположение драйвера без схемы URI должно быть именем файла, соответствующим шаблону [A-Za-z0-9._-]+.jar. Путь после URL-декодирования не должен содержать сегмент родительского каталога ... Эта проверка также применяется к ALTER CATALOG и расположениям драйверов JDBC Catalog для Iceberg и Paimon. Действующие проверки безопасности каталога драйверов и списка разрешённых путей по-прежнему применяются.

    • Необязательные свойства

      Имя параметраЗначение по умолчаниюОписание
      lower_case_meta_namesfalseСинхронизировать ли имена баз данных, таблиц и столбцов из внешнего источника данных в нижнем регистре
      meta_names_mappingЕсли во внешнем источнике данных есть имена, различающиеся только регистром, например MY_TABLE и my_table, Doris сообщит об ошибке из-за неоднозначности при запросе к Catalog. Для разрешения конфликтов необходимо настроить параметр meta_names_mapping.
      only_specified_databasefalseСинхронизировать ли только базу данных, указанную в jdbc_url (эта база данных соответствует уровню базы данных в Doris)
      connection_pool_min_size1Задаёт минимальное количество соединений в пуле. Используется для инициализации пула и поддержания как минимум этого количества активных соединений при включённом механизме keep-alive.
      connection_pool_max_size30Задаёт максимальное количество соединений в пуле. Каждый узел FE или BE может поддерживать до этого количества соединений для каждого Catalog.
      connection_pool_max_wait_time5000Задаёт максимальное время ожидания соединения клиентом в миллисекундах, если в пуле нет доступных соединений.
      connection_pool_max_life_time1800000Задаёт максимальную продолжительность активности соединения в пуле (в миллисекундах). Соединения, превысившие это время, будут закрыты и заменены. Кроме того, половина этого значения используется как минимальное время простоя для удаления из пула: соединения, достигшие этого времени простоя, могут быть удалены.
      connection_pool_keep_alivefalseДействует только на узлах BE и определяет, следует ли поддерживать активными соединения, которые достигли минимального времени простоя для удаления, но ещё не достигли максимального времени существования. По умолчанию отключён, чтобы снизить излишнее потребление ресурсов.
  • [CommonProperties]

    Раздел CommonProperties используется для настройки общих свойств. См. раздел Общие свойства в обзоре Catalog.

Выполнение запросов​

Простой запрос​

-- 1. switch to catalog, use database and query
SWITCH mysql_ctl;
USE mysql_db;
SELECT * FROM mysql_tbl LIMIT 10;

-- 2. use mysql database directly
USE mysql_ctl.mysql_db;
SELECT * FROM mysql_tbl LIMIT 10;

-- 3. use full qualified name to query
SELECT * FROM mysql_ctl.mysql_db.mysql_tbl LIMIT 10;

Оптимизация запросов​

Проталкивание предикатов​

При обращении JDBC Catalog к источнику данных выбирается узел BE, который с помощью JDBC Client отправляет сгенерированный SQL-запрос источнику и получает данные. Поэтому производительность полностью зависит от эффективности выполнения сгенерированного SQL на стороне источника. Doris пытается протолкнуть условия предикатов в источник и включить их в сгенерированный SQL. Для просмотра сгенерированного SQL можно использовать инструкцию EXPLAIN SQL.

EXPLAIN SELECT smallint_u, sum(int_u)
FROM all_types WHERE smallint_u > 10 GROUP BY smallint_u;

...
| 0:VJdbcScanNode(206) |
| TABLE: `doris_test`.`all_types` |
| QUERY: SELECT `smallint_u`, `int_u` FROM `doris_test`.`all_types` WHERE ((`smallint_u` > 10)) |
| PREDICATES: (smallint_u[#1] > 10) |
| final projections: smallint_u[#1], int_u[#3] |
| final project output tuple id: 1
... |

Проталкивание функций​

Семантика или поведение условий предикатов в Doris и внешних источниках данных могут различаться. Поэтому Doris ограничивает и контролирует проталкивание предикатов в запросах к внешним таблицам JDBC с помощью следующих параметров и переменных:

Примечание: в настоящее время Doris поддерживает проталкивание предикатов только для источников данных MySQL, Clickhouse и Oracle. В будущем будет добавлена поддержка других источников данных.

  • enable_jdbc_oracle_null_predicate_push_down

    Переменная сеанса. Значение по умолчанию — false. Это означает, что если условие предиката содержит значение NULL, предикат не будет протолкнут в источник данных Oracle. Причина в том, что до версии 21 Oracle не поддерживает NULL в качестве оператора.

    Этот параметр поддерживается начиная с версий 2.1.7 и 3.0.3.

  • enable_jdbc_cast_predicate_push_down

    Переменная сеанса. Значение по умолчанию — false. Это означает, что при наличии явного или неявного CAST в условии предиката предикат не будет протолкнут в источник данных JDBC. Поскольку поведение CAST различается в разных базах данных, по умолчанию CAST не проталкивается, чтобы обеспечить корректность результатов. Однако пользователи могут вручную проверить, совпадает ли поведение CAST. Если оно совпадает, этот параметр можно установить в true, чтобы разрешить проталкивание большего количества предикатов и повысить производительность.

    Этот параметр поддерживается начиная с версий 2.1.7 и 3.0.3.

  • Списки запрещённых и разрешённых функций для проталкивания

    Функции с одинаковой сигнатурой могут иметь разную семантику в Doris и внешних источниках данных. В Doris предопределены списки запрещённых и разрешённых функций для проталкивания:

    Источник данныхЗапрещённые функцииРазрешённые функцииОписание
    MySQL- DATE_TRUNC
    - MONEY_FORMAT
    - NEGTIVE
    Для MySQL можно также задать дополнительные запрещённые функции с помощью параметра конфигурации FE jdbc_mysql_unsupported_pushdown_functions, например: jdbc_mysql_unsupported_pushdown_functions==func1,func2
    Clickhouse- FROM_UNIXTIME
    - UNIX_TIMESTAMP
    Oracle- NVL
    - IFNULL
  • Правила переписывания функций

    Некоторые функции в Doris и внешних источниках данных имеют одинаковое поведение, но разные имена. Doris поддерживает переписывание таких функций при проталкивании. В настоящее время встроены следующие правила переписывания:

    Источник данныхФункция DorisЦелевая функция
    MySQLnvlifnull
    MySQLto_datedate
    Clickhousefrom_unixtimeFROM_UNIXTIME
    Clickhouseunix_timestamptoUnixTimestamp
    Oracleifnullnvl
  • Пользовательские правила проталкивания и переписывания функций

    В версиях после 3.0.7 Doris поддерживает более гибкие правила проталкивания и переписывания функций. Пользователи могут задавать такие правила для конкретного Catalog в его свойствах:

    create catalog jdbc properties (
    ...
    'function_rules' = '{"pushdown" : {"supported": ["to_date"], "unsupported" : ["abs"]}, "rewrite" : {"to_date" : "date2"}}'
    )

    С помощью function_rules можно задать следующие правила:

    • pushdown

      Задаёт правила проталкивания функций. Массивы supported и unsupported содержат имена функций, которые можно и нельзя проталкивать соответственно. Если функция присутствует в обоих массивах, приоритет имеет supported.

      Doris сначала применяет предопределённые системные списки запрещённых и разрешённых функций, а затем списки, заданные пользователем.

    • rewrite

      Задаёт правила переписывания функций. В приведённом выше примере имя функции to_date будет заменено на date2, после чего функция будет протолкнута в источник.

      Примечание: переписываются только функции, для которых разрешено проталкивание.

Ограничение количества строк​

Если запрос содержит ключевое слово LIMIT, Doris протолкнёт предложение LIMIT в источник данных, чтобы уменьшить объём передаваемых данных. С помощью инструкции EXPLAIN можно проверить, содержит ли сгенерированный SQL предложение LIMIT.

Операции записи​

Doris поддерживает запись данных в соответствующий источник данных по протоколу JDBC.

INSERT INTO mysql_table SELECT * FROM internal.doris_db.doris_tbl;

Прямая передача инструкций​

Сценарии применения​

Doris поддерживает непосредственное выполнение соответствующих инструкций DDL, DML и запросов в источнике данных JDBC с помощью прямой передачи инструкций. Эта функция применима в следующих сценариях:

  • Повышение производительности сложных запросов

    По умолчанию оптимизатор запросов Doris разбирает исходный SQL и по определённым правилам генерирует SQL для отправки в источник данных. Обычно сгенерированный SQL представляет собой простой запрос к одной таблице и не может содержать такие операторы, как агрегация или соединение таблиц. Например, рассмотрим следующий запрос:

    SELECT smallint_u, sum(int_u)
    FROM all_types WHERE smallint_u > 10 GROUP BY smallint_u;

    Итоговый сгенерированный SQL будет выглядеть так:

    SELECT smallint_u, int_u 
    FROM all_types
    WHERE smallint_u > 10;

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

  • Единое управление

    Помимо SQL-запросов, функция прямой передачи инструкций позволяет передавать инструкции DDL и DML. Благодаря этому пользователи могут выполнять операции с базами данных и таблицами источника непосредственно через Doris, например создавать и удалять таблицы или изменять их структуру.

Прямая передача SQL​

SELECT * FROM
QUERY(
'catalog' = 'mysql_catalog',
'query' = 'SELECT smallint_u, sum(int_u) FROM db.all_types WHERE smallint_u > 10 GROUP BY smallint_u;'
);

Табличная функция QUERY принимает два параметра:

  • catalog: имя Catalog, которое должно совпадать с именем нужного Catalog.
  • query: выполняемый запрос, записанный непосредственно с использованием синтаксиса соответствующего источника данных.

Прямая передача DDL и DML​

CALL EXECUTE_STMT("jdbc_catalog", "insert into db1.tbl1 values(1,2), (3, 4)");

CALL EXECUTE_STMT("jdbc_catalog", "delete from db1.tbl1 where k1 = 2");

CALL EXECUTE_STMT("jdbc_catalog", "create table dbl1.tbl2 (k1 int)");

Функция EXECUTE_STMT() принимает два параметра:

  • Первый параметр: имя Catalog. В настоящее время поддерживаются только Catalog типа JDBC.
  • Второй параметр: выполняемая инструкция SQL. В настоящее время поддерживаются только инструкции DDL и DML, которые должны быть записаны с использованием синтаксиса соответствующего источника данных.

Ограничения использования​

При использовании команды CALL EXECUTE_STMT() Doris напрямую отправляет написанную пользователем инструкцию SQL на выполнение в источник данных JDBC, связанный с Catalog. Поэтому для этой операции действуют следующие ограничения:

  • Инструкция SQL должна соответствовать синтаксису соответствующего источника данных. Doris не выполняет синтаксические или семантические проверки.

  • Для имён таблиц, указанных в инструкции SQL, рекомендуется использовать полные имена, например db.tbl. Если база данных не указана, будет использовано имя базы данных из JDBC URL соответствующего JDBC Catalog.

  • Инструкция SQL не может ссылаться на базы данных или таблицы за пределами источника данных JDBC, в том числе на базы данных или таблицы Doris. Однако она может ссылаться на таблицы в источнике данных JDBC, которые не синхронизированы с JDBC Catalog в Doris.

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

  • Только пользователи с разрешением LOAD для Catalog могут выполнять команду CALL EXECUTE_STMT().

  • Только пользователи с разрешением SELECT для Catalog могут выполнять табличную функцию query().

  • Пользователь JDBC, указанный при создании Catalog, должен иметь необходимые разрешения в источнике данных для выполнения соответствующих инструкций.

  • Типы данных результатов, считываемых табличной функцией query(), соответствуют типам данных, поддерживаемым типом Catalog, к которому выполняется запрос.

Приложение​

Настройки чувствительности к регистру​

По умолчанию имена баз данных и таблиц в Doris чувствительны к регистру, а имена столбцов — нет. Это поведение можно изменить с помощью параметров конфигурации. Кроме того, правила чувствительности к регистру для имён баз данных, таблиц и столбцов в некоторых источниках данных JDBC могут отличаться от правил Doris. Такое различие может вызывать конфликты имён при их сопоставлении через JDBC Catalog. Далее объясняется, как решать подобные проблемы.

Отображаемое имя и имя для запросов​

В Doris имя объекта (здесь в качестве примера используются имена таблиц) можно разделить на отображаемое имя и имя для запросов. Для таблицы отображаемое имя — это имя, выводимое в результате SHOW TABLES, а имя для запросов — имя, которое можно использовать в инструкции SELECT.

Например, если фактическое имя таблицы — MyTable, её отображаемое имя и имя для запросов могут различаться в зависимости от настройки параметра Frontend (FE) lower_case_table_names:

НастройкаОписаниеФактическое имяОтображаемое имяИмя для запросов
lower_case_table_names=0Настройка по умолчанию. Исходное имя сохраняется и отображается без изменений, а запросы чувствительны к регистру.MyTableMyTableЗапросы чувствительны к регистру, необходимо использовать: MyTable
lower_case_table_names=1Имя сохраняется и отображается в нижнем регистре, а запросы нечувствительны к регистру.MyTablemytableЗапросы нечувствительны к регистру, например можно использовать MyTable или mytable.
lower_case_table_names=2Исходное имя сохраняется и отображается без изменений, но запросы нечувствительны к регистру.MyTableMyTableЗапросы нечувствительны к регистру, например можно использовать MyTable или mytable.

Правила чувствительности имён к регистру в JDBC Catalog​

Сам Doris позволяет настраивать правила чувствительности к регистру только для имён таблиц. Однако JDBC Catalog требует дополнительной обработки имён баз данных и имён столбцов. Поэтому используется дополнительное свойство Catalog, lower_case_meta_names, совместно с lower_case_table_names.

НастройкаОписание
lower_case_meta_namesЗадаётся через properties при создании Catalog и действует только для этого Catalog. Значение по умолчанию — false. При значении true Doris преобразует все имена баз данных, таблиц и столбцов в нижний регистр для хранения и отображения. В запросах к Doris необходимо использовать имена в нижнем регистре.
lower_case_table_namesПараметр конфигурации Frontend (FE), который задаётся в fe.conf и действует для всего кластера. Значение по умолчанию — 0.

Примечание: если lower_case_meta_names = true, настройка lower_case_table_names игнорируется, а все имена баз данных, таблиц и столбцов преобразуются в нижний регистр.

В следующей таблице показано поведение имён баз данных, таблиц и столбцов при хранении и выполнении запросов для различных сочетаний lower_case_meta_names (true/false) и lower_case_table_names (0/1/2). «Исходный регистр» означает сохранение регистра из внешнего источника данных, «Нижний регистр» — автоматическое преобразование в нижний регистр, а «Любой регистр» — возможность использовать в запросах любой регистр:

lower_case_table_names & lower_case_meta_namesОтображаемое имя базы данныхОтображаемое имя таблицыОтображаемое имя столбцаИмя базы данных для запросовИмя таблицы для запросовИмя столбца для запросов
0 & falseИсходный регистрИсходный регистрИсходный регистрИсходный регистрИсходный регистрЛюбой регистр
0 & trueНижний регистрНижний регистрНижний регистрНижний регистрНижний регистрЛюбой регистр
1 & falseИсходный регистрНижний регистрИсходный регистрИсходный регистрЛюбой регистрЛюбой регистр
1 & trueНижний регистрНижний регистрНижний регистрНижний регистрЛюбой регистрЛюбой регистр
2 & falseИсходный регистрИсходный регистрИсходный регистрИсходный регистрЛюбой регистрЛюбой регистр
2 & trueНижний регистрНижний регистрНижний регистрНижний регистрЛюбой регистрЛюбой регистр

Проверка конфликтов регистра​

При сопоставлении имён через JDBC Catalog могут возникать конфликты. Например, если имена столбцов в источнике чувствительны к регистру и существуют два столбца, ID и id, то при настройке lower_case_meta_names = true после преобразования в нижний регистр их имена будут конфликтовать. Doris проверяет конфликты по следующим правилам:

  • В любом сценарии Doris проверяет конфликты регистра имён столбцов (например, существуют ли одновременно id и ID).

  • При lower_case_meta_names = true Doris проверяет конфликты регистра в именах баз данных, таблиц и столбцов (например, существуют ли одновременно DORIS и doris).

  • При lower_case_meta_names = false, если lower_case_table_names установлен в 1 или 2, Doris проверяет конфликты имён таблиц (например, существуют ли одновременно orders и ORDERS).

  • При lower_case_table_names = 0 имена баз данных и таблиц чувствительны к регистру и дополнительное преобразование не требуется.

Разрешение конфликтов регистра​

При возникновении конфликтов Doris выдаёт ошибку. Для их разрешения необходимо использовать следующий подход.

Если базы данных, таблицы или столбцы с именами, различающимися только регистром (например, DORIS и doris), не позволяют Doris корректно различать их, конфликт можно разрешить, задав для Catalog свойство meta_names_mapping с ручными сопоставлениями.

Примеры

{
"databases": [
{
"remoteDatabase": "DORIS",
"mapping": "doris_1"
},
{
"remoteDatabase": "doris",
"mapping": "doris_2"
}
],
"tables": [
{
"remoteDatabase": "DORIS",
"remoteTable": "DORIS",
"mapping": "doris_1"
},
{
"remoteDatabase": "DORIS",
"remoteTable": "doris",
"mapping": "doris_2"
}
],
"columns": [
{
"remoteDatabase": "DORIS",
"remoteTable": "DORIS",
"remoteColumn": "DORIS",
"mapping": "doris_1"
},
{
"remoteDatabase": "DORIS",
"remoteTable": "DORIS",
"remoteColumn": "doris",
"mapping": "doris_2"
}
]
}

Безопасность пакетов драйверов​

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

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

  2. Если пакет драйвера указан с помощью локального пути или HTTP-пути, Doris выполняет следующие проверки:

    • Допустимые пути к пакетам драйверов определяются параметром конфигурации FE jdbc_driver_secure_path. В этой настройке можно указать несколько путей, разделённых точками с запятой. Если настройка задана, Doris проверяет, входит ли префикс пути driver_url в jdbc_driver_secure_path. Если не входит, создание будет отклонено.

      Пример:

      Если настроено jdbc_driver_secure_path = "file:///path/to/jdbc_drivers;http://path/to/jdbc_drivers", разрешены только пути к пакетам драйверов, начинающиеся с file:///path/to/jdbc_drivers или http://path/to/jdbc_drivers.

    • Значение этого параметра по умолчанию — *. Если он пуст или установлен в *, разрешены все пути к пакетам Jar.

  3. При создании каталога данных можно указать контрольную сумму пакета драйвера с помощью параметра checksum. После загрузки пакета драйвера Doris проверит контрольную сумму. Если проверка завершится неудачно, создание будет отклонено.

Очистка пулов соединений​

В Doris каждый узел FE и BE поддерживает пул соединений, чтобы избежать частого открытия и закрытия отдельных соединений с источниками данных. Каждое соединение в пуле может использоваться для подключения к источнику данных и выполнения запросов. После завершения задачи соединения возвращаются в пул для повторного использования. Это повышает производительность, сокращает системные накладные расходы на установление соединений и помогает избежать достижения лимита соединений источника данных.

Размер пула соединений можно настроить в соответствии с фактическими потребностями, чтобы лучше адаптироваться к различным рабочим нагрузкам. Как правило, минимальное количество соединений в пуле следует установить в 1, чтобы при включённом механизме keep-alive хотя бы одно соединение оставалось активным. Для максимального количества соединений следует выбрать разумное значение, чтобы избежать чрезмерного потребления ресурсов.

Чтобы предотвратить накопление неиспользуемых кешей пулов соединений на BE, можно задать параметр jdbc_connection_pool_cache_clear_time_sec на BE, указав интервал очистки кеша. Значение по умолчанию — 28,800 секунд (8 часов), по истечении которых BE принудительно очистит все кеши пулов соединений, которые не использовались в течение этого времени.

Обновление учётных данных​

При подключении к внешним источникам данных через JDBC Catalog необходимо внимательно подходить к обновлению учётных данных базы данных.

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

При необходимости сменить учётные данные рекомендуется одновременно обновить конфигурацию JDBC Catalog в Doris и перезапустить кластер Doris, чтобы все узлы использовали актуальные учётные данные. Это позволит предотвратить ошибки подключения и возможную блокировку учётных записей.

Возможные сообщения о блокировке учётной записи:

MySQL: account is locked

Oracle: ORA-28000: the account is locked

SQL Server: Login is locked out

Устранение неполадок пула соединений​

  1. Ошибка тайм-аута соединения HikariPool: Connection is not available, request timed out after 5000ms

    • Возможные причины

      • Причина 1: проблемы с сетью (например, сервер недоступен)

      • Причина 2: проблемы аутентификации, например неверное имя пользователя или пароль

      • Причина 3: высокая сетевая задержка, из-за которой создание соединения превышает тайм-аут в 5 секунд

      • Причина 4: слишком большое количество одновременных запросов, превышающее максимальное количество соединений, настроенное в пуле

    • Решения

      • Если возникает только ошибка Connection is not available, request timed out after 5000ms, проверьте причины 3 и 4:

        • Проверьте, нет ли высокой сетевой задержки или нехватки ресурсов.

        • Увеличьте максимальное количество соединений в пуле:

          ALTER CATALOG catalog_name SET PROPERTIES ('connection_pool_max_size' = '100');
        • Увеличьте тайм-аут ожидания соединения:

          ALTER CATALOG catalog_name SET PROPERTIES ('connection_pool_max_wait_time' = '10000');
      • Если помимо Connection is not available, request timed out after 5000ms появляются другие сообщения об ошибках, проверьте их:

        • Проблемы с сетью (например, недоступность сервера) могут приводить к сбоям подключения. Убедитесь, что сетевое соединение стабильно.

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

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