Важно: Данный раздел актуален для Платформы данных On-Premise.
В СУБД RT.Warehouse инстансы серверов базы данных (мастер и все сегменты) запускаются или останавливаются на всех хостах в системе таким образом, что они могут работать вместе как единая СУБД.
Поскольку система RT.Warehouse распределена по множеству машин, процесс запуска и остановки системы RT.Warehouse отличается от процесса запуска и остановки обычной СУБД PostgreSQL.
Используйте утилиты gpstart и gpstop для запуска и остановки RT.Warehouse соответственно. Эти утилиты находятся в каталоге $GPHOME/bin на хосте мастера RT.Warehouse.
|
Внимание. Не используйте команду kill для завершения любого процесса Postgres. Вместо этого используйте команду базы данных pg_cancel_backend(). Выполнение kill -9 или kill -11 может привести к повреждению базы данных и помешать выполнению анализа первопричин. |
Для получения информации о gpstart и gpstop см. Справочник по утилитам.
Запустите инициализированную систему RT.Warehouse, запустив утилиту gpstart на инстансе мастера.
Используйте утилиту gpstart для запуска системы RT.Warehouse, которая уже была инициализирована утилитой gpinitsystem, но остановлена утилитой gpstop. Утилита gpstart запускает RT.Warehouse, запустив все инстансы базы данных Postgres в кластере RT.Warehouse. gpstart управляет этим процессом и выполняет его параллельно.
Запустите gpstart на хосте мастера, чтобы запустить RT.Warehouse:
| $ gpstart |
Остановите систему RT.Warehouse, а затем перезапустите её.
Утилита gpstop с параметром -r может остановить, а затем перезапустить RT.Warehouse после завершения работы.
Чтобы перезапустить RT.Warehouse, введите следующую команду на хосте мастера:
$ gpstop -rПовторно загрузите изменения в файлы конфигурации RT.Warehouse, не прерывая работу системы.
Утилита gpstop может перезагружать изменения в файл конфигурации pg_hba.conf и параметры времени выполнения в файле мастера postgresql.conf и файле pg_hba.conf без прерывания обслуживания. Активные сеансы принимают изменения при повторном подключении к базе данных. Многие параметры конфигурации сервера требуют полной перезагрузки системы (gpstop -r) для активации.
Перезагрузите изменения файла конфигурации, не выключая систему, с помощью утилиты gpstop:
$ gpstop -uЗапустите только мастер для выполнения задач обслуживания или администрирования, не затрагивая данные в сегментах.
Например, вы можете подключиться к базе данных только на инстансе мастера в режиме обслуживания и редактировать настройки системного каталога.
1. Запустите gpstart с параметром -m:
$ gpstart -m2. Подключитесь к мастеру в режиме обслуживания для обслуживания каталога. Например:
$ PGOPTIONS='-c gp_session_role=utility' psql postgres3. После завершения административных задач остановите мастер в режиме утилит. Затем перезапустите его в производственном режиме.
$ gpstop -mr
|
Внимание. Неправильное использование подключений в режиме обслуживания может привести к несогласованному состоянию системы. |
Утилита gpstop останавливает или перезапускает вашу систему RT.Warehouse и всегда запускается на хосте мастера. При активации gpstop останавливает все процессы postgres в системе, включая мастер и все инстансы сегментов. Утилита gpstop по умолчанию использует до 64 параллельных рабочих потоков для остановки инстансов Postgres, составляющих кластер RT.Warehouse. Перед завершением работы система ожидает завершения всех активных транзакций. Чтобы немедленно остановить RT.Warehouse, используйте режим fast.
Чтобы остановить RT.Warehouse:
$ gpstopЧтобы остановить RT.Warehouse в режиме fast:
$ gpstop -M fastПо умолчанию вам не разрешено останавливать RT.Warehouse, если есть какие-либо клиентские подключения к базе данных. Используйте параметр -M fast, чтобы откатить все выполняющиеся транзакции и разорвать все соединения перед завершением работы.
RT.Warehouse запускает новый внутренний процесс для каждого клиентского подключения. Пользователь RT.Warehouse с привилегиями superuser может отменить и завершить эти клиентские внутренние процессы.
Отмена внутреннего процесса с помощью функции pg_cancel_backend() завершает конкретный поставленный в очередь или активный клиентский запрос. Завершение внутреннего процесса с помощью функции pg_terminate_backend() завершает клиентское соединение с базой данных.
Функция pg_cancel_backend() имеет две сигнатуры:
Функция pg_terminate_backend() имеет две похожие сигнатуры:
Если вы предоставите msg, RT.Warehouse включает текст в сообщения об отмене, который возвращается клиенту. msg ограничен 128 байтами. RT.Warehouse обрезает всё, что больше.
Функции pg_cancel_backend() и pg_terminate_backend() возвращают true в случае успеха и false в ином случае.
Чтобы отменить или завершить серверный процесс, вы должны сначала определить идентификатор процесса серверной части. Вы можете получить идентификатор процесса из столбца pid представления pg_stat_activity. Например, чтобы просмотреть информацию о процессе, связанную со всеми запущенными запросами и запросами в очереди:
=# SELECT usename, pid, waiting, state, query, datname
FROM pg_stat_activity;Пример частичного вывода запроса:
usename | pid | waiting | state | query | datname
---------+----------+---------+--------+------------------------+---------
sammy | 31861 | f | idle | SELECT * FROM testtbl; | testdb
billy | 31905 | t | active | SELECT * FROM topten; | testdbИспользуйте выходные данные для определения идентификатора процесса (pid) запроса или клиентского соединения.
Например, чтобы отменить ожидающий запрос, указанный в приведённом выше примере выходных данных, и включить 'Admin canceled long-running query.' в качестве возвращаемого сообщения клиенту:
=# SELECT pg_cancel_backend(31905 ,'Admin canceled long-running query.');
ERROR: canceling statement due to user request: "Admin canceled long-running query."В этом разделе описываются различные клиентские инструменты, которые вы можете использовать для подключения к RT.Warehouse, а как установить подключение.
Пользователи могут подключаться к RT.Warehouse с помощью клиентской программы, совместимой с PostgreSQL, например psql. Пользователи и администраторы всегда подключаются к RT.Warehouse через машину мастера, сегменты не могут принимать клиентские соединения.
Чтобы установить соединение с сервером мастера RT.Warehouse, вам необходимо знать следующую информацию о подключении и соответствующим образом настроить клиентскую программу.
Таблица 1— Параметры подключения
|
Параметр подключения |
Описание |
Переменная окружения |
|---|---|---|
| Имя приложения | Имя приложения, которое подключается к базе данных. Значение по умолчанию, содержащееся в параметре подключения application_name, —psql. | $PGAPPNAME |
| Имя базы данных | Имя базы данных, к которой вы хотите подключиться. Для вновь инициализированной системы используйте базу данных postgres для первого подключения. | $PGDATABASE |
| Имя хоста | Имя хоста сервера мастера RT.Warehouse. Хост по умолчанию — это локальный хост. | $PGHOST |
| Порт | Номер порта, на котором работает инстанс мастера RT.Warehouse. По умолчанию 5432. | $PGPORT |
| Имя пользователя | Имя пользователя (роли) базы данных для подключения. Это не обязательно имя пользователя вашей ОС. Если вы не уверены, какое имя пользователя базы данных у вас, обратитесь к администратору RT.Warehouse. Обратите внимание, что каждая система RT.Warehouse имеет одну учётную запись суперпользователя, которая создается автоматически во время инициализации. Эта учётная запись имеет то же имя, что и имя пользователя ОС, инициализировавшего систему RT.Warehouse (обычно gpadmin). | $PGUSER |
Пользователи могут подключаться к RT.Warehouse с помощью различных клиентских приложений:
RT.Warehouse поставляется с установленным рядом клиентских служебных приложений, расположенных в каталоге $GPHOME/bin вашей установки хоста мастера RT.Warehouse. Ниже приведены наиболее часто используемые клиентские служебные приложения:
Таблица 2— Часто используемые клиентские приложения
|
Имя |
Использование |
|---|---|
| createdb | Создание новой базы данных. |
| createlang | Определение нового процедурного языка. |
| createuser | Определение новуой роли базы данных. |
| dropdb | Удаление базы данных. |
| droplang | Удаление процедурного языка. |
| dropuser | Удаление роли. |
| psql | Интерактивный терминал PostgreSQL. |
| reindexdb | Переиндексация базы данных. |
| vacuumdb | Сбор мусора и анализ базы данных. |
|
Примечание. createlang и droplang устарели и могут быть удалены в будущем выпуске. |
При использовании этих клиентских приложений вы должны подключиться к базе данных через инстанс мастера RT.Warehouse. Вам нужно будет знать имя вашей целевой базы данных, имя хоста и номер порта мастера, а также имя пользователя базы данных для подключения. Эта информация может быть предоставлена в командной строке с помощью параметров -d, -h, -p и-U соответственно. Если найден аргумент, не принадлежащий ни одному параметру, он будет сначала интерпретирован как имя базы данных.
Все эти параметры имеют значения по умолчанию, которые будут использоваться, если параметр не указан. Хост по умолчанию — это локальный хост. Номер порта по умолчанию — 5432. Имя пользователя по умолчанию — это имя пользователя вашей ОС, как и имя базы данных по умолчанию. Обратите внимание, что имена пользователей ОС и имена пользователей RT.Warehouse не обязательно совпадают.
Если значения по умолчанию неверны, вы можете установить для переменных окружения PGDATABASE, PGHOST, PGPORT и PGUSER соответствующие значения или использовать файл psql ~/.pgpass для хранения часто используемых паролей.
В зависимости от используемых значений по умолчанию или установленных вами переменных окружения следующие примеры показывают, как получить доступ к базе данных через psql:
$ psql -d gpdatabase -h master_host -p 5432 -U gpadmin
$ psql gpdatabase
$ psqlЕсли пользовательская база данных ещё не создана, вы можете получить доступ к системе, подключившись к базе данных postgres. Например:
$ psql postgresПосле подключения к базе данных psql отображает подсказку с именем базы данных, к которой в настоящее время подключён psql, за которым следует строка => (или =#, если вы являетесь суперпользователем базы данных). Например:
gpdatabase =>В командной строке вы можете ввести команды SQL. Команда SQL должна заканчиваться на ; (точка с запятой) для отправки на сервер и выполнения. Например:
=> SELECT * FROM mytable;Утилита PgBouncer управляет пулами соединений для соединений PostgreSQL и RT.Warehouse.
В следующих разделах описывается, как настроить и использовать PgBouncer с RT.Warehouse. Обратитесь к веб-сайту PgBouncer для получения информации об использовании PgBouncer с PostgreSQL.
Пул соединений с базой данных — это кэш соединений с базой данных. После того, как пул подключений создан, пул подключений минимизирует издержки на создание новых подключений к базе данных, поэтому клиенты подключаются намного быстрее и нагрузка на сервер снижается.
PgBouncer — это лёгкий менеджер пула соединений для RT.Warehouse и PostgreSQL. PgBouncer поддерживает пул соединений для каждой комбинации базы данных и пользователя. PgBouncer либо создаёт новое соединение с базой данных для клиента, либо повторно использует существующее соединение для того же пользователя и базы данных. Когда клиент отключается, PgBouncer возвращает соединение в пул для повторного использования.
PgBouncer разделяет соединения в одном из трёх режимов пула:
Вы можете установить режим пула по умолчанию для инстанса PgBouncer. Вы можете переопределить этот режим для отдельных баз данных и пользователей.
PgBouncer поддерживает стандартный интерфейс подключения, используемый PostgreSQL и RT.Warehouse. Клиентское приложение RT.Warehouse (например, psql) подключается к хосту и порту, на котором работает PgBouncer, а не к хосту и порту мастера RT.Warehouse.
PgBouncer включает консоль администрирования, подобную psql. Авторизованные пользователи могут подключаться к виртуальной базе данных для мониторинга и управления PgBouncer. Вы можете управлять процессом демона PgBouncer через консоль администратора. Вы также можете использовать консоль для обновления и перезагрузки конфигурации PgBouncer во время выполнения без остановки и перезапуска процесса.
PgBouncer изначально поддерживает TLS.
При переходе на новую версию RT.Warehouse необходимо перенести свой инстанс PgBouncer на инстанс в новой установке RT.Warehouse.
1. Если вы переходите на версию RT.Warehouse 5.8.x или более раннюю, вы можете выполнить миграцию PgBouncer, не разрывая соединения. Запустите новый процесс PgBouncer с параметром -R и файлом конфигурации, с которого вы запустили процесс:
$ pgbouncer -R -d pgbouncer.iniПараметр -R (reboot) заставляет новый процесс подключаться к консоли старого процесса через сокет Unix и выполнять следующие команды:
SUSPEND;
SHOW FDS;
SHUTDOWN;Когда новый процесс обнаруживает, что старый процесс завершён он возобновляет работу со старыми соединениями. Это возможно, потому что команда SHOW FDS отправляет фактические файловые дескрипторы новому процессу. Если переход не удастся по какой-либо причине, завершите новый процесс, и старый процесс возобновится.
2. Если вы переходите на RT.Warehouse версии 5.9.0 или новее, вы должны закрыть инстанс PgBouncer в своей старой установке и перенастроить и перезапустить PgBouncer в новой установке.
3. Если вы использовали stunnel для защиты соединений PgBouncer в своей старой установке, вы должны настроить SSL/TLS в новой установке, используя встроенные возможности TLS в PgBouncer 1.8.1 и более поздних версиях.
4. Если вы использовали аутентификацию LDAP в своей старой установке, вы должны настроить LDAP в новой установке, используя встроенные возможности интеграции PAM в PgBouncer 1.8.1 и более поздних версиях. Вы также должны удалить или заменить все строки пароля с префиксом ldap:// в auth_file.
Вы настраиваете PgBouncer и его доступ к RT.Warehouse через файл конфигурации. Этот файл конфигурации, обычно называемый pgbouncer.ini, предоставляет информацию о расположении баз данных RT.Warehouse. Файл pgbouncer.ini также определяет процесс, пул соединений, авторизованных пользователей и конфигурацию аутентификации для PgBouncer.
Пример содержимого файла pgbouncer.ini:
[databases]
postgres = host=127.0.0.1 port=5432 dbname=postgres
pgb_mydb = host=127.0.0.1 port=5432 dbname=mydb
[pgbouncer]
pool_mode = session
listen_port = 6543
listen_addr = 127.0.0.1
auth_type = md5
auth_file = users.txt
logfile = pgbouncer.log
pidfile = pgbouncer.pid
admin_users = gpadminСм. pgbouncer.ini для получения информации о формате файла конфигурации PgBouncer и списке свойств конфигурации, которые он поддерживает.
Когда клиент подключается к PgBouncer, пул соединений ищет конфигурацию для запрошенной базы данных (которая может быть псевдонимом для фактической базы данных), которая была указана в файле конфигурации pgbouncer.ini, чтобы найти имя хоста, порт и базу данных. имя для подключения к базе данных. Файл конфигурации также определяет режим аутентификации, действующий для базы данных.
PgBouncer требует файл аутентификации — текстовый файл, содержащий список пользователей и пароли RT.Warehouse. Содержимое файла зависит от auth_type, который вы настраиваете в файле pgbouncer.ini. Пароли могут быть в виде открытого текста или строк в кодировке MD5. Вы также можете настроить PgBouncer для запроса целевой базы данных для получения информации о паролях для пользователей, которых нет в файле аутентификации.
PgBouncer требует собственного файла аутентификации пользователя. Вы указываете имя этого файла в свойстве auth_file конфигурационного файла pgbouncer.ini. auth_file — это текстовый файл следующего формата:
"username1" "password" ...
"username2" "md5abcdef012342345" ...auth_file содержит по одной строке для каждого пользователя. Каждая строка должна иметь как минимум два поля, каждое из которых заключено в двойные кавычки (""). Первое поле определяет имя пользователя RT.Warehouse. Второе поле — это либо обычный текст, либо пароль в кодировке MD5. PgBouncer игнорирует оставшуюся часть строки.
Формат auth_file аналогичен формату текстового файла pg_auth, который RT.Warehouse использует для информации об аутентификации. PgBouncer может работать напрямую с этим файлом аутентификации RT.Warehouse.
Используйте пароль в кодировке MD5. Формат пароля в кодировке MD5:
"md5" + MD5_encoded(<password><username>)Вы также можете получить пароли в кодировке MD5 всех пользователей RT.Warehouse из представления pg_shadow.
PgBouncer поддерживает аутентификацию на основе HBA. Чтобы настроить аутентификацию на основе HBA для PgBouncer, установите auth_type=hba в файле конфигурации pgbouncer.ini. Также укажите имя файла формата HBA в параметре auth_hba_file файла pgbouncer.ini.
Пример содержимого файла HBA PgBouncer с именем hba_bouncer.conf:
local all bouncer trust
host all bouncer 127.0.0.1/32 trustПример отрывка из связанного файла конфигурации pgbouncer.ini:
[databases]
p0 = port=15432 host=127.0.0.1 dbname=p0 user=bouncer pool_size=2
p1 = port=15432 host=127.0.0.1 dbname=p1 user=bouncer
...
[pgbouncer]
...
auth_type = hba
auth_file = userlist.txt
auth_hba_file = hba_bouncer.conf
...Обратитесь к обсуждению формата файла HBA в документации PgBouncer для получения информации о поддержке PgBouncer формата файла аутентификации HBA.
Вы можете запустить PgBouncer на сервере мастера RT.Warehouse или на другом сервере. Если вы устанавливаете PgBouncer на отдельный сервер, вы можете легко переключить клиентов на резервный мастер, обновив файл конфигурации PgBouncer и перезагрузив конфигурацию с помощью консоли администрирования PgBouncer.
Выполните следующие действия, чтобы настроить PgBouncer:
[databases]
postgres = host=127.0.0.1 port=5432 dbname=postgres
pgb_mydb = host=127.0.0.1 port=5432 dbname=mydb
[pgbouncer]
pool_mode = session
listen_port = 6543
listen_addr = 127.0.0.1
auth_type = md5
auth_file = users.txt
logfile = pgbouncer.log
pidfile = pgbouncer.pid
admin_users = gpadminВ файле перечислите базы данных и детали их подключения. Файл также настраивает инстанс PgBouncer. См. pgbouncer.ini для получения информации о формате и содержимом файла конфигурации PgBouncer.
2. Создайте файл аутентификации. Имя файла должно быть именем, указанным вами для параметра auth_file файла pgbouncer.ini — users.txt. Каждая строка содержит имя пользователя и пароль. Формат строки пароля соответствует auth_type, который вы настроили в файле конфигурации PgBouncer. Если параметр auth_type является plain, строка пароля представляет собой открытый текстовый пароль, например:
"gpadmin" "gpadmin1234"Если auth_type как в примере — md5, поле аутентификации должно быть закодировано MD5. Формат пароля в кодировке MD5:
"md5" + MD5_encoded(<password><username>)3. Запустите pgbouncer:
$ $GPHOME/bin/pgbouncer -d pgbouncer.iniПараметр -d запускает PgBouncer как фоновый (демон) процесс. См. pgbouncer, чтобы узнать о синтаксисе и параметрах команды pgbouncer.
4. Обновите клиентские приложения для подключения к pgbouncer, а не напрямую к серверу RT.Warehouse. Например, чтобы подключиться к настроенной выше RT.Warehouse с именем mydb, запустите psql следующим образом:
$ psql -p 6543 -U someuser pgb_mydbЗначение параметра -p — это порт прослушивания, который вы настроили для инстанса PgBouncer.
PgBouncer предоставляет консоль администрирования, подобную psql. Войдите в консоль администрирования PgBouncer, указав номер порта PgBouncer и виртуальную базу данных с именем pgbouncer. Консоль принимает команды, подобные SQL, которые можно использовать для мониторинга, перенастройки и управления PgBouncer.
Полную документацию по командам консоли администрирования PgBouncer см. в pgbouncer-admin.
Выполните следующие действия, чтобы начать работу с консолью администрирования PgBouncer.
1. С помощью psql войдите в виртуальную базу данных pgbouncer:
$ psql -p 6543 -U username pgbouncerУказанное вами имя пользователя должно быть указано в параметре admin_users в файле конфигурации pgbouncer.ini. Вы также можете войти в консоль администрирования PgBouncer с текущим именем пользователя Unix, если процесс pgbouncer выполняется под UID этого пользователя.
2. Чтобы просмотреть доступные команды консоли администрирования PgBouncer, запустите команду SHOW help:
pgbouncer=# SHOW help;
NOTICE: Console usage
DETAIL:
SHOW HELP|CONFIG|DATABASES|POOLS|CLIENTS|SERVERS|VERSION
SHOW FDS|SOCKETS|ACTIVE_SOCKETS|LISTS|MEM
SHOW DNS_HOSTS|DNS_ZONES
SHOW STATS|STATS_TOTALS|STATS_AVERAGES
SET key = arg
RELOAD
PAUSE [<db>]
RESUME [<db>]
DISABLE <db>
ENABLE <db>
KILL <db>
SUSPEND
SHUTDOWN3. Если вы обновляете конфигурацию PgBouncer, редактируя файл конфигурации pgbouncer.ini, используйте команду RELOAD для перезагрузки файла:
pgbouncer=# RELOAD;Чтобы сопоставить клиент PgBouncer с подключением к серверу RT.Warehouse, используйте команды консоли администрирования PgBouncer SHOW CLIENTS и SHOW SERVERS:
Возможно, вы захотите разработать свои собственные клиентские приложения, которые будут взаимодействовать с RT.Warehouse. PostgreSQL предоставляет ряд драйверов баз данных для наиболее часто используемых API баз данных, которые также можно использовать с RT.Warehouse. Эти драйверы доступны для отдельной загрузки. Каждый драйвер (кроме libpq, который поставляется с PostgreSQL) является независимым проектом разработки PostgreSQL и должен быть загружен, установлен и настроен для подключения к RT.Warehouse. Доступны драйверы, представленные в таблице.
Таблица 3— Интерфейсы RT.Warehouse
|
API |
Драйвер PostgreSQL |
Ссылка для загрузки драйвера |
|---|---|---|
| ODBC | psqlODBC | https://odbc.postgresql.org/ |
| JDBC | pgjdbc | https://jdbc.postgresql.org/ |
| Perl DBI | pgperl | https://metacpan.org/release/DBD-Pg |
| Python DBI | pygresql | http://www.pygresql.org/ |
| libpq C Library | libpq | https://www.postgresql.org/docs/9.4/libpq.html |
Загрузите платформу языка программирования и соответствующий API из соответствующего источника. Например, вы можете получить Java Development Kit (JDK) и JDBC API от Oracle.
Напишите свое клиентское приложение в соответствии со спецификациями API. При программировании приложения помните о поддержке SQL в RT.Warehouse, не включайте неподдерживаемый синтаксис SQL.
Загрузите соответствующий драйвер и настройте подключение к инстансу мастера RT.Warehouse.
Ряд вещей может помешать успешному подключению клиентского приложения к RT.Warehouse. В этом разделе объясняются некоторые из распространённых причин проблем с подключением и способы их устранения.
Таблица 4— Общие проблемы с подключением
|
Проблема |
Решение |
|---|---|
| Отсутствует запись в pg_hba.conf для хоста или пользователя | Чтобы RT.Warehouse могла принимать удалённые клиентские подключения, необходимо настроить гинстанс мастера RT.Warehouse таким образом, чтобы разрешались подключения от клиентских хостов и пользователей базы данных, которые будут подключаться к RT.Warehouse. Это делается путём добавления соответствующих записей в файл конфигурации pg_hba.conf (расположенный в каталоге данных инстанса мастера). |
| RT.Warehouse не работает | Если инстанс мастера RT.Warehouse не работает, пользователи не смогут подключиться. Вы можете проверить, что система RT.Warehouse запущена, запустив утилиту gpstate на хосте мастера RT.Warehouse. |
| Проблемы с сетью, таймауты интерконнекта |
Если пользователи подключаются к хосту мастера RT.Warehouse с удалённого клиента, сетевые проблемы могут помешать подключению (например, проблемы с разрешением имени хоста DNS, хост-система не работает и т.д.). Чтобы убедиться, что сетевые проблемы не являются причиной, подключитесь к хосту мастера RT.Warehouse с удалённого клиентского хоста. Например: ping hostname. Если система не может разрешить имена хостов и IP-адреса хостов, задействованных в RT.Warehouse, запросы и соединения не будут выполнены. Для некоторых операций соединения с мастером RT.Warehouse используют localhost, а другие используют фактическое имя хоста, поэтому вы должны иметь возможность разрешить оба. Если вы столкнулись с этой ошибкой, сначала убедитесь, что вы можете подключиться к каждому хосту в массиве RT.Warehouse с хоста мастера по сети. Убедитесь, что в файле /etc/hosts мастера и всех сегментов указаны правильные имена хостов и IP-адреса для всех хостов, входящих в массив RT.Warehouse. IP-адрес 127.0.0.1 должен разрешаться в localhost. |
| Слишком много клиентов | По умолчанию RT.Warehouse настроена так, чтобы разрешить до 250 одновременных подключений пользователей к мастеру и 750 к сегменту. Попытка подключения, которая приводит к превышению этого лимита, будет отклонена. Этот предел контролируется параметром max_connections в файле конфигурации postgresql.conf сервера мастера RT.Warehouse. Если вы измените этот параметр для мастера, вы также должны внести соответствующие изменения в сегменты. |
Параметры конфигурации сервера влияют на поведение базы данных RT.Warehouse. Они являются частью системы «Grand Unified Configuration» PostgreSQL, поэтому их иногда называют «GUC». Большинство параметров конфигурации сервера базы данных RT.Warehouse совпадают с параметрами конфигурации PostgreSQL, но некоторые из них специфичны для RT.Warehouse.
Файлы конфигурации сервера содержат параметры, которые настраивают поведение сервера. Файл конфигурации базы данных RT.Warehouse, postgresql.conf, находится в каталоге данных инстанса базы данных.
Мастер и каждый инстанс сегмента имеют свой собственный файл postgresql.conf. Некоторые параметры являются локальными: каждый инстанс сегмента проверяет свой файл postgresql.conf, чтобы получить значение этого параметра. Установите локальные параметры на мастере и на каждом инстансе сегмента.
Другие параметры являются параметрами мастера, которые вы задаёте для инстанса мастера. Значение передаётся (или в некоторых случаях игнорируется) инстансами сегмента во время выполнения запроса.
Многие параметры конфигурации ограничивают круг лиц, которые могут их изменять, а также место и время их установки. Например, чтобы изменить определённые параметры, вы должны быть суперпользователем базы данных RT.Warehouse. Другие параметры могут быть установлены только на системном уровне в файле postgresql.conf или требуют перезагрузки системы для вступления в силу.
Многие параметры конфигурации являются параметрами сеанса. Вы можете установить параметры сеанса на уровне системы, на уровне базы данных, на уровне роли или на уровне сеанса. Пользователи базы данных могут изменять большинство параметров сеанса в рамках своего сеанса, но для некоторых требуются права суперпользователя.
Чтобы изменить локальный параметр конфигурации в нескольких сегментах, обновите параметр в файле postgresql.conf каждого целевого сегмента, как основного, так и резервного. Используйте утилиту gpconfig для установки параметра во всех файлах RT.Warehouse postgresql.conf. Например:
$ gpconfig -c gp_vmem_protect_limit -v 4096Перезапустите базу данных RT.Warehouse, чтобы изменения конфигурации вступили в силу:
$ gpstop -rЧтобы задать параметр мастера конфигурации, задайте его в инстансе мастера базы данных RT.Warehouse. Если это также параметр сеанса, вы можете установить параметр для конкретной базы данных, роли или сеанса. Если параметр задан на нескольких уровнях, приоритет имеет наиболее детальный уровень. Например, сеанс переопределяет роль, роль переопределяет базу данных, а база данных переопределяет систему.
Настройки параметров мастера в файле мастера postgresql.conf являются общесистемными по умолчанию. Чтобы установить параметр мастера:
1. Отредактируйте файл $MASTER_DATA_DIRECTORY/postgresql.conf.
2. Найдите параметр, который необходимо установить, раскомментируйте его (удалите предшествующий символ #) и введите нужное значение.
3. Сохраните и закройте файл.
Для параметров сеанса, не требующих перезагрузки сервера, загрузите изменения postgresql.conf следующим образом:
$ gpstop -u4. Для изменения параметров, требующих перезагрузки сервера, перезапустите базу данных RT.Warehouse следующим образом:
$ gpstop -rИспользуйте ALTER DATABASE для установки параметров на уровне базы данных. Например:
=# ALTER DATABASE mydatabase SET search_path TO myschema;Когда вы устанавливаете параметр сеанса на уровне базы данных, каждый сеанс, который подключается к этой базе данных, использует этот параметр. Настройки на уровне базы данных переопределяют настройки на системном уровне.
Используйте ALTER ROLE, чтобы установить параметр на уровне роли. Например:
=# ALTER ROLE bob SET search_path TO bobschema;Когда вы устанавливаете параметр сеанса на уровне роли, каждый сеанс, инициированный этой ролью, использует этот параметр. Настройки на уровне роли переопределяют настройки на уровне базы данных.
Любой параметр сеанса можно задать в активном сеансе базы данных с помощью команды SET. Например:
=# SET statement_mem TO '200MB';Установка параметра действительна до конца этого сеанса или до тех пор, пока вы не выполните команду RESET. Например:
=# RESET statement_mem;Настройки на уровне сеанса переопределяют настройки на уровне роли.
Команда SQL SHOW позволяет просмотреть текущие настройки параметров конфигурации сервера. Например, чтобы посмотреть настройки всех параметров:
$ psql -c 'SHOW ALL;'SHOW перечисляет настройки только для инстанса мастера. Чтобы увидеть значение того или иного параметра во всей системе (мастер и все сегменты), используйте утилиту gpconfig. Например:
$ gpconfig --show max_connectionsПараметры конфигурации влияют на такие категории поведения сервера, как потребление ресурсов, настройка запросов и проверка подлинности.
Вы можете настроить базу данных RT.Warehouse для использования сжатия данных с некоторыми функциями базы данных и некоторыми утилитами. Сжатие сокращает использование дискового пространства и улучшает операции ввода-вывода в системе, однако оно увеличивает производительность при сжатии и распаковке данных.
Вы можете настроить поддержку сжатия данных с помощью функций и утилит. См. конкретную функцию или утилиту для получения информации о поддержке сжатия.
Для некоторых алгоритмов сжатия (например, zlib) базе данных RT.Warehouse требуются пакеты программного обеспечения, установленные на хосте системы. Для получения информации о необходимых пакетах программного обеспечения см. Руководство по установке RT.Warehouse.
Отказоустойчивость и функции высокой доступности базы данных RT.Warehouse можно настроить.
|
Примечание. Если потеря данных неприемлема для кластера базы данных RT.Warehouse, необходимо включить зеркалирование мастера и сегментов. |
Систему базы данных RT.Warehouse можно сделать высокодоступной, предоставив отказоустойчивую аппаратную платформу, активировав функции высокой доступности базы данных RT.Warehouse и выполняя процедуры регулярного мониторинга и обслуживания для обеспечения работоспособности всех компонентов системы.
Аппаратные компоненты в конечном итоге выходят из строя из-за естественного износа или непредвиденных обстоятельств. Потеря питания может привести к временной недоступности компонентов. Систему можно сделать высокодоступной, предоставив избыточные резервы для компонентов, которые могут выйти из строя, чтобы службы могли продолжать бесперебойную работу в случае возникновения сбоя. В некоторых случаях стоимость избыточности выше, чем терпимость пользователей к прерыванию обслуживания. В этом случае цель состоит в том, чтобы обеспечить возможность восстановления полного обслуживания в течение ожидаемого периода времени.
С помощью базы данных RT.Warehouse отказоустойчивость и доступность данных достигаются за счёт:
1. Защита хранилища RAID на аппаратном уровне.
В передовом опыте развёртывания базы данных RT.Warehouse используется RAID аппаратного уровня для обеспечения высокопроизводительной избыточности на случай отказа одного диска без необходимости переходить на уровень отказоустойчивости базы данных. Это обеспечивает более низкий уровень избыточности на уровне диска.
2. Контрольные суммы хранения данных.
База данных RT.Warehouse использует контрольные суммы для проверки того, что данные, загруженные с диска в память, не были повреждены в файловой системе.База данных RT.Warehouse имеет два типа хранилища для пользовательских данных: heap и оптимизированное по добавлению. Обе модели хранения используют контрольные суммы для проверки данных, считываемых из файловой системы, и при настройках по умолчанию они обрабатывают ошибки проверки контрольной суммы аналогичным образом.
Базы данных мастера и сегментов RT.Warehouse обрабатывают данные об обновлении данных на страницах в памяти, которой они управляют. Когда страница памяти обновляется и сбрасывается на диск, контрольные суммы вычисляются и сохраняются вместе со страницей. Когда позже страница извлекается с диска, контрольные суммы проверяются, и странице разрешается войти в управляемую память только в том случае, если проверка прошла успешно. Неудачная проверка контрольной суммы указывает на повреждение файловой системы и приводит к тому, что база данных RT.Warehouse выдаёт ошибку, прерывая транзакцию.
Параметры контрольной суммы по умолчанию обеспечивают наилучший уровень защиты от необнаруженного повреждения диска, распространяющегося на базу данных и зеркальные сегменты.
Поддержка контрольной суммы heap включена по умолчанию, когда кластер базы данных RT.Warehouse инициализируется с помощью утилиты управления gpinitsystem. Хотя это настоятельно не рекомендуется, кластер можно инициализировать без поддержки контрольной суммы heap, установив для параметра HEAP_CHECKSUM значение off в файле конфигурации кластера gpinitsystem.
После инициализации невозможно изменить поддержку контрольной суммы heap для кластера без повторной инициализации системы и перезагрузки баз данных.
Вы можете проверить параметр конфигурации сервера, доступный только для чтения, data_checksums, чтобы узнать, включены ли в кластере контрольные суммы heap:
$ gpconfig -s data_checksumsКогда кластер базы данных RT.Warehouse запускается, утилита gpstart проверяет, постоянно ли включены или отключены контрольные суммы heap на мастере и всех сегментах. Если есть какие-либо различия, кластер не запускается.
В случаях, когда необходимо игнорировать ошибки проверки контрольной суммы heap, чтобы можно было восстановить данные, установка для системного параметра конфигурации ignore_checksum_failure значения on приводит к тому, что база данных RT.Warehouse выдаёт предупреждение в случае сбоя проверки контрольной суммы heap, но после этого страница может загружаться в управляемую память. Если страница обновляется и сохраняется на диск, повреждённые данные могут быть реплицированы в зеркальный сегмент. Поскольку это может привести к потере данных, установка для ignore_checksum_failure значения on должна выполняться только для включения восстановления данных.
Для хранилища, оптимизированного для добавления, поддержка контрольной суммы является одним из нескольких параметров хранения, установленных во время создания таблицы, оптимизированной для добавления, с помощью команды CREATE TABLE. Параметры хранилища по умолчанию указываются в параметре конфигурации сервера gp_default_storage_options. Опция хранения контрольной суммы включена по умолчанию, и её отключение настоятельно не рекомендуется.
Если вы решите отключить контрольные суммы для таблицы, оптимизированной для добавления, вы можете либо:
Обратите внимание, что оператор CREATE TABLE позволяет вам устанавливать параметры хранения, включая контрольные суммы, для отдельных файлов партиций.
3. Зеркалирование сегмента RT.Warehouse.
База данных RT.Warehouse хранит данные на нескольких инстансах сегментов, каждый из которых является инстансом базы данных RT.Warehouse PostgreSQL. Данные для каждой таблицы распределяются между сегментами на основе политики распределения, определённой для таблицы в DDL во время создания таблицы. Когда зеркалирование сегментов включено, для каждого инстанса сегмента существует пара основного и зеркального. Зеркальный сегмент поддерживается в актуальном состоянии с основным сегментом с помощью потоковой репликации на основе записи с опережением (WAL).
Зеркальный инстанс для каждого сегмента обычно инициализируется с помощью утилиты gpinitsystem или утилиты gpexpand. Рекомендуется, чтобы зеркало работало на хосте, отличном от основного инстанса, чтобы обеспечить защиту от сбоя одной машины. Существуют разные стратегии назначения зеркал хостам. При выборе компоновки основных и зеркальных серверов важно учитывать сценарии отказа, чтобы свести к минимуму перекос обработки в случае отказа одной машины.
4.Зеркалирование мастера.
В высокодоступном кластере есть два главных экземпляра: основной и резервный. Как и в случае с сегментами, главный и резервный серверы должны быть развернуты на разных хостах, чтобы кластер мог выдержать сбой одного хоста. Клиенты подключаются к первичному мастеру, и запросы могут выполняться только на первичном мастере. Резервный мастер поддерживается в актуальном состоянии с основным мастером с помощью потоковой репликации на основе ведения журнала с опережающей записью (WAL).
Если мастер выходит из строя, администратор запускает утилиту gpactivatestandby, чтобы резервный мастер стал новым основным мастером. Вы можете настроить виртуальные IP-адреса для мастера и резервного мастера, чтобы клиентским программам не приходилось переключаться на другой сетевой адрес при смене текущего мастера. В случае сбоя хоста мастера виртуальный IP-адрес может быть заменён фактическим действующим мастером.
5.Двойные кластеры.
Дополнительный уровень избыточности может быть обеспечен за счёт поддержки двух кластеров базы данных RT.Warehouse, в которых хранятся одни и те же данные.
Два метода синхронизации данных в двойных кластерах — «двойной ETL» и «резервное копирование/восстановление».
Двойной ETL обеспечивает полный резервный кластер с теми же данными, что и основной кластер. ETL (извлечение, преобразование и загрузка) относится к процессу очистки, преобразования, проверки и загрузки входящих данных в хранилище данных. При использовании двойного ETL этот процесс выполняется дважды параллельно, по одному разу в каждом кластере, и каждый раз проверяется. Это также позволяет запрашивать данные в обоих кластерах, удваивая пропускную способность запросов. Приложения могут использовать преимущества обоих кластеров, а также обеспечивать успешное выполнение и проверку ETL на обоих кластерах.
Для поддержки двойного кластера методом резервного копирования/восстановления создайте резервные копии основного кластера и восстановите их на вторичном кластере. Этот метод требует больше времени для синхронизации данных на вторичном кластере, чем стратегия двойного ETL, но требует меньше разработки логики приложения. Заполнение второго кластера резервными копиями идеально в тех случаях, когда изменения данных и ETL выполняются ежедневно или реже.
6.Резервное копирование и восстановление базы данных.
Рекомендуется регулярно делать резервные копии баз данных, за исключением случаев, когда базу данных можно легко восстановить из исходных данных. Необходимо делать резервные копии для защиты от операционных, программных и аппаратных ошибок.
Используйте утилиту gpbackup для резервного копирования баз данных RT.Warehouse. gpbackup выполняет резервное копирование параллельно между сегментами, поэтому производительность резервного копирования увеличивается по мере добавления оборудования в кластер.
При разработке стратегии резервного копирования основное внимание уделяется тому, где хранить данные резервного копирования. Данные, которыми управляет каждый сегмент, могут быть скопированы в локальное хранилище сегмента, но не должны храниться там постоянно — резервная копия уменьшает дисковое пространство, доступное для сегмента, и, что более важно, сбой оборудования может одновременно уничтожить оперативные данные сегмента и резервную копию. После выполнения резервного копирования файлы резервных копий следует переместить из основного кластера в отдельное безопасное хранилище. Кроме того, резервную копию можно сделать непосредственно в отдельном хранилище.
Используя плагин хранилища базы данных RT.Warehouse с утилитами gpbackup и gprestore, вы можете отправить резервную копию или получить резервную копию из удалённого места или устройства хранения. Плагины хранилища базы данных RT.Warehouse поддерживают подключение к локациям, включая локации Amazon Simple Storage Service (Amazon S3) и устройства хранения данных Dell EMC Data Domain.
Используя API-интерфейс Backup/Restore Storage Plugin, вы можете создать собственный плагин, который утилиты gpbackup и gprestore могут использовать для интеграции кастомной системы хранения резервных копий с базой данных RT.Warehouse.
Когда включена высокая доступность базы данных RT.Warehouse, существует два типа инстансов сегментов: основной и зеркальный. Каждому основному сегменту соответствует один зеркальный сегмент. Инстанс основного сегмента получает запросы от мастера на внесение изменений в данные сегмента, а затем реплицирует эти изменения на соответствующее зеркало. Если база данных RT.Warehouse обнаруживает, что основной сегмент вышел из строя или стал недоступным, она изменяет роль своего зеркального сегмента на основной сегмент, а роль недоступного основного сегмента — на зеркальный сегмент. Транзакции, выполнявшиеся на момент сбоя, откатываются и должны быть перезапущены. Затем администратор должен восстановить зеркальный сегмент, разрешить зеркалу синхронизироваться с текущим основным сегментом, а затем поменять местами основной и зеркальный сегменты, чтобы они выполняли свои предпочтительные роли.
Если зеркалирование сегментов не включено, система базы данных RT.Warehouse отключается при сбое инстанса сегмента. Администраторы должны вручную восстановить все повреждённые сегменты, прежде чем можно будет возобновить работу базы данных RT.Warehouse.
Когда зеркалирование сегментов включено для существующей системы, инстансы основного сегмента продолжают предоставлять услуги пользователям, пока создаётся снапшот основных сегментов. Пока снапшоты создаются и развёртываются на инстансах зеркального сегмента, также записываются изменения в основном сегменте. После развёртывания снапшота в зеркальном сегменте зеркальный сегмент синхронизируется и поддерживается в актуальном состоянии с помощью потоковой репликации на основе WAL. Репликация WAL базы данных RT.Warehouse использует процессы репликации walsender и walreceiver. Процесс walsender является процессом основного сегмента. walreceiver — это процесс зеркального сегмента.
Когда происходят изменения в базе данных, журналы, фиксирующие изменения, передаются в зеркальный сегмент, чтобы поддерживать его актуальность с соответствующими основными сегментами. Во время репликации WAL изменения базы данных записываются в журналы перед применением, чтобы обеспечить целостность данных для любых внутрипроцессных операций.
Когда база данных RT.Warehouse обнаруживает сбой основного сегмента, процесс репликации WAL останавливается, и зеркальный сегмент автоматически запускается как активный основной сегмент. Если зеркальный сегмент выходит из строя или становится недоступным, когда основной активен, основной сегмент отслеживает изменения базы данных в журналах, которые применяются к зеркалу при его восстановлении.
Эти таблицы системного каталога базы данных RT.Warehouse содержат информацию о зеркалировании и репликации:
Инстансы зеркального сегмента могут быть размещены на хостах в кластере в различных конфигурациях. Рекомендуется размещать основной сегмент и соответствующее зеркало на разных хостах. Каждый хост должен иметь одинаковое количество основных и зеркальных сегментов. Когда вы создаёте зеркала сегментов с помощью утилит базы данных RT.Warehouse gpinitsystem или gpaddmirrors, вы можете указать конфигурацию зеркал сегментов: групповое зеркалирование (по умолчанию) или распределённое зеркалирование. С помощью gpaddmirrors вы можете создавать собственные конфигурации зеркального отображения с помощью файла конфигурации gpaddmirrors и указывать файл в командной строке.
Групповое зеркалирование является конфигурацией зеркалирования по умолчанию. Зеркальные сегменты для основных сегментов каждого хоста размещаются на другом хосте. В случае сбоя одного узла количество активных основных сегментов удваивается на узле, поддерживающем отказавший узел.
Распределённое зеркалирование распределяет зеркала каждого хоста по нескольким хостам, так что в случае сбоя любого отдельного хоста ни на одном другом хосте не будет более одного зеркала, повышенного до активного основного сегмента. Распределённое зеркалирование возможно только в том случае, если хостов больше, чем сегментов на хост.
Вы можете развернуть резервную копию или зеркало мастера на отдельной хост-машине. Резервный мастер служит в качестве «горячего» резерва, если основной мастер выходит из строя. Вы создаёте резервный мастер из основного мастера, пока основной находится в сети.
Когда вы включаете зеркалирование мастера для существующей системы, основной мастер продолжает предоставлять услуги пользователям, пока создаётся снапшот инстанса основного мастера. Когда снапшот создаётся и развёртывается на резервном мастере, изменения на основном мастере также записываются. После развёртывания снапшота на резервном мастере резервный мастер синхронизируется и поддерживается в актуальном состоянии с помощью потоковой репликации на основе WAL. Репликация WAL базы данных RT.Warehouse использует процессы репликации walsender и walreceiver. Процесс walsender является процессом основного мастера. walreceiver — это процесс резервного мастера.
Поскольку мастер не содержит пользовательских данных, между основным и резервным мастерами синхронизируются только таблицы системного каталога. Когда эти таблицы обновляются, журналы репликации, в которых фиксируются изменения, передаются на резервный мастер, чтобы поддерживать его в актуальном состоянии с основным. Во время репликации WAL все изменения базы данных перед применением записываются в журналы репликации, чтобы обеспечить целостность данных для любых внутрипроцессных операций.
Вот как база данных RT.Warehouse обрабатывает сбой мастера:
Эти таблицы системного каталога базы данных RT.Warehouse содержат информацию о зеркалировании и репликации:
Вы можете настроить систему базы данных RT.Warehouse с зеркалированием во время установки с помощью gpinitsystem или включить зеркалирование позже с помощью gpaddmirrors и gpinitstandby. В этом разделе предполагается, что вы добавляете зеркала в существующую систему, которая была инициализирована без зеркал.
Зеркальные сегменты позволяют запросам базы данных переключаться на резервный сегмент, если основной сегмент недоступен. По умолчанию зеркала настраиваются на том же массиве хостов, что и основные сегменты. Вы можете выбрать совершенно другой набор хостов для своих зеркальных сегментов, чтобы они не делили машины ни с одним из ваших основных сегментов.
|
Примечание. Во время онлайн-репликации данных база данных RT.Warehouse должна находиться в состоянии покоя, рабочие нагрузки и другие запросы не должны выполняться. |
Чтобы добавить зеркала сегментов в существующую систему (те же хосты, что и основные):
$ gpaddmirrors -p 10000Где -p указывает номер, который нужно добавить к номерам портов основного сегмента. Зеркала добавляются с конфигурацией группового зеркального отображения по умолчанию.
Чтобы добавить зеркала сегментов в существующую систему (отличные хосты от основных):
1. Убедитесь, что программное обеспечение базы данных RT.Warehouse установлено на всех хостах. Подробные инструкции по установке см. в Руководстве по установке RT.Warehouse.
2. Выделите область хранения данных для зеркальных данных и табличных пространств, если необходимо, на всех хостах сегмента.
3. Используйте gpssh-exkeys, чтобы хосты сегмента могли связываться друг с другом через SSH и SCP без запроса пароля.
4. Создайте файл конфигурации, в котором перечислены имена хостов, порты и каталоги данных, на которых нужно создавать зеркала. Чтобы создать пример файла конфигурации для использования в качестве отправной точки, запустите:
$ gpaddmirrors -o filenameФормат файла конфигурации зеркала:
row_id=contentID|address|port|data_dirГде row_id — это строка в файле, contentID — это идентификатор содержимого инстанса сегмента, address — это имя хоста или IP-адрес хоста сегмента, port — это коммуникационный порт, а data_dir — каталог данных инстанса сегмента.
Например, это содержимое файла конфигурации зеркала для двух хостов сегмента и двух инстансов сегмента на хост:
0=2|sdw1-1|41000|/data/mirror1/gp2
1=3|sdw1-2|41001|/data/mirror2/gp3
2=0|sdw2-1|41000|/data/mirror1/gp0
3=1|sdw2-2|41001|/data/mirror2/gp15. Запустите утилиту gpaddmirrors, чтобы включить зеркалирование в системе базы данных RT.Warehouse:
$ gpaddmirrors -i mirror_config_fileПараметр -i указывает созданный вами файл конфигурации зеркала.
Вы можете настроить новую систему базы данных RT.Warehouse с помощью резервного мастера с помощью gpinitsystem или включить его позже с помощью gpinitstandby. В этом разделе предполагается, что вы добавляете резервный мастер в существующую систему, которая была инициализирована без него.
Чтобы добавить резервный мастер в существующую систему:
$ gpinitstandby -s smdwГде -s указывает имя хоста резервного мастера.
Чтобы проверить состояние процесса зеркалирования мастера (опционально):
Вы можете запустить утилиту gpstate с параметром -f, чтобы отобразить сведения о резервном мастере.
$ gpstate -fСостояние резервного мастера должно быть пассивным, а состояние отправителя WAL — потоковым.
При включённом зеркалировании сегментов база данных RT.Warehouse автоматически переключается на инстанс зеркального сегмента, когда инстанс основного сегмента выходит из строя. При условии, что один инстанс сегмента находится в сети для каждой порции данных, пользователи могут не осознавать, что сегмент не работает. Если транзакция выполняется в момент возникновения ошибки, выполняемая транзакция откатывается и автоматически перезапускается на перенастроенном наборе сегментов. Утилиту gpstate можно использовать для выявления неисправных сегментов. Утилита отображает информацию из таблиц каталога, включая gp_segment_configuration.
Если вся система базы данных RT.Warehouse перестает работать из-за сбоя сегмента (например, если зеркальное отображение не включено или недостаточно подключённых сегментов для доступа ко всем пользовательским данным), пользователи увидят ошибки при попытке подключения к базе данных. Ошибки, возвращаемые клиентской программе, могут указывать на сбой. Например:
ERROR: All segment databases are unavailableНа мастере базы данных RT.Warehouse процесс Postgres postmaster разветвляет процесс проверки сбоев, ftsprobe. Он также известен как процесс FTS (Fault Tolerance Server). Процесс postmaster перезапускает FTS в случае сбоя.
FTS работает в цикле с интервалом ожидания между каждым циклом. В каждом цикле FTS проверяет каждый инстанс основного сегмента, устанавливая соединение сокета TCP с инстансом сегмента, используя имя хоста и порт, зарегистрированные в таблице gp_segment_configuration. Если соединение установлено успешно, сегмент выполняет несколько простых проверок и отчитывается перед FTS. Проверки включают в себя выполнение системного вызова stat для каталогов критических сегментов и проверку внутренних ошибок в инстансе сегмента. Если проблем не обнаружено, в FTS отправляется положительный ответ, и для этого инстанса сегмента не предпринимается никаких действий.
Если соединение не может быть установлено или если ответ не получен в течение периода ожидания, то для инстанса сегмента предпринимается повторная попытка. Если настроенное максимальное количество попыток проверки не удаётся, FTS проверяет зеркало сегмента, чтобы убедиться, что оно включено, а затем обновляет таблицу gp_segment_configuration, помечая основной сегмент как отключённый и настраивая зеркало в качестве основного. FTS обновляет таблицу gp_configuration_history с выполненными операциями.
Когда есть только основной сегмент активе, а соответствующее зеркало не работает, основной сегмент переходит в состояние отсутствия синхронизации и продолжает регистрировать изменения базы данных, поэтому зеркало можно синхронизировать без выполнения полной копии данных с основного сервера на зеркало.
Запуск утилиты gpstate с параметром -e отображает все проблемы с инстансами основного или зеркального сегмента. Другие параметры gpstate, отображающие информацию обо всех инстансах основного или зеркального сегмента, такие как -m (информация об инстансе зеркального экземпляра) и -c (информация о конфигурации основного и зеркального инстансов), также отображают информацию о проблемах основного и зеркального сегментов.
Вы также можете увидеть режим: s (синхронизация) или n (отсутствие синхронизации) для каждого инстанса сегмента, а также статус u (активен) или d (сбой) в таблице gp_segment_configuration.
Утилита gprecoverseg используется для запуска зеркала, которое не работает. По умолчанию gprecoverseg выполняет инкрементное восстановление, переводя зеркало в режим синхронизации, который начинает воспроизводить записанные изменения с основного сервера на зеркало. Если инкрементное восстановление не может быть завершено, восстановление завершается ошибкой, и gprecoverseg следует запустить снова с параметром -F, чтобы выполнить полное восстановление. Это приводит к тому, что основной сервер копирует все данные на зеркало.
После восстановления инстанса сегмента команда gpstate -e может вывести список инстансов основного и зеркального сегментов, которые были переключены. Это указывает на то, что система не сбалансирована (основной и зеркальный инстансы не в своих изначально настроенных ролях). Если система не сбалансирована, может возникнуть перекос из-за количества активных инстансов основного сегмента на хосте сегментов.
В таблице gp_segment_configuration есть столбцы role и preferred_role. Они могут иметь значения либо p для основного, либо m для зеркального. Столбец role показывает текущую роль инстанса сегмента, а preferred_role показывает исходную роль инстанса сегмента.
В сбалансированной системе role и preferred_role совпадают для всех инстансов сегмента. Когда они не совпадают, система не сбалансирована. Чтобы перебалансировать кластер и привести все сегменты к их предпочтительной роли, запустите команду gprecoverseg с параметром -r.
Рассмотрим одну пару инстансом основного и зеркального сегментов, в которой основной сегмент переключился на зеркальный. В следующей таблице показаны предпочтительная роль, роль, режим и состояние инстанса сегмента из таблицы gp_segment_configuration перед началом восстановления отказавшего основного сегмента.
Вы также можете запустить gpstate -e, чтобы отобразить любые проблемы с инстансами основного или зеркального сегмента.
Таблица 5— Исходная информация о сегментах
| Сегмент | preferred_role | role | mode | status |
|---|---|---|---|---|
| Основной | p (primary) | m (mirror) | n (not synchronizing) | d (down) |
| Зеркальный | m (mirror) | p (primary) | n (not synchronizing) | u (up) |
Роли инстанса сегмента не соответствуют их предпочтительным ролям, а основная роль недоступна. Зеркало включено, роль теперь является основной, и она не синхронизируется, поскольку её зеркало, вышедший из строя основной инстанс, отключено. После устранения проблем с хостом сегмента и основным инстансом сегмента используйте gprecoverseg для подготовки отказавших инстансов сегмента к восстановлению и запуска синхронизации между основным и зеркальным инстансами.
После завершения gprecoverseg сегменты будут находиться в состояниях, показанных в следующей таблице, где пара сегментов «основной-зеркальный» находится в рабочем состоянии, а основные и зеркальные роли меняются местами по сравнению с их предпочтительными ролями.
Таблица 6— Промежуточная информация о сегментах
| Сегмент | preferred_role | role | mode | status |
|---|---|---|---|---|
| Основной | p (primary) | m (mirror) | s (synchronizing) | u (up) |
| Зеркальный | m (mirror) | p (primary) | s (synchronizing) | u (up) |
Команда gprecoverseg -r перебалансирует систему, возвращая роли сегментов к их предпочтительным ролям.
Таблица 7— Итоговая информация о сегментах
| Сегмент | preferred_role | role | mode | status |
|---|---|---|---|---|
| Основной | p (primary) | p (primary) | s (synchronizing) | u (up) |
| Зеркальный | m (mirror) | m (mirror) | s (synchronizing) | u (up) |
Существует набор параметров конфигурации сервера, влияющих на поведение FTS. Параметры представлены в таблице ниже.
Таблица 8— Параметры поведения FTS
| Параметр | Описание |
|---|---|
| gp_fts_probe_interval | Как часто в секундах начинать новый цикл FTS. Например, если параметр равен 60, а цикл проверки занимает 10 секунд, процесс FTS приостанавливается на 50 секунд. Если параметр равен 60, а цикл проверки занимает 75 секунд, процесс приостанавливается на 0 секунд. Значение по умолчанию — 60, максимальное — 3600. |
| gp_fts_probe_timeout | Время ожидания пробы между мастером и сегментом в секундах. Значение по умолчанию — 20, максимальное — 3600. |
| gp_fts_probe_retries | Количество попыток проб сегмента. Например, если установлено значение 5, будет 4 повторных попытки после неудачной первой попытки. По умолчанию — 5. |
| gp_log_fts | Уровень ведения журнала для FTS. Значение может быть off, terse, verbose или debug. verbose можно использовать в производственной среде для предоставления полезных данных для устранения неполадок. debug не должен использоваться в производственной среде. По умолчанию — terse. |
| gp_segment_connect_timeout | Максимальное время (в секундах), в течение которого зеркало может ответить. По умолчанию — 600 (10 минут). |
В дополнение к проверке неисправностей, выполняемой FTS, основной сегмент, который не может отправить данные на своё зеркало, может изменить состояние зеркала на неработающее. Основной сервер ставит данные в очередь и по прошествии секунд gp_segment_connect_timeout указывает на сбой зеркала, в результате чего зеркало помечается как неработающее, а основной сервер переходит в режим отслеживания изменений.
При включённом зеркалировании вы можете иметь в системе инстансы сегментов, в которых произошел сбой, без прерывания обслуживания или какого-либо указания на то, что произошел сбой. Вы можете проверить состояние вашей системы с помощью утилиты gpstate. gpstate предоставляет статус каждого отдельного компонента системы базы данных RT.Warehouse, включая основные сегменты, зеркальные сегменты, мастера и резервного мастера.
$ gpstate -eЕсли утилита перечисляет сегменты с переключёнными ролями основного и зеркального, а сегмент не находится в своей предпочтительной роли (роли, которой он был назначен при инициализации системы). Это означает, что система находится в потенциально несбалансированном состоянии, поскольку некоторые хосты сегментов могут иметь больше активных сегментов, чем это оптимально для максимальной производительности системы.
Сегменты, которые отображают состояние конфигурации как down, указывают на то, что соответствующий зеркальный сегмент не работает.
2.Чтобы получить подробную информацию о неисправных сегментах, вы можете проверить таблицу каталога gp_segment_configuration. Например:
$ psql postgres -c "SELECT * FROM gp_segment_configuration WHERE status='d';"3. Для инстансов сегмента запишите хост, порт, предпочитаемую роль и каталог данных. Эта информация поможет определить инстанс хоста и сегмента для устранения неполадок.
4. Чтобы отобразить информацию об инстанса зеркального сегмента, выполните:
$ gpstate -mФайлы лога могут предоставить информацию, помогающую определить причину ошибки. У инстансов мастера и сегментов есть свой собственный файл лога в pg_log каталога данных. Основной файл лога содержит больше всего информации, и вы всегда должны проверять его в первую очередь.
Используйте утилиту gplogfilter, чтобы проверить дополнительные сведения в файлах лога базы данных RT.Warehouse. Чтобы проверить файлы лога сегмента, запустите gplogfilter на хостах сегмента с помощью gpssh.
Чтобы проверить файлы лога:
1. Используйте gplogfilter, чтобы проверить файл лога мастера на наличие сообщений уровня журнала WARNING, ERROR, FATAL или PANIC:
$ gplogfilter -t2. Используйте gpssh для проверки наличия сообщений уровня журнала WARNING, ERROR, FATAL или PANIC для каждого инстанса сегмента. Например:
$ gpssh -f seg_hosts_file -e 'source
/usr/local/greenplum-db/greenplum_path.sh ; gplogfilter -t
/data1/primary/*/pg_log/gpdb*.log' > seglog.outЕсли мастер не может подключиться к инстансу сегмента, он помечает этот сегмент как отключённый в системном каталоге базы данных RT.Warehouse. Инстанс сегмента остаётся в автономном режиме до тех пор, пока администратор не предпримет шаги, чтобы вернуть сегмент в оперативный режим. Процесс восстановления отказавшего инстанса сегмента или хоста зависит от причины сбоя и от того, включено ли зеркалирование. Инстанс сегмента может быть недоступен по многим причинам:
Сбои хоста сегмента обычно вызывают сбои нескольких сегментов: все основные или зеркальные инстансы сегмента на хосте помечаются как отключённые и нерабочие. Если зеркалирование не включено и сегмент выходит из строя, система автоматически перестает работать.
Инстанс сегмента может выйти из строя по нескольким причинам, таким как сбой хоста, сбой сети или диска. Когда инстанс сегмента выходит из строя, его статус помечается как неработающий в системном каталоге базы данных RT.Warehouse, а его зеркало активируется в режиме отслеживания изменений. Для того, чтобы вернуть отказавший инстанс сегмента в работу, вы должны сначала устранить проблему, из-за которой произошёл сбой, а затем восстановить инстанс сегмента в базе данных RT.Warehouse с помощью gprecoverseg.
Если хост сегмента не подлежит восстановлению и вы потеряли один или несколько инстансов сегмента с включённым зеркалированием, вы можете попытаться восстановить инстанс сегмента с его зеркала. Вы также можете воссоздать свою систему базы данных RT.Warehouse из файлов резервных копий.
1. Убедитесь, что вы можете подключиться к хосту сегмента с мастера. Например:
$ ping failed_seg_host_address2. Устраните неполадку, из-за которой хост мастера не может подключиться к хосту сегмента. Например, может потребоваться перезапуск или замена машина хоста.
3. После того, как хост находится в сети и к нему можно подключиться, запустите утилиту gprecoverseg с хоста мастера, чтобы повторно активировать инстансы сегмента, в которых произошел сбой, и запустить процесс синхронизации мастера и зеркальных инстансов. Например:
$ gprecoverseg4. В процессе восстановления выявляются повреждённые сегменты и определяются изменённые файлы, которые необходимо синхронизировать. Процесс может занять некоторое время; дождитесь завершения процесса.
5. После завершения gprecoverseg система переходит в режим повторной синхронизации и начинает копирование изменённых файлов. Этот процесс выполняется в фоновом режиме, пока система подключена к сети и принимает запросы к базе данных.
6. Когда процесс ресинхронизации завершится, состояние системы будет синхронизировано. Запустите утилиту gpstate, чтобы проверить статус процесса ресинхронизации:
$ gpstate -mКогда инстанс основного сегмента выходит из строя, зеркало активируется и становится основным сегментом. После запуска gprecoverseg текущий активный инстанс сегмента остаётся основным, а отказавший сегмент становится зеркальным. Инстансы сегментов не возвращаются к предпочтительной роли, которая была им дана во время инициализации системы. Это означает, что система может находиться в потенциально несбалансированном состоянии, если хосты сегментов имеют больше активных сегментов, чем это оптимально для максимальной производительности системы. Чтобы проверить несбалансированные сегменты и перебалансировать систему, запустите:
$ gpstate -eВсе сегменты должны быть подключены к сети и полностью синхронизированы, чтобы сбалансировать систему. Сеансы базы данных остаются подключёнными во время повторной балансировки, но выполняемые запросы отменяются и откатываются.
1. Запустите gpstate -m, чтобы убедиться, что все зеркала синхронизированы.
$ gpstate -m2. Если какие-либо зеркала находятся в режиме повторной синхронизации, дождитесь их завершения.
3. Запустите gprecoverseg с параметром -r, чтобы вернуть сегментам их предпочитаемые роли.
$ gprecoverseg -r4. После перебалансировки запустите gpstate -e, чтобы убедиться, что все сегменты находятся в своих предпочтительных ролях.
$ gpstate -eПри двойной ошибке не работают как основной сегмент, так и его зеркало. Это может произойти, если аппаратные сбои на хостах разных сегментов происходят одновременно. База данных RT.Warehouse недоступна, если происходит двойная ошибка.
Чтобы исправить двойную ошибку:
1. Устраните проблему, вызвавшую двойную ошибку, и убедитесь, что хосты сегмента работают и доступны с хоста мастера.
2. Перезапустите базу данных RT.Warehouse. Опция gpstop -r останавливает и перезапускает систему.
$ gpstop -r3. После перезапуска системы запустите gprecoverseg, чтобы повторно активировать инстансы сегментов, в которых произошёл сбой.
$ gprecoverseg4. После завершения gprecoverseg используйте gpstate, чтобы проверить состояние ваших зеркал и убедиться, что инстансы сегмента перешли из режима ресинхронизации в режим синхронизации:
$ gpstate -m5. Если у вас всё ещё есть инстансы сегментов в режиме отслеживания изменений, вы можете запустить gprecoverseg с параметром -F, чтобы выполнить полное восстановление сегмента.
|
Внимание. Полное восстановление удаляет каталог данных инстанса неактивного сегмента перед копированием данных из активного (текущего основного) инстанса сегмента. Перед выполнением полного восстановления убедитесь, что сбой сегмента не привёл к повреждению данных и что все проблемы с диском сегмента хоста устранены. |
$ gprecoverseg -F6. При необходимости верните инстансы сегментов в их предпочтительную роль.
1. Убедитесь, что вы можете подключиться к хосту сегмента с хоста мастера. Например:
$ ping failed_seg_host_address2. Устраните проблему, которая не позволяет хосту мастера подключиться к хосту сегмента. Например, может потребоваться перезагрузка машин хоста.
3. После подключения хоста к сети убедитесь, что вы можете подключиться к нему, и перезапустите базу данных RT.Warehouse. Опция gpstop -r останавливает и перезапускает систему:
$ gpstop -r4. Запустите утилиту gpstate, чтобы убедиться, что все инстансы сегментов подключены к сети:
$ gpstateЕсли хост не работает, например, из-за аппаратного сбоя, восстановите сегменты на запасной набор аппаратных ресурсов. Если зеркалирование включено, вы можете восстановить инстанс сегмента с его зеркала на альтернативный хост с помощью утилиты gprecoverseg. Например:
$ gprecoverseg -i recover_config_fileГде формат файла recovery_config_file:
<failed_host>|<port>|<data_dir>[ <recovery_host>|<port>|<recovery_data_dir>]Например, для восстановления на хост, отличный от хоста, на котором произошёл сбой, без настройки дополнительных табличных пространств (помимо табличного пространства pg_system по умолчанию):
sdw1-1|50001|/data1/mirror/gpseg16 sdw4-1|50001|/data1/recover1/gpseg16Новый восстанавливаемый хост сегмента должен быть предварительно установлен с программным обеспечением базы данных RT.Warehouse и настроен точно так же, как существующие хосты сегмента.
Если основной мастер выходит из строя, система базы данных RT.Warehouse становится недоступной, и репликация WAL останавливается. Используйте gpactivatestandby для активации резервного мастера. После активации резервного мастера база данных RT.Warehouse восстанавливает состояние хоста мастера на момент последней успешно зафиксированной транзакции.
Эти шаги предполагают, что для системы настроен резервный мастер.
Чтобы активировать резервный мастер:
1. Запустите утилиту gpactivatestandby с хоста резервного мастера, который вы активируете. Например:
$ gpactivatestandby -d /data/master/gpseg-1Где -d указывает каталог данных хоста мастера, который вы активируете.
После того, как вы активируете резервный сервер, он станет основным мастером для вашего массива базы данных RT.Warehouse.
2. После завершения работы утилиты запустите gpstate с параметром -b, чтобы отобразить сводку о состоянии системы:
$ gpstate -bСтатус инстанса мастера должен быть активен. Если резервный мастер не сконфигурирован, команда отображает No master standby configured для состояния резервного мастера. Если вы настроили новый резервный мастер, его статус будет пассивным.
3. После переключения на хост нового активного мастера запустите на нём ANALYZE. Например:
$ psql dbname -c 'ANALYZE;'4. Опционально: если вы ещё не сделали этого при активации предыдущего резервного мастера, вы можете запустить gpinitstandby на активном хосте мастера, чтобы настроить новый резервный мастер.
|
Внимание. Вы должны инициализировать новый резервный мастер, чтобы продолжить обеспечивать зеркалирование мастера. |
После активации резервного мастера для восстановления резервный мастер становится основным мастером. Вы можете продолжить работу этого инстанса в качестве хоста мастера, если он обладает теми же возможностями и надёжностью, что и исходный мастер.
Вы должны инициализировать новый резервный мастер, чтобы продолжить обеспечивать зеркалирование мастера, если вы ещё не сделали это при активации предыдущего резервного мастера. Запустите gpinitstandby на активном хосте мастера, чтобы настроить новый резервный мастер.
Вы можете восстановить основной и резервный инстансы мастера на исходных хостах. Этот процесс меняет роли основного и резервного мастера, и его следует выполнять только в том случае, если вы настоятельно предпочитаете запускать инстансы мастера на тех же хостах, которые они занимали до сценария восстановления.
|
Внимание. Восстановление основного и резервного инстансов мастера на их исходные хосты не является онлайн-операцией. Мастер должен быть остановлен для выполнения операции. |
1. Убедитесь, что исходный хост мастера находится в надёжном рабочем состоянии. Убедитесь, что причина исходного сбоя устранена.
2. На исходном хосте мастера переместите или удалите каталог данных, gpseg-1. В этом примере каталог перемещается в backup_gpseg-1:
$ mv /data/master/gpseg-1 /data/master/backup_gpseg-1Вы можете удалить каталог резервного копирования после успешной настройки резервного сервера.
3. Инициализируйте резервный мастер на исходном хосте мастера. Например, запустите эту команду с текущего хоста мастера smdw:
$ gpinitstandby -s mdw4. После завершения инициализации проверьте состояние резервного мастера, mdw. Запустите gpstate с параметром -f, чтобы проверить состояние резервного мастера:
$ gpstate -fСостояние резервного мастера должно быть passive, а состояние отправителя WAL — streaming.
5. Остановите инстанс мастера базы данных RT.Warehouse на инстансе резервного мастера. Например:
$ gpstop -m6. Запустите утилиту gpactivatestandby с исходного хоста мастера, mdw, который в настоящее время является резервным мастером. Например:
$ gpactivatestandby -d $MASTER_DATA_DIRECTORYГде параметр -d указывает каталог данных хоста, который вы активируете.
7. После завершения работы утилиты запустите gpstate с параметром -b, чтобы отобразить сводку о состоянии системы:
$ gpstate -bСтатус инстанса мастера должен быть active. Если резервный мастер не сконфигурирован, команда отображает No master standby configured для состояния резервного мастера.
8. На хосте резервного мастера переместите или удалите каталог данных, gpseg-1. Этот пример перемещает каталог:
$ mv /data/master/gpseg-1 /data/master/backup_gpseg-1Вы можете удалить каталог резервного копирования после успешной настройки резервного сервера.
9. После того, как исходный хост масера запустит основной мастер базы данных RT.Warehouse, вы можете инициализировать резервный мастер на исходном хосте основного мастера. Например:
$ gpinitstandby -s smdwПосле завершения команды вы можете запустить команду gpstate -f на хосте основного мастера, чтобы проверить статус резервного мастера.
Вы можете запустить утилиту gpstate с параметром -f, чтобы отобразить сведения о хосте резервного мастера.
$ gpstate -fСостояние резервного мастера должно быть passive, а состояние отправителя WAL — streaming.
В этом разделе описывается, как использовать функции резервного копирования и восстановления RT.Warehouse.
Регулярное резервное копирование гарантирует, что вы сможете восстановить данные или перестроить систему базы данных RT.Warehouse в случае повреждения данных или сбоя системы. Вы также можете использовать резервные копии для переноса данных из одной системы базы данных RT.Warehouse в другую.
База данных RT.Warehouse поддерживает параллельные и непараллельные методы резервного копирования и восстановления баз данных. Параллельные операции масштабируются независимо от количества сегментов в вашей системе, поскольку каждый хост сегмента одновременно записывает свои данные в локальное дисковое хранилище. При непараллельных операциях резервного копирования и восстановления данные должны передаваться по сети от сегментов к мастеру, который записывает все данные в своё хранилище. В дополнение к ограничению ввода-вывода одним хостом, непараллельное резервное копирование требует, чтобы у мастера было достаточно места на локальном диске для хранения всей базы данных.
gpbackup и gprestore — это утилиты резервного копирования и восстановления базы данных RT.Warehouse. gpbackup использует блокировки ACCESS SHARE на уровне отдельных таблиц вместо блокировок EXCLUSIVE для таблицы каталога pg_class. Это позволяет выполнять операторы DML во время резервного копирования, такие как операции CREATE, ALTER, DROP и TRUNCATE, если эти операции не нацелены на текущий набор резервных копий.
Файлы резервных копий, созданные с помощью gpbackup, предназначены для обеспечения будущих возможностей восстановления отдельных объектов базы данных вместе с их зависимостями, такими как функции и требуемые пользовательские типы данных.
Утилиты непараллельного резервного копирования PostgreSQL pg_dump и pg_dumpall можно использовать для создания единого файла дампа на хосте мастера, который содержит все данные из всех активных сегментов.
Непараллельные утилиты PostgreSQL следует использовать только в особых случаях. Они намного медленнее, чем использование утилит резервного копирования RT.Warehouse, поскольку все данные должны проходить через мастера. Кроме того, часто бывает так, что на хосте мастера недостаточно места на диске для сохранения резервной копии всей распределённой базы данных RT.Warehouse.
Для утилиты pg_restore требуются сжатые файлы дампа, созданные pg_dump или pg_dumpall. Перед началом восстановления вы должны изменить инструкции CREATE TABLE в файлах дампа, включив в них предложение DISTRIBUTED. Если вы не включаете предложение DISTRIBUTED, база данных RT.Warehouse назначает значения по умолчанию, которые могут быть неоптимальными.
Чтобы выполнить непараллельное восстановление с использованием файлов параллельных резервных копий, вы можете скопировать файлы резервных копий с каждого хоста сегмента на хост мастера, а затем загрузить их через мастера.
Другой непараллельный метод резервного копирования данных базы данных RT.Warehouse заключается в использовании SQL-команды COPY TO для копирования всей таблицы или её части из базы данных в текстовый файл с разделителями на хосте мастера.
gpbackup и gprestore — это утилиты RT.Warehouse, которые создают и восстанавливают наборы резервных копий для базы данных RT.Warehouse. По умолчанию gpbackup сохраняет только файлы метаданных объекта и файлы DDL для резервного копирования в каталоге основных данных базы данных RT.Warehouse. Сегменты базы данных RT.Warehouse используют команду COPY ... ON SEGMENT для сохранения своих данных для резервных копий таблиц в сжатых файлах данных CSV, расположенных в каталоге резервных копий каждого сегмента.
Файлы метаданных резервных копий содержат всю информацию, необходимую gprestore для параллельного восстановления полного набора резервных копий. Метаданные резервного копирования также обеспечивают основу для восстановления только отдельных объектов в наборе данных вместе с любыми зависимыми объектами в будущих версиях gprestore. Хранение данных таблицы в файлах CSV также даёт возможность использовать другие утилиты восстановления, такие как gpload, для загрузки данных либо в тот же кластер, либо в другой кластер. По умолчанию для каждой таблицы сегмента создаётся один файл. Вы можете указать параметр --leaf-partition-data с gpbackup, чтобы создать один файл данных для каждой leaf-партиции партиционированной таблицы вместо одного файла. Этот параметр также позволяет фильтровать наборы резервных копий по leaf-партициям.
Каждая задача gpbackup использует одну транзакцию в базе данных RT.Warehouse. Во время этой транзакции метаданные резервируются на хосте мастера, а данные для каждой таблицы на каждом хосте сегмента записываются в файлы резервных копий CSV с помощью команд COPY ... ON SEGMENT параллельно. Процесс резервного копирования устанавливает блокировку ACCESS SHARE для каждой резервной копии таблицы.
gpbackup и gprestore имеют следующие ограничения:
1. Если вы создаете индекс для родительской партиционированной таблицы, gpbackup не создаёт резервную копию этого же индекса для дочерних партиционированных таблиц родителя, так как создание такого же индекса для дочерней таблицы вызовет ошибку. Однако, если вы замените партицию, gpbackup не обнаружит, что индекс в заменённой партиции унаследован от новой родительской таблицы. В этом случае gpbackup создаёт резервную копию конфликтующих операторов CREATE INDEX, что вызывает ошибку при восстановлении набора резервных копий.
2. Вы можете запустить несколько инстансов gpbackup, но для каждого выполнения требуется отдельная временная метка.
3. Фильтрация объектов базы данных в настоящее время ограничена схемами и таблицами.
4. При резервном копировании партиционированной таблицы, в которой некоторые или все leaf-партиции находятся в схемах, отличных от корневой партиции, определения таблицы с leaf-партициями, включая схемы, резервируются как метаданные. Это происходит, даже если в операции резервного копирования указано, что схемы, содержащие leaf-партиции, должны быть исключены. Для управления резервным копированием данных для этого типа партиционированной таблицы в этой ситуации используйте параметр --leaf-partition-data.
5. Если вы укажете имя leaf-партиции с --exclude-table или в файле, используемом с --exclude-table-table, gpbackup проигнорирует имя партиции. Leaf-партиция не исключается из резервной копии.
6. Если вы используете параметр gpbackup --single-data-file для объединения резервных копий таблиц в один файл для каждого сегмента, вы не сможете выполнить операцию параллельного восстановления с помощью gprestore (нельзя установить для --jobs значение выше 1).
7. Резервное копирование базы данных с помощью gpbackup при одновременном выполнении команд DDL может привести к сбою gpbackup, чтобы обеспечить согласованность в наборе резервных копий. Например, если таблица удалена после начала операции резервного копирования, gpbackup завершает работу и отображает сообщение об ошибке ERROR: relation <schema.table> does not exist.
8. gpbackup может дать сбой, если таблица будет удалена во время операции резервного копирования из-за проблем с блокировкой таблицы. gpbackup создаёт список таблиц для резервного копирования и устанавливает блокировку ACCESS SHARED для таблиц. Если для таблицы удерживается EXCLUSIVE LOCK, gpbackup получает блокировку ACCESS SHARED после снятия существующей блокировки. Если таблица больше не существует, когда gpbackup пытается получить блокировку таблицы, gpbackup завершает работу с сообщением об ошибке.
Таблицы, которые могут быть удалены во время резервного копирования, можно исключить из резервной копии с помощью параметра фильтрации таблиц gpbackup, такого как --exclude-table или --exclude-schema.
9. Чтобы восстановить кластер, который имеет другое количество сегментов, чем исходный кластер, вы должны активировать параметр resize-cluster при вызове gprestore.
Чтобы включить функцию --resize-cluster для gprestore, необходимо создавать резервные копии с помощью gpbackup 1.26 или более поздней версии.
10. Если вы запускаете gpexpand для добавления сегментов в кластер, резервные копии, которые вы сделали до запуска расширения, не могут быть восстановлены после завершения расширения, если только вы не активируете параметр resize-cluster при вызове gprestore.
В следующей таблице перечислены объекты, резервное копирование и восстановление которых выполняется с помощью gpbackup и gprestore.
Объекты базы данных резервируются для базы данных, которую вы указываете с помощью параметра --dbname.
Глобальные объекты (системные объекты базы данных RT.Warehouse) резервируются по умолчанию, но не восстанавливаются по умолчанию. Используйте параметр gprestore --with-globals для восстановления глобальных объектов. Или используйте параметр gpbackup --without-globals, чтобы предотвратить резервное копирование глобальных объектов.
Таблица 9— Объекты, включённые в резервную копию или восстановление
| Объекты базы данных | Глобальные объекты |
|---|---|
|
Настройки параметров конфигурации на уровне сеанса (GUC) Схемы, см. примечание Расширения процедурного языка Последовательности Комментарии Таблицы Индексы Владельцы Доступные для записи внешние таблицы (только DDL) Читаемые внешние таблицы (только DDL) Функции Агрегаты Преобразования типов Типы Представления Материализованные представления (только DDL) Протоколы Триггеры. (Хотя база данных RT.Warehouse не поддерживает триггеры, любые существующие определения триггеров копируются и восстанавливаются.) Правила Домены Операторы, семейства операторов и классы операторов Конверсии Расширения Парсеры текстового поиска, словари, шаблоны и конфигурации Статистика таблицы (если указана опция --with-stats.) |
Табличные пространства Настройки параметров конфигурации для всей базы данных (GUC) Определения группы ресурсов Определения очереди ресурсов Роли GRANT назначения ролей базам данных |
|
Примечание. Эти схемы не включаются в резервную копию:
|
При восстановлении в существующей базе данных gprestore предполагает, что схема public существует при восстановлении объектов в схеме public. При восстановлении в новую базу данных (с параметром --create-db) gprestore автоматически создаёт схему public при создании базы данных с помощью команды CREATE DATABASE. Команда использует базу данных template0, содержащую схему public.
Чтобы выполнить полное резервное копирование базы данных, а также системных метаданных базы данных RT.Warehouse, используйте команду:
$ gpbackup --dbname <database_name>Например:
$ gpbackup --dbname demo
20180105:11:27:54 gpbackup:gpadmin:centos6.localdomain:002182-[INFO]:-Starting backup of database demo
20180105:11:27:54 gpbackup:gpadmin:centos6.localdomain:002182-[INFO]:-Backup Timestamp = 20180105112754
20180105:11:27:54 gpbackup:gpadmin:centos6.localdomain:002182-[INFO]:-Backup Database = demo
20180105:11:27:54 gpbackup:gpadmin:centos6.localdomain:002182-[INFO]:-Backup Type = Unfiltered Compressed Full Backup
20180105:11:27:54 gpbackup:gpadmin:centos6.localdomain:002182-[INFO]:-Gathering list of tables for backup
20180105:11:27:54 gpbackup:gpadmin:centos6.localdomain:002182-[INFO]:-Acquiring ACCESS SHARE locks on tables
Locks acquired: 6 / 6 [================================================================] 100.00% 0s
20180105:11:27:54 gpbackup:gpadmin:centos6.localdomain:002182-[INFO]:-Gathering additional table metadata
20180105:11:27:54 gpbackup:gpadmin:centos6.localdomain:002182-[INFO]:-Writing global database metadata
20180105:11:27:54 gpbackup:gpadmin:centos6.localdomain:002182-[INFO]:-Global database metadata backup complete
20180105:11:27:54 gpbackup:gpadmin:centos6.localdomain:002182-[INFO]:-Writing pre-data metadata
20180105:11:27:54 gpbackup:gpadmin:centos6.localdomain:002182-[INFO]:-Pre-data metadata backup complete
20180105:11:27:54 gpbackup:gpadmin:centos6.localdomain:002182-[INFO]:-Writing post-data metadata
20180105:11:27:54 gpbackup:gpadmin:centos6.localdomain:002182-[INFO]:-Post-data metadata backup complete
20180105:11:27:54 gpbackup:gpadmin:centos6.localdomain:002182-[INFO]:-Writing data to file
Tables backed up: 3 / 3 [==============================================================] 100.00% 0s
20180105:11:27:54 gpbackup:gpadmin:centos6.localdomain:002182-[INFO]:-Data backup complete
20180105:11:27:54 gpbackup:gpadmin:centos6.localdomain:002182-[INFO]:-Found neither /usr/local/greenplum-db/./bin/gp_email_contacts.yaml nor /home/gpadmin/gp_email_contacts.yaml
20180105:11:27:54 gpbackup:gpadmin:centos6.localdomain:002182-[INFO]:-Email containing gpbackup report /gpmaster/seg-1/backups/20180105/20180105112754/gpbackup_20180105112754_report will not be sent
20180105:11:27:55 gpbackup:gpadmin:centos6.localdomain:002182-[INFO]:-Backup completed successfullyПриведённая выше команда создаёт файл, содержащий глобальные и специфичные для базы данных метаданные, на хосте мастера базы данных RT.Warehouse в каталоге по умолчанию, $MASTER_DATA_DIRECTORY/backups/<YYYYMMDD>/<YYYYMMDDHHMMSS>/. Например:
$ ls /gpmaster/gpsne-1/backups/20180105/20180105112754
gpbackup_20180105112754_config.yaml gpbackup_20180105112754_report
gpbackup_20180105112754_metadata.sql gpbackup_20180105112754_toc.yamlПо умолчанию каждый сегмент хранит данные каждой таблицы для резервной копии в отдельном сжатом файле CSV в <seg_dir>/backups/<YYYYMMDD>/<YYYYMMDDHHMMSS>/:
$ ls /gpdata1/gpsne0/backups/20180105/20180105112754/
gpbackup_0_20180105112754_17166.gz gpbackup_0_20180105112754_26303.gz
gpbackup_0_20180105112754_21816.gzЧтобы объединить все файлы резервных копий в один каталог, включите параметр --backup-dir. Обратите внимание, что вы должны указать абсолютный путь с этой опцией:
$ gpbackup --dbname demo --backup-dir /home/gpadmin/backups
20171103:15:31:56 gpbackup:gpadmin:0ee2f5fb02c9:017586-[INFO]:-Starting backup of database demo
...
20171103:15:31:58 gpbackup:gpadmin:0ee2f5fb02c9:017586-[INFO]:-Backup completed successfully
$ find /home/gpadmin/backups/ -type f
/home/gpadmin/backups/gpseg0/backups/20171103/20171103153156/gpbackup_0_20171103153156_16543.gz
/home/gpadmin/backups/gpseg0/backups/20171103/20171103153156/gpbackup_0_20171103153156_16524.gz
/home/gpadmin/backups/gpseg1/backups/20171103/20171103153156/gpbackup_1_20171103153156_16543.gz
/home/gpadmin/backups/gpseg1/backups/20171103/20171103153156/gpbackup_1_20171103153156_16524.gz
/home/gpadmin/backups/gpseg-1/backups/20171103/20171103153156/gpbackup_20171103153156_config.yaml
/home/gpadmin/backups/gpseg-1/backups/20171103/20171103153156/gpbackup_20171103153156_predata.sql
/home/gpadmin/backups/gpseg-1/backups/20171103/20171103153156/gpbackup_20171103153156_global.sql
/home/gpadmin/backups/gpseg-1/backups/20171103/20171103153156/gpbackup_20171103153156_postdata.sql
/home/gpadmin/backups/gpseg-1/backups/20171103/20171103153156/gpbackup_20171103153156_report
/home/gpadmin/backups/gpseg-1/backups/20171103/20171103153156/gpbackup_20171103153156_toc.yamlПри выполнении операции резервного копирования вы можете использовать --single-data-file в ситуациях, когда дополнительные затраты на несколько файлов могут быть непомерно высокими. Например, если вы используете стороннее решение для хранения, такое как Data Domain, с резервными копиями.
При резервном копировании материализованного представления не создаются резервные копии данных материализованного представления. Резервируется только определение материализованного представления.
Чтобы использовать gprestore для восстановления из набора резервных копий, необходимо использовать параметр --timestamp, чтобы указать точное значение метки времени (YYYYMMDDHHMMSS) для восстановления. Включите параметр --create-db, если база данных не существует в кластере. Например:
$ dropdb demo
$ gprestore --timestamp 20171103152558 --create-db
20171103:15:45:30 gprestore:gpadmin:0ee2f5fb02c9:017714-[INFO]:-Restore Key = 20171103152558
20171103:15:45:31 gprestore:gpadmin:0ee2f5fb02c9:017714-[INFO]:-Creating database
20171103:15:45:44 gprestore:gpadmin:0ee2f5fb02c9:017714-[INFO]:-Database creation complete
20171103:15:45:44 gprestore:gpadmin:0ee2f5fb02c9:017714-[INFO]:-Restoring pre-data metadata from /gpmaster/gpsne-1/backups/20171103/20171103152558/gpbackup_20171103152558_predata.sql
20171103:15:45:45 gprestore:gpadmin:0ee2f5fb02c9:017714-[INFO]:-Pre-data metadata restore complete
20171103:15:45:45 gprestore:gpadmin:0ee2f5fb02c9:017714-[INFO]:-Restoring data
20171103:15:45:45 gprestore:gpadmin:0ee2f5fb02c9:017714-[INFO]:-Data restore complete
20171103:15:45:45 gprestore:gpadmin:0ee2f5fb02c9:017714-[INFO]:-Restoring post-data metadata from /gpmaster/gpsne-1/backups/20171103/20171103152558/gpbackup_20171103152558_postdata.sql
20171103:15:45:45 gprestore:gpadmin:0ee2f5fb02c9:017714-[INFO]:-Post-data metadata restore completeЕсли вы указали пользовательскую --backup-dir для объединения файлов резервных копий, включите ту же опцию --backup-dir при использовании gprestore для поиска файлов резервных копий:
$ dropdb demo
$ gprestore --backup-dir /home/gpadmin/backups/ --timestamp 20171103153156 --create-db
20171103:15:51:02 gprestore:gpadmin:0ee2f5fb02c9:017819-[INFO]:-Restore Key = 20171103153156
...
20171103:15:51:17 gprestore:gpadmin:0ee2f5fb02c9:017819-[INFO]:-Post-data metadata restore completeПо умолчанию gprestore не пытается восстановить глобальные метаданные для системы RT.Warehouse. Если это необходимо, включите аргумент --with-globals.
По умолчанию gprestore использует 1 соединение для восстановления данных таблицы и метаданных. Если у вас большой набор резервных копий, вы можете повысить производительность восстановления, увеличив количество параллельных подключений с помощью параметра --jobs. Например:
$ gprestore --backup-dir /home/gpadmin/backups/ --timestamp 20171103153156 --create-db --jobs 8Проверьте количество параллельных подключений к вашему набору резервных копий, чтобы определить оптимальное количество для быстрого восстановления данных.
|
Примечание. Вы не можете выполнить операцию параллельного восстановления с помощью gprestore, если резервная копия объединяет резервные копии таблиц в один файл для каждого сегмента с параметром gpbackup --single-data-file. |
Восстановление материализованного представления не восстанавливает данные материализованного представления. Восстанавливается только определение материализованного представления. Чтобы заполнить материализованное представление данными, используйте REFRESH MATERIALIZED VIEW. Таблицы, на которые ссылается определение материализованного представления, должны быть доступны при обновлении материализованного представления. В файле лога gprestore перечислены восстановленные материализованные представления и команды REFRESH MATERIALIZED VIEW, которые используются для заполнения материализованных представлений данными.
При выполнении операции резервного копирования или восстановления gpbackup и gprestore создают файл отчёта. Когда уведомление по электронной почте настроено, отправленное электронное письмо содержит содержимое файла отчёта.
Файл отчёта помещается в каталог резервной копии мастера базы данных RT.Warehouse. Имя файла отчёта содержит временную метку операции. Это форматы имён файлов отчётов gpbackup и gprestore.
gpbackup_<backup_timestamp>_report
gprestore_<backup_timestamp>_<restore_timesamp>_reportВ этих примерах имён файлов отчётов 20180213114446 — это временная метка резервного копирования, а 20180213115426 — временная метка операции восстановления.
gpbackup_20180213114446_report
gprestore_20180213114446_20180213115426_reportЭтот каталог резервного копирования на хосте мастера базы данных RT.Warehouse содержит файл отчёта gpbackup и gprestore.
$ ls -l /gpmaster/seg-1/backups/20180213/20180213114446
total 36
-r--r--r--. 1 gpadmin gpadmin 295 Feb 13 11:44 gpbackup_20180213114446_config.yaml
-r--r--r--. 1 gpadmin gpadmin 1855 Feb 13 11:44 gpbackup_20180213114446_metadata.sql
-r--r--r--. 1 gpadmin gpadmin 1402 Feb 13 11:44 gpbackup_20180213114446_report
-r--r--r--. 1 gpadmin gpadmin 2199 Feb 13 11:44 gpbackup_20180213114446_toc.yaml
-r--r--r--. 1 gpadmin gpadmin 404 Feb 13 11:54 gprestore_20180213114446_20180213115426_reportСодержимое файлов отчётов аналогично. Это пример содержимого файла отчёта gprestore.
Greenplum Database Restore Report
Timestamp Key: 20180213114446
GPDB Version: 5.4.1+dev.8.g9f83645 build commit:9f836456b00f855959d52749d5790ed1c6efc042
gprestore Version: 1.0.0-alpha.3+dev.73.g0406681
Database Name: test
Command Line: gprestore --timestamp 20180213114446 --with-globals --createdb
Start Time: 2018-02-13 11:54:26
End Time: 2018-02-13 11:54:31
Duration: 0:00:05
Restore Status: SuccessПри выполнении операции резервного копирования gpbackup добавляет информацию о резервном копировании в файл истории gpbackup, gpbackup_history.yaml, в каталог данных мастера базы данных RT.Warehouse. Файл содержит отметку времени резервного копирования, информацию о параметрах резервного копирования и информацию о наборе резервных копий для инкрементного резервного копирования. Начиная с gpbackup v1.19.0, этот файл также записывает неудачные операции резервного копирования. Этот файл не резервируется gpbackup.
gpbackup использует информацию в файле, чтобы найти подходящую резервную копию для инкрементной резервной копии, когда вы запускаете gpbackup с параметром --incremental и не указываете параметр --from-timesamp, чтобы указать резервную копию, которую вы хотите использовать в качестве последней резервной копии. в инкрементном резервном наборе.
Один из этих кодов возвращается после завершения gpbackup или gprestore.
gpbackup создаёт резервные копии всех схем и таблиц в указанной базе данных, если только вы не исключите или не включите отдельные объекты схемы или таблицы с параметрами фильтрации уровня схемы или таблицы.
Параметры уровня схемы — это параметры командной строки --include-schema, --include-schema-file или --exclude-schema, --exclude-schema-file для gpbackup. Например, если база данных demo включает только две схемы, wikipedia и twitter, обе следующие команды создают резервную копию только схемы wikipedia:
$ gpbackup --dbname demo --include-schema wikipedia
$ gpbackup --dbname demo --exclude-schema twitterВы можете включить несколько параметров --include-schema в gpbackup или несколько параметров --exclude-schema. Например:
$ gpbackup --dbname demo --include-schema wikipedia --include-schema twitterЕсли у вас большое количество схем, вы можете перечислить схемы в текстовом файле и указать файл с параметрами --include-schema-file или --exclude-schema-file в команде gpbackup. Каждая строка в файле должна определять одну схему, и файл не может содержать завершающие строки. Например, эта команда использует файл в домашнем каталоге gpadmin для включения набора схем.
gpbackup --dbname demo --include-schema-file /users/home/gpadmin/backup-schemasЧтобы отфильтровать отдельные таблицы, включённые в резервный набор или исключённые из резервного набора, укажите отдельные таблицы с параметром --include-table или параметром --exclude-table. Таблица должна быть квалифицирована схемой, <schema-name>.<table-name>. Параметры фильтрации отдельных таблиц можно указывать несколько раз. Однако --include-table и --exclude-table нельзя использовать в одной команде одновременно.
Вы можете создать список квалифицированных имён таблиц в текстовом файле. При перечислении таблиц в файле каждая строка в текстовом файле должна определять одну таблицу в формате <schema-name>.<table-name>. В файле не должно быть завершающих строк. Например:
wikipedia.articles
twitter.messageЕсли в имени таблицы или схемы используется какой-либо символ, кроме буквы нижнего регистра, цифры или символа подчёркивания, это имя необходимо заключить в двойные кавычки. Например:
beer."IPA"
"Wine".riesling
"Wine"."sauvignon blanc"
water.tonicПосле создания файла вы можете использовать его для включения или исключения таблиц с параметрами gpbackup --include-table-file или --exclude-table-file. Например:
$ gpbackup --dbname demo --include-table-file /home/gpadmin/table-list.txtВы можете комбинировать --include-schema с --exclude-table или --exclude-table-file для резервного копирования. В этом примере используется --include-schema с --exclude-table для резервного копирования схемы, за исключением одной таблицы.
$ gpbackup --dbname demo --include-schema mydata --exclude-table mydata.addressesВы не можете комбинировать --include-schema с--include-table или --include-table-file, и вы не можете комбинировать --exclude-schema с любым параметром фильтрации таблиц, таким как--exclude-table или --include-table.
При использовании --include-table или --include-table-file зависимые объекты автоматически не резервируются и не восстанавливаются, необходимо явно указать требуемые зависимые объекты. Например, если вы создаёте резервную копию или восстанавливаете представление или материализованное представление, вы также должны указать таблицы, которые использует это представление или материализованное представление. Если вы создаёте резервную копию или восстанавливаете таблицу, в которой используется последовательность, вы также должны указать эту последовательность.
По умолчанию gpbackup создаёт один файл для каждой таблицы в сегменте. Вы можете указать параметр --leaf-partition-data, чтобы создать один файл данных для каждой leaf-партиции партиционированной таблицы вместо одного файла. Вы также можете отфильтровать резервные копии по определённым leaf-партициям, перечислив имена leaf-партиций в текстовом файле для включения. Например, рассмотрим таблицу, созданную с помощью оператора:
demo=# CREATE TABLE sales (id int, date date, amt decimal(10,2))
DISTRIBUTED BY (id)
PARTITION BY RANGE (date)
( PARTITION Jan17 START (date '2017-01-01') INCLUSIVE ,
PARTITION Feb17 START (date '2017-02-01') INCLUSIVE ,
PARTITION Mar17 START (date '2017-03-01') INCLUSIVE ,
PARTITION Apr17 START (date '2017-04-01') INCLUSIVE ,
PARTITION May17 START (date '2017-05-01') INCLUSIVE ,
PARTITION Jun17 START (date '2017-06-01') INCLUSIVE ,
PARTITION Jul17 START (date '2017-07-01') INCLUSIVE ,
PARTITION Aug17 START (date '2017-08-01') INCLUSIVE ,
PARTITION Sep17 START (date '2017-09-01') INCLUSIVE ,
PARTITION Oct17 START (date '2017-10-01') INCLUSIVE ,
PARTITION Nov17 START (date '2017-11-01') INCLUSIVE ,
PARTITION Dec17 START (date '2017-12-01') INCLUSIVE
END (date '2018-01-01') EXCLUSIVE );
NOTICE: CREATE TABLE will create partition "sales_1_prt_jan17" for table "sales"
NOTICE: CREATE TABLE will create partition "sales_1_prt_feb17" for table "sales"
NOTICE: CREATE TABLE will create partition "sales_1_prt_mar17" for table "sales"
NOTICE: CREATE TABLE will create partition "sales_1_prt_apr17" for table "sales"
NOTICE: CREATE TABLE will create partition "sales_1_prt_may17" for table "sales"
NOTICE: CREATE TABLE will create partition "sales_1_prt_jun17" for table "sales"
NOTICE: CREATE TABLE will create partition "sales_1_prt_jul17" for table "sales"
NOTICE: CREATE TABLE will create partition "sales_1_prt_aug17" for table "sales"
NOTICE: CREATE TABLE will create partition "sales_1_prt_sep17" for table "sales"
NOTICE: CREATE TABLE will create partition "sales_1_prt_oct17" for table "sales"
NOTICE: CREATE TABLE will create partition "sales_1_prt_nov17" for table "sales"
NOTICE: CREATE TABLE will create partition "sales_1_prt_dec17" for table "sales"
CREATE TABLEЧтобы создать резервную копию только данных за последний квартал года, сначала создайте текстовый файл, в котором перечислены имена leaf-партиций вместо полного имени таблицы:
public.sales_1_prt_oct17
public.sales_1_prt_nov17
public.sales_1_prt_dec17Затем укажите файл с параметром --include-table-file, чтобы сгенерировать один файл данных для каждой leaf-партиции:
$ gpbackup --dbname demo --include-table-file last-quarter.txt --leaf-partition-dataКогда вы указываете --leaf-partition-data, gpbackup создаёт один файл данных на leaf-партицию при резервном копировании партиционированной таблицы. Например, эта команда создаёт один файл данных для каждой leaf-партиции:
$ gpbackup --dbname demo --include-table public.sales --leaf-partition-dataПри резервном копировании leaf-партиций данные leaf-партиции копируются вместе с метаданными для всей партиционированной таблицы.
После создания набора резервных копий с помощью gpbackup вы можете отфильтровать схемы и таблицы, которые вы хотите восстановить из набора резервных копий, используя параметры gprestore --include-schema и --include-table-file. Эти параметры работают так же, как их аналоги gpbackup, но имеют следующие ограничения:
gprestore выполняет специальную операцию фильтрованного восстановления с плагином хранилища, который поддерживает эту функцию, когда выполняются все следующие условия:
Плагин хранилища считывает и восстанавливает только те отношения, которые вы указываете из файла резервной копии, повышая производительность восстановления.
gpbackup и gprestore могут отправлять уведомления по электронной почте после завершения операции резервного копирования или восстановления.
Чтобы gpbackup или gprestore отправляли уведомления по электронной почте о состоянии, вы должны поместить файл с именем gp_email_contacts.yaml в домашний каталог пользователя, запустившего gpbackup или gprestore, в тот же каталог, что и утилиты ($GPHOME/bin). Утилита выдаёт сообщение, если не может найти файл gp_email_contacts.yaml ни в одном месте. Если оба расположения содержат файл .yaml, утилита использует файл в папке пользователя $HOME.
Строка темы электронного письма включает имя утилиты, отметку времени, статус задания (Success или Failure) и имя хоста базы данных RT.Warehouse, с которого вызывается gpbackup или gprestore. Это примеры строк темы для электронных писем gpbackup.
gpbackup 20180202133601 on gp-master completed: Successили же
gpbackup 20200925140738 on mdw completed: FailureЭлектронное письмо содержит сводную информацию об операции, включая параметры, продолжительность и количество объектов, зарезервированных или восстановленных.
|
Примечание. Почтовая утилита UNIX должна быть запущена на хосте базы данных RT.Warehouse и должна быть настроена так, чтобы суперпользователь RT.Warehouse (gpadmin) мог отправлять электронную почту. Также убедитесь, что исполняемый файл почтовой программы доступен через $PATH пользователя gpadmin. |
В YAML-файле gp_email_contacts.yaml уведомлений по электронной почте gpbackup и gprestore используются отступы (пробелы) для определения иерархии документа и взаимосвязи секций друг с другом. Использование белого пространства имеет большое значение. Пробелы не должны использоваться просто для целей форматирования, а вкладки вообще не должны использоваться.
|
Примечание. Если параметры status указаны неправильно, утилита не выдаёт предупреждение. Например, если в параметре success указана ошибка и установлено значение true, предупреждение не выдаётся и электронное письмо не отправляется на адрес электронной почты после успешной операции. Чтобы убедиться, что уведомления по электронной почте настроены правильно, запустите тесты с настроенными уведомлениями по электронной почте. |
Это формат YAML-файла gp_email_contacts.yaml для уведомлений gpbackup по электронной почте:
contacts:
gpbackup:
- address: <user>@<domain>
status:
success: [true | false]
success_with_errors: [true | false]
failure: [true | false]
gprestore:
- address: <user>@<domain>
status:
success: [true | false]
success_with_errors: [true | false]
failure: [true | false]Таблица 10— Секции файла YAML по электронной почте
| Секция | Описание |
|---|---|
| contacts | Необходимая. Секция, содержащая секции gpbackup и gprestore. Файл YAML может содержать секцию gpbackup, секцию gprestore или по одной из них. |
| gpbackup | Опционально. Начинает секцию электронной почты gpbackup. |
| address |
Необходимая. Необходимо указать хотя бы один адрес электронной почты. Можно указать несколько параметров адреса электронной почты. Для каждой секции address требуется секция status. :user@domain — это единственный действующий адрес электронной почты. |
| status |
Необходимая. Укажите, когда утилита отправляет электронное письмо на указанный адрес электронной почты. По умолчанию уведомление по электронной почте не отправляется. : вы указываете отправку уведомлений по электронной почте в зависимости от состояния завершения операции резервного копирования или восстановления. Должен быть указан хотя бы один из этих параметров, и каждый параметр может встречаться не более одного раза. **success** : Optional. Specify if an email is sent if the operation completes without errors. If the value is `true`, an email is sent if the operation completes without errors. If the value is `false` (the default), an email is not sent. **success_with_errors** : Optional. Specify if an email is sent if the operation completes with errors. If the value is `true`, an email is sent if the operation completes with errors. If the value is `false` (the default), an email is not sent. **failure** : Optional. Specify if an email is sent if the operation fails. If the value is `true`, an email is sent if the operation fails. If the value is `false` (the default), an email is not sent. |
|
gprestore
|
Опционально. Начинает секцию электронной почты gprestore. Эта секция содержит параметры address и status, которые используются для отправки уведомления по электронной почте после операции gprestore. Синтаксис такой же, как и в секции gpbackup. |
В этом примере файла YAML указывается отправка электронной почты на адреса электронной почты в зависимости от успеха или неудачи операции. Для операции резервного копирования электронное письмо отправляется на другой адрес в зависимости от успеха или неудачи операции резервного копирования. Для операции восстановления электронное письмо отправляется на адрес gpadmin@example.com только в случае успешного выполнения операции или её завершения с ошибками.
contacts:
gpbackup:
- address: gpadmin@example.com
status:
success:true
- address: my_dba@example.com
status:
success_with_errors: true
failure: true
gprestore:
- address: gpadmin@example.com
status:
success: true
success_with_errors: true|
Внимание. Все файлы метаданных gpbackup создаются с правами только на чтение. Никогда не удаляйте и не изменяйте файлы метаданных для набора резервных копий gpbackup. Это приведёт к тому, что файлы резервных копий не будут работать. |
Полный набор резервных копий для gpbackup включает несколько файлов метаданных, вспомогательных файлов и файлов данных CSV, каждый из которых имеет отметку времени создания резервной копии.
По умолчанию метаданные и вспомогательные файлы хранятся на хосте мастера базы данных RT.Warehouse в каталоге $MASTER_DATA_DIRECTORY/backups/YYYYMMDD/YYYYMMDDHHMMSS/. Если вы укажете пользовательский каталог резервного копирования, этот же путь к файлу будет создан как подкаталог каталога резервного копирования. В следующей таблице описаны имена и содержимое метаданных и вспомогательных файлов.
Таблица 11— Файлы метаданных gpbackup (мастер)
| Файл | Описание |
|---|---|
| gpbackup_<YYYYMMDDHHMMSS>_metadata.sql |
Содержит глобальные и специфичные для базы данных метаданные:
К глобальным объектам относятся:
Примечание. По умолчанию глобальные метаданные не восстанавливаются. Вы должны включить параметр --with-globals в команду gprestore, чтобы восстановить глобальные метаданные. Объекты, специфичные для базы данных, которые необходимо создать перед восстановлением фактических данных, включают:
Примечание. Данные материализованного представления не восстанавливаются, только определение.
Объекты, специфичные для базы данных, которые необходимо создать после восстановления фактических данных, включают:
|
| gpbackup_<YYYYMMDDHHMMSS>_toc.yaml | Содержит метаданные для поиска объекта DDL в файлах _predata.sql и _postdata.sql. Этот файл также содержит имена таблиц и OID, используемые для поиска соответствующих табличных данных в файлах данных CSV, которые создаются для каждого сегмента. |
| gpbackup_<YYYYMMDDHHMMSS>_report |
Содержит информацию об операции резервного копирования, которая используется для заполнения уведомления по электронной почте (если настроено), отправляемого после завершения резервного копирования. Этот файл содержит такую информацию, как:
|
| gpbackup_<YYYYMMDDHHMMSS>_config.yaml |
Содержит метаданные о выполнении конкретной задачи резервного копирования, в том числе:
|
| gpbackup_<YYYYMMDDHHMMSS>_statistics.sql |
Содержит статистику таблиц. Создаётся, когда указана опция gpbackup --with-stats. Статистика восстанавливается при указании опции gprestore --with-stats. |
| gpbackup_history.yaml |
Содержит информацию об опциях, которые использовались при создании резервной копии с помощью gpbackup, информацию об инкрементных резервных копиях и информацию о неудачных операциях резервного копирования. Хранится на хосте мастера базы данных RT.Warehouse в каталоге данных мастера базы данных RT.Warehouse. Этот файл не резервируется gpbackup. |
По умолчанию каждый сегмент создаёт один сжатый CSV-файл для каждой таблицы, резервная копия которой создаётся в сегменте. Вы можете дополнительно указать параметр --single-data-file, чтобы создать один файл данных для каждого сегмента. Файлы хранятся в <seg_dir>/backups/YYYYMMDD/YYYYMMDDHHMMSS/.
Если вы укажете пользовательский каталог резервного копирования, файлы данных сегмента будут скопированы по тому же пути к файлу, что и подкаталог каталога резервного копирования. Если вы включаете параметр --leaf-partition-data, gpbackup создаёт один файл данных для каждой leaf-партиции партиционированной таблицы, а не только одну таблицу для файла.
Каждый файл данных использует формат имени файла gpbackup_<content_id>.gz, где:
При желании вы можете указать уровень сжатия (от 1 до 9), используя параметр --compression-level, или полностью деактивировать сжатие с помощью --no-compression. Если вы не укажете уровень сжатия, gpbackup по умолчанию использует уровень сжатия 1.
Чтобы увеличить производительность и ёмкость хранилища, расширьте свою систему базы данных RT.Warehouse, добавив в систему хосты. Как правило, добавление хостов в кластер RT.Warehouse обеспечивает линейное масштабирование производительности и ёмкости хранилища.
Хранилища данных обычно растут со временем по мере сбора дополнительных данных и увеличения сроков хранения существующих данных. Иногда необходимо увеличить ёмкость базы данных, чтобы объединить различные хранилища данных в единую базу данных. Дополнительные вычислительные мощности (ЦП) также могут потребоваться для размещения недавно добавленных аналитических проектов. Хотя разумно предусмотреть возможности для роста, когда система первоначально определена, как правило, невозможно инвестировать в ресурсы задолго до того, как они потребуются. Поэтому вам следует ожидать периодического выполнения расширения базы данных.
Из-за архитектуры MPP RT.Warehouse при добавлении ресурсов в систему ёмкость и производительность остаются такими же, как если бы система изначально была реализована с добавленными ресурсами. В отличие от систем хранилища данных, которые требуют значительного времени простоя для создания дампа и восстановления данных, расширение системы базы данных RT.Warehouse представляет собой поэтапный процесс с минимальным временем простоя. Регулярные и нерегламентированные рабочие нагрузки могут продолжаться, пока данные перераспределяются и поддерживается согласованность транзакций. Администратор может запланировать деятельность по распределению так, чтобы она соответствовала текущим операциям, и может приостанавливать и возобновлять её по мере необходимости. Таблицы можно ранжировать таким образом, чтобы наборы данных перераспределялись в приоритетной последовательности, чтобы гарантировать, что критические рабочие нагрузки быстрее получат выгоду от расширенной ёмкости, или чтобы освободить место на диске, необходимое для перераспределения очень больших таблиц.
В процессе расширения используются стандартные операции базы данных RT.Warehouse, поэтому администраторы могут легко устранять неполадки и устранять неполадки. Зеркалирование сегментов и любые имеющиеся механизмы репликации остаются активными, поэтому отказоустойчивость не подвергается риску, а меры аварийного восстановления остаются эффективными.
Вы можете выполнить расширение базы данных RT.Warehouse, чтобы добавить инстансы сегментов и хосты сегментов с минимальным временем простоя. Как правило, добавление хостов в кластер RT.Warehouse обеспечивает линейное масштабирование производительности и ёмкости хранилища.
Хранилища данных обычно растут со временем, часто в непрерывном темпе, по мере сбора дополнительных данных и увеличения срока хранения существующих данных. Иногда необходимо увеличить ёмкость базы данных, чтобы объединить разрозненные хранилища данных в единую базу данных. Хранилищу данных также может потребоваться дополнительная вычислительная мощность (ЦП) для реализации дополнительных аналитических проектов. Хорошо предоставлять возможности для роста, когда система изначально определена, но даже если вы ожидаете высоких темпов роста, как правило, неразумно инвестировать в мощности задолго до того, как они потребуются. Таким образом, расширение базы данных — это проект, который вы должны выполнять периодически.
Когда вы расширяете свою базу данных, вы должны ожидать следующих качеств:
Планирование и физические аспекты проекта расширения составляют большую часть работы, чем расширение самой базы данных. Для планирования и реализации проекта потребуется многопрофильная команда. Для локальной установки необходимо выделить и подготовить пространство для новых серверов. Серверы должны быть указаны, приобретены, установлены, подключены, настроены и протестированы. Для облачных развёртываний также должны быть составлены аналогичные планы. Планирование новых аппаратных платформ описывает общие соображения по развёртыванию нового оборудования.
После предоставления новых аппаратных платформ и настройки их сетей настройте операционные системы и запустите тесты производительности с помощью утилит RT.Warehouse. В состав дистрибутива программного обеспечения базы данных RT.Warehouse входят утилиты, которые помогают тестировать и запускать новые серверы перед началом программной фазы расширения.
После установки и тестирования новых серверов начинается программная фаза процесса расширения базы данных RT.Warehouse. Этап программного обеспечения спроектирован таким образом, чтобы он был минимально разрушительным, согласованным с точки зрения транзакций, надёжным и гибким.
1. Первым шагом программного этапа процесса расширения является подготовка системы базы данных RT.Warehouse: добавление новых хостов сегментов и инициализация новых инстансов сегментов. Эту фазу можно запланировать на период низкой активности, чтобы избежать нарушения текущих бизнес-операций. В процессе инициализации выполняются следующие задачи:
После обновления системы новые инстансы сегментов на новых хостах сегментов становятся доступными.
2. Последним этапом программного этапа является перераспределение данных таблицы. Используя контрольные таблицы расширения в схеме gpexpand в качестве руководства, таблицы перераспределяются. Для каждой таблицы:
Когда все таблицы перераспределены, расширение завершено.
|
Внимание. Утилита gprestore не может восстановить резервные копии, сделанные до расширения с помощью утилиты gpbackup, поэтому сделайте резервную копию своих баз данных сразу после завершения расширения системы. |
Перераспределение данных таблицы — это длительный процесс, который создаёт большой объём сетевой и дисковой активности. Перераспределение некоторых очень больших баз данных может занять несколько дней. Чтобы свести к минимуму влияние повышенной активности на бизнес-операции, системные администраторы могут приостанавливать и возобновлять деятельность по расширению на разовой основе или в соответствии с заранее определённым графиком. Наборы данных могут быть распределены по приоритетам, чтобы критически важные приложения выиграли от расширения в первую очередь.
В типичной операции вы запускаете утилиту gpexpand четыре раза с различными параметрами в течение всего процесса расширения:
1. Чтобы создать входной файл расширения:
gpexpand -f hosts_file2. Чтобы инициализировать сегменты и создать схему расширения:
gpexpand -i input_filegpexpand создаёт каталог данных, копирует пользовательские таблицы из всех существующих баз данных в новые сегменты и записывает метаданные для каждой таблицы в схему расширения для отслеживания состояния. После завершения этого процесса операция расширения фиксируется и не может быть отменена.
3. Чтобы перераспределить данные таблицы:
gpexpand -d durationВо время инициализации gpexpand добавляет и инициализирует новые инстансы сегментов. Чтобы завершить расширение системы, вы должны запустить gpexpand, чтобы перераспределить таблицы данных между вновь добавленными инстансами сегментов. В зависимости от размера и масштаба вашей системы перераспределение может быть выполнено за один сеанс в часы малой загрузки или вы можете разделить процесс на пакеты в течение длительного периода. Каждая таблица или партиция недоступны для операций чтения или записи во время перераспределения. Поскольку каждая таблица перераспределяется между новыми сегментами, производительность базы данных должна постепенно улучшаться, пока она не превысит уровни производительности до расширения.
Вам может потребоваться запустить gpexpand несколько раз, чтобы завершить расширение в крупномасштабных системах, требующих нескольких сеансов перераспределения. gpexpand может выиграть от явного ранжирования перераспределения таблиц.
Пользователи могут получить доступ к базе данных RT.Warehouse во время инициализации, но они могут столкнуться со снижением производительности в системах, которые сильно зависят от распределения хэшей таблиц. Обычные операции, такие как задания ETL, пользовательские запросы и отчёты, могут продолжаться, хотя время отклика пользователей может увеличиться.
4. Чтобы удалить схему расширения:
gpexpand -cТщательное планирование поможет обеспечить успешный проект расширения RT.Warehouse.
Темы в этом разделе помогут вам подготовиться к расширению системы.
Этот чеклист суммирует задачи по расширению системы базы данных RT.Warehouse.
|
Онлайн-задачи перед расширением * Система запущена и доступна |
|
| Разработать и выполнить план заказа, создания и объединения в сеть новых аппаратных платформ или предоставления облачных ресурсов. | |
| Разработать план расширения базы данных. Сопоставить количество сегментов на хост, запланировать период простоя для тестирования производительности и создания схемы расширения, а также запланировать интервалы для перераспределения таблиц. | |
| Выполнить полный дамп схемы. | |
| Установить бинарные файлы базы данных RT.Warehouse на новые хосты. | |
| Скопировать ключи SSH на новые хосты (gpssh-exkeys). | |
| Проверить дисковый ввод-вывод и пропускную способность памяти нового оборудования или облачных ресурсов (gpcheckperf). | |
| Убедиться, что в каталоге данных мастера нет очень больших файлов в каталогах pg_log или gpperfmon/data. | |
|
Автономные задачи перед расширением * Система недоступна для всех действий пользователя во время этого процесса. |
|
| Убедиться, что проблем с каталогом нет (gpcheckcat). | |
| Проверить дисковый ввод-вывод и пропускную способность памяти объединённого существующего и нового оборудования или облачных ресурсов (gpcheckperf). | |
|
Онлайн-инициализация инстанса сегмента * Система запущена и доступна |
|
| Подготовить входной файл расширения (gpexpand). | |
| Инициализировать новые сегменты в массиве и создать схему расширения (gpexpand-i input_file). | |
|
Онлайн-расширение и распределение таблиц * Система запущена и доступна |
|
| Прежде чем приступить к перераспределению таблиц, остановить все автоматизированные процессы снапшотов или другие процессы, занимающие место на диске. | |
| Перераспределить таблицы через расширенную систему (gpexpand). | |
| Удалить схему расширения (gpexpand -c). | |
|
Запустите analyze, чтобы обновить статистику распределения. Во время расширения используйте gpexpand -a, а после расширения используйте analyze. |
|
|
Резервное копирование баз данных * Система запущена и доступна |
|
| Резервное копирование баз данных с помощью утилиты gpbackup. Резервные копии, созданные до начала расширения системы, не могут быть восстановлены в новой расширенной системе, поскольку утилита gprestore может восстанавливать резервные копии только в системе базы данных RT.Warehouse с тем же количеством сегментов. | |
Обдуманный и тщательный подход к развёртыванию совместимого оборудования значительно сводит к минимуму риск для процесса расширения.
Аппаратные ресурсы и конфигурации для новых хостов сегмента должны соответствовать существующим хостам.
Шаги по планированию и настройке новых аппаратных платформ различаются для каждого развёртывания. Некоторые соображения включают в себя:
Расширение базы данных RT.Warehouse может быть выполнено, когда система запущена и доступна. Запустите gpexpand, чтобы инициализировать новые инстансы сегментов в массиве и создать схему расширения.
Требуемое время зависит от количества объектов схемы в системе RT.Warehouse и других факторов, связанных с производительностью оборудования. В большинстве сред для инициализации новых сегментов требуется менее тридцати минут в автономном режиме.
Следующие утилиты нельзя запускать, пока gpexpand выполняет инициализацию сегмента:
|
Внимание. После того, как вы начнёте инициализировать новые сегменты, вы больше не сможете восстановить систему с помощью файлов резервных копий, созданных для системы до расширения. После успешного завершения инициализации расширение фиксируется и не может быть отменено. |
Если в вашей существующей системе есть зеркальные сегменты, для новых сегментов должно быть настроено зеркалирование. Если для существующих сегментов не настроены зеркала, вы не сможете добавить зеркала на новые хосты с помощью утилиты gpexpand.
Для массивов базы данных RT.Warehouse с зеркальными сегментами убедитесь, что вы добавили достаточно новых хост-машин для размещения новых зеркальных сегментов. Необходимое количество новых хостов зависит от вашей стратегии зеркалирования:
По умолчанию новые хосты инициализируются таким количеством основных сегментов, как и существующие хосты. Вы можете увеличить количество сегментов на хост или добавить новые сегменты к существующим хостам.
Например, если существующие хосты в настоящее время имеют два сегмента на хост, вы можете использовать gpexpand для инициализации двух дополнительных сегментов на существующих хостах, чтобы в общей сложности было четыре сегмента, и инициализировать четыре новых сегмента на новых хостах.
Интерактивный процесс создания входного файла расширения запрашивает эту опцию; вы также можете указать новые каталоги сегментов вручную во входном файле конфигурации.
При инициализации утилита gpexpand создаёт схему расширения с именем gpexpand в базе данных postgres.
Схема расширения хранит метаданные для каждой таблицы в системе, поэтому её состояние можно отслеживать на протяжении всего процесса расширения. Схема расширения состоит из двух таблиц и представления для отслеживания хода операции расширения:
Управляйте аспектами процесса расширения, изменяя gpexpand.status_detail. Например, удаление записи из этой таблицы не позволяет системе расширять таблицу на новые сегменты. Управляйте порядком, в котором таблицы обрабатываются для перераспределения, обновляя значение ранга для записи.
Перераспределение таблиц выполняется, пока система находится в сети. Для многих систем RT.Warehouse перераспределение таблиц выполняется за один сеанс gpexpand, запланированный на период низкого использования. В более крупных системах может потребоваться несколько сеансов и настройка порядка перераспределения таблиц, чтобы свести к минимуму влияние на производительность. Завершите перераспределение таблиц за один сеанс, если это возможно.
|
Внимание. Для выполнения перераспределения таблиц хосты вашего сегмента должны иметь достаточно места на диске для временного хранения копии вашей самой большой таблицы. Все таблицы недоступны для операций чтения и записи во время перераспределения. |
Влияние перераспределения таблиц на производительность зависит от размера, типа хранилища и структуры партиционирования таблицы. Для любой данной таблицы её перераспределение с помощью gpexpand занимает столько же времени, сколько операция CREATE TABLE AS SELECT. При перераспределении таблицы фактов в терабайтном масштабе утилита расширения может использовать большую часть доступных системных ресурсов, что может повлиять на производительность запросов или другие рабочие нагрузки базы данных.
При планировании этапа перераспределения учитывайте влияние блокировки ACCESS EXCLUSIVE на каждую таблицу и метод перераспределения данных таблицы. Действия пользователя над таблицей могут задержать её перераспределение, но также таблицы недоступны для действий пользователя во время перераспределения.
Вы можете управлять порядком перераспределения таблиц, настраивая их ранжирование. Управление порядком перераспределения может помочь приспособиться к ограниченному дисковому пространству и быстрее восстановить оптимальную производительность запросов с высоким приоритетом.
Существует два метода перераспределения данных при расширении базы данных RT.Warehouse.
В системах с большим количеством свободного места на диске (необходимым для хранения копии самой большой таблицы) вы можете сосредоточиться на восстановлении оптимальной производительности запросов как можно скорее, сначала перераспределив важные таблицы, которые интенсивно используются запросами. Назначьте этим таблицам высокий ранг и запланируйте операции перераспределения на периоды низкого использования системы. Запускайте по одному процессу перераспределения, пока не будут перераспределены большие или критически важные таблицы.
Если ваши существующие хосты имеют ограниченное дисковое пространство, вы можете предпочесть сначала перераспределить меньшие таблицы (например, таблицы измерений), чтобы освободить место для хранения копии самой большой таблицы. Доступное дисковое пространство в исходных сегментах увеличивается по мере перераспределения каждой таблицы в расширенном массиве. Когда во всех сегментах имеется достаточно свободного места для хранения копии самой большой таблицы, вы можете перераспределить большие или критические таблицы. Перераспределение больших таблиц требует эксклюзивных блокировок; запланируйте эту процедуру на непиковые часы.
Также обратите внимание на следующее:
gpexpand перераспределяет оптимизированные для добавления и сжатые таблицы, оптимизированные для добавления, с разной скоростью, чем Heap-таблицы. Мощность ЦП, необходимая для сжатия и распаковки данных, имеет тенденцию увеличивать влияние на производительность системы. Для таблиц одинакового размера с похожими данными вы можете обнаружить общие различия в производительности, например следующие:
|
Внимание. Если хосты вашей системы используют сжатие данных, используйте идентичные параметры сжатия на новых хостах, чтобы избежать нехватки места на диске. |
Поскольку утилита расширения может обрабатывать каждую отдельную партицию большой таблицы, эффективная структура партиций снижает влияние перераспределения таблиц на производительность. Только дочерние таблицы партиционированной таблицы настроены на политику случайного распределения. Блокировка чтения/записи для перераспределения одновременно применяется только к одной дочерней таблице.
Поскольку утилита gpexpand должна переиндексировать каждую проиндексированную таблицу после перераспределения, высокий уровень индексации оказывает большое влияние на производительность. В системах с интенсивным индексированием скорость перераспределения таблиц значительно ниже.
Убедитесь, что ваши новые хосты готовы к интеграции в существующую систему RT.Warehouse.
Чтобы подготовить новые хостs к расширению, установите бинарные файлы программного обеспечения базы данных RT.Warehouse, обменяйтесь необходимыми ключами SSH и запустите тесты производительности.
Запустите тесты производительности сначала на новых хостах, а затем на всех хостах. Запустите тесты на всех хостах с системой в автономном режиме, чтобы активность пользователя не искажала результаты.
Как правило, вы должны запускать тесты производительности, когда администратор изменяет сетевые параметры хоста или другие особые условия в системе. Например, если вы будете запускать расширенную систему на двух сетевых кластерах, запустите тесты на каждом кластере.
Новые хосты должны обмениваться ключами SSH с существующими хостами, чтобы административные утилиты RT.Warehouse могли подключаться ко всем сегментам без запроса пароля. Дважды выполните процесс обмена ключами с помощью утилиты gpssh-exkeys.
Сначала выполните процесс от имени пользователя root для удобства администрирования, а затем от имени пользователя gpadmin для утилит управления. Выполните следующие задания по порядку:
|
Примечание. Соглашение об именовании хостов сегмента базы данных RT.Warehouse — sdwN, где sdw — префикс, а N — целое число (sdw1, sdw2 и т.д.). Для хостов с несколькими интерфейсами принято добавлять тире (-) и число к имени хоста. Например, sdw1-1 и sdw1-2 — это два имени интерфейса для хоста sdw1. |
1. Создайте файл хоста с существующими именами хостов в вашем массиве и отдельный файл хоста с новыми именами хостов расширения. Для существующих хостов вы можете использовать тот же файл хоста, который использовался для настройки ключей SSH в системе. В файлах перечислите все хосты (сегментов и основного и резервного мастера) с одним именем в строке и без лишних строк или пробелов. Обменяйтесь ключами SSH, используя настроенные имена хостов для данного хоста, если вы используете конфигурацию с несколькими сетевыми картами. В этом примере mdw настроен с одной сетевой картой, а sdw1, sdw2 и sdw3 настроены с 4 сетевыми картами:
mdw
sdw1-1
sdw1-2
sdw1-3
sdw1-4
sdw2-1
sdw2-2
sdw2-3
sdw2-4
sdw3-1
sdw3-2
sdw3-3
sdw3-42. Войдите в систему как root на хосте мастера и получите файл greenplum_path.sh из вашей установки RT.Warehouse.
$ su -
# source /usr/local/greenplum-db/greenplum_path.sh3. Запустите утилиту gpssh-exkeys, ссылаясь на файлы списка хостов. Например:
# gpssh-exkeys -e /home/gpadmin/existing_hosts_file -x
/home/gpadmin/new_hosts_file4. gpssh-exkeys проверит удалённые хосты и выполняет обмен ключами между всеми хостами. При появлении запроса введите пароль пользователя root. Например:
***Enter password for root@hostname: <root_password>1. Используйте gpssh для создания пользователя gpadmin на всех хостах новых сегментов (если он еще не существует). Используйте список новых хостов, созданный вами для обмена ключами. Например:
# gpssh -f new_hosts_file '/usr/sbin/useradd gpadmin -d
/home/gpadmin -s /bin/bash'2. Установите пароль для нового пользователя gpadmin. В Linux это можно сделать на всех хостах сегмента одновременно с помощью gpssh. Например:
# gpssh -f new_hosts_file 'echo gpadmin_password | passwd
gpadmin --stdin'3. Убедитесь, что пользователь gpadmin создан, выполнив поиск его домашнего каталога:
# gpssh -f new_hosts_file ls -l /home1. Войдите в систему как gpadmin и запустите утилиту gpssh-exkeys, ссылаясь на файлы списка хостов. Например:
# gpssh-exkeys -e /home/gpadmin/existing_hosts_file -x
/home/gpadmin/new_hosts_file2. gpssh-exkeys проверит удалённые хосты и выполнит обмен ключами между всеми хостами. При появлении запроса введите пароль пользователя gpadmin. Например:
***Enter password for gpadmin@hostname: <gpadmin_password>Используйте утилиту gpcheckperf для проверки дискового ввода-вывода и пропускной способности памяти.
Чтобы запустить gpcheckperf:
1. Запустите утилиту gpcheckperf, используя файл хоста для новых хостов. Используйте параметр -d, чтобы указать файловые системы, которые вы хотите протестировать на каждом хосте. У вас должен быть доступ на запись к этим каталогам. Например:
$ gpcheckperf -f new_hosts_file -d /data1 -d /data2 -v2. Выполнение тестов утилитой может занять много времени, поскольку она копирует очень большие файлы между хостами. По завершении вы увидите сводные результаты тестов записи на диск, чтения с диска и потоковой передачи.
Для сети, разделённой на подсети, повторите эту процедуру с отдельным файлом хоста для каждой подсети.
Перед инициализацией системы с новыми сегментами выключите систему с помощью gpstop, чтобы действия пользователя не искажали результаты теста производительности. Затем повторите тесты производительности, используя файлы хостов, включающие все хосты, существующие и новые.
Используйте утилиту gpexpand для создания и инициализации новых инстансов сегментов и создания схемы расширения.
При первом запуске gpexpand с допустимым входным файлом он создаёт и инициализирует инстансы сегментов и создаёт схему расширения. После выполнения этих шагов запуск gpexpand определяет, была ли создана схема расширения, и, если да, выполняет перераспределение таблиц.
Чтобы начать расширение, gpexpand требуется входной файл, содержащий информацию о новых сегментах и хостах. Если вы запустите gpexpand без указания входного файла, утилита отобразит интерактивное интервью, которое соберёт необходимую информацию и автоматически создаст входной файл.
Если вы создаёте входной файл с помощью интерактивного интервью, вы можете указать файл со списком хостов расширения в запросе на интервью. Если ваша платформа или командная оболочка ограничивают длину списка хостов, указание хостов с -f может быть обязательным.
Перед запуском gpexpand для создания входного файла в интерактивном режиме убедитесь, что вы знаете:
Утилита автоматически создаёт входной файл на основе этой информации, dbid, content ID и значений каталога данных, хранящихся в gp_segment_configuration, и сохраняет файл в текущем каталоге.
Чтобы создать входной файл в интерактивном режиме:
1. Войдите на хост мастера как пользователь, который будет запускать вашу систему базы данных RT.Warehouse; например, gpadmin.
2. Запустите gpexpand. Утилита отображает сообщения о том, как подготовиться к операции расширения, и предлагает вам выйти или продолжить.
При необходимости укажите файл хостов с помощью -f. Например:
$ gpexpand -f /home/gpadmin/new_hosts_file3. При появлении запроса выберите Y, чтобы продолжить.
4. Если вы не указали файл хостов с помощью -f, вам будет предложено ввести имена хостов. Введите разделённый запятыми список имён новых хостов расширения. Не включайте имена хостов интерфейса. Например:
> sdw4, sdw5, sdw6, sdw7Чтобы добавить сегменты только к существующим хостам, введите в этом приглашении пустую строку. Не указывайте localhost или любое существующее имя хоста.
5. Введите стратегию зеркалирования, используемую в вашей системе, если таковая имеется. Варианты spread|grouped|none. Настройка по умолчанию grouped.
Убедитесь, что у вас достаточно хостов для выбранной стратегии группировки.
6. Введите количество новых основных сегментов для добавления, если таковые имеются. По умолчанию новые хосты инициализируются с тем же количеством основных сегментов, что и существующие хосты. Увеличьте количество сегментов на хост, введя число больше нуля. Введённое вами число будет числом дополнительных сегментов, инициализированных на всех хостах. Например, если существующие хосты в настоящее время имеют по два сегмента каждый, ввод значения 2 инициализирует ещё два сегмента на существующих хостах и четыре сегмента на новых хостах.
7. Если вы добавляете новые основные сегменты, введите новый корень каталога данных для новых основных сегментов. Не указывайте фактическое имя каталога данных, которое автоматически создается gpexand на основе существующих имён каталогов данных.
Например, если ваши существующие каталоги данных выглядят следующим образом:
/gpdata/primary/gp0
/gpdata/primary/gp1Затем введите следующее (по одному в каждом запросе), чтобы указать каталоги данных для двух новых основных сегментов:
/gpdata/primary
/gpdata/primaryКогда запустится инициализация, утилита создаст новые каталоги gp2 и gp3 в /gpdata/primary.
8. Если вы добавляете новые зеркальные сегменты, введите новый корень каталога данных для новых зеркальных сегментов. Не указывайте имя каталога данных; он создаётся автоматически gpexpand на основе существующих имён каталогов данных.
Например, если ваши существующие каталоги данных выглядят следующим образом:
/gpdata/mirror/gp0
/gpdata/mirror/gp1Введите следующее (по одному в каждом запросе), чтобы указать каталоги данных для двух новых зеркальных сегментов:
/gpdata/mirror
/gpdata/mirrorКогда запустится инициализация, утилита создаст новые каталоги gp2 и gp3 в каталоге /gpdata/mirror.
Эти основные и зеркальные корневые каталоги для новых сегментов должны существовать на хостах, а пользователь, запускающий gpexpand, должен иметь права на создание в них каталогов.
После того, как вы введёте всю необходимую информацию, утилита создаст входной файл и сохранит его в текущем каталоге. Например:
gpexpand_inputfile_yyyymmdd_145134Используйте интерактивный процесс интервью для создания собственного входного файла, если только ваш сценарий расширения не требует нетипичных требований.
Формат входных файлов расширения:
hostname|address|port|datadir|dbid|content|preferred_roleНапример:
sdw5|sdw5-1|50011|/gpdata/primary/gp9|11|9|p
sdw5|sdw5-2|50012|/gpdata/primary/gp10|12|10|p
sdw5|sdw5-2|60011|/gpdata/mirror/gp9|13|9|m
sdw5|sdw5-1|60012|/gpdata/mirror/gp10|14|10|mДля каждого нового сегмента этот формат входного файла расширения требует данных, представленных в таблице ниже.
Таблица 12— Данные для файла конфигурации расширения
| Параметр | Допустимые значения | Описание |
|---|---|---|
| hostname |
Имя хоста |
Имя хоста для хоста сегмента. |
| port |
Доступный номер порта |
Порт слушателя базы данных для сегмента, увеличенный на базовый номер порта существующего сегмента. |
| datadir |
Имя каталога |
Местоположение каталога данных для сегмента в соответствии с системным каталогом gp_segment_configuration. |
| dbid |
Integer. Не должно конфликтовать с существующими значениями dbid |
Идентификатор базы данных для сегмента. Вводимые значения должны последовательно увеличиваться из существующих значений dbid, показанных в системном каталоге gp_segment_configuration. Например, чтобы добавить четыре инстанса сегмента к существующему массиву из десяти сегментов со значениями dbid от 1 до 10, укажите новые значения dbid 11, 12, 13 и 14. |
| content |
Integer. Не должны конфликтовать с существующими значениями content |
Идентификатор контента сегмента. Основной сегмент и его зеркало должны иметь один и тот же идентификатор контента, последовательно увеличивающийся на основе существующих значений. |
| preferred_role | p | m |
Определяет, является ли этот сегмент основным или зеркальным. Укажите p для основного и m для зеркала. |
После создания входного файла запустите gpexpand, чтобы инициализировать новые Инстансы сегментов.
Чтобы запустить gpexpand с входным файлом:
$ gpexpand -i input_fileУтилита определит, существует ли схема расширения для системы базы данных RT.Warehouse. Если схема gpexpand существует, удалите её с помощью команды gpexpand -c перед началом новой операции расширения.
После инициализации новых сегментов и создания схемы расширения утилита выведет сообщение об успешном выполнении и завершит работу.
Когда процесс инициализации завершится, вы сможете подключиться к базе данных RT.Warehouse и просмотреть схему расширения. Схема gpexpand находится в базе данных postgres.
Вы можете откатить операцию настройки расширения (добавление инстансов сегмента и хостов сегмента) только в случае сбоя операции.
Если расширение завершается ошибкой на этапе инициализации, когда база данных отключена, необходимо сначала перезапустить базу данных в режиме master-only, выполнив команду gpstart -m.
Откатите неудачное расширение с помощью следующей команды:
gpexpand --rollbackВ любой момент вы можете проверить состояние расширения кластера, запустив утилиту gpstate с флагом -x:
gpexpand -xЕсли схема расширения существует в базе данных postgres, gpstate -x сообщит о ходе расширения. На первом этапе расширения gpstate сообщает о ходе инициализации нового сегмента. На втором этапе gpstate сообщает о ходе перераспределения таблиц, а также о том, приостановлено ли перераспределение или активно.
Вы также можете запросить схему расширения, чтобы увидеть статус расширения.
Перераспределите таблицы, чтобы сбалансировать существующие данные во вновь расширенном кластере.
После создания схемы расширения вы можете перераспределить таблицы по всей системе с помощью gpexpand. Планируйте запуск в часы малой загрузки, когда загрузка ЦП утилиты и блокировки таблиц оказывают минимальное влияние на операции. Ранжируйте таблицы, чтобы сначала перераспределить самые большие или наиболее важные таблицы.
|
Примечание. При перераспределении данных база данных RT.Warehouse должна работать в рабочем режиме. База данных RT.Warehouse не может находиться в ограниченном режиме или в режиме мастера. Нельзя указать параметры gpstart -R или -m для запуска базы данных RT.Warehouse. |
Пока происходит перераспределение таблиц, любые новые созданные таблицы или партиции распределяются по всем сегментам точно так же, как в нормальных условиях работы. Запросы могут обращаться ко всем сегментам даже до того, как соответствующие данные будут перераспределены в таблицы новых сегментов. Перераспределяемая таблица или партиция заблокированы и недоступны для операций чтения или записи. Когда его перераспределение завершится, нормальная работа возобновится.
Для больших систем можно управлять порядком перераспределения таблиц. Настройте значения рангов таблиц в схеме расширения, чтобы отдать приоритет интенсивно используемым таблицам и минимизировать влияние на производительность. Доступное свободное место на диске может повлиять на ранжирование таблицы.
Чтобы ранжировать таблицы для перераспределения, обновив значения ранга в gpexpand.status_detail, подключитесь к базе данных RT.Warehouse с помощью psql или другого поддерживаемого клиента. Обновите gpexpand.status_detail с помощью таких команд, как:
=> UPDATE gpexpand.status_detail SET rank=10;
=> UPDATE gpexpand.status_detail SET rank=1 WHERE fq_name = 'public.lineitem';
=> UPDATE gpexpand.status_detail SET rank=2 WHERE fq_name = 'public.orders';Эти команды понижают приоритет всех таблиц до 10, а затем присваивают ранг 1 lineitem и ранг 2 orders. Когда начинается перераспределение таблиц, сначала перераспределяется lineitem, затем orders и все остальные таблицы в gpexpand.status_detail. Чтобы исключить таблицу из перераспределения, удалите её из таблицы gpexpand.status_detail.
Чтобы перераспределить таблицы с помощью gpexpand:
$ gpexpand -d 60:00:00Утилита перераспределяет таблицы до тех пор, пока последняя таблица в схеме не будет завершена или не достигнет указанной продолжительности или времени окончания. gpexpand обновляет статус и время в gpexpand.status при запуске и завершении сеанса.
Вы можете запросить схему расширения в процессе перераспределения таблицы. Представление gpexpand.expansion_progress предоставляет текущую сводку о ходе выполнения, включая расчётную скорость перераспределения таблиц и расчётное время до завершения. Вы можете запросить таблицу gpexpand.status_detail для получения информации о состоянии каждой таблицы.
После завершения перераспределения первой таблицы gpexpand.expansion_progress вычисляет свои оценки и обновляет их на основе коэффициентов перераспределения всех таблиц. Вычисления перезапускаются каждый раз, когда вы запускаете сеанс перераспределения таблиц с помощью gpexpand. Чтобы отслеживать прогресс, подключитесь к базе данных RT.Warehouse с помощью psql или другого поддерживаемого клиента; запросите gpexpand.expansion_progress с помощью следующей команды:
=# SELECT * FROM gpexpand.expansion_progress;
name | value
------------------------------+-----------------------
Bytes Left | 5534842880
Bytes Done | 142475264
Estimated Expansion Rate | 680.75667095996092 MB/s
Estimated Time to Completion | 00:01:01.008047
Tables Expanded | 4
Tables Left | 4
(6 rows)В таблице gpexpand.status_detail хранится статус, время последнего обновления и другие сведения о каждой таблице в схеме. Чтобы увидеть статус таблицы, подключитесь к базе данных RT.Warehouse с помощью psql или другого поддерживаемого клиента и запросите gpexpand.status_detail:
=> SELECT status, expansion_started, source_bytes FROM
gpexpand.status_detail WHERE fq_name = 'public.sales';
status | expansion_started | source_bytes
-----------+----------------------------+--------------
COMPLETED | 2017-02-20 10:54:10.043869 | 4929748992
(1 row)Чтобы выполнить очистку после расширения кластера RT.Warehouse, удалите схему расширения.
Вы можете безопасно удалить схему расширения после завершения и проверки операции расширения. Чтобы выполнить ещё одну операцию расширения в системе RT.Warehouse, сначала удалите существующую схему расширения.
Чтобы удалить схему расширения:
$ gpexpand -c
|
Примечание. В некоторых системах требуется дважды нажать Enter. |
Вы можете использовать утилиту gpcopy для передачи данных между базами данных в разных кластерах базы данных RT.Warehouse.
gpcopy — это высокопроизводительная утилита, которая может копировать метаданные и данные из одной базы данных RT.Warehouse в другую базу данных RT.Warehouse. Вы можете перенести все содержимое базы данных или только выбранные таблицы. Кластеры могут иметь разные версии базы данных RT.Warehouse.
|
Примечание. Утилита gpcopy доступна как отдельная загрузка для базы данных RT.Warehouse. |
Вы можете контролировать систему базы данных RT.Warehouse с помощью различных инструментов, включенных в систему или доступных в качестве надстроек.
Наблюдение за ежедневной работой системы базы данных RT.Warehouse помогает администраторам понять поведение системы, спланировать рабочий процесс и устранить неполадки. В этой главе обсуждаются инструменты для мониторинга производительности и активности базы данных.
Кроме того, обязательно ознакомьтесь с рекомендуемыми задачами мониторинга и обслуживания, чтобы отслеживать действия, которые вы можете написать для быстрого обнаружения проблем в системе.
База данных RT.Warehouse включает дополнительную базу данных мониторинга и управления системой, gpperfmon, которую администраторы могут включить. Утилита командной строки gpperfmon_install создает базу данных gpperfmon и включает агенты сбора данных, которые собирают и сохраняют запросы и системные метрики в базе данных. Администраторы могут запрашивать метрики в базе данных gpperfmon.
RT.Warehouse Command Center, дополнительный веб-интерфейс, предоставляет информацию о состоянии кластера, графические инструменты администрирования, мониторинг запросов в реальном времени, а также исторические данные о кластерах и запросах.
Как администратор базы данных RT.Warehouse, вы должны отслеживать наличие проблемных событий в системе, таких как выход из строя сегмента или нехватка места на диске на хосте сегмента. В следующих разделах описывается, как отслеживать работоспособность системы базы данных RT.Warehouse и проверять определенную информацию о состоянии системы базы данных RT.Warehouse.
Система базы данных RT.Warehouse состоит из нескольких экземпляров PostgreSQL (основной и сегментов), охватывающих несколько машин. Для мониторинга системы базы данных RT.Warehouse вам необходимо знать информацию о системе в целом, а также информацию о состоянии отдельных экземпляров. Утилита gpstate предоставляет информацию о состоянии системы базы данных RT.Warehouse.
По умолчанию gpstate проверяет экземпляры сегментов и показывает краткий статус действительных и ошибочных сегментов. Например, для быстрого просмотреть состояние вашей системы базы данных RT.Warehouse:
$ gpstateЧтобы просмотреть более подробную информацию о конфигурации массива базы данных RT.Warehouse, используйте gpstate с параметром -s:
$ gpstate -sЕсли вы используете зеркальное отображение для избыточности данных, вам может понадобиться просмотреть список экземпляров зеркального сегмента в системе, их текущий статус синхронизации и сопоставление зеркального с первичным. Например, чтобы увидеть зеркальные сегменты в системе и их статус:
$ gpstate -mЧтобы увидеть сопоставление основного и зеркального сегментов:
$ gpstate -cЧтобы увидеть состояние резервного главного зеркала:
$ gpstate -fСамая важная задача администратора базы данных — убедиться, что файловые системы, в которых находятся главные каталоги и каталоги данных сегментов, не заполняются более чем на 70 процентов. Заполненный диск данных не приведет к повреждению данных, но может помешать нормальной работе базы данных. Если диск переполнится, это может привести к отключению сервера базы данных.
Вы можете использовать внешнюю таблицу gp_disk_free в административной схеме gp_toolkit для проверки оставшегося свободного места (в килобайтах) в файловых системах узла сегмента. Например:
=# SELECT * FROM gp_toolkit.gp_disk_free
ORDER BY dfsegment;Административная схема gp_toolkit содержит несколько представлений, которые можно использовать для определения использования дискового пространства для распределенной базы данных, схемы, таблицы или индекса базы данных RT.Warehouse.
Чтобы увидеть общий размер базы данных (в байтах), используйте представление gp_size_of_database в административной схеме gp_toolkit. Например:
=> SELECT * FROM gp_toolkit.gp_size_of_database
ORDER BY sodddatname;Административная схема gp_toolkit содержит несколько представлений для проверки размера таблицы. Представления размера таблицы перечисляют таблицу по идентификатору объекта (а не по имени). Чтобы проверить размер таблицы по имени, вы должны найти имя отношения (relname) в таблице pg_class. Например:
=> SELECT relname AS name, sotdsize AS size, sotdtoastsize
AS toast, sotdadditionalsize AS other
FROM gp_toolkit.gp_size_of_table_disk as sotd, pg_class
WHERE sotd.sotdoid=pg_class.oid ORDER BY relname;Административная схема gp_toolkit содержит ряд представлений для проверки размеров индексов. Чтобы увидеть общий размер всех индексов в таблице, используйте представление gp_size_of_all_table_indexes. Чтобы увидеть размер определенного индекса, используйте представление gp_size_of_index. Представления для определения размера индекса перечисляют таблицы и индексы по идентификатору объекта (а не по имени). Чтобы проверить размер индекса по имени, вы должны найти имя отношения (relname) в таблице pg_class. Например:
=> SELECT soisize, relname as indexname
FROM pg_class, gp_toolkit.gp_size_of_index
WHERE pg_class.oid=gp_size_of_index.soioid
AND pg_class.relkind='i';Все таблицы в базе данных RT.Warehouse распределены, то есть их данные разделены по всем сегментам системы. Неравномерно распределенные данные могут снизить производительность обработки запросов. Политика распределения таблицы, установленная во время создания таблицы, определяет, как распределяются строки таблицы.
Чтобы просмотреть столбцы, используемые в качестве ключа распределения данных для таблицы, вы можете использовать метакоманду \d+ в psql для проверки определения таблицы. Например:
=# \d+ sales
Table "retail.sales"
Column | Type | Modifiers | Description
-------------+--------------+-----------+-------------
sale_id | integer | |
amt | float | |
date | date | |
Has OIDs: no
Distributed by: (sale_id)Когда вы создаете реплицированную таблицу, база данных RT.Warehouse сохраняет все строки в таблице для каждого сегмента. Реплицированные таблицы не имеют ключа распределения. Если метакоманда \d+ сообщает о ключе распределения для нормально распределенной таблицы, то для реплицированной таблицы она показывает Distributed Replicated.
Чтобы посмотреть распределение строк данных таблицы (количество строк в каждом сегменте), вы можете запустить такой запрос, как:
=# SELECT gp_segment_id, count(*)
FROM table_name GROUP BY gp_segment_id;Считается, что таблица имеет сбалансированное распределение, если все сегменты имеют примерно одинаковое количество строк.
|
Примечание. Примечание. Если вы запустите этот запрос для реплицированной таблицы, произойдет сбой, поскольку база данных RT.Warehouse не разрешает пользовательским запросам ссылаться на системный столбец gp_segment_id (или системные столбцы ctid, cmin, cmax, xmin и xmax) в реплицированных таблицах. Поскольку в каждом сегменте есть все строки таблиц, реплицированные таблицы по определению распределяются равномерно. |
При обработке запроса все сегменты должны иметь одинаковую рабочую нагрузку, чтобы обеспечить максимально возможную производительность. Если вы обнаружите плохо работающий запрос, вам может потребоваться дальнейшее исследование с помощью команды EXPLAIN.
Рабочая нагрузка обработки запросов может быть неравномерной, если политика распределения данных таблицы и предикаты запроса не совпадают. Чтобы проверить перекос обработки, вы можете запустить такой запрос, как:
=# SELECT gp_segment_id, count(*) FROM table_name
WHERE column='value' GROUP BY gp_segment_id;Это покажет количество строк, возвращаемых сегментом для данного предиката WHERE.
Как отмечалось в разделе Просмотр распределения данных, этот запрос завершится ошибкой, если вы запустите его в реплицированной таблице, потому что вы не можете ссылаться на системный столбец gp_segment_id в запросе в реплицированной таблице.
Вы можете получить следующее предупреждающее сообщение при выполнении запроса, выполняющего операцию хеш-соединения:
Экстремальный перекос внутри Hashjoin.
Это происходит, когда входные данные оператора хеш-соединения искажены. Это не препятствует успешному завершению запроса. Вы можете выполнить следующие шаги, чтобы избежать перекоса в плане:
1. Убедитесь, что все таблицы фактов проанализированы.
2. Убедитесь, что анализируется любая заполненная временная таблица, используемая запросом.
3. Просмотрите план EXPLAIN ANALYZE для запроса и найдите следующее:
4. Проверьте, соответствуют ли фильтры, примененные в запросе, ключам распределения базовых таблиц. Если фильтры и ключи распределения совпадают, рассмотрите возможность перераспределения некоторых базовых таблиц с другими ключами распределения.
5. Проверьте кардинальность ключей соединения. Если они имеют низкую кардинальность, попробуйте переписать запрос с другими соединяемыми столбцами или дополнительными фильтрами для таблиц, чтобы уменьшить количество строк. Эти изменения могут изменить семантику запроса.
База данных RT.Warehouse отслеживает в своих системных каталогах различную информацию метаданных об объектах, хранящихся в базе данных, таких как таблицы, представления, индексы и т. д., а также о глобальных объектах, таких как роли и табличные пространства.
Вы можете использовать системные представления pg_stat_operations и pg_stat_partition_operations для поиска действий, выполняемых с объектом, например с таблицей. Например, чтобы увидеть действия, выполненные над таблицей, например, когда она была создана и когда она в последний раз очищалась и анализировалась:
=> SELECT schemaname as schema, objname as table,
usename as role, actionname as action,
subtype as type, statime as time
FROM pg_stat_operations
WHERE objname='cust';
schema | table | role | action | type | time
--------+-------+------+---------+-------+--------------------------
sales | cust | main | CREATE | TABLE | 2016-02-09 18:10:07.867977-08
sales | cust | main | VACUUM | | 2016-02-10 13:32:39.068219-08
sales | cust | main | ANALYZE | | 2016-02-25 16:07:01.157168-08
(3 rows)Чтобы просмотреть определение объекта, такого как таблица или представление, вы можете использовать метакоманду \d+ при работе в psql. Например, чтобы увидеть определение таблицы:
=> \d+ mytableВы можете создать и использовать представление session_level_memory_consumption, которое предоставляет информацию о текущем использовании памяти для сеансов, выполняющих запросы к базе данных RT.Warehouse. Представление содержит информацию о сеансе и такую информацию, как база данных, к которой подключен сеанс, запрос, который сеанс выполняет в данный момент, и память, используемая процессами сеанса.
Чтобы создать представление session_state.session_level_memory_consumption в базе данных RT.Warehouse, запустите скрипт CREATE EXTENSION gp_internal_tools; один раз для каждой базы данных. Например, чтобы установить представление в базу данных testdb, используйте эту команду:
$ psql -d testdb -c "CREATE EXTENSION gp_internal_tools;"Представление session_state.session_level_memory_consumption предоставляет информацию о потреблении памяти и времени простоя для сеансов, выполняющих SQL-запросы.
Когда управление ресурсами на основе очереди ресурсов активно, столбец is_runaway указывает, считает ли база данных RT.Warehouse сеанс неконтролируемым сеансом на основе потребления памяти vmem запросами сеанса. Согласно схеме управления ресурсами на основе очереди ресурсов, база данных RT.Warehouse считает сеанс неконтролируемым, когда запросы потребляют чрезмерное количество памяти. Параметр конфигурации сервера базы данных RT.Warehouse runaway_detector_activation_percent определяет условия, при которых база данных RT.Warehouse считает сеанс неконтролируемым сеансом.
Столбцы is_runaway, runaway_vmem_mb и runaway_command_cnt неприменимы, если активно управление ресурсами на основе группы ресурсов.
Таблица 13— session_state.session_level_memory_consumption
| Столбец | Тип | Рекомендации | Описание |
|---|---|---|---|
| datname | name | Имя базы данных, к которой подключен сеанс. | |
| sess_id | integer | Идентификатор сессии (Session ID). | |
| usename | name | Имя пользователя сеанса. | |
| query | text | Текущий SQL-запрос, который выполняется в сеансе. | |
| segid | integer | Идентификатор сегмента (Segment ID). | |
| vmem_mb | integer | Общее использование памяти vmem для сеанса в МБ. | |
| is_runaway | boolean | Сессия помечается как неуправляемая на сегменте. | |
| qe_count | integer | Количество процессов запросов для сеанса. | |
| active_qe_count | integer | Количество активных процессов запросов для сеанса | |
| dirty_qe_count | integer |
Количество процессов запросов, которые еще не освободили свою память. Значение равно -1 для сеансов, которые не выполняются. |
|
| runaway_vmem_mb | integer | Объем памяти vmem, который потреблял сеанс, когда был помечен как неуправляемый сеанс. | |
| runaway_command_cnt | integer | Счетчик команд для сеанса, когда он был помечен как неуправляемый сеанс. | |
| idle_start | timestamptz | Последний раз, когда процесс запроса в этом сеансе простаивал. |
Административная схема gp_toolkit базы данных RT.Warehouse содержит представления, отображающие информацию о рабочих файлах базы данных RT.Warehouse. База данных RT.Warehouse создает рабочие файлы на диске, если у нее недостаточно памяти для выполнения запроса в памяти. Эту информацию можно использовать для устранения неполадок и настройки запросов. Информация в представлениях также может использоваться для указания значений параметров конфигурации базы данных RT.Warehouse gp_workfile_limit_per_query и gp_workfile_limit_per_segment.
Это представления в схеме gp_toolkit:
Каждый инстанс базы данных в базе данных RT.Warehouse (мастер и сегменты) запускает сервер базы данных PostgreSQL с собственным файлом журнала сервера. Файлы журнала создаются в каталоге pg_log мастера и каталоге данных каждого сегмента.
Файлы лога сервера записываются в формате значений, разделенных запятыми (CSV). Некоторые записи лога не будут иметь значения для всех полей лога. Например, только записи лога, связанные с рабочим процессом запроса, будут иметь заполненный slice_id. Вы можете идентифицировать связанные записи лога конкретного запроса по идентификатору сеанса запроса (gp_session_id) и идентификатору команды (gp_command_count).
Таблица 14— Формат лога сервера базы данных RT.Warehouse
| # | Имя поля | Тип | Описание |
|---|---|---|---|
| 1 | event_time | timestamp with time zone | Время, когда запись лога была записана в лог |
| 2 | user_name | varchar(100) | Имя пользователя базы данных |
| 3 | database_name | varchar(100) | Имя базы данных |
| 4 | process_id | varchar(10) | Идентификатор системного процесса (с префиксом "p") |
| 5 | thread_id | varchar(50) | Количество потоков (с префиксом "th") |
| 6 | remote_host | varchar(100) | На мастере имя хоста/адрес клиентской машины. В сегменте имя хоста/адрес мастера. |
| 7 | remote_port | varchar(10) | Номер сегмента или главного порта |
| 8 | session_start_time | timestamp with time zone | Время, когда было открыто сеансовое соединение |
| 9 | transaction_id | int | ID транзакции верхнего уровня на мастере. Этот ID является родительским для любых подтранзакций. |
| 10 | gp_session_id | text | Номер идентификатора сеанса (с префиксом "con") |
| 11 | gp_command_count | text | Номер команды в сеансе (с префиксом «cmd») |
| 12 | gp_segment | text | Идентификатор содержимого сегмента (с префиксом «seg» для основных или «mir» для зеркал). Мастер всегда имеет идентификатор контента -1. |
| 13 | slice_id | text | ID среза (выполняемая часть плана запроса) |
| 14 | distr_tranx_id | text | ID распределенной транзакции |
| 15 | local_tranx_id | text | ID локальной транзакции |
| 16 | sub_tranx_id | text | ID части транзакции |
| 17 | event_severity | varchar(10) | Возможные значения: LOG, ERROR, FATAL, PANIC, DEBUG1, DEBUG2. |
| 18 | sql_state_code | varchar(10) | Код состояния SQL, связанный с сообщением лога |
| 19 | event_message | text | Текст лога или сообщения об ошибке |
| 20 | event_detail | text | Подробный текст сообщения, связанный с сообщением об ошибке или предупреждением |
| 21 | event_hint | text | Текст сообщения-подсказки, связанный с сообщением об ошибке или предупреждением |
| 22 | internal_query | text | Внутренне сгенерированный текст запроса |
| 23 | internal_query_pos | int | Индекс курсора в внутренне сгенерированном тексте запроса |
| 24 | event_context | text | Контекст, в котором генерируется это сообщение |
| 25 | debug_query_string | text | Предоставленная пользователем строка запроса с полной информацией для отладки. Эта строка может быть изменена для внутреннего использования |
| 26 | error_cursor_pos | int | Индекс курсора в строке запроса |
| 27 | func_name | text | Функция, в которой генерируется это сообщение |
| 28 | file_name | text | Файл внутреннего кода, в котором было создано сообщение |
| 29 | file_line | int | Строка файла кода, в которой было создано сообщение |
| 30 | stack_trace | text | Текст трассировки стека, связанный с этим сообщением |
База данных RT.Warehouse предоставляет утилиту под названием gplogfilter, которая может искать в файле лога базы данных RT.Warehouse записи, соответствующие заданным критериям. По умолчанию эта утилита выполняет поиск в основном файле лога базы данных RT.Warehouse в расположении лога по умолчанию. Например, чтобы отобразить последние три строки основного файла лога:
$ gplogfilter -n 3Для одновременного поиска по всем файлам лога сегментов запустите gplogfilter с помощью утилиты gpssh. Например, чтобы отобразить последние три строки файла лога каждого сегмента:
$ gpssh -f seg_host_file
=> source /usr/local/greenplum-db/greenplum_path.sh
=> gplogfilter -n 3 /gpdata/gp*/pg_log/gpdb*.logВ следующей таблице перечислены все определенные коды ошибок. Некоторые не используются, но определяются стандартом SQL. Также показаны классы ошибок. Для каждого класса ошибок существует стандартный код ошибки, состоящий из трех последних символов 000. Этот код используется только для ошибок, которые относятся к этому классу, но не имеют более конкретного кода.
Имя условия PL/pgSQL для каждого кода ошибки совпадает с фразой, показанной в таблице, с заменой пробелов символами подчеркивания. Например, код 22012, DIVISION BY ZERO, имеет имя условия DIVISION_BY_ZERO. Имена условий могут быть написаны как в верхнем, так и в нижнем регистре.
|
Примечание. PL/pgSQL не распознает предупреждения, в отличие от ошибок, имен условий; это классы 00, 01 и 02. |
Таблица 14— Коды SQL
| Код ошибки | Значение | Константа |
|---|---|---|
| Class 00 — Successful Completion | ||
| 00000 | SUCCESSFUL COMPLETION | successful_completion |
| Class 01 — Warning | ||
| 01000 | WARNING | warning |
| 0100C | DYNAMIC RESULT SETS RETURNED | dynamic_result_sets_returned |
| 01008 | IMPLICIT ZERO BIT PADDING | implicit_zero_bit_padding |
| 01003 | NULL VALUE ELIMINATED IN SET FUNCTION | null_value_eliminated_in_set_function |
| 01007 | PRIVILEGE NOT GRANTED | privilege_not_granted |
| 01006 | PRIVILEGE NOT REVOKED | privilege_not_revoked |
| 01004 | STRING DATA RIGHT TRUNCATION | string_data_right_truncation |
| 01P01 | DEPRECATED FEATURE | deprecated_feature |
| Class 02 — No Data (this is also a warning class per the SQL standard) | ||
| 02000 | NO DATA | no_data |
| 02001 | NO ADDITIONAL DYNAMIC RESULT SETS RETURNED | no_additional_dynamic_result_sets_returned |
| Class 03 — SQL Statement Not Yet Complete | ||
| 03000 | SQL STATEMENT NOT YET COMPLETE | sql_statement_not_yet_complete |
| Class 08 — Connection Exception | ||
| 08000 | CONNECTION EXCEPTION | connection_exception |
| 08003 | CONNECTION DOES NOT EXIST | connection_does_not_exist |
| 08006 | CONNECTION FAILURE | connection_failure |
| 08001 | SQLCLIENT UNABLE TO ESTABLISH SQLCONNECTION | sqlclient_unable_to_establish_sqlconnection |
| 08004 | SQLSERVER REJECTED ESTABLISHMENT OF SQLCONNECTION | sqlserver_rejected_establishment_of_sqlconnection |
| 08007 | TRANSACTION RESOLUTION UNKNOWN | transaction_resolution_unknown |
| 08P01 | PROTOCOL VIOLATION | protocol_violation |
| Class 09 — Triggered Action Exception | ||
| 09000 | TRIGGERED ACTION EXCEPTION | triggered_action_exception |
| Class 0A — Feature Not Supported | ||
| 0A000 | FEATURE NOT SUPPORTED | feature_not_supported |
| Class 0B — Invalid Transaction Initiation | ||
| 0B000 | INVALID TRANSACTION INITIATION | invalid_transaction_initiation |
| Class 0F — Locator Exception | ||
| 0F000 | LOCATOR EXCEPTION | locator_exception |
| 0F001 | INVALID LOCATOR SPECIFICATION | invalid_locator_specification |
| Class 0L — Invalid Grantor | ||
| 0L000 | INVALID GRANTOR | invalid_grantor |
| 0LP01 | INVALID GRANT OPERATION | invalid_grant_operation |
| Class 0P — Invalid Role Specification | ||
| 0P000 | INVALID ROLE SPECIFICATION | invalid_role_specification |
| Class 21 — Cardinality Violation | ||
| 21000 | CARDINALITY VIOLATION | cardinality_violation |
| Class 22 — Data Exception | ||
| 22000 | DATA EXCEPTION | data_exception |
| 2202E | ARRAY SUBSCRIPT ERROR | array_subscript_error |
| 22021 | CHARACTER NOT IN REPERTOIRE | character_not_in_repertoire |
| 22008 | DATETIME FIELD OVERFLOW | datetime_field_overflow |
| 22012 | DIVISION BY ZERO | division_by_zero |
| 22005 | ERROR IN ASSIGNMENT | error_in_assignment |
| 2200B | ESCAPE CHARACTER CONFLICT | escape_character_conflict |
| 22022 | INDICATOR OVERFLOW | indicator_overflow |
| 22015 | INTERVAL FIELD OVERFLOW | interval_field_overflow |
| 2201E | INVALID ARGUMENT FOR LOGARITHM | invalid_argument_for_logarithm |
| 2201F | INVALID ARGUMENT FOR POWER FUNCTION | invalid_argument_for_power_function |
| 2201G | INVALID ARGUMENT FOR WIDTH BUCKET FUNCTION | invalid_argument_for_width_bucket_function |
| 22018 | INVALID CHARACTER VALUE FOR CAST | invalid_character_value_for_cast |
| 22007 | INVALID DATETIME FORMAT | invalid_datetime_format |
| 22019 | INVALID ESCAPE CHARACTER | invalid_escape_character |
| 2200D | INVALID ESCAPE OCTET | invalid_escape_octet |
| 22025 | INVALID ESCAPE SEQUENCE | invalid_escape_sequence |
| 22P06 | NONSTANDARD USE OF ESCAPE CHARACTER | nonstandard_use_of_escape_character |
| 22010 | INVALID INDICATOR PARAMETER VALUE | invalid_indicator_parameter_value |
| 22020 | INVALID LIMIT VALUE | invalid_limit_value |
| 22023 | INVALID PARAMETER VALUE | invalid_parameter_value |
| 2201B | INVALID REGULAR EXPRESSION | invalid_regular_expression |
| 22009 | INVALID TIME ZONE DISPLACEMENT VALUE | invalid_time_zone_displacement_value |
| 2200C | INVALID USE OF ESCAPE CHARACTER | invalid_use_of_escape_character |
| 2200G | MOST SPECIFIC TYPE MISMATCH | most_specific_type_mismatch |
| 22004 | NULL VALUE NOT ALLOWED | null_value_not_allowed |
| 22002 | NULL VALUE NO INDICATOR PARAMETER | null_value_no_indicator_parameter |
| 22003 | NUMERIC VALUE OUT OF RANGE | numeric_value_out_of_range |
| 22026 | STRING DATA LENGTH MISMATCH | string_data_length_mismatch |
| 22001 | STRING DATA RIGHT TRUNCATION | string_data_right_truncation |
| 22011 | SUBSTRING ERROR | substring_error |
| 22027 | TRIM ERROR | trim_error |
| 22024 | UNTERMINATED C STRING | unterminated_c_string |
| 2200F | ZERO LENGTH CHARACTER STRING | zero_length_character_string |
| 22P01 | FLOATING POINT EXCEPTION | floating_point_exception |
| 22P02 | INVALID TEXT REPRESENTATION | invalid_text_representation |
| 22P03 | INVALID BINARY REPRESENTATION | invalid_binary_representation |
| 22P04 | BAD COPY FILE FORMAT | bad_copy_file_format |
| 22P05 | UNTRANSLATABLE CHARACTER | untranslatable_character |
| Class 23 — Integrity Constraint Violation | ||
| 23000 | INTEGRITY CONSTRAINT VIOLATION | integrity_constraint_violation |
| 23001 | RESTRICT VIOLATION | restrict_violation |
| 23502 | NOT NULL VIOLATION | not_null_violation |
| 23503 | FOREIGN KEY VIOLATION | foreign_key_violation |
| 23505 | UNIQUE VIOLATION | unique_violation |
| 23514 | CHECK VIOLATION | check_violation |
| Class 24 — Invalid Cursor State | ||
| 24000 | INVALID CURSOR STATE | invalid_cursor_state |
| Class 25 — Invalid Transaction State | ||
| 25000 | INVALID TRANSACTION STATE | invalid_transaction_state |
| 25001 | ACTIVE SQL TRANSACTION | active_sql_transaction |
| 25002 | BRANCH TRANSACTION ALREADY ACTIVE | branch_transaction_already_active |
| 25008 | HELD CURSOR REQUIRES SAME ISOLATION LEVEL | held_cursor_requires_same_isolation_level |
| 25003 | INAPPROPRIATE ACCESS MODE FOR BRANCH TRANSACTION | inappropriate_access_mode_for_branch_transaction |
| 25004 | INAPPROPRIATE ISOLATION LEVEL FOR BRANCH TRANSACTION | inappropriate_isolation_level_for_branch_transaction |
| 25005 | NO ACTIVE SQL TRANSACTION FOR BRANCH TRANSACTION | no_active_sql_transaction_for_branch_transaction |
| 25006 | READ ONLY SQL TRANSACTION | read_only_sql_transaction |
| 25007 | SCHEMA AND DATA STATEMENT MIXING NOT SUPPORTED | schema_and_data_statement_mixing_not_supported |
| 25P01 | NO ACTIVE SQL TRANSACTION | no_active_sql_transaction |
| 25P02 | IN FAILED SQL TRANSACTION | in_failed_sql_transaction |
| Class 26 — Invalid SQL Statement Name | ||
| 26000 | INVALID SQL STATEMENT NAME | invalid_sql_statement_name |
| Class 27 — Triggered Data Change Violation | ||
| 27000 | TRIGGERED DATA CHANGE VIOLATION | triggered_data_change_violation |
| Class 28 — Invalid Authorization Specification | ||
| 28000 | INVALID AUTHORIZATION SPECIFICATION | invalid_authorization_specification |
| Class 2B — Dependent Privilege Descriptors Still Exist | ||
| 2B000 | DEPENDENT PRIVILEGE DESCRIPTORS STILL EXIST | dependent_privilege_descriptors_still_exist |
| 2BP01 | DEPENDENT OBJECTS STILL EXIST | dependent_objects_still_exist |
| Class 2D — Invalid Transaction Termination | ||
| 2D000 | INVALID TRANSACTION TERMINATION | invalid_transaction_termination |
| Class 2F — SQL Routine Exception | ||
| 2F000 | SQL ROUTINE EXCEPTION | sql_routine_exception |
| 2F005 | FUNCTION EXECUTED NO RETURN STATEMENT | function_executed_no_return_statement |
| 2F002 | MODIFYING SQL DATA NOT PERMITTED | modifying_sql_data_not_permitted |
| 2F003 | PROHIBITED SQL STATEMENT ATTEMPTED | prohibited_sql_statement_attempted |
| 2F004 | READING SQL DATA NOT PERMITTED | reading_sql_data_not_permitted |
| Class 34 — Invalid Cursor Name | ||
| 34000 | INVALID CURSOR NAME | invalid_cursor_name |
| Class 38 — External Routine Exception | ||
| 38000 | EXTERNAL ROUTINE EXCEPTION | external_routine_exception |
| 38001 | CONTAINING SQL NOT PERMITTED | containing_sql_not_permitted |
| 38002 | MODIFYING SQL DATA NOT PERMITTED | modifying_sql_data_not_permitted |
| 38003 | PROHIBITED SQL STATEMENT ATTEMPTED | prohibited_sql_statement_attempted |
| 38004 | READING SQL DATA NOT PERMITTED | reading_sql_data_not_permitted |
| Class 39 — External Routine Invocation Exception | ||
| 39000 | EXTERNAL ROUTINE INVOCATION EXCEPTION | external_routine_invocation_exception |
| 39001 | INVALID SQLSTATE RETURNED | invalid_sqlstate_returned |
| 39004 | NULL VALUE NOT ALLOWED | null_value_not_allowed |
| 39P01 | TRIGGER PROTOCOL VIOLATED | trigger_protocol_violated |
| 39P02 | SRF PROTOCOL VIOLATED | srf_protocol_violated |
| Class 3B — Savepoint Exception | ||
| 3B000 | SAVEPOINT EXCEPTION | savepoint_exception |
| 3B001 | INVALID SAVEPOINT SPECIFICATION | invalid_savepoint_specification |
| Class 3D — Invalid Catalog Name | ||
| 3D000 | INVALID CATALOG NAME | invalid_catalog_name |
| Class 3F — Invalid Schema Name | ||
| 3F000 | INVALID SCHEMA NAME | invalid_schema_name |
| Class 40 — Transaction Rollback | ||
| 40000 | TRANSACTION ROLLBACK | transaction_rollback |
| 40002 | TRANSACTION INTEGRITY CONSTRAINT VIOLATION | transaction_integrity_constraint_violation |
| 40001 | SERIALIZATION FAILURE | serialization_failure |
| 40003 | STATEMENT COMPLETION UNKNOWN | statement_completion_unknown |
| 40P01 | DEADLOCK DETECTED | deadlock_detected |
| Class 42 — Syntax Error or Access Rule Violation | ||
| 42000 | SYNTAX ERROR OR ACCESS RULE VIOLATION | syntax_error_or_access_rule_violation |
| 42601 | SYNTAX ERROR | syntax_error |
| 42501 | INSUFFICIENT PRIVILEGE | insufficient_privilege |
| 42846 | CANNOT COERCE | cannot_coerce |
| 42803 | GROUPING ERROR | grouping_error |
| 42830 | INVALID FOREIGN KEY | invalid_foreign_key |
| 42602 | INVALID NAME | invalid_name |
| 42622 | NAME TOO LONG | name_too_long |
| 42939 | RESERVED NAME | reserved_name |
| 42804 | DATATYPE MISMATCH | datatype_mismatch |
| 42P18 | INDETERMINATE DATATYPE | indeterminate_datatype |
| 42809 | WRONG OBJECT TYPE | wrong_object_type |
| 42703 | UNDEFINED COLUMN | undefined_column |
| 42883 | UNDEFINED FUNCTION | undefined_function |
| 42P01 | UNDEFINED TABLE | undefined_table |
| 42P02 | UNDEFINED PARAMETER | undefined_parameter |
| 42704 | UNDEFINED OBJECT | undefined_object |
| 42701 | DUPLICATE COLUMN | duplicate_column |
| 42P03 | DUPLICATE CURSOR | duplicate_cursor |
| 42P04 | DUPLICATE DATABASE | duplicate_database |
| 42723 | DUPLICATE FUNCTION | duplicate_function |
| 42P05 | DUPLICATE PREPARED STATEMENT | duplicate_prepared_statement |
| 42P06 | DUPLICATE SCHEMA | duplicate_schema |
| 42P07 | DUPLICATE TABLE | duplicate_table |
| 42712 | DUPLICATE ALIAS | duplicate_alias |
| 42710 | DUPLICATE OBJECT | duplicate_object |
| 42702 | AMBIGUOUS COLUMN | ambiguous_column |
| 42725 | AMBIGUOUS FUNCTION | ambiguous_function |
| 42P08 | AMBIGUOUS PARAMETER | ambiguous_parameter |
| 42P09 | AMBIGUOUS ALIAS | ambiguous_alias |
| 42P10 | INVALID COLUMN REFERENCE | invalid_column_reference |
| 42611 | INVALID COLUMN DEFINITION | invalid_column_definition |
| 42P11 | INVALID CURSOR DEFINITION | invalid_cursor_definition |
| 42P12 | INVALID DATABASE DEFINITION | invalid_database_definition |
| 42P13 | INVALID FUNCTION DEFINITION | invalid_function_definition |
| 42P14 | INVALID PREPARED STATEMENT DEFINITION | invalid_prepared_statement_definition |
| 42P15 | INVALID SCHEMA DEFINITION | invalid_schema_definition |
| 42P16 | INVALID TABLE DEFINITION | invalid_table_definition |
| 42P17 | INVALID OBJECT DEFINITION | invalid_object_definition |
| Class 44 — WITH CHECK OPTION Violation | ||
| 44000 | WITH CHECK OPTION VIOLATION | with_check_option_violation |
| Class 53 — Insufficient Resources | ||
| 53000 | INSUFFICIENT RESOURCES | insufficient_resources |
| 53100 | DISK FULL | disk_full |
| 53200 | OUT OF MEMORY | out_of_memory |
| 53300 | TOO MANY CONNECTIONS | too_many_connections |
| Class 54 — Program Limit Exceeded | ||
| 54000 | PROGRAM LIMIT EXCEEDED | program_limit_exceeded |
| 54001 | STATEMENT TOO COMPLEX | statement_too_complex |
| 54011 | TOO MANY COLUMNS | too_many_columns |
| 54023 | TOO MANY ARGUMENTS | too_many_arguments |
| Class 55 — Object Not In Prerequisite State | ||
| 55000 | OBJECT NOT IN PREREQUISITE STATE | object_not_in_prerequisite_state |
| 55006 | OBJECT IN USE | object_in_use |
| 55P02 | CANT CHANGE RUNTIME PARAM | cant_change_runtime_param |
| 55P03 | LOCK NOT AVAILABLE | lock_not_available |
| Class 57 — Operator Intervention | ||
| 57000 | OPERATOR INTERVENTION | operator_intervention |
| 57014 | QUERY CANCELED | query_canceled |
| 57P01 | ADMIN SHUTDOWN | admin_shutdown |
| 57P02 | CRASH SHUTDOWN | crash_shutdown |
| 57P03 | CANNOT CONNECT NOW | cannot_connect_now |
| Class 58 — System Error | ||
| 58030 | IO ERROR | io_error |
| 58P01 | UNDEFINED FILE | undefined_file |
| 58P02 | DUPLICATE FILE | duplicate_file |
| Class F0 — Configuration File Error | ||
| F0000 | CONFIG FILE ERROR | config_file_error |
| F0001 | LOCK FILE EXISTS | lock_file_exists |
| Class P0 — PL/pgSQL Error | ||
| P0000 | PLPGSQL ERROR | plpgsql_error |
| P0001 | RAISE EXCEPTION | raise_exception |
| P0002 | NO DATA FOUND | no_data_found |
| P0003 | TOO MANY ROWS | too_many_rows |
| Class XX — Internal Error | ||
| XX000 | INTERNAL ERROR | internal_error |
| XX001 | DATA CORRUPTED | data_corrupted |
| XX002 | INDEX CORRUPTED | index_corrupted |
Чтобы система базы данных RT.Warehouse работала эффективно, базу данных необходимо регулярно очищать от просроченных данных, а статистику таблиц необходимо обновлять, чтобы оптимизатор запросов имел точную информацию.
База данных RT.Warehouse требует регулярного выполнения определенных задач для достижения оптимальной производительности. Обсуждаемые здесь задачи являются обязательными, но администраторы баз данных могут автоматизировать их с помощью стандартных средств UNIX, таких как сценарии cron. Администратор настраивает соответствующие сценарии и проверяет их успешное выполнение.
Дизайн модели параллелизма транзакций MVCC, используемой в базе данных RT.Warehouse, означает, что удаленные или обновленные строки данных по-прежнему занимают физическое пространство на диске, даже если они не видны для новых транзакций. Если в вашей базе данных много обновлений и удалений, существует много строк с истекшим сроком действия, и используемое ими пространство необходимо освободить с помощью команды VACUUM. Команда VACUUM также собирает статистику на уровне таблицы, такую как количество строк и страниц, поэтому также необходимо очищать оптимизированные для добавления таблицы, даже если нет места для освобождения от обновленных или удаленных строк.
Процесс vacuum таблицы, оптимизированной для добавления, отличается от процесса vacuum таблиц heap. На каждом сегменте создается новый файл сегмента и в него копируются видимые строки из текущего сегмента. После того как файл сегмента будет скопирован, планируется удалить исходный файл и сделать доступным новый файл сегмента. Для этого требуется достаточно свободного места на диске для копирования видимых строк до тех пор, пока исходный файл сегмента не будет удален.
Если отношение скрытых строк к общему количеству строк в файле сегмента меньше порогового значения (10 по умолчанию), файл сегмента не сжимается. Пороговое значение можно настроить с помощью параметра конфигурации сервера gp_appendonly_compaction_threshold. VACUUM FULL игнорирует значение gp_appendonly_compaction_threshold и перезаписывает файл сегмента независимо от соотношения.
Вы можете использовать функцию __gp_aovisimap_compaction_info() в схеме gp_toolkit для исследования эффективности операции VACUUM в таблицах, оптимизированных для добавления.
VACUUM можно отключить для таблиц, оптимизированных для добавления, с помощью параметра конфигурации сервера gp_appendonly_compaction.
Семантика транзакций MVCC RT.Warehouse зависит от сравнения номеров идентификаторов транзакций (XID) для определения видимости для других транзакций. Идентификаторы транзакций сравниваются с использованием арифметики по модулю 232, поэтому система RT.Warehouse, в которой выполняется более двух миллиардов транзакций, может столкнуться с переносом идентификаторов транзакций, где прошлые транзакции кажутся будущими. Это означает, что результаты прошлых транзакций становятся невидимыми. Поэтому необходимо использовать VACUUM на каждую таблицу в каждой базе данных по крайней мере один раз на каждые два миллиарда транзакций.
База данных RT.Warehouse присваивает значения XID только транзакциям, которые включают операции DDL или DML, которые обычно являются единственными транзакциями, для которых требуется XID.
|
Внимание. База данных RT.Warehouse отслеживает идентификаторы транзакций. Если вы не используете vacuum базы данных регулярно, база данных RT.Warehouse выдаст предупреждение и ошибку. |
База данных RT.Warehouse выдает следующее предупреждение, когда значительная часть идентификаторов транзакций больше недоступна и до того, как произойдет перенос идентификаторов транзакций:
WARNING: database "database_name" must be vacuumed within number_of_transactions transactionsПри появлении предупреждения требуется операция VACUUM. Если операция VACUUM не выполняется, база данных RT.Warehouse прекращает создание транзакций, когда она достигает предела до того, как происходит перенос идентификатора транзакции. База данных RT.Warehouse выдает ошибку, когда прекращает создавать транзакции, чтобы избежать возможной потери данных:
FATAL: database is not accepting commands to avoid
wraparound data loss in database "database_name"Параметр конфигурации базы данных RT.Warehouse xid_warn_limit определяет время отображения предупреждения. Параметр xid_stop_limit определяет, когда база данных RT.Warehouse прекращает создание транзакций.
Когда база данных RT.Warehouse достигает предела идентификатора транзакции xid_stop_limit из-за нечастого обслуживания VACUUM, она перестает отвечать на запросы. Чтобы выйти из этой ситуации, выполните следующие действия от имени администратора базы данных:
Многочисленные обновления базы данных с помощью команд CREATE и DROP увеличивают размер системного каталога и влияют на производительность системы. Например, выполнение многих инструкций DROP TABLE снижает общую производительность системы из-за чрезмерного сканирования данных во время операций с метаданными в таблицах каталога. Потеря производительности происходит от тысяч до десятков тысяч операторов DROP TABLE, в зависимости от системы.
Следует регулярно запускать процедуру обслуживания системного каталога, чтобы освободить пространство, занимаемое удаленными объектами. Если обычная процедура давно не выполнялась, может потребоваться запустить более интенсивную процедуру для очистки системного каталога.
Рекомендуется периодически запускать REINDEX и VACUUM для системного каталога, чтобы очистить место, занимаемое удаленными объектами в системных индексах и таблицах. Если регулярные операции с базой данных включают многочисленные операторы DROP, безопасно и уместно запускать процедуру обслуживания системного каталога с помощью VACUUM ежедневно в нерабочие часы. Вы можете сделать это, пока система доступна.
Этапы обслуживания системного каталога базы данных RT.Warehouse:
Выполните REINDEX для таблиц системного каталога, чтобы перестроить индексы системного каталога. Это устраняет раздувание индексов и повышает производительность VACUUM.
|
Внимание. При выполнении REINDEX для таблиц системного каталога произойдет блокировка таблиц, что может повлиять на текущие запросы. Вы можете запланировать операцию REINDEX на период низкой активности, чтобы не прерывать текущие бизнес-операции. |
Выполните VACUUM для таблиц системного каталога.
Выполните ANALYZE для таблиц системного каталога, чтобы обновить статистику таблицы каталога.
Этот пример скрипта выполняет REINDEX, VACUUM и ANALYZE системного каталога базы данных RT.Warehouse. В сценарии замените <database-name> именем базы данных.
#!/bin/bash
DBNAME="<database-name>"
SYSTABLES="' pg_catalog.' || relname || ';' FROM pg_class a, pg_namespace b
WHERE a.relnamespace=b.oid AND b.nspname='pg_catalog' AND a.relkind='r'"
reindexdb --system -d $DBNAME
psql -tc "SELECT 'VACUUM' || $SYSTABLES" $DBNAME | psql -a $DBNAME
analyzedb -s pg_catalog -d $DBNAME
|
Внимание. Если вы выполняете обслуживание каталога в течение периода обслуживания и вам необходимо остановить процесс из-за нехватки времени, запустите функцию базы данных RT.Warehouse pg_cancel_backend(<PID>), чтобы безопасно остановить процесс базы данных RT.Warehouse. |
Если обслуживание системного каталога не проводилось в течение длительного времени, каталог может раздуться из-за мертвого пространства; это приводит к чрезмерно длительному времени ожидания для простых операций с метаданными. Ожидание более двух секунд для получения списка пользовательских таблиц, например, с помощью метакоманды \d из psql, указывает на раздувание каталога.
Если вы видите признаки раздувания системного каталога, вы должны выполнить интенсивную процедуру обслуживания системного каталога с VACUUM FULL в течение запланированного периода простоя. В течение этого периода остановите все действия с каталогом в системе; процедура обслуживания системного каталога VACUUM FULL устанавливает эксклюзивные блокировки системного каталога.
Выполнение регулярных процедур обслуживания системного каталога может предотвратить необходимость в этой более дорогостоящей процедуре.
Этапы интенсивного обслуживания системного каталога:
|
Внимание. Таблица системного каталога pg_attribute обычно является самой большой таблицей каталога. Если таблица pg_attribute значительно раздута, операция VACUUM FULL для этой таблицы может потребовать значительного времени и может потребоваться отдельное выполнение. Наличие обоих этих условий указывает на сильно раздутую таблицу pg_attribute, для которой может потребоваться длительное время VACUUM FULL:
|
База данных RT.Warehouse использует оптимизатор запросов на основе затрат, который опирается на статистику базы данных. Точная статистика позволяет оптимизатору запросов лучше оценивать селективность и количество строк, извлекаемых операцией запроса. Эти оценки помогают ему выбрать наиболее эффективный план запроса. Команда ANALYZE собирает статистику на уровне столбцов для оптимизатора запросов.
Вы можете запускать операции VACUUM и ANALYZE в одной команде. Например:
=# VACUUM ANALYZE mytable;Выполнение команды VACUUM ANALYZE может привести к неправильной статистике, если команда запускается для таблицы со значительным объемом раздувания (значительный объем дискового пространства таблицы занят удаленными или устаревшими строками). Для больших таблиц команда ANALYZE вычисляет статистику из случайной выборки строк. Он оценивает количество строк в таблице, умножая среднее количество строк на страницу в выборке на количество фактических страниц в таблице. Если образец содержит много пустых страниц, расчетное количество строк может быть неточным.
Для таблицы можно просмотреть информацию о количестве неиспользуемого дискового пространства (место, которое занято удаленными или устаревшими строками) в представлении gp_toolkit gp_bloat_diag. Если столбец bdidiag для таблицы содержит значение «значительный объем подозрений на раздувание», значит, значительный объем дискового пространства таблицы состоит из неиспользуемого пространства. Записи добавляются в представление gp_bloat_diag после очистки таблицы.
Чтобы удалить из таблицы неиспользуемое дисковое пространство, вы можете запустить команду VACUUM FULL для таблицы. Из-за требований к блокировке таблицы VACUUM FULL может быть невозможен до периода обслуживания.
В качестве временного решения запустите ANALYZE, чтобы вычислить статистику по столбцам, а затем запустите VACUUM для таблицы, чтобы сгенерировать точное количество строк. В этом примере выполняется ANALYZE, а затем VACUUM в таблице cust_info.
ANALYZE cust_info;
VACUUM cust_info;
|
Внимание. Если вы собираетесь выполнять запросы к многораздельным таблицам с включенной GPORCA (по умолчанию), вы должны собрать статистику по корневому разделу многораздельной таблицы с помощью команды ANALYZE. |
|
Примечание. Вы можете использовать утилиту базы данных RT.Warehouse analyzedb для обновления статистики таблицы. Таблицы можно анализировать одновременно. Для таблиц, оптимизированных для добавления, analyzedb обновляет статистику только в том случае, если она устарела. |
Для индексов B-дерева доступ к недавно созданному индексу немного быстрее, чем к индексу, который многократно обновлялся, потому что логически смежные страницы обычно также физически смежны во вновь созданном индексе. Периодическая переиндексация старых индексов может улучшить скорость доступа. Если на странице удалены все ключи индекса, кроме нескольких, то на странице индекса будет потрачено неиспользуемое место. Переиндексация вернет это потраченное впустую пространство. В базе данных RT.Warehouse зачастую быстрее удалить индекс (DROP INDEX), а затем создать его заново (CREATE INDEX), чем использовать команду REINDEX.
Для столбцов таблицы с индексами некоторые операции, такие как массовые обновления или вставки в таблицу, могут выполняться медленнее из-за обновлений индексов. Чтобы повысить производительность массовых операций над таблицами с индексами, вы можете удалить индексы, выполнить массовую операцию, а затем заново создать индекс.
Выходные данные лога базы данных RT.Warehouse имеют тенденцию быть объемными, особенно на более высоких уровнях отладки, и вам не нужно сохранять их бесконечно. Администраторы должны периодически очищать старые лог-файлы.
В базе данных RT.Warehouse по умолчанию включена ротация файлов лога для логов основной базы данных и базы данных сегментов. Файлы журналов создаются в подкаталоге pg_log главного каталога и каталога данных каждого сегмента с использованием следующего соглашения об именах: gpdb-YYYY-MM-DD_hhmmss.csv. Администраторам необходимо реализовать сценарии или программы для периодической очистки старых файлов журналов в каталоге pg_log мастера и каждого экземпляра сегмента.
Ротация лога может быть вызвана размером текущего или возрастом текущего лог-файла. Параметр конфигурации log_rotation_size задает размер отдельного файла лога, который запускает ротацию лога. Когда размер файла лога равен или превышает указанный размер, файл закрывается и создается новый файл лога. Значение log_rotation_size указывается в килобайтах. Значение по умолчанию — 1048576 килобайт или 1 ГБ. Если для log_rotation_size установлено значение 0, ротация на основе размера отключена.
Параметр конфигурации log_rotation_age указывает возраст файла лога, который запускает ротацию. По истечении указанного времени, с момента создания файла лога, файл закрывается и создается новый файл журнала. По умолчанию log_rotation_age, 1d, создает новый файл журнала через 24 часа после создания текущего файла журнала. Если для log_rotation_age установлено значение 0, ротация на основе времени отключена.
Лог-файлы для утилит управления базой данных RT.Warehouse по умолчанию записываются в ~/gpAdminLogs. Соглашение об именах файлов журнала управления:
script_name_date.logФормат записи лога:
timestamp:utility:host:user:[INFO|WARN|FATAL]:messageФайл лога для выполнения конкретной утилиты добавляется к ее ежедневному файлу лога каждый раз при запуске этой утилиты.
В этом разделе перечислены действия по мониторингу и техническому обслуживанию, рекомендуемые для обеспечения высокой доступности и стабильной производительности вашего кластера базы данных RT.Warehouse.
Таблицы в следующих разделах предлагают действия, которые системный администратор RT.Warehouse может периодически выполнять для обеспечения оптимальной работы всех компонентов системы. Действия по мониторингу помогают обнаруживать и диагностировать проблемы на ранней стадии. Действия по обслуживанию помогают поддерживать систему в актуальном состоянии и избегать снижения производительности, например, из-за раздутых системных таблиц или уменьшения свободного места на диске.
Нет необходимости реализовывать все эти предложения в каждом кластере; используйте рекомендации по частоте и степени серьезности как руководство для реализации мер в соответствии с вашими требованиями к обслуживанию.
Таблица 15— Мониторинг состояния базы данных
| Действие | Процедура | Корректирующие действия |
|---|---|---|
|
Список сегментов, которые в настоящее время недоступны. Если возвращаются какие-либо строки, это должно генерировать предупреждение или оповещение. Рекомендуемая частота: запускать каждые 5-10 минут. Серьезность: ВАЖНО |
Запустите следующий запрос в базе данных postgres:
SELECT * FROM gp_segment_configuration WHERE status <> 'u'; |
Если запрос возвращает какие-либо строки, выполните следующие действия, чтобы устранить проблему:
|
|
Проверьте сегменты, которые в настоящее время находятся в режиме отслеживания изменений. Если возвращаются какие-либо строки, это должно генерировать предупреждение или оповещение. Рекомендуемая частота: запускать каждые 5-10 минут. Серьезность: ВАЖНО |
Выполните следующий запрос в базе данных postgres: SELECT * FROM gp_segment_configuration WHERE mode = 'c'; |
Если запрос возвращает какие-либо строки, выполните следующие действия, чтобы устранить проблему:
|
|
Проверьте сегменты, которые в настоящее время повторно синхронизируются. Если возвращаются строки, это должно генерировать предупреждение или оповещение. Рекомендуемая частота: запускать каждые 5-10 минут. Серьезность: ВАЖНО |
Выполните следующий запрос в базе данных postgres: SELECT * FROM gp_segment_configuration WHERE mode = 'r'; |
Когда этот запрос возвращает строки, это означает, что сегменты находятся в процессе повторной синхронизации. Если состояние не меняется с 'r' на 's', проверьте файлы pg_log с основных и зеркал затронутых сегментов на наличие ошибок. |
|
Проверьте сегменты, которые не работают в своей оптимальной роли. Если какие-либо сегменты найдены, возможно, кластер не сбалансирован. Если возвращаются какие-либо строки, это должно генерировать предупреждение или оповещение. Рекомендуемая частота: запускать каждые 5-10 минут. Серьезность: ВАЖНО |
Выполните следующий запрос в базе данных postgres: SELECT * FROM gp_segment_configuration WHERE preferred_role <> role; |
Когда сегменты не работают в своей предпочтительной роли, хосты имеют нечетное количество первичных сегментов на каждом хосте, что означает, что обработка неравномерна. Дождитесь потенциального окна и перезапустите базу данных, чтобы сегменты заняли свои предпочтительные роли. |
|
Запустите распределенный запрос, чтобы проверить, работает ли он во всех сегментах. Для каждого основного сегмента должна быть возвращена одна строка. Рекомендуемая частота: запускать каждые 5-10 минут. Серьезность: КРИТИЧЕСКАЯ |
Выполните следующий запрос в базе данных postgres: SELECT gp_segment_id, count(*) FROM gp_dist_random('pg_class') GROUP BY 1; |
Если этот запрос завершается ошибкой, возникает проблема с диспетчеризацией некоторых сегментов в кластере. Это редкое событие. Проверьте хосты, которые не могут быть отправлены, чтобы убедиться в отсутствии проблем с оборудованием или сетью. |
|
Проверьте состояние зеркалированного мастера в базе данных RT.Warehouse. Если значение отличается от «STREAMING», создается оповещение или предупреждение. Рекомендуемая частота: запускать каждые 5-10 минут. Серьезность: ВАЖНО |
Запустите следующую команду psql: psql dbname -c 'SELECT pid, state FROM pg_stat_replication;' |
Проверьте файл pg_log главного и резервного мастера на наличие ошибок. Если неожиданных ошибок нет и машины работают, запустите утилиту gpinitstandby, чтобы перевести резервную машину в режим онлайн. |
|
Выполните базовую проверку, чтобы убедиться в работоспособности мастера. Рекомендуемая частота: запускать каждые 5-10 минут. Серьезность: КРИТИЧЕСКАЯ |
Запустите следующий запрос в базе данных postgres: SELECT count(*) FROM gp_segment_configuration; |
Если этот запрос не сработал, возможно, активный мастер не работает. Повторите попытку несколько раз, а затем проверьте активный мастер вручную. Если активный мастер не работает, перезагрузите или выключите, чтобы убедиться, что на активном мастере не осталось процессов, а затем активируйте резервный мастер. |
Таблица 16— Мониторинг лога предупреждений базы данных
| Действие | Процедура | Корректирующие действия |
|---|---|---|
|
Проверьте наличие сообщений лога FATAL и ERROR от системы. Рекомендуемая частота: запускать каждые 15 минут. Серьезность: ПРЕДУПРЕЖДЕНИЕ |
Запустите следующий запрос в базе данных gpperfmon: SELECT * FROM log_alert_history WHERE logseverity in ('FATAL', 'ERROR') AND logtime > (now() - interval '15 minutes'); |
Отправьте предупреждение администратору баз данных для анализа предупреждения. Вы можете добавить в запрос дополнительные фильтры, чтобы игнорировать определенные малоинтересные сообщения. |
Таблица 17— Мониторинг оборудования и операционной системы
| Действие | Процедура | Корректирующие действия |
|---|---|---|
|
Проверьте использование дискового пространства на томах, используемых для хранения данных базы данных RT.Warehouse и операционной системы. Рекомендуемая частота: каждые 5-30 минут. Серьезность: КРИТИЧЕСКАЯ |
Настройте проверку свободного места на диске.
|
Освободите место в системе, удалив некоторые данные или файлы. |
|
Проверьте наличие ошибок или потерянных пакетов на сетевых интерфейсах. Рекомендуемая частота: ежечасно Серьезность: ВАЖНО |
Настройте проверку сетевого интерфейса. | Работайте с сетевыми и ОС-командами над устранением ошибок. |
|
Проверьте наличие ошибок RAID или снижения производительности RAID. Рекомендуемая частота: каждые 5 минут Серьезность: КРИТИЧЕСКАЯ |
Настройте проверку RAID. |
Как можно скорее замените неисправные диски. Отработайте, совместно с командой системного администрирования, чтобы как можно скорее устранить другие ошибки RAID или контроллера. |
|
Проверьте достаточную пропускную способность ввода-вывода и перекос ввода-вывода.. Рекомендуемая частота: при создании кластера или при подозрении на проблемы с оборудованием. |
Запустите утилиту RT.Warehouse gpcheckperf. |
Кластер может быть недостаточно определен, если скорость передачи данных не похожа на следующую:
Если скорость передачи ниже ожидаемой, проконсультируйтесь со своим архитектором данных относительно ожидаемой производительности. Если машины в кластере демонстрируют неравномерный профиль производительности, обратитесь к группе системных администраторов, чтобы исправить неисправные машины. |
Таблица 18— Действия по мониторингу каталога
| Действие | Процедура | Корректирующие действия |
|---|---|---|
|
Запустите проверки согласованности каталога, чтобы убедиться, что каталог на каждом хосте в кластере непротиворечив и находится в хорошем состоянии. Рекомендуемая частота: еженедельно Серьезность: ВАЖНО |
Запустите утилиту RT.Warehouse gpcheckcat в каждой базе данных: gpcheckcat -O |
Запустите сценарии восстановления для любых обнаруженных проблем. |
|
Проверьте наличие записей pg_class, которым не соответствует запись pg_attribute. Рекомендуемая периодичность: ежемесячно Серьезность: ВАЖНО |
Во время простоя, когда в системе нет пользователей, запустите утилиту RT.Warehouse gpcheckcat в каждой базе данных: gpcheckcat -R pgclass |
Запустите сценарии восстановления для любых обнаруженных проблем. |
|
Проверьте, нет ли утечки временной схемы и отсутствующего определения схемы. Рекомендуемая периодичность: ежемесячно Серьезность: ВАЖНО |
Во время простоя, когда в системе нет пользователей, запустите утилиту RT.Warehouse gpcheckcat в каждой базе данных: gpcheckcat -R namespace |
Запустите сценарии восстановления для любых обнаруженных проблем. |
|
Проверьте ограничения для случайно распределенных таблиц. Рекомендуемая периодичность: ежемесячно Серьезность: ВАЖНО |
Во время простоя, когда в системе нет пользователей, запустите утилиту RT.Warehouse gpcheckcat в каждой базе данных: gpcheckcat -R distribution_policy |
Запустите сценарии восстановления для любых обнаруженных проблем. |
|
Проверить наличие зависимостей от несуществующих объектов. Рекомендуемая периодичность: ежемесячно Серьезность: ВАЖНО |
Во время простоя, когда в системе нет пользователей, запустите утилиту RT.Warehouse gpcheckcat в каждой базе данных: gpcheckcat -R dependency |
Запустите сценарии восстановления для любых обнаруженных проблем. |
Таблица 19— Действия по обслуживанию данных
| Действие | Процедура | Корректирующие действия |
|---|---|---|
| Проверьте отсутствующую статистику по таблицам. |
Проверьте представление gp_stats_missing в каждой базе данных: SELECT * FROM gp_toolkit.gp_stats_missing; |
Запустите ANALYZE для таблиц, в которых отсутствует статистика. |
|
Проверьте наличие таблиц с раздуванием в файлах данных, которые нельзя восстановить с помощью обычной команды VACUUM. Рекомендуемая периодичность: еженедельно или ежемесячно Серьезность: ПРЕДУПРЕЖДЕНИЕ |
Проверьте представление gp_bloat_diag в каждой базе данных: SELECT * FROM gp_toolkit.gp_bloat_diag; |
Выполните оператор VACUUM FULL в то время, когда пользователи не обращаются к таблице, чтобы удалить раздувание и сжать данные. |
Таблица 20— Действия по обслуживанию базы данных
| Действие | Процедура | Корректирующие действия |
|---|---|---|
|
Отметьте удаленные строки в таблицах heap, чтобы занимаемое ими пространство можно было использовать повторно. Рекомендуемая частота: ежедневно Серьезность: КРИТИЧЕСКАЯ |
Очистить пользовательские таблицы: VACUUM <table>; |
Регулярно используйте vacuum обновленных таблиц, чтобы предотвратить их раздувание. |
|
Обновить статистику таблицы. Рекомендуемая частота: после загрузки данных и перед выполнением запросов. Серьезность: КРИТИЧЕСКАЯ |
Анализ пользовательских таблиц. Вы можете использовать утилиту управления analyzedb: analyzedb -d <database> -a |
Регулярно анализируйте обновляемые таблицы, чтобы оптимизатор мог создавать эффективные планы выполнения запросов. |
|
Сделайте резервную копию данных базы данных. Рекомендуемая частота: ежедневно или согласно вашему плану резервного копирования. Серьезность: КРИТИЧЕСКАЯ |
Запустите утилиту gpbackup, чтобы параллельно создать резервную копию основной базы данных и базы данных сегмента. | Лучшая практика - иметь наготове текущую резервную копию на случай восстановления базы данных. |
|
Проведите vacuum, переиндексируйте и анализируйте системные каталоги, для поддержки эффективности каталог. Рекомендуемая частота: еженедельно или чаще, если объекты базы данных часто создаются и удаляются. |
VACUUM системные таблицы в каждой базе данных. Запустите REINDEX SYSTEM в каждой базе данных или используйте утилиту командной строки reindexdb с параметром -s: reindexdb -s <database> Проведите ANALYZE каждой из системных таблиц: analyzedb -s pg_catalog -d <database> |
Оптимизатор извлекает информацию из системных таблиц для создания планов запросов. Если системные таблицы и индексы со временем могут раздуваться, сканирование системных таблиц увеличивает время выполнения запроса. Важно запустить ANALYZE после переиндексации, потому что REINDEX оставляет индексы без статистики. |
Таблица 21— Действия по установке патчей и обновлений
| Действие | Процедура | Корректирующие действия |
|---|---|---|
|
Убедитесь, что все исправления ошибок или улучшения применены к ядру. Рекомендуемая частота: не реже одного раза в 6 месяцев. Серьезность: ВАЖНО |
Следуйте инструкциям поставщика, чтобы обновить ядро Linux. | Держите ядро в актуальном состоянии, чтобы включить исправления ошибок и безопасности, а также избежать сложных обновлений в будущем. |
Защита базы данных RT.Warehouse включает в себя защиту доступа к базе данных с помощью конфигурации сети, аутентификации пользователей базы данных и шифрования.
В этом разделе объясняется, как настроить клиентские подключения и аутентификацию для базы данных RT.Warehouse.
Когда RT.Warehouse впервые инициализируется, система содержит одну предопределенную роль суперпользователя. Эта роль будет иметь то же имя, что и пользователь операционной системы, который инициализировал систему базы данных RT.Warehouse. Эта роль называется gpadmin. По умолчанию система настроена на разрешение локальных подключений к базе данных только из роли gpadmin. Если вы хотите разрешить подключение любых других ролей или разрешить подключения с удаленных хостов, вам необходимо настроить базу данных RT.Warehouse для разрешения таких подключений. В этом разделе объясняется, как настроить клиентские соединения и аутентификацию в базе данных RT.Warehouse.
Вы можете контролировать доступ к базе данных RT.Warehouse с помощью сервера LDAP и, при желании, защитить соединение с помощью шифрования, добавив параметры в записи файла pg_hba.conf.
База данных RT.Warehouse поддерживает аутентификацию LDAP с использованием протокола TLS/SSL для шифрования связи с сервером LDAP:
Если протокол не указан, база данных RT.Warehouse взаимодействует с сервером LDAP с помощью открытого текстового соединения.
Чтобы использовать аутентификацию LDAP, мастер хост базы данных RT.Warehouse должен быть настроен как клиент LDAP. См. документацию по LDAP для получения информации о настройке клиентов LDAP.
Чтобы включить STARTTLS с протоколом TLS, в файле pg_hba.conf добавьте строку ldap и укажите для параметра ldaptls значение 1. Порт по умолчанию — 389. В этом примере параметры метода аутентификации включают параметр ldaptls.
| ldap ldapserver=myldap.com ldaptls=1 ldapprefix="uid=" ldapsuffix=",ou=People,dc=example,dc=com" |
Укажите порт не по умолчанию с параметром ldapport. В этом примере метод аутентификации включает параметр ldaptls и параметр ldapport для указания порта 550.
ldap ldapserver=myldap.com ldaptls=1 ldapport=500 ldapprefix="uid=" ldapsuffix=",ou=People,dc=example,dc=com"Чтобы включить безопасное соединение с помощью TLS/SSL, добавьте ldaps:// в качестве префикса к имени сервера LDAP, указанному в параметре ldapserver. Порт по умолчанию — 636.
В этом примере параметр ldapserver указывает безопасное соединение и протокол TLS/SSL для сервера LDAP myldap.com.
ldapserver=ldaps://myldap.comЧтобы указать порт не по умолчанию, добавьте двоеточие (:) и номер порта после имени сервера LDAP. В этом примере параметр ldapserver включает префикс ldaps:// и нестандартный порт 550.
ldapserver=ldaps://myldap.com:550Если у вас общесистемная система OpenLDAP и логины настроены на использование LDAP с TLS или SSL в файле pg_hba.conf, логины могут завершиться ошибкой со следующим сообщением:
could not start LDAP TLS session: error code '-11'Чтобы использовать существующую систему OpenLDAP для аутентификации, необходимо настроить базу данных RT.Warehouse для использования сертификата ЦС сервера LDAP для проверки сертификатов пользователей. Выполните следующие действия на мастер и резервном хостах, чтобы настроить базу данных RT.Warehouse:
1. Скопируйте файл цепочки корневых ЦС в кодировке base64 с сервера Active Directory или LDAP на мастер и резервный главные хосты базы данных RT.Warehouse. В этом примере используется каталог /etc/pki/tls/certs.
2. Перейдите в каталог, в который вы скопировали файл сертификата ЦС, и от имени пользователя root сгенерируйте хэш для OpenLDAP:
# cd /etc/pki/tls/certs
# openssl x509 -noout -hash -in <ca-certificate-file>
# ln -s <ca-certificate-file> <ca-certificate-file>.03. Настройте файл конфигурации OpenLDAP для базы данных RT.Warehouse, указав каталог сертификатов ЦС и файл сертификата.
Как пользователь root, отредактируйте файл конфигурации OpenLDAP /etc/openldap/ldap.conf:
SASL_NOCANON on
URI ldaps://ldapA.example.priv ldaps://ldapB.example.priv ldaps://ldapC.example.priv
BASE dc=example,dc=priv
TLS_CACERTDIR /etc/pki/tls/certs
TLS_CACERT /etc/pki/tls/certs/<ca-certificate-file>
|
Примечание. Чтобы проверка сертификата прошла успешно, имя хоста в сертификате должно совпадать с именем хоста в свойстве URI. В противном случае вы также должны добавить разрешение TLS_REQCERT в файл. |
4. От имени пользователя gpadmin отредактируйте /usr/local/greenplum-db/greenplum_path.sh и добавьте следующую строку:
export LDAPCONF=/etc/openldap/ldap.confБаза данных RT.Warehouse регистрирует ошибку, если в записи файла pg_hba.conf указано следующее:
Включение шифрованной связи для аутентификации LDAP шифрует только связь между базой данных RT.Warehouse и сервером LDAP.
Это примеры записей из файла pg_hba.conf.
В этом примере указана аутентификация LDAP без шифрования между базой данных RT.Warehouse и сервером LDAP.
host all plainuser 0.0.0.0/0 ldap ldapserver=myldap.com ldapprefix="uid=" ldapsuffix=",ou=People,dc=example,dc=com"В этом примере указана аутентификация LDAP с использованием протоколов STARTTLS и TLS между базой данных RT.Warehouse и сервером LDAP.
host all tlsuser 0.0.0.0/0 ldap ldapserver=myldap.com ldaptls=1 ldapprefix="uid=" ldapsuffix=",ou=People,dc=example,dc=com" В этом примере указана аутентификация LDAP с безопасным соединением и протоколом TLS/SSL между базой данных RT.Warehouse и сервером LDAP.
host all ldapsuser 0.0.0.0/0 ldap ldapserver=ldaps://myldap.com ldapprefix="uid=" ldapsuffix=",ou=People,dc=example,dc=com"Вы можете контролировать доступ к базе данных RT.Warehouse с помощью сервера аутентификации Kerberos.
База данных RT.Warehouse поддерживает универсальный программный интерфейс службы безопасности (GSSAPI) с аутентификацией Kerberos. GSSAPI обеспечивает автоматическую аутентификацию (единый вход) для систем, которые его поддерживают. Вы указываете пользователей (роли) базы данныхRT.Warehouse, которым требуется аутентификация Kerberos, в файле конфигурации базы данных RT.Warehouse pg_hba.conf. Логин завершается ошибкой, если аутентификация Kerberos недоступна, когда роль пытается войти в базу данных RT.Warehouse.
Kerberos предоставляет безопасную службу аутентификации с шифрованием. Он не шифрует данные, которыми обмениваются клиент и база данных, и не предоставляет услуг авторизации. Для шифрования данных, которыми обмениваются по сети, необходимо использовать соединение SSL. Для управления авторизацией доступа к базам данных и объектам RT.Warehouse, таким как схемы и таблицы, вы используете настройки в файле pg_hba.conf и привилегии, предоставляемые пользователям и ролям базы данных RT.Warehouse в базе данных.
Перед настройкой аутентификации Kerberos для базы данных RT.Warehouse убедитесь, что:
Вы можете определить сервер KDC, который вы используете для аутентификации Kerberos, и область Kerberos для вашей системы базы данных RT.Warehouse.
Системное время на сервере центра распространения ключей Kerberos (KDC) и мастере базы данных RT.Warehouse синхронизировано. (Например, установите пакет ntp на оба сервера.)
Сетевое подключение существует между сервером KDC и мастер хостом базы данных RT.Warehouse.
Java 1.7.0_17 или более поздняя версия установлена на всех хостах базы данных RT.Warehouse. Java 1.7.0_17 требуется для использования JDBC с аутентификацией Kerberos.
Ниже приведены задачи, которые необходимо выполнить для настройки проверки подлинности Kerberos для базы данных RT.Warehouse.
1. Создайте принципал службу для службы базы данных RT.Warehouse и принципал администратор Kerberos, который позволяет управлять базой данных KDC от имени пользователя gpadmin.
Войдите на сервер Kerberos KDC как пользователь root.
$ ssh root@<kdc-server> 2. Создайте принципала для службы базы данных RT.Warehouse.
Параметр -randkey запрещает команде запрашивать пароль.
3. Создайте принципала для роли gpadmin/admin.
# kadmin.local -q "addprinc gpadmin/admin@GPDB.KRB"Этот принципал позволяет вам управлять базой данных KDC, когда вы вошли в систему как gpadmin. Убедитесь, что файл конфигурации Kerberos kadm.acl содержит ACL для предоставления разрешений. Например, этот ACL предоставляет все разрешения любому администратору в области GPDB.KRB.
*/admin@GPDB.KRB *4. Создайте файл keytab с kadmin.local. В следующем примере создается файл keytab gpdb-kerberos.keytab в текущем каталоге с данными аутентификации для принципала службы базы данных RT.Warehouse и субъекта gpadmin/admin.
# kadmin.local -q "ktadd -k gpdb-kerberos.keytab postgres/mdw@GPDB.KRB gadmin/admin@GPDB.KRB"5. Скопируйте файл keytab на мастер хост.
# scp gpdb-kerberos.keytab gpadmin@mdw:~Установите клиентские утилиты и библиотеки Kerberos на мастер базы данных RT.Warehouse.
1. Установите пакеты Kerberos на мастер базы данных RT.Warehouse.
$ sudo yum install krb5-libs krb5-workstation2. Скопируйте файл /etc/krb5.conf с сервера KDC в /etc/krb5.conf на мастер хост RT.Warehouse.
Настройте базу данных RT.Warehouse для использования Kerberos.
1. Войдите на мастер хост базы данных RT.Warehouse как пользователь gpadmin.
$ ssh gpadmin@<master>
$ source /usr/local/greenplum-db/greenplum_path.sh2. Установите владельца и разрешения файла keytab, который вы скопировали с сервера KDC.
$ chown gpadmin:gpadmin /home/gpadmin/gpdb-kerberos.keytab
$ chmod 400 /home/gpadmin/gpdb-kerberos.keytab3. Настройте расположение файла keytab, задав параметр конфигурации сервера krb_server_keyfile базы данных RT.Warehouse. Эта команда gpconfig указывает папку /home/gpadmin в качестве местоположения файла keytab gpdb-kerberos.keytab.
$ gpconfig -c krb_server_keyfile -v '/home/gpadmin/gpdb-kerberos.keytab'4. Измените файл RT.Warehouse pg_hba.conf, чтобы включить поддержку Kerberos. Например, добавление следующей строки в pg_hba.conf добавляет поддержку аутентификации GSSAPI и Kerberos для запросов на подключение от всех пользователей и хостов в одной сети ко всем базам данных RT.Warehouse.
host all all 0.0.0.0/0 gss include_realm=0 krb_realm=GPDB.KRBУстановка для параметра krb_realm имени области гарантирует, что только пользователи из этой области смогут успешно пройти аутентификацию с помощью Kerberos. Установка для параметра include_realm значения 0 исключает имя области из имени аутентифицированного пользователя.
5. Перезапустите базу данных RT.Warehouse после обновления параметра krb_server_keyfile и файла pg_hba.conf.
$ gpstop -ar6. Создайте роль суперпользователя базы данных RT.Warehouse gpadmin/admin.
$ createuser gpadmin/admin
Shall the new role be a superuser? (y/n) yКлючи Kerberos для этой роли базы данных находятся в ключевом файле, который вы скопировали с сервера KDC.
7. Создайте тикет с помощью kinit и покажите тикеты в кэше тикетов Kerberos с помощью klist.
$ LD_LIBRARY_PATH= kinit -k -t /home/gpadmin/gpdb-kerberos.keytab gpadmin/admin@GPDB.KRB
$ LD_LIBRARY_PATH= klist
Ticket cache: FILE:/tmp/krb5cc_1000
Default principal: gpadmin/admin@GPDB.KRB
Valid starting Expires Service principal
06/13/2018 17:37:35 06/14/2018 17:37:35 krbtgt/GPDB.KRB@GPDB.KRB
|
Примечание. Когда вы настраиваете среду RT.Warehouse с помощью сценария greenplum-db_path.sh, переменная среды LD_LIBRARY_PATH задается для включения каталога lib базы данных RT.Warehouse, который включает библиотеки Kerberos. Это может привести к сбою служебных команд Kerberos, таких как kinit и klist, из-за конфликтов версий. Решение состоит в том, чтобы запустить утилиты Kerberos до того, как вы получите файл greenplum-db_path.sh, или временно сбросить значение переменной LD_LIBRARY_PATH при выполнении утилит Kerberos, как показано в примере. |
8. В качестве теста войдите в базу данных postgres с ролью gpadmin/admin:
$ psql -U "gpadmin/admin" -h mdw postgres
psql (9.4.20)
Type "help" for help.
postgres=# select current_user;
current_user
---------------
gpadmin/admin
(1 row)
|
Примечание. Когда вы запускаете psql на мастер хосте, вы должны включить параметр -h <master-hostname>, чтобы принудительно установить TCP-соединение, поскольку аутентификация Kerberos не работает с локальными соединениями. |
Если принципал Kerberos не является пользователем базы данных RT.Warehouse, при попытке пользователя войти в базу данных в командной строке psql отображается сообщение, подобное следующему:
| psql: krb5_sendauth: Bad response |
Принципал должен быть добавлен как пользователь базы данных RT.Warehouse.
Чтобы подключиться к системе базы данных RT.Warehouse с включенной аутентификацией Kerberos, пользователь сначала запрашивает разрешение на получение тикета с сервера KDC с помощью утилиты kinit с паролем или файлом keytab, предоставленным администратором Kerberos. Когда пользователь затем подключается к системе базы данных RT.Warehouse с поддержкой Kerberos, основным именем пользователя Kerberos будет имя роли базы данных RT.Warehouse с учетом преобразований, указанных в поле параметров записи gss в файле pg_hba.conf базы данных RT.Warehouse:
Карта имен пользователей определяется в файле конфигурации $MASTER_DATA_DIRECTORY/pg_ident.conf. В этом примере определяется карта с именем mymap с двумя записями.
# MAPNAME SYSTEM-USERNAME GP-USERNAME
mymap /^admin@GPDB.KRB$ gpadmin
mymap /^(.*)_gp)@GPDB.KRB$ \1Имя схемы указывается в записи Kerberos pg_hba.conf в поле параметров:
host all all 0.0.0.0/0 gss include_realm=0 krb_realm=GPDB.KRB map=mymapПервая запись сопоставления соответствует принципалу Kerberos admin@GPDB.KRB и заменяет его именем роли gpadmin базы данных RT.Warehouse. Во второй записи используется подстановочный знак для сопоставления любого принципала Kerberos в области GPDB-KRB с именем, заканчивающимся символами _gp, и заменяется начальной частью имени принципала. База данных RT.Warehouse применяет первую совпадающую запись карты в файле pg_ident.conf, поэтому порядок записей имеет значение.
Включите доступ JDBC с проверкой подлинности Kerberos к базе данных RT.Warehouse.
Вы можете настроить базу данных RT.Warehouse для использования Kerberos, для запуска пользовательских функций Java.
1. Убедитесь, что Kerberos установлен и настроен на мастере базы данных RT.Warehouse.
2. Создайте файл .java.login.config в папке /home/gpadmin и добавьте в него следующий текст:
pgjdbc {
com.sun.security.auth.module.Krb5LoginModule required
doNotPrompt=true
useTicketCache=true
debug=true
client=true;
};3. Создайте приложение Java, которое подключается к базе данных RT.Warehouse с использованием проверки подлинности Kerberos. В следующем примере URL-адреса подключения к базе данных используется драйвер JDBC PostgreSQL и указываются параметры для проверки подлинности Kerberos:
jdbc:postgresql://mdw:5432/mytest?kerberosServerName=postgres
&jaasApplicationName=pgjdbc&user=gpadmin/gpdb-kdcИмена и значения указанных параметров зависят от того, как приложение Java выполняет аутентификацию Kerberos.
4. Протестируйте вход в систему Kerberos, запустив образец Java-приложения из базы данных RT.Warehouse.
В данном пункте представлены шаги настройки сервера центра распространения ключей Kerberos (KDC) на хосте Red Hat Enterprise Linux для использования с базой данных RT.Warehouse.
Если у вас еще нет KDC, выполните следующие шаги, чтобы установить и настроить сервер KDC на хосте Red Hat Enterprise Linux с областью GPDB.KRB. Имя хоста сервера KDC в этом примере — gpdb-kdc.
1. Установите сервер Kerberos и клиентские пакеты:
$ sudo yum install krb5-libs krb5-server krb5-workstation2. Отредактируйте файл конфигурации /etc/krb5.conf. В следующем примере показан сервер Kerberos, настроенный с областью GPDB.KRB по умолчанию.
[logging]
default = FILE:/var/log/krb5libs.log
kdc = FILE:/var/log/krb5kdc.log
admin_server = FILE:/var/log/kadmind.log
[libdefaults]
default_realm = GPDB.KRB
dns_lookup_realm = false
dns_lookup_kdc = false
ticket_lifetime = 24h
renew_lifetime = 7d
forwardable = true
default_tgs_enctypes = aes128-cts des3-hmac-sha1 des-cbc-crc des-cbc-md5
default_tkt_enctypes = aes128-cts des3-hmac-sha1 des-cbc-crc des-cbc-md5
permitted_enctypes = aes128-cts des3-hmac-sha1 des-cbc-crc des-cbc-md5
[realms]
GPDB.KRB = {
kdc = gpdb-kdc:88
admin_server = gpdb-kdc:749
default_domain = gpdb.krb
}
[domain_realm]
.gpdb.krb = GPDB.KRB
gpdb.krb = GPDB.KRB
[appdefaults]
pam = {
debug = false
ticket_lifetime = 36000
renew_lifetime = 36000
forwardable = true
krb4_convert = false
}Ключи kdc и admin_server в разделе [realms] указывают хост (gpdb-kdc) и порт, на котором работает сервер Kerberos. Вместо имен хостов можно использовать IP-номера.
3. Чтобы создать базу данных Kerberos, запустите файл kdb5_util.
# kdb5_util create -sКоманда kdb5_util создает базу данных для хранения ключей областей Kerberos, управляемых этим сервером KDC. Опция -s создает файл тайника (stash файл). Без stash файла каждый раз, при запуске сервера KDC, запрашивается пароль.
4. Добавьте пользователя-администратора в базу данных KDC с помощью утилиты kadmin.local. Поскольку сама по себе она не зависит от проверки подлинности Kerberos, утилита kadmin.local позволяет добавить начального пользователя-администратора на локальный сервер Kerberos. Чтобы добавить пользователя gpadmin в качестве администратора в базу данных KDC, выполните следующую команду:
# kadmin.local -q "addprinc gpadmin/admin"Большинству пользователей не требуется административный доступ к серверу Kerberos. Они могут использовать kadmin для управления своими принципалами (например, для изменения собственного пароля).
5. При необходимости отредактируйте файл /var/kerberos/krb5kdc/kadm5.acl, чтобы предоставить gpadmin соответствующие разрешения.
6. Запустите демоны Kerberos:
# /sbin/service krb5kdc start#
/sbin/service kadmin start7. Для автоматического запуска Kerberos при перезапуске:
# /sbin/chkconfig krb5kdc on
# /sbin/chkconfig kadmin onВы можете настроить клиентские приложения Linux для подключения к системе базы данных RT.Warehouse, настроенной для аутентификации с помощью Kerberos.
Если ваше приложение JDBC в Red Hat Enterprise Linux использует аутентификацию Kerberos при подключении к вашей базе данных RT.Warehouse, ваша клиентская система должна быть настроена на использование аутентификации Kerberos. Если вы не используете аутентификацию Kerberos для подключения к базе данных RT.Warehouse, Kerberos не требуется в вашей клиентской системе.
Ниже приведены требования для подключения к базе данных RT.Warehouse с включенной аутентификацией Kerberos из клиентской системы с приложением JDBC.
|
Внимание. База данных RT.Warehouse должна быть настроена таким образом, чтобы удаленный пользователь мог подключаться к базе данных RT.Warehouse с аутентификацией Kerberos. Авторизация для доступа к базе данных RT.Warehouse контролируется файлом pg_hba.conf. |
На клиентском компьютере требуется утилита Kerberos kinit. Утилита kinit доступна при установке пакетов Kerberos:
|
Примечание. При установке пакетов Kerberos можно использовать другие утилиты Kerberos, такие как klist, для отображения информации о билетах Kerberos. |
Приложения Java требуют этого дополнительного программного обеспечения:
Для подключения к базе данных RT.Warehouse с аутентификацией Kerberos требуется тикет Kerberos. В клиентских системах тикеты генерируются из keytab файлов Kerberos с помощью утилиты kinit и сохраняются в файле кэша.
1. Установите копию файла конфигурации Kerberos krb5.conf из мастера базы данных RT.Warehouse. Этот файл используется клиентским программным обеспечением базы данных Greenplum и утилитами Kerberos.
Установите krb5.conf в каталог /etc.
При необходимости добавьте параметр default_ccache_name в раздел [libdefaults] файла krb5.ini и укажите расположение файла кэша билетов Kerberos в клиентской системе.
2. Получите keytab файл Kerberos, содержащий учетные данные для аутентификации пользователя базы данных RT.Warehouse.
3. Запустите kinit, указав файл keytab, чтобы создать тикет на клиентском компьютере. В этом примере файл keytab gpdb-kerberos.keytab находится в текущем каталоге. Файл кэша билетов находится в домашнем каталоге пользователя gpadmin.
> kinit -k -t gpdb-kerberos.keytab -c /home/gpadmin/cache.txt
gpadmin/kerberos-gpdb@KRB.EXAMPLE.COMИз дистанционно удаленной системы вы можете получить доступ к базе данных RT.Warehouse, в которой включена аутентификация Kerberos.
В следующем примере выполняется вход в базу данных RT.Warehouse на машине kerberos-gpdb в качестве пользователя gpadmin с учетными данными Kerberos gpadmin/kerberos-gpdb:
$ psql -U "gpadmin/kerberos-gpdb" -h kerberos-gpdb postgresДоступ к базе данных RT.Warehouse из приложения Java с аутентификацией Kerberos использует службу аутентификации и авторизации Java (JAAS).
1. Создайте файл .java.login.config в домашней папке пользователя.
Например, в системе Linux домашняя папка похожа на /home/gpadmin.
Добавьте в файл следующий текст:
pgjdbc {
com.sun.security.auth.module.Krb5LoginModule required
doNotPrompt=true
useTicketCache=true
ticketCache = "/home/gpadmin/cache.txt"
debug=true
client=true;
};2. Создайте приложение Java, которое подключается к базе данных RT.Warehouse с использованием проверки подлинности Kerberos, и запустите приложение от имени пользователя.
В этом примере URL-адреса подключения к базе данных используется драйвер JDBC PostgreSQL и указываются параметры для проверки подлинности Kerberos.
jdbc:postgresql://kerberos-gpdb:5432/mytest?
kerberosServerName=postgres&jaasApplicationName=pgjdbc&
user=gpadmin/kerberos-gpdbИмена и значения указанных параметров зависят от того, как приложение Java выполняет аутентификацию Kerberos.
Вы можете настроить клиентские приложения Microsoft Windows для подключения к системе базы данных RT.Warehouse, настроенной для аутентификации с помощью Kerberos.
Когда система базы данных RT.Warehouse настроена на аутентификацию с помощью Kerberos, вы можете настроить аутентификацию Kerberos для клиентских утилит базы данных RT.Warehouse gpload и psql в системе Microsoft Windows. Клиенты базы данных RT.Warehouse аутентифицируются напрямую с помощью Kerberos.
Клиентские программы kinit, kdestroy и klist MIT Kerberos для Windows и вспомогательные библиотеки устанавливаются в вашей системе при установке клиента базы данных RT.Warehouse и пакета инструментов загрузки:
Вам необходимо настроить Kerberos на клиенте Windows для аутентификации в базе данных RT.Warehouse:
1. Скопируйте файл конфигурации Kerberos /etc/krb5.conf из базы данных RT.Warehouse в систему Windows, переименуйте его в krb5.ini и поместите в папку Kerberos по умолчанию в системе Windows, C:\ProgramData\MIT\Kerberos5\ krb5.ini. Этот каталог может быть скрыт. Этот шаг требует прав администратора в клиентской системе Windows. Вы также можете разместить файл /etc/krb5.ini в другом месте. Если вы решите сделать это, вы должны настроить и установить системную переменную среды с именем KRB5_CONFIG в пользовательское расположение.
2. Найдите раздел [libdefaults] файла krb5.ini и удалите запись, указывающую расположение файла кэша учетных данных Kerberos, default_ccache_name. Этот шаг требует прав администратора в клиентской системе Windows.
Ниже пример файла конфигурации с удаленным default_ccache_name. Раздел [log] также удален.
[libdefaults]
debug = true
default_etypes = aes256-cts-hmac-sha1-96
default_realm = EXAMPLE.LOCAL
dns_lookup_realm = false
dns_lookup_kdc = false
ticket_lifetime = 24h
renew_lifetime = 7d
forwardable = true
[realms]
EXAMPLE.LOCAL = {
kdc =bocdc.example.local
admin_server = bocdc.example.local
}
[domain_realm]
.example.local = EXAMPLE.LOCAL
example.local = EXAMPLE.LOCAL3. Настройте файл кэша учетных данных Kerberos. В системе Windows задайте переменную среды KRB5CCNAME, чтобы указать расположение файла кэша в файловой системе. Файл должен называться krb5cache. Это местоположение определяет файл, а не каталог, и должно быть уникальным для каждого входа на сервер. Когда вы устанавливаете KRB5CCNAME, вы можете указать значение либо в локальной пользовательской среде, либо в рамках сеанса. Например, следующая команда устанавливает KRB5CCNAME в сеансе:
set KRB5CCNAME=%USERPROFILE%\krb5cache4. Получите принципал и пароль Kerberos или файл keytab у системного администратора.
5. Сгенерируйте тикет Kerberos, используя пароль или keytab. Например, чтобы сгенерировать билет с использованием пароля:
kinit [<principal>]Чтобы сгенерировать билет с помощью keytab:
kinit -k -t <keytab_filepath> [<principal>]6. Настройте клиентскую среду RT.Warehouse:
set PGGSSLIB=gssapi
"c:\Program Files\Greenplum\greenplum-clients\greenplum_clients_path.bat"После настройки Kerberos и создания тикета Kerberos в системе Windows вы можете запустить клиент командной строки базы данных RT.Warehouse psql.
Если вы получаете предупреждения о том, что кодовая страница консоли отличается от кодовой страницы Windows, вы можете запустить утилиту Windows chcp, чтобы изменить кодовую страницу.
Далее приведен пример предупреждения и исправления:
psql -h prod1.example.local warehouse
psql (9.4.20)
WARNING: Console code page (850) differs from Windows code page (1252)
8-bit characters might not work correctly. See psql reference
page "Notes for Windows users" for details.
Type "help" for help.
warehouse=# \q
chcp 1252
Active code page: 1252
psql -h prod1.example.local warehouse
psql (9.4.20)
Type "help" for help.Вы можете создать и использовать Keytab файл Kerberos, чтобы не вводить пароль в командной строке или указывать пароль в скрипте при подключении к системе базы данных RT.Warehouse, например, как при автоматизации запланированной задачи RT.Warehouse, такой как gpload. Вы можете создать файл keytab с помощью утилиты keytab Java JRE ktab. Если вы используете шифрование AES256-CTS-HMAC-SHA1-96, вам необходимо загрузить и установить расширение Java Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files для JDK/JRE от Oracle.
|
Примечание. Вы должны ввести пароль для создания файла keytab. Пароль будет виден на экране, когда вы его вводите. |
В этом примере запускается программа Java ktab.exe для создания keytab файла (параметр -a) и перечисления keytab имени и записей (параметры -l -e -t).
C:\Users\dev1>"\Program Files\Java\jre1.8.0_77\bin"\ktab -a dev1
Password for dev1@EXAMPLE.LOCAL:your_password
Done!
Service key for dev1 is saved in C:\Users\dev1\krb5.keytab
C:\Users\dev1>"\Program Files\Java\jre1.8.0_77\bin"\ktab -l -e -t
Keytab name: C:\Users\dev1\krb5.keytab
KVNO Timestamp Principal
---- -------------- ------------------------------------------------------
4 13/04/16 19:14 dev1@EXAMPLE.LOCAL (18:AES256 CTS mode with HMAC SHA1-96)
4 13/04/16 19:14 dev1@EXAMPLE.LOCAL (17:AES128 CTS mode with HMAC SHA1-96)
4 13/04/16 19:14 dev1@EXAMPLE.LOCAL (16:DES3 CBC mode with SHA1-KD)
4 13/04/16 19:14 dev1@EXAMPLE.LOCAL (23:RC4 with HMAC)Затем вы можете сгенерировать тикет Kerberos, используя keytab с помощью следующей команды:
kinit -kt dev1.keytab dev1или
kinit -kt %USERPROFILE%\krb5.keytab dev1Когда вы инициируете задание gpload в систему базы данных RT.Warehouse с использованием аутентификации Kerberos, вы опускаете USER: свойство и значение из управляющего файла YAML.
В этом примере управляющий файл gpload YAML с именем test.yaml не содержит записи USER:
---
VERSION: 1.0.0.1
DATABASE: warehouse
HOST: prod1.example.local
PORT: 5432
GPLOAD:
INPUT:
- SOURCE:
PORT_RANGE: [18080,18080]
FILE:
- /Users/dev1/Downloads/test.csv
- FORMAT: text
- DELIMITER: ','
- QUOTE: '"'
- ERROR_LIMIT: 25
- LOG_ERRORS: true
OUTPUT:
- TABLE: public.test
- MODE: INSERT
PRELOAD:
- REUSE_TABLES: trueЭти команды запускают kinit с помощью файла keytab, запускают gpload.bat с файлом test.yaml, а затем отображают успешный вывод gpload.
kinit -kt %USERPROFILE%\krb5.keytab dev1
gpload.bat -f test.yaml
2016-04-10 16:54:12|INFO|gpload session started 2016-04-10 16:54:12
2016-04-10 16:54:12|INFO|started gpfdist -p 18080 -P 18080 -f "/Users/dev1/Downloads/test.csv" -t 30
2016-04-10 16:54:13|INFO|running time: 0.23 seconds
2016-04-10 16:54:13|INFO|rows Inserted = 3
2016-04-10 16:54:13|INFO|rows Updated = 0
2016-04-10 16:54:13|INFO|data formatting errors = 0
2016-04-10 16:54:13|INFO|gpload succeededЭто сообщение означает, что Kerberos не может найти ваш файл кэша учетных данных Kerberos:
Credentials cache I/O operation failed XXX
(Kerberos error 193)
krb5_cc_default() failedЧтобы убедиться, что Kerberos может найти файл, установите переменную среды KRB5CCNAME и запустите kinit.
set KRB5CCNAME=%USERPROFILE%\krb5cache
kinitЭто сообщение kinit указывает, что команде kinit -k -t не удалось найти keytab.
kinit: Generic preauthentication failure while getting initial credentialsУбедитесь, что полный путь и имя keytab файла Kerberos указаны правильно.
Доступ и аутентификация клиента контролируются стандартным файлом аутентификации на основе хоста PostgreSQL, pg_hba.conf.
В базе данных RT.Warehouse файл pg_hba.conf мастер инстанс управляет клиентским доступом и аутентификацией в вашей системе базы данных RT.Warehouse. Сегменты базы данных RT.Warehouse также имеют файлы pg_hba.conf, при этом они уже правильно настроены, чтобы разрешать только клиентские подключения с мастер хоста. Сегменты никогда не принимают внешних клиентских подключений, поэтому нет необходимости изменять файл pg_hba.conf для сегментов.
Общий формат файла pg_hba.conf представляет собой набор записей, по одной в строке. База данных RT.Warehouse игнорирует пустые строки и любой текст после символа комментария #. Запись состоит из ряда полей, разделенных пробелами или символами табуляции. Поля могут содержать пробелы, если значение поля заключено в кавычки. Записи не могут быть продолжены через строки. Каждая запись доступа удаленного клиента имеет следующий формат:
host database role address authentication-methodКаждая запись доступа к сокету домена UNIX имеет следующий формат:
local database role authentication-methodВ Таблице 22 описано значение каждого поля.
Таблица 22— Поля pg_hba.conf
| Поле | Описание |
|---|---|
| local | Соответствует попыткам подключения с использованием сокетов домена UNIX. Без записи этого типа соединения сокетов домена UNIX запрещены. |
| host | Соответствует попыткам подключения, выполненным с использованием TCP/IP. Удаленные соединения TCP/IP будут невозможны, если сервер не будет запущен с соответствующим значением параметра конфигурации сервера listen_addresses. |
| hostssl | Соответствует попыткам подключения, выполненным с использованием TCP/IP, но только в том случае, если подключение выполняется с шифрованием SSL. SSL необходимо включить во время запуска сервера, задав параметр конфигурации сервера ssl. |
| hostnossl | Соответствует попыткам подключения по протоколу TCP/IP без использования SSL. |
| database | Указывает, каким именам баз данных соответствует эта запись. Значение all указывает, что оно соответствует всем базам данных. Можно указать несколько имен баз данных, разделив их запятыми. Отдельный файл, содержащий имена баз данных, можно указать, указав перед именем файла символ @. |
| role | Указывает, для каких ролей базы данных соответствует эта запись. Значение all указывает, что оно соответствует всем ролям. Если указанная роль является группой, и вы хотите, чтобы в нее были включены все члены этой группы, поставьте перед ролью знак +. Можно указать несколько ролей, разделив их запятыми. Отдельный файл, содержащий роли, можно указать, указав перед именем файла символ @. |
| address |
Задает адреса клиентских компьютеров, которым соответствует эта запись. Это поле может содержать IP-адрес, диапазон IP-адресов или имя хоста. Диапазон IP-адресов указывается с использованием стандартной числовой записи для начального адреса диапазона, затем косой черты (/) и длины маски CIDR. Длина маски указывает количество старших битов IP-адреса клиента, которые должны совпадать. Биты справа от этого должны быть нулевыми в данном IP-адресе. Между IP-адресом, символом / и длиной маски CIDR не должно быть пробелов. Типичными примерами диапазона адресов IPv4, указанного таким образом, являются 172.20.143.89/32 для одного хоста, или 172.20.143.0/24 для небольшой сети, или 10.6.0.0/16 для более крупной сети. Диапазон адресов IPv6 может выглядеть как ::1/128 для одного хоста (в данном случае IPv6 loopback-адрес) или fe80::7a31:c1ff:0000:0000/96 для небольшой сети. 0.0.0.0/0 представляет все адреса IPv4, а ::0/0 представляет все адреса IPv6. Чтобы указать один хост, используйте длину маски 32 для IPv4 или 128 для IPv6. В сетевом адресе не опускайте нули в конце. Запись в формате IPv4 будет соответствовать только подключениям IPv4, а запись в формате IPv6 будет соответствовать только подключениям IPv6, даже если представленный адрес находится в диапазоне IPv4-in-IPv6. Примечание: Записи в формате IPv6 будут отклонены, если библиотека C хост-системы не поддерживает адреса IPv6. Если указано имя хоста (адрес, который не является IP-адресом или диапазоном IP-адресов, рассматривается как имя хоста), это имя сравнивается с результатом обратного разрешения имени IP-адреса клиента (например, обратный поиск DNS, если используется DNS). При сравнении имен хостов регистр не учитывается. Если есть совпадение, то для имени хоста выполняется прямое разрешение имени (например, прямой поиск DNS), чтобы проверить, равен ли какой-либо из адресов, которые оно разрешает, IP-адресу клиента. Если оба направления совпадают, то запись считается соответствующей. Некоторые базы данных имен хостов позволяют связать IP-адрес с несколькими именами хостов, но операционная система возвращает только одно имя хоста, когда ее просят разрешить IP-адрес. Имя хоста, используемое в pg_hba.conf, должно быть тем, которое возвращает преобразование IP-адреса клиента в имя, иначе строка не будет считаться совпадением. Когда имена хостов указаны в pg_hba.conf, вы должны обеспечить достаточно быстрое разрешение имен. Может оказаться полезным настроить локальный кэш разрешения имен, такой как nscd. Кроме того, вы можете включить параметр конфигурации сервера log_hostname, чтобы в журнале отображалось имя хоста клиента вместо IP-адреса. |
|
IP-address IP-mask |
Эти поля можно использовать в качестве альтернативы нотации адреса CIDR. Вместо указания длины маски фактическая маска указывается в отдельном столбце. Например, 255.0.0.0 соответствует длине маски CIDR IPv4, равной 8, а 255.255.255.255 соответствует длине маски CIDR, равной 32. |
| authentication-method | Указывает метод проверки подлинности, используемый при подключении. RT.Warehouse поддерживает методы аутентификации, поддерживаемые PostgreSQL 9.4. |
|
Внимание. Для повышения безопасности системы рассмотрите возможность удаления записей для удаленных подключений, использующих доверительную аутентификацию, из файла pg_hba.conf. Доверительная аутентификация предоставляет любому пользователю, который может подключиться к серверу, доступ к базе данных, используя любую указанную им роль. Вы можете безопасно заменить доверительную аутентификацию на идентификационную аутентификацию для локальных подключений через UNIX-сокет. Вы также можете использовать идентификацию для локальных и удаленных TCP-клиентов, но на хосте клиента должна быть запущена служба идентификации, и вы должны доверять целостности этой машины. |
Изначально файл pg_hba.conf настраивается с большими разрешениями для пользователя gpadmin и без доступа к базе данных для других ролей базы данных RT.Warehouse. Вам нужно будет отредактировать файл pg_hba.conf, чтобы разрешить пользователям доступ к базам данных и защитить пользователя gpadmin. Рассмотрите возможность удаления записей с доверительной аутентификацией, поскольку они позволяют любому, у кого есть доступ к серверу, подключаться с любой выбранной ролью. Для локальных подключений (сокет UNIX) используйте идентификацию, которая требует, чтобы пользователь операционной системы соответствовал указанной роли. Для локальных и удаленных TCP-соединений аутентификация ident требует, чтобы хост клиента запускал ident службу. Вы можете установить службу ident на мастер хосте, а затем использовать аутентификацию ident для локальных соединений TCP, например 127.0.0.1/28. Использование ident-аутентификации для удаленных TCP-соединений менее безопасно, поскольку требует, чтобы вы доверяли целостности службы ident на хосте клиента.
В примере ниже показано, как пошагово отредактировать файл pg_hba.conf мастера, чтобы разрешить удаленному клиенту доступ ко всем базам данных из всех ролей с использованием аутентификации с зашифрованным паролем.
Редактирование pg_hba.conf:
1. Откройте файл $MASTER_DATA_DIRECTORY/pg_hba.conf в текстовом редакторе.
2. Добавьте строку в файл для каждого типа подключения, которое вы хотите разрешить. Записи читаются последовательно, поэтому порядок записей имеет значение. Как правило, более ранние записи будут иметь параметры жесткого соответствия соединения и более слабые методы проверки подлинности, в то время как более поздние записи будут иметь более слабые параметры соответствия и более надежные методы проверки подлинности. Например:
# allow the gpadmin user local access to all databases
# using ident authentication
local all gpadmin ident sameuser
host all gpadmin 127.0.0.1/32 ident
host all gpadmin ::1/128 ident
# allow the 'dba' role access to any database from any
# host with IP address 192.168.x.x and use md5 encrypted
# passwords to authenticate the user
# Note that to use SHA-256 encryption, replace md5 with
# password in the line below
host all dba 192.168.0.0/32 md5
# allow all roles access to any database from any
# host and use ldap to authenticate the user. Greenplum role
# names must match the LDAP common name.
host all all 192.168.0.0/32 ldap ldapserver=usldap1 ldapport=1389 ldapprefix="cn=" ldapsuffix=",ou=People,dc=company,dc=com"3. Сохраните и закройте файл.
4. Перезагрузите файл конфигурации pg_hba.conf, чтобы ваши изменения вступили в силу:
$ gpstop -u
|
Примечание. Обратите внимание, что вы также можете управлять доступом к базе данных, устанавливая права доступа к объектам, как описано в разделе Управление правами доступа к объектам. Файл pg_hba.conf просто контролирует, кто может инициировать сеанс базы данных и как эти соединения аутентифицируются. |
База данных RT.Warehouse выделяет ресурсы для каждого подключения, поэтому рекомендуется установить максимально допустимое количество подключений.
Чтобы ограничить количество одновременных активных сеансов с вашей системой базы данных RT.Warehouse, вы можете настроить параметр конфигурации сервера max_connections. Это локальный параметр, то есть его необходимо установить в файле postgresql.conf мастера, резервного мастера и каждого инстанса сегмента (основного и зеркального). Рекомендуемое значение max_connections для сегментов в 5-10 раз превышает значение для мастера.
Когда вы устанавливаете max_connections, вы также должны установить зависимый параметр max_prepared_transactions. Это значение должно быть не меньше значения max_connections на мастере, а для экземпляров сегмента должно быть установлено то же значение, что и для мастера.
Например:
max_connections=100
max_prepared_transactions=100
max_connections=500
max_prepared_transactions=100Следующие шаги устанавливают значения параметров с помощью утилиты базы данных RT.Warehouse gpconfig.
Далее представлена пошаговая инструкция для изменения количества разрешенных подключений.
1. Войдите на мастер хост базы данных RT.Warehouse в качестве администратора базы данных RT.Warehouse и укажите источник файла $GPHOME/greenplum_path.sh.
2. Установите значение параметра max_connections. Команда gpconfig устанавливает для сегментов значение 1000, а для главного устройства — 200.
$ gpconfig -c max_connections -v 1000 -m 200Значение на сегментах должно быть больше, чем значение на мастере. Рекомендуемое значение max_connections для сегментов в 5-10 раз превышает значение для мастера.
3. Установите значение параметра max_prepared_transactions. Команда gpconfig устанавливает значение 200 для мастера и всех сегментов.
$ gpconfig -c max_prepared_transactions -v 200Значение max_prepared_transactions должно быть больше или равно max_connections на мастере.
4. Остановите и перезапустите систему базы данных RT.Warehouse.
$ gpstop -r5. Вы можете проверить значение параметров мастера и сегментов с помощью параметра gpconfig -s. Команда gpconfig отображает значения параметра max_connections.
$ gpconfig -s max_connections
|
Примечание. Увеличение значений этих параметров может привести к тому, что база данных RT.Warehouse потребует больше общей памяти. Чтобы смягчить этот эффект, рассмотрите возможность уменьшения других параметров, связанных с памятью, таких как gp_cached_segworkers_threshold. |
Включите SSL для клиентских подключений к базе данных RT.Warehouse, чтобы зашифровать данные, передаваемые по сети между клиентом и базой данных.
База данных RT.Warehouse имеет встроенную поддержку соединений SSL между клиентом и главным сервером. Соединения SSL предотвращают отслеживание пакетов третьими лицами, а также предотвращают атаки «человек посередине». SSL следует использовать всякий раз, когда клиентское соединение проходит через небезопасную ссылку, и его необходимо использовать всякий раз, когда используется проверка подлинности клиентского сертификата.
Для включения SSL требуется, чтобы OpenSSL был установлен как на клиентской, так и на главной серверной системе. Базу данных RT.Warehouse можно запустить с включенным SSL, установив параметр конфигурации сервера ssl=on в главном файле postgresql.conf. При запуске в режиме SSL сервер будет искать файлы server.key (закрытый ключ сервера) и server.crt (сертификат сервера) в каталоге основных данных. Эти файлы должны быть правильно настроены перед запуском системы базы данных RT.Warehouse с поддержкой SSL.
|
Внимание. Не защищайте закрытый ключ парольной фразой. Сервер не запрашивает парольную фразу для закрытого ключа, и запуск базы данных завершается с ошибкой, если она требуется. |
Самозаверяющий сертификат можно использовать для тестирования, но в производстве следует использовать сертификат, подписанный центром сертификации (ЦС), чтобы клиент мог проверить. Можно использовать как глобальный, так и локальный ЦС. Если все клиенты являются локальными для организации, рекомендуется использовать локальный ЦС.
Чтобы создать быстрый самозаверяющий сертификат для сервера для тестирования, используйте следующую команду OpenSSL:
# openssl req -new -text -out server.reqВведите информацию, запрашиваемую подсказками. Обязательно введите локальное имя хоста в качестве общего имени. Пароль вызова можно оставить пустым.
Программа сгенерирует ключ, защищенный парольной фразой, и не принимает парольную фразу длиной менее четырех символов.
Чтобы использовать этот сертификат с базой данных RT.Warehouse, удалите парольную фразу с помощью следующих команд:
# openssl rsa -in privkey.pem -out server.key
# rm privkey.pemВведите старую парольную фразу, когда будет предложено разблокировать существующий ключ.
Затем введите следующую команду, чтобы превратить сертификат в самозаверяющий сертификат и скопировать ключ и сертификат в место, где их будет искать сервер.
# openssl req -x509 -in server.req -text -key server.key -out server.crtНаконец, измените разрешения на ключ с помощью следующей команды. Сервер отклонит файл, если разрешения менее строгие, чем эти.
# chmod og-rwx server.keyМеханизм авторизации базы данных RT.Warehouse хранит роли и разрешения на доступ к объектам базы данных в базе данных и администрируется с помощью операторов SQL или утилит командной строки.
База данных RT.Warehouse управляет правами доступа к базе данных с помощью ролей. Концепция ролей включает в себя концепции пользователей и групп. Роль может быть пользователем базы данных, группой или и тем, и другим. Роли могут владеть объектами базы данных (например, таблицами) и могут назначать права доступа к этим объектам другим ролям для управления доступом к объектам. Роли могут быть членами других ролей, поэтому роль-член может наследовать объектные привилегии своей родительской роли.
Каждая система базы данных RT.Warehouse содержит набор ролей базы данных (пользователей и групп). Эти роли отделены от пользователей и групп, управляемых операционной системой, в которой работает сервер. Однако для удобства вы можете поддерживать взаимосвязь между именами пользователей операционной системы и именами ролей базы данных RT.Warehouse, поскольку многие клиентские приложения используют текущее имя пользователя операционной системы по умолчанию.
В базе данных RT.Warehouse пользователи входят в систему и подключаются через мастер инстанс, который затем проверяет их роль и права доступа. Затем мастер негласно выдает команды инстансам сегмента в качестве текущей роли, вошедшей в систему.
Роли определяются на системном уровне, то есть они действительны для всех баз данных в системе.
Для начальной загрузки системы базы данных RT.Warehouse только что инициализированная система всегда содержит одну предопределенную роль суперпользователя (также называемую системным пользователем). Эта роль будет иметь то же имя, что и пользователь операционной системы, который инициализировал систему базы данных RT.Warehouse. Обычно эта роль называется gpadmin. Чтобы создать больше ролей, вам сначала нужно подключиться в качестве этой начальной роли.
Ниже приведены рекомендации по безопасности:
Роль уровня пользователя считается ролью базы данных, которая может входить в базу данных и инициировать сеанс базы данных. Поэтому, когда вы создаете новую роль уровня пользователя с помощью команды CREATE ROLE, вы должны указать привилегию LOGIN. Например:
=# CREATE ROLE jsmith WITH LOGIN;Роль базы данных может иметь ряд атрибутов, определяющих, какие задачи эта роль может выполнять в базе данных. Эти атрибуты можно установить при создании роли или позднее с помощью команды ALTER ROLE.
Роль базы данных может иметь ряд атрибутов, определяющих, какие задачи эта роль может выполнять в базе данных.
В Таблице 23 описаны атрибуты роли значение каждого поля.
Таблица 23— Атрибуты роли
| Атрибуты | Описание |
|---|---|
| SUPERUSER | NOSUPERUSER | Определяет, является ли роль суперпользователем. Вы должны сами быть суперпользователем, чтобы создать нового суперпользователя. NOSUPERUSER используется по умолчанию. |
| CREATEDB | NOCREATEDB | Определяет, разрешено ли роли создавать базы данных. NOCREATEDB используется по умолчанию. |
| CREATEROLE | NOCREATEROLE | Определяет, разрешено ли роли создавать другие роли и управлять ими. NOCREATEROLE используется по умолчанию. |
| INHERIT | NOINHERIT | Определяет, наследует ли роль привилегии ролей, членом которых она является. Роль с атрибутом INHERIT может автоматически использовать любые привилегии базы данных, предоставленные всем ролям, членом которых она прямо или косвенно является. INHERIT (НАСЛЕДУЕТ) по умолчанию. |
| LOGIN | NOLOGIN | Определяет, разрешено ли для роли входить в систему. Роль с атрибутом LOGIN можно рассматривать как пользователя. Роли без этого атрибута полезны для управления привилегиями базы данных (группами). NOLOGIN используется по умолчанию. |
| CONNECTION LIMIT connlimit | Если роль может входить в систему, это указывает, сколько одновременных подключений может выполнять роль. -1 (значение по умолчанию) означает отсутствие ограничений. |
| CREATEEXTTABLE | NOCREATEEXTTABLE | Определяет, разрешено ли роли создавать внешние таблицы. NOCREATEEXTTABLE используется по умолчанию. Для роли с атрибутом CREATEEXTTABLE тип внешней таблицы по умолчанию доступен для чтения, а протокол по умолчанию — gpfdist. Обратите внимание, что внешние таблицы, которые используют файл или протоколы выполнения, могут быть созданы только суперпользователями. |
| PASSWORD 'password' | Устанавливает пароль роли. Если вы не планируете использовать аутентификацию по паролю, этот параметр можно пропустить. Если пароль не указан, для пароля будет установлено значение null, и аутентификация по паролю для этого пользователя всегда будет завершаться ошибкой. Нулевой пароль можно при желании записать явно как PASSWORD NULL. |
| ENCRYPTED | UNENCRYPTED |
Определяет, сохраняется ли новый пароль в виде хеш-строки в системном каталоге pg_authid. Если ни ENCRYPTED, ни UNENCRYPTED не указаны, поведение по умолчанию определяется параметром конфигурации password_encryption, который по умолчанию включен. Если предоставленная строка пароля уже имеет хешированный формат, она сохраняется как есть, независимо от того, указано ли значение ENCRYPTED или UNENCRYPTED. |
| VALID UNTIL 'timestamp' | Устанавливает дату и время, после которых пароль роли становится недействительным. Если его не указать, пароль будет действителен все время. |
| RESOURCE QUEUE queue_name | Назначает роль именованной очереди ресурсов для управления рабочей нагрузкой. Любая инструкция, выдаваемая ролью, затем подчиняется ограничениям очереди ресурсов. Обратите внимание, что атрибут RESOURCE QUEUE не наследуется; он должен быть установлен для каждой роли уровня пользователя (LOGIN). |
| DENY {deny_interval | deny_point} | Ограничивает доступ в течение интервала, указанного днем или днем и временем. |
Эти атрибуты можно установить при создании роли или позднее с помощью команды ALTER ROLE. Например:
=# ALTER ROLE jsmith WITH PASSWORD 'passwd123';
=# ALTER ROLE admin VALID UNTIL 'infinity';
=# ALTER ROLE jsmith LOGIN;
=# ALTER ROLE jsmith RESOURCE QUEUE adhoc;
=# ALTER ROLE jsmith DENY DAY 'Sunday';Роль также может иметь специфичные для роли значения по умолчанию для многих параметров конфигурации сервера. Например, чтобы задать путь поиска схемы для роли по умолчанию:
=# ALTER ROLE admin SET search_path TO myschema, public;Часто бывает удобно группировать пользователей вместе, чтобы облегчить управление объектными привилегиями. Таким образом привилегии могут быть предоставлены или отозваны для группы в целом. В базе данных RT.Warehouse это делается путем создания роли, представляющей группу, а затем предоставления членства в роли группы отдельным ролям пользователей.
Используйте команду SQL CREATE ROLE для создания новой групповой роли. Например:
=# CREATE ROLE admin CREATEROLE CREATEDB;Когда групповая роль существует, вы можете добавлять и удалять участников (роли пользователей) с помощью команд GRANT и REVOKE. Например:
=# GRANT admin TO john, sally;
=# REVOKE admin FROM bob;Для управления объектными привилегиями вы должны предоставить соответствующие разрешения только роли группового уровня. Роли пользователей-членов затем наследуют объектные привилегии групповой роли.
Например:
=# GRANT ALL ON TABLE mytable TO admin;
=# GRANT ALL ON SCHEMA myschema TO admin;
=# GRANT ALL ON DATABASE mydb TO admin;Атрибуты ролей LOGIN, SUPERUSER, CREATEDB, CREATEROLE, CREATEEXTTABLE и RESOURCE QUEUE никогда не наследуются, как обычные привилегии для объектов базы данных. Пользователи-члены должны фактически установить SET ROLE для конкретной роли, имеющей один из этих атрибутов, чтобы использовать этот атрибут. В приведенном выше примере мы передали CREATEDB и CREATEROLE роли администратора. Если пользователь является администратором, он может ввести следующую команду, чтобы принять атрибуты роли родительской роли:
=> SET ROLE admin;Когда создается объект (таблица, представление, последовательность, база данных, функция, язык, схема или табличное пространство), ему назначается владелец. Владельцем обычно является роль, которая выполнила оператор создания. Для большинства видов объектов начальное состояние таково, что только владелец (или суперпользователь) может что-либо делать с объектом. Чтобы разрешить другим ролям использовать его, должны быть предоставлены привилегии. В Таблице 24 представлены привилегии для каждого типа объекта, поддерживаемые в Базе данных RT.Warehouse:
Таблица 24— Привилегии объекта
| Тип объекта | Привилегии |
|---|---|
|
Таблицы, представления, последовательности (Tables, Views, Sequences) |
SELECT INSERT UPDATE DELETE RULE ALL |
| Внешние таблицы (External Tables) |
SELECT RULE ALL |
| Базы данных (Databases) |
CONNECT CREATE TEMPORARY | TEMP ALL |
| Функции (Functions) | EXECUTE |
| Процедурные языки (Procedural Languages) | USAGE |
| Схемы (Schemas) |
CREATE USAGE ALL |
| Пользовательский протокол (Custom Protocol) |
SELECT INSERT UPDATE DELETE RULE ALL |
|
Примечание. Вы должны предоставить привилегии для каждого объекта отдельно. Например, предоставление ALL для базы данных не дает полного доступа к объектам в этой базе данных. Он предоставляет все привилегии уровня базы данных (CONNECT, CREATE, TEMPORARY) только самой базе данных. |
Используйте команду GRANT SQL, чтобы предоставить указанной роли права доступа к объекту. Например, чтобы предоставить роли с именем jsmith права на вставку в таблицу с именем mytable:
=# GRANT INSERT ON mytable TO jsmith;Точно так же, чтобы предоставить привилегии выбора jsmith только для столбца с именем col1 в таблице с именем table2:
=# GRANT SELECT (col1) on TABLE table2 TO jsmith;Чтобы отозвать привилегии, используйте команду REVOKE. Например:
=# REVOKE ALL PRIVILEGES ON mytable FROM jsmith;Вы также можете использовать команды DROP OWNED и REASSIGN OWNED для управления объектами, принадлежащими устаревшим ролям (только владелец объекта или суперпользователь может удалить объект или переназначить владельца). Например:
=# REASSIGN OWNED BY sally TO bob;
=# DROP OWNED BY visitor;База данных RT.Warehouse не поддерживает доступ или безопасность на уровне строк. Вы можете имитировать доступ на уровне строк, используя представления для ограничения выбранных строк. Вы можете имитировать метки на уровне строк, добавив в таблицу дополнительный столбец для хранения конфиденциальной информации, а затем используя представления для управления доступом на уровне строк на основе этого столбца. Затем вы можете предоставить ролям доступ к представлениям, а не к базовой таблице.
База данных RT.Warehouse устанавливается с дополнительным модулем функций шифрования/дешифрования под названием pgcrypto. Функции pgcrypto позволяют администраторам баз данных хранить определенные столбцы данных в зашифрованном виде. Это добавляет дополнительный уровень защиты конфиденциальных данных, поскольку данные, хранящиеся в базе данных RT.Warehouse в зашифрованном виде, не могут быть прочитаны кем-либо, у кого нет ключа шифрования, и не могут быть прочитаны непосредственно с дисков.
|
Примечание. Функции pgcrypto выполняются внутри сервера базы данных, что означает, что все данные и пароли перемещаются между pgcrypto и клиентским приложением открытым текстом. Для оптимальной безопасности также рассмотрите возможность использования SSL-соединений между клиентом и мастер сервером RT.Warehouse. |
Чтобы использовать функции pgcrypto, зарегистрируйте расширение pgcrypto в каждой базе данных, в которой вы хотите использовать эти функции. Например:
$ psql -d testdb -c "CREATE EXTENSION pgcrypto"В конфигурации по умолчанию база данных RT.Warehouse сохраняет хэши MD5 паролей входа пользователей в систему в системном каталоге pg_authid, а не сохраняет пароли в открытом виде. Любой, кто может просматривать таблицу pg_authid, может видеть хеш-строки, но не пароли. Это также гарантирует, что пароли будут скрыты, когда база данных сбрасывается в файлы резервных копий.
Хеш-функция выполняется, когда пароль устанавливается с помощью любой из следующих команд:
Ключевое слово ENCRYPTED может быть опущено, если параметр конфигурации системы password_encryption включен, что является значением по умолчанию. Параметр конфигурации password_encryption определяет, будут ли сохраняться пароли в открытом виде или в виде хэшей, если в команде нет ключевого слова ENCRYPTED или UNENCRYPTED.
|
Примечание. Синтаксис команды SQL и переменная конфигурации password_encryption включают термин шифрование, но пароли технически не шифруются. Они хэшируются и поэтому не могут быть расшифрованы. |
Хэш вычисляется на основе объединенного открытого текста пароля и имени роли. Хэш MD5 создает 32-байтовую шестнадцатеричную строку с префиксом символов md5. Хэшированный пароль сохраняется в столбце rolpassword системной таблицы pg_authid.
Хотя это и не рекомендуется, пароли можно сохранять в базе данных в открытом виде, включив ключевое слово UNENCRYPTED в команду или установив для переменной конфигурации password_encryption значение off. Обратите внимание, что изменение значения конфигурации не влияет на существующие пароли, а только на вновь созданные или обновленные пароли.
Чтобы установить password_encryption глобально, выполните эти команды в оболочке от имени пользователя gpadmin:
$ gpconfig -c password_encryption -v 'off'
$ gpstop -uЧтобы установить password_encryption в сессии, используйте команду SQL SET:
=# SET password_encryption = 'on';Пароли могут быть хешированы с использованием алгоритма хеширования SHA-256 вместо алгоритма хеширования MD5 по умолчанию. Алгоритм создает 64-байтовую шестнадцатеричную строку с префиксом символов sha256.
|
Примечание. Хотя SHA-256 использует более надежный криптографический алгоритм и создает более длинную хеш-строку, его нельзя использовать с методом аутентификации MD5. Чтобы использовать хеширование паролей SHA-256, метод аутентификации должен быть установлен на пароль в файле конфигурации pg_hba.conf, чтобы пароли в открытом виде отправлялись в базу данных RT.Warehouse. Поскольку пароли в открытом виде отправляются по сети, очень важно использовать SSL для клиентских подключений при использовании SHA-256. С другой стороны, метод аутентификации md5 по умолчанию дважды хэширует пароль перед его отправкой в базу данных RT.Warehouse, один раз с паролем и именем роли, а затем еще раз со значением, общим для клиента и сервера, поэтому пароль в открытом виде никогда не отправляется по сети. |
Чтобы включить хеширование SHA-256, измените значение параметра конфигурации password_hash_algorithm со значения по умолчанию, md5, на sha-256. Параметр может быть установлен либо глобально, либо на уровне сеанса. Чтобы установить password_hash_algorithm глобально, выполните эти команды в оболочке от имени пользователя gpadmin:
$ gpconfig -c password_hash_algorithm -v 'sha-256'
$ gpstop -uЧтобы установить password_hash_algorithm в сеансе, используйте команду SQL SET:
=# SET password_hash_algorithm = 'sha-256';База данных RT.Warehouse позволяет администратору ограничить доступ в определенное время по роли. Используйте команды CREATE ROLE или ALTER ROLE, чтобы указать временные ограничения.
Контроль целостности позволяет согласовать конкурентные запросы с правильными результатами, обеспечивая целостность базы данных. Традиционные базы данных используют протокол двухфазной блокировки, что предотвращает транзакцию от изменения данных, которые были прочитаны другой параллельной транзакцией, и не позволяет любой параллельной транзакции считывать или записывать данные, обновленные другой транзакцией. Блокировки, необходимые для координации транзакций, добавляют нагрузку на базу данных, уменьшая общую пропускную способность.
В RT.Warehouse используется PostgreSQL Multiversion Concurrency Control (MVCC) для управления параллельными транзакциями heap-таблиц. С MVCC каждый запрос работает со снапшотом базы данных, создаваемым в тот момент, когда запрос объявляется. Пока выполняется снапшот, запрос не может видеть сделанные другими параллельными транзакциями изменения. Это гарантирует, что запрос видит последовательное представление базы данных. Запросы, которые читают строки, никогда не блокируют транзакции, пишущие строки. И наоборот, запросы, которые записывают строки, не могут быть заблокированы транзакциями, которые читают строки. Это позволяет значительно увеличить параллелизм в сравнении с традиционными базами данных, в которых используется блокировка для координации доступа между транзакциями, которые считывают и записывают данные.
|
Внимание. Append optimized таблицы управляются с помощью иной модели управления параллелизмом, нежели чем модель MVCC, которая обсуждалась в данном разделе. Они предназначены для приложений write-once, read-many, что никогда (или только очень редко) подразумевает обновления на уровне строк. |
Модель MVCC основывается на способности системы управлять несколькими версиями строк данных. Запрос работает со снапшотом базы данных. Снапшот — это набор строк, которые видны в момент транзакции. Снапшот гарантирует, что запрос имеет действительный и корректный снимок базы данных на время выполнения запроса или транзакции.
Каждой транзакции присваивается уникальный идентификатор (XID), 32-битное значение. Оператор SQL, не являющийся частью транзакции, обрабатывается как одиночная транзакция (с добавлением BEGIN и COMMIT). Это похоже на autocommit, используемый в некоторых базах данных.
Когда транзакция вставляет строку, XID сохраняется со строкой в столбце xmin. Когда транзакция удаляет строку, XID сохраняется в столбце системы xmax. Обновление строки рассматривается как delete и insert, поэтому XID сохраняется в xmax текущей строки и xmin только что вставленного ряда. Столбцы xmin и xmax вместе со статусом завершения транзакции определяют диапазон транзакций, для которых видна текущая версия строки. Транзакция видит результаты работы всех транзакций меньше, чем xmin, но не может видеть результаты работы любой транзакции больше или равной xmax.
Операции с несколькими действиями также должны записывать, какая команда в транзакции вставляла строку (cmin) или удаляла строку (cmax), чтобы транзакция могла видеть изменения, сделанные предыдущими командами в транзакции. Последовательность команд имеет смысл только во время выполнения транзакции, поэтому она сбрасывается до 0 в самом начале.
Каждый сегмент RT.Warehouse имеет свою собственную последовательность XID, которая не может сравниваться с XID других инcтансов. Мастер координирует распределённые транзакции с сегментами, использующими идентификационный номер сеанса, называемый gp_session_id. Сегменты сопоставляют идентификаторы распределённых транзакций с их локальными XID. Мастер координирует распределённые транзакции с помощью двухфазового протокола фиксации. Если транзакция не выполняется на одном из сегментов, транзакция прекращается на всех сегментах, и данные возвращаются в первоначальный вид.
Столбцы xmin, xmax, cmin и cmax для любой строки можно увидеть при помощи оператора SELECT:
SELECT xmin, xmax, cmin, cmax, * FROM tablename;Поскольку команда SELECT выполняется на мастере, XID являются идентификаторами распределённых транзакций. В случае если команда выполняется в отдельной базе данных сегментов, значения xmin и xmax соответствуют локальным значениям XID.
Модель MVCC использует идентификаторы транзакций (XID), чтобы определить, какие строки видны в начале запроса или транзакции. XID — это 32-битное значение, поэтому база данных может теоретически выполнить более четырех миллиардов транзакций до того, как значение переполнится и обнулиться. Тем не менее, в RT.Warehouse используется арифметика по модулю 2^32, что позволяет XID зацикливаться. Для любого XID может быть около двух миллиардов предыдущих и новых XID. Это работает до тех пор, пока текущая версия строки примерно через два миллиарда транзакций неожиданно не станет новой строкой. Чтобы предотвратить это, RT.Warehouse имеет специальный XID, называемый FrozenXID, который всегда считается старше обычного XID, с которым он сравнивается. xmin строки должен быть заменён на FrozenXID в течение двух миллиардов транзакций, и это одна из функций, выполняемых командой VACUUM.
Очистка (vacuuming) как минимум раз в два миллиарда транзакций предотвращает зацикливание XID. RT.Warehouse отслеживает XID и предупреждает, когда требуется произвести очистку (операция VACUUM).
Когда значительная часть идентификаторов больше недоступна и до того, как происходит зацикливание XID, выдается предупреждение:
WARNING: database "database_name" must be vacuumed within number_of_transactions
TransactionsЕсли операция VACUUM не выполняется, RT.Warehouse перестаёт создавать транзакции, чтобы избежать возможной потери данных. При достижении лимита, система сообщает об ошибке:
FATAL: database is not accepting commands to avoid wraparound data loss in database
"database_name"Параметры конфигурации сервера xid_warn_limit и xid_stop_limit управляют отображением предупреждений и ошибок. Параметр xid_warn_limit показывает количество идентификаторов транзакций перед значением xid_stop_limit. А параметр xid_stop_limit показывает количество XID перед тем, как происходит зацикливание и выдаётся ошибка.
Стандарт SQL описывает три явления, которые могут возникать при запуске транзакций базы данных одновременно:
Стандарт SQL определяет четыре режима изоляции транзакций, которые должны поддерживать системы баз данных:
Команды SQL RT.Warehouse позволяют запросить READ UNCOMMITTED, READ COMMITTED илиSERIALIZABLE. RT.Warehouse рассматривает READ UNCOMMITTED так же, как READ COMMITTED. Запрос REPEATABLE READ вызывает ошибку, вместо этого необходимо использовать SERIALIZABLE. Режим изоляции по умолчанию — READ COMMITTED.
Разница между READ COMMITTED и SERIALIZABLE заключается в том, что в режиме READ COMMITTED каждый оператор в транзакции видит только строки, обновлённые до начала выполнения оператора, в то время как в режиме SERIALIZABLE все операторы транзакции видят строки, обновлённые до начала транзакции.
Режим изоляции READ COMMITTED обеспечивает лучшее распараллеливание и лучшую производительность, чем режим SERIALIZABLE. Он допускает неповторяющиеся чтения, где значения в строке, полученные дважды в транзакции, могут отличаться, поскольку другая параллельная транзакция совершила изменения. Режим READ COMMITTED также позволяет делать фантомные чтения, где запрос, выполненный дважды в одной и той же транзакции, может возвращать два разных набора строк.
Режим изоляции SERIALIZABLE предотвращает как неповторяющиеся чтения, так и фантомные чтения, но за счёт ухудшения распараллеливания и производительности. Все параллельные транзакции имеют одинаковый снимок базы данных, полученный перед началом транзакций. Параллельная транзакция, которая пытается изменить данные, уже изменённые другой транзакцией, получает запрет на это действие. Приложения, выполняющие транзакции в режиме SERIALIZABLE, должны быть подготовлены к обработке транзакций, не выполняющихся из-за ошибок сериализации. Если режим изоляции SERIALIZABLE жёстко не требуется, лучше использовать режим READ COMMITTED.
Стандарт SQL подразумевает, что параллельные упорядоченные транзакции приводят базу данных в одно состояние в независимости от типа их обработки (т.е. в параллели или друг за другом). Модель изоляции снапшотов MVCC предотвращает грязные чтения, неповторяющиеся чтения и фантомные чтения, не используя блокировку. Однако, иные взаимодействия, которые могут возникнуть между некоторыми транзакциями SERIALIZABLE в RT.Warehouse, не позволяют им называться полностью упорядоченными. Эти аномалии можно отнести к тому факту, что RT.Warehouse не выполняет блокировку предикатов, а это означает, что запись одной транзакции может повлиять на результат предыдущего чтения в другой параллельной транзакции.
Транзакции, которые выполняются одновременно, должны быть проверены на предмет взаимодействий, которые не могут быть предотвращены путём запрета параллельных обновлений одних и тех же данных. Определённые проблемы можно предотвратить, используя блокировки таблиц или потребовав, чтобы конфликтующие транзакции обновили фиктивную строку, введённую для представления конфликта.
Оператор SQL SET TRANSACTION ISOLATION LEVEL устанавливает режим изоляции для текущей транзакции. Режим должен быть установлен перед любыми операциями SELECT, INSERT, DELETE, UPDATE или COPY:
BEGIN;
SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;
...
COMMIT;Режим изоляции также может быть указан как часть инструкции BEGIN:
BEGIN TRANSACTION ISOLATION LEVEL SERIALIZABLE;Режим изоляции транзакции по умолчанию можно изменить с помощью свойства default_transaction_isolation.
Обновление или удаление строки оставляет предыдущую версию строки в таблице. Если строка с истёкшим сроком действия указана в активных транзакциях, её можно удалить, а занимаемое ею пространство повторно использовать. За это действие отвечает команда VACUUM.
Когда недействительные строки накапливаются в таблице, дисковые файлы должны быть расширены для размещения новых строк. Увеличенная нагрузка на ввод/вывод дисков, используемых для обработки запросов, негативно влияет на производительность. Эта ситуация называется раздутие (bloat), и её следует контролировать с помощью регулярной чистки.
Команда VACUUM может работать одновременно с другими запросами. Она удаляет неиспользуемые строки со страниц и переупаковывает оставшиеся строки для консолидации свободного места. Если после очистки осталось много свободного пространства, в таблицу свободного пространства добавляется страница. Позднее, когда базе данных требуется пространство для новых строк, она обращается к карте свободного пространства таблицы. Если ни одна страница не найдена, добавляются новые страницы.
VACUUM не консолидирует страницы и не уменьшает размер таблицы на диске. Пространство, которое эта команда восстанавливает, доступно только через карту свободного пространства. Чтобы размер файлов на диске не рос, важно хотя бы один раз в день запускать VACUUM. Также важно запускать VACUUM после выполнения транзакции, которая обновляет или удаляет большое количество строк.
Команда VACUUM FULL перезаписывает таблицу без неиспользуемых строк, сводя её к минимальному размеру. Для создания новой таблицы должно быть достаточно места на диске. При этом таблица блокируется до тех пор, пока команда VACUUM FULL не завершится. Это очень ресурсоёмко по сравнению с обычной командой VACUUM, и её можно избежать или отложить путём регулярной чистки. Лучше всего запускать VACUUM FULL в течение периода технического обслуживания. Альтернативой VACUUM FULL является воссоздание таблицы с помощью инструкции CREATE TABLE AS с последующим удалением старой таблицы.
Карта свободного пространства находится в общей памяти и отслеживает свободное пространство для всех таблиц и индексов. Каждая таблица или индекс использует около 60 байт памяти, и каждая страница со свободным пространством занимает 6 байт. Два параметра конфигурации системы определяют размер карты свободного пространства:
Если карта свободного пространства слишком маленькая, дисковые страницы с доступным пространством не добавляются на карту, и это пространство не может быть повторно использовано до тех пор, пока не будет запущена, по меньшей мере, следующая команда VACUUM. Это приводит к росту файлов.
Можно запустить VACUUM VERBOSE tablename, чтобы получить отчёт по сегменту о количестве удалённых строк, количестве затронутых страниц и количестве страниц с полезным свободным пространством.
Чтобы узнать, сколько страниц таблица использует во всех сегментах, необходимо запросить системную таблицу pg_class. Чтобы получить точные данные обязательно следует сначала выполнить ANALYZE для таблицы.
| SELECT relname, relpages, reltuples FROM pg_class WHERE relname = 'tablename'; |
Другим полезным инструментом является gp_bloat_diag в схеме gp_toolkit, который идентифицирует раздутие (bloat) в таблицах путём сравнения фактического количества используемых таблицей страниц с ожидаемым числом.
В разделе приводится краткое описание методов загрузки данных в RT.Warehouse.
В крупномасштабном хранилище большие объёмы данных должны загружаться за довольно короткий промежуток времени. RT.Warehouse поддерживает быструю параллельную загрузку данных с помощью функции внешних таблиц. Администраторы также могут загружать внешние таблицы в режиме изоляции ошибочных строк, чтобы фильтровать ошибочные строки в отдельную таблицу, продолжая загрузку правильно отформатированных строк. Администраторы могут указать порог ошибок для операции загрузки, чтобы контролировать, какое количество неправильно отформатированных строк заставляет RT.Warehouse прерывать операцию загрузки.
Используя внешние таблицы в сочетании с параллельным файловым сервером (gpfdist) можно достичь максимального распараллеливания и пропускной способности базы данных.
Другая утилита RT.Warehouse gpload запускает задачу загрузки, указанную в управляемом файле в формате YAML. Необходимо описать местоположение исходных данных, формат, необходимые преобразования, участвующие хосты, адресаты баз данных и другие данные в файле управления, после чего gpload выполняет загрузку. Это позволяет описать сложную задачу и выполнить её контролируемым системным образом.
В данном разделе представлен общий обзор функций высокой доступности базы данных RT.Warehouse.
Вы можете развернуть базу данных RT.Warehouse без единой точки отказа за счёт зеркалирования компонентов. В следующих разделах описываются стратегии зеркалирования основных компонентов системы RT.Warehouse.
При развёртывании базы данных RT.Warehouse вы можете настроить инстансы зеркальных сегментов. Зеркальные сегменты позволяют запросам базы данных переключаться на резервный сегмент, если основной сегмент становится недоступным. Зеркальный сегмент поддерживается в актуальном состоянии за счёт процесса репликации журнала транзакций, который синхронизирует данные между основным и зеркальным инстансами.
Рекомендуется, чтобы инстанс резервного (зеркального) сегмента всегда находился на хосте, отличном от его инстанса основного сегмента, чтобы защититься от сбоя одного хоста. В виртуализированных средах резервный (зеркальный) сегмент всегда должен находиться в системе хранения, отличной от основного сегмента. Зеркальные сегменты могут быть размещены поверх оставшихся хостов в кластере в конфигурациях, предназначенных для обеспечения максимальной доступности или минимизации деградации производительности при сбое хостов или нескольких основных сегментов.
При инициализации или расширении системы RT.Warehouse доступны две стандартные конфигурации зеркалирования. Конфигурация по умолчанию, называемая групповым зеркалированием, размещает зеркальные сегменты для всех основных сегментов одного хоста на другом хосте. Другая стандартная конфигурация, называемая распределённым зеркалированием, может быть выбрана с помощью параметра командной строки. Распределённое зеркалирование распределяет зеркала для основных сегментов каждого хоста по остальным хостам. Распределённое зеркалирование требует, чтобы в системе было больше хостов, чем основных сегментов на хосте.
Когда зеркалирование сегментов включено в базе данных RT.Warehouse, система автоматически переключается на инстанс зеркального сегмента, если инстанс основного сегмента становится недоступным. База данных RT.Warehouse может оставаться работоспособной, если инстанс сегмента или хост выходит из строя, пока все данные доступны в оставшихся активных инстансах сегмента.
Если мастер не может подключиться к инстансу сегмента, он помечает этот инстанс сегмента как отключённый в системном каталоге базы данных RT.Warehouse и переносит на его место зеркальный сегмент. Инстанс отказавшего сегмента не будет работать до тех пор, пока администратор не предпримет шаги, чтобы вернуть этот сегмент в оперативный режим. Администратор может восстановить неисправный сегмент, пока система работает. Процесс восстановления копирует только те изменения, которые были пропущены, пока сегмент не работал.
Если у вас не включено зеркалирование, система автоматически отключится, если инстанс сегмента станет недействительным. Вы должны восстановить все поврежденные сегменты, прежде чем операции можно будет продолжить.
Вы также можете дополнительно развернуть резервную копию или зеркало инстанса мастера на отдельном хосте, отличном от хоста мастера. Резервный мастер служит в качестве горячего резерва на случай, если основной мастер перестанет работать. Резервный мастер поддерживается в актуальном состоянии за счёт процесса репликации журнала транзакций, который синхронизирует данные между основным и резервным мастером.
Если основной мастер выходит из строя, процесс репликации журнала останавливается, и можно активировать резервный мастер. Переключение не происходит автоматически, а должно быть вызвано извне. После активации резервного мастера реплицированные журналы используются для восстановления состояния хоста мастера на момент последней успешно зафиксированной транзакции. Активированный резервный мастер фактически становится мастером базы данных RT.Warehouse, принимая клиентские подключения через порт мастера.
Поскольку мастер не содержит пользовательских данных, необходимо синхронизировать только таблицы системного каталога между основной и резервной копиями. Когда эти таблицы обновляются, изменения автоматически копируются на резервный мастер, чтобы обеспечить синхронизацию с основным мастером.
Интерконнект относится к межпроцессному взаимодействию между сегментами и сетевой инфраструктурой, от которой зависит данное взаимодействие. Вы можете добиться высокодоступного интерконнекта, развернув в своей сети два коммутатора Gigabit Ethernet и резервные соединения Gigabit с хост-серверами базы данных RT.Warehouse (мастером и сегментами). Из соображений производительности рекомендуется 10 Gigabit Ethernet или выше.
В разделе представлен обзор статистики, собранной командой ANALYZE в базе данных RT.Warehouse.
Статистика — это метаданные, которые описывают данные, хранящиеся в базе данных. Оптимизатору запросов нужна актуальная статистика, чтобы выбрать наилучший план выполнения запроса. Например, если запрос объединяет две таблицы, и одна из них должна быть передана всем сегментам, оптимизатор может выбрать меньшую из двух таблиц, чтобы минимизировать сетевой трафик.
Статистика, используемая оптимизатором, рассчитывается и сохраняется в системном каталоге командой ANALYZE. Существует три способа инициировать операцию ANALYZE:
Эти методы описаны в следующих разделах. Команда VACUUM ANALYZE — это ещё один способ инициировать операцию ANALYZE, но её использование не рекомендуется, поскольку операции очистки и анализа — это разные операции с разными целями.
Вычисление статистики требует времени и ресурсов, поэтому база данных RT.Warehouse производит оценки, вычисляя статистику по выборкам больших таблиц. В большинстве случаев параметры по умолчанию предоставляют информацию, необходимую для создания корректных планов выполнения запросов. Если полученная статистика не даёт оптимальных планов выполнения запросов, администратор может настроить параметры конфигурации для получения более точных статистических данных, увеличив размер выборки или степень детализации статистики, сохраняемой в системном каталоге. Создание более точных статистических данных связано с затратами на ЦПУ и хранилище и может не привести к лучшим планам, поэтому важно просматривать планы объяснения и тестировать производительность запросов, чтобы убедиться, что дополнительные затраты, связанные со статистикой, приводят к повышению производительности запросов.
Планировщик запросов стремится свести к минимуму дисковый ввод-вывод и сетевой трафик, необходимые для выполнения запроса, используя оценки количества строк, которые должны быть обработаны, и количество дисковых страниц, к которым должен обращаться запрос. Данные, из которых получены эти оценки, представляют собой столбцы системной таблицы pg_class reltuples и relpages, которые содержат количество строк и страниц на момент последнего запуска команды VACUUM или ANALYZE. По мере добавления или удаления строк числа становятся менее точными. Тем не менее, операционная система всегда может получить точное количество страниц на диске, поэтому до тех пор, пока отношение reltuples к relpages существенно не изменится, оптимизатор может произвести оценку количества строк, достаточно точную, чтобы выбрать корректный план выполнения запроса.
Когда столбец reltuples значительно отличается от количества строк, возвращаемого SELECT COUNT(*), необходимо выполнить ANALYZE для обновления статистики.
Когда команда REINDEX завершает воссоздание индекса, столбцы relpages и reltuples обнуляются. Команду ANALYZE следует запустить для базовой таблицы, чтобы обновить эти столбцы.
Системная таблица pg_statistic содержит результаты последней операции ANALYZE для каждой таблицы базы данных. Для каждого столбца каждой таблицы есть строка. Она имеет столбцы, описанные в таблице ниже.
Таблица 13— Столбцы системной таблицы pg_statistic
| Наименование столбца | Описание |
|---|---|
| starelid |
Идентификатор объекта таблицы или индекса, которому принадлежит столбец. |
| staattnum |
Номер описываемого столбца, начиная с 1. |
| stainherit |
Если true, статистика включает дочерние столбцы наследования, а не только значения в указанном отношении. |
| stanullfrac |
Доля записей столбца, которые являются нулевыми. |
| stawidth |
Средняя сохраняемая ширина ненулевых записей в байтах. |
| stadistinct |
Положительное число — это оценка количества различных значений в столбце. Ожидается, что это число не будет меняться в зависимости от количества строк. Отрицательное значение — это количество уникальных значений, делённое на количество строк, то есть доля строк с уникальными значениями для столбца. Эта форма используется, когда количество различных значений увеличивается с количеством строк. Например, уникальный столбец имеет значение n_distinct, равное -1.0. Столбцы со средней шириной более 1024 считаются уникальными. |
| stakindN |
Кодовое число, указывающее тип статистики, хранящейся в N-м слоте строки pg_statistic. |
| staopN |
Оператор, используемый для получения статистики, хранящейся в N-м слоте. Например, слот Histogram будет отображать оператор <, который определяет порядок сортировки данных. |
| stanumbersN |
Массив float4, содержащий числовую статистику соответствующего вида для N-го слота, или NULL, если вид слота не включает числовые значения. |
| stavaluesN |
Значения данных столбца соответствующего типа для N-го слота или NULL, если тип слота не хранит никаких значений данных. Значения элементов каждого массива фактически имеют тип данных определённого столбца, так что определить типы эти столбцов более конкретно, чем anyarray, нельзя. |
Статистика, собранная для столбца, различается для разных типов данных, поэтому таблица pg_statistic хранит статистику, соответствующую типу данных, в четырех слотах, состоящих из четырёх столбцов на каждый слот. Например, первый слот, который обычно содержит наиболее распространённые значения для столбца, состоит из столбцов stakind1, staop1, stanumbers1 и stavalues1.
Каждый столбец stakindN содержит числовой код, описывающий тип статистики, хранящейся в соответствующем слоте. Кодовые номера stakind от 1 до 99 зарезервированы для основных типов данных PostgreSQL. База данных RT.Warehouse использует кодовые номера 1, 2, 3, 4, 5 и 99. Значение 0 означает, что слот не используется. В следующей таблице описаны виды статистики, хранящейся для кодов.
Таблица 14— Виды статистики кодов stakind
| Код stakind | Описание |
|---|---|
| 1 |
Слот Most CommonValues (MCV):
Значения упорядочены по убыванию частоты. Поскольку массивы имеют переменный размер, K может быть выбран сборщиком статистики. Значения должны встречаться более одного раза, чтобы быть добавленными в массив stavalues; уникальный столбец не имеет слота MCV. |
| 2 |
Слот Histogram — описывает распределение скалярных данных:
Если также предусмотрен слот Most Common Values, то Histogram описывает распределение данных после удаления значений, перечисленных в массиве MCV (на техническом языке это compressed histogram). Это позволяет более точно представить распределение столбца с некоторыми очень распространёнными значениями. В столбце с несколькими различными значениями список MCV может описывать всю совокупность данных; в данном случае гистограмма становится пустой и её следует пропустить. |
| 3 |
Слот Correlation — описывает корреляцию между физическим порядком кортежей таблицы и порядком значений данных этого столбца.
|
| 4 |
Слот Most Common Elements — аналогичен слоту Most Common Values (MCV), за исключением того, что в нём хранятся наиболее распространённые отличные от null элементы значений столбца. Это полезно, когда тип данных столбца представляет собой массив или какой-либо другой тип с идентифицируемыми элементами (например, tsvector):
Частоты измеряются как доля отличных от null строк, в которых появляется значение элемента, а не как частота всех строк. Кроме того, значения сортируются в порядке по умолчанию для типа элемента (для поддержки бинарного поиска определённого значения). Поскольку это помещает минимальную и максимальную частоты в непредсказуемые места в stanumbers, есть два дополнительных члена stanumbers, которые содержат копии минимальной и максимальной частот. При желании может быть третий дополнительный член, который содержит частоту нулевых элементов (частота выражается теми же терминами: доля отличных от null строк, содержащих хотя бы один null элемент). Если этот элемент опущен, предполагается, что столбец не содержит элементов NULL. Примечание. Для столбцов tsvector элементы stavalues имеют тип text, хотя их представление в tsvector не совсем text. |
| 5 |
Слот Distinct Elements Count Histogram — описывает распределение количества значений отдельных элементов, присутствующих в каждой строке столбца типа массива. Учитываются только отличные от null строки и только отличные от null элементы:
|
| 99 |
Слот Hyperloglog — для дочерних leaf-партиций партиционированной таблицы хранит счётчик hyperloglog_counter, созданный для выборочных данных. Структура данных hyperloglog_counter преобразуется в bytea и сохраняется в слоте stavalues5 таблицы каталога pg_statistic. |
Представление pg_stats представляет содержимое pg_statistic в более удобном формате. В представлении pg_stats есть столбцы, представленные в таблице ниже.
Таблица 15— Столбцы представления pg_stats
| Наименование столбца | Описание |
|---|---|
| schemaname |
Имя схемы, содержащей таблицу. |
| tablename |
Имя таблицы. |
| attname |
Имя столбца, который описывает эта строка. |
| inherited |
Если true, статистика включает дочерние столбцы наследования. |
| null_frac |
Доля записей столбца, которые являются null. |
| avg_width |
Средняя ширина хранилища в байтах для записей столбца, вычисляемая как avg(pg_column_size(column_name)). |
| n_distinct |
Положительное число — это оценка количества различных значений в столбце. Ожидается, что это число не будет меняться в зависимости от количества строк. Отрицательное значение — это количество уникальных значений, делённое на количество строк, то есть доля строк с уникальными значениями для столбца. Эта форма используется, когда количество различных значений увеличивается с количеством строк. Например, уникальный столбец имеет значение n_distinct, равное -1.0. Столбцы со средней шириной более 1024 считаются уникальными. |
| most_common_vals |
Массив, содержащий наиболее распространённые значения в столбце, или null, если нет более распространённых значений. Если столбец n_distinct равен -1, то most_common_vals имеет значение null. Длина массива равна меньшему из числа фактических отдельных значений столбца или значению параметра конфигурации default_statistics_target. Количество значений для столбца можно переопределить с помощью таблицы ALTER TABLE SET COLUMN column SET STATISTICS N. |
| most_common_freqs |
Массив, содержащий частоты значений в массиве most_common_vals. Это количество вхождений значения, делённое на общее количество строк. Массив имеет ту же длину, что и массив most_common_vals. Это значение null, если значение most_common_vals равно null. |
| histogram_bounds |
Массив значений, который делит значения столбца на группы примерно одинакового размера. Гистограмма может быть определена, только если для столбца существует агрегатная функция max(). Количество групп в гистограмме равно размеру массива most_common_vals. |
| correlation |
База данных RT.Warehouse вычисляет статистику корреляции для heap-таблиц. Эта статистика используется Планировщиком Postgres. RT.Warehouse не вычисляет корреляционную статистику для таблиц AO и AOCO; значение в этом столбце для этих типов таблиц не определено. |
| most_common_elems |
Массив, содержащий наиболее распространённые значения элементов. |
| most_common_elem_freqs |
Массив, содержащий частоты общих элементов. |
| elem_count_histogram |
Массив, описывающий распределение количества различных значений элементов, присутствующих в каждой строке столбца типа массива. |
Вновь созданные таблицы и индексы не имеют статистики. Вы можете проверить наличие таблиц с отсутствующей статистикой, используя представление gp_stats_missing, которое находится в схеме gp_toolkit:
SELECT * from gp_toolkit.gp_stats_missing;При расчёте статистики для больших таблиц база данных RT.Warehouse создаёт таблицу меньшего размера путём выборки из базовой таблицы. Если таблица партиционирована, выборки берутся со всех партиций.
Запуск ANALYZE без аргументов обновляет статистику для всех таблиц в базе данных. Это может занять очень много времени, поэтому лучше выборочно анализировать таблицы после изменения данных. Вы также можете проанализировать подмножество столбцов в таблице, например, столбцы, используемые в соединениях (JOIN), предложениях WHERE, предложениях SORT, предложениях GROUP BY или предложениях HAVING.
Анализ сильно раздутой таблицы может привести к плохой статистике, если образец содержит пустые страницы, поэтому рекомендуется очищать раздутую таблицу перед её анализом.
Когда команда ANALYZE запускается для партиционированной таблицы, она анализирует каждую дочернюю leaf-таблицу партиций по одной. Вы можете запустить ANALYZE только для новых или изменённых файлов партиций, чтобы избежать анализа партиций, которые не изменились.
Утилита командной строки analyzedb автоматически пропускает неизменённые партиции. Он также запускает параллельные сеансы, поэтому может одновременно анализировать несколько партиций. По умолчанию она запускает пять сеансов, но количество сеансов можно установить от 1 до 10 с помощью параметра командной строки -p. Каждый раз, когда analyzedb запускается, он сохраняет информацию о состоянии для таблиц и партиций, оптимизированных для добавления, в каталоге db_analyze в каталоге данных мастера. При следующем запуске, analyzedb сравнивает текущее состояние каждой таблицы с сохранённым состоянием и пропускает анализ таблицы или партиции, если они не изменились. Heap-таблицы всегда анализируются.
Если GPORCA включён (по умолчанию), вам также необходимо запустить ANALYZE или ANALYZE ROOTPARTITION, чтобы обновить статистику корневой партиции. GPORCA требует статистики на корневом уровне для партиционированных таблиц. Планировщик Postgres не использует эту статистику.
Время анализа партиционированной таблицы аналогично времени анализа непартиционированной таблицы с теми же данными, поскольку ANALYZE ROOTPARTITION не собирает статистику по leaf-партициям (данные только выбираются). Утилита analyzedb обновляет статистику корневой партиции по умолчанию, но вы можете добавить параметр --skip_root_stats, чтобы оставить статистику корневой партиции пустой, если вы не используете GPORCA.
Параметр конфигурации сервера базы данных RT.Warehouse optimizer_analyze_root_partition влияет на сбор статистики по корневой партиции партиционированной таблицы. Если параметр включён (по умолчанию), ключевое слово ROOTPARTITION не требуется для сбора статистики по корневой партиции при запуске ANALYZE. Статистика корневой партиции собирается, когда вы запускаете ANALYZE для корневой партиции или когда вы запускаете ANALYZE для дочерней leaf-партиции партиционированной таблицы, а другие дочерние конечные партиции имеют статистику. Если параметр выключен, необходимо запустить ANALYZE ROOTPARTITION для сбора статистики корневой партиции.
Если вы не собираетесь выполнять запросы к партиционированным таблицам с помощью GPORCA (отключив параметр optimizer конфигурации сервера), вы также можете отключить параметр конфигурации сервера optimizer_analyze_root_partition, чтобы ограничить время, когда ANALYZE обновляет статистику корневой партиции.
Существует несколько вариантов настройки сбора статистики базы данных RT.Warehouse.
Целью статистики является размер массивов most_common_vals, most_common_freqs и histogram_bounds для отдельного столбца. По умолчанию целевое значение равно 25. Целевое значение по умолчанию можно изменить, задав параметр конфигурации сервера, а целевое значение можно установить для любого столбца с помощью команды ALTER TABLE. Большие значения увеличивают время, необходимое для выполнения ANALYZE, но могут улучшить качество оценок Планировщика Postgres.
Задайте для цели статистики системы по умолчанию другое значение, установив параметр конфигурации сервера default_statistics_target. Обычно достаточно значения по умолчанию, и его следует увеличивать или уменьшать только в том случае, если ваши тесты показывают, что планы запросов улучшаются с новой целью. Например, чтобы поднять цель статистики по умолчанию со 100 до 150, вы можете использовать утилиту gpconfig:
gpconfig -c default_statistics_target -v 150Цель статистики для отдельных столбцов может быть установлена с помощью команды ALTER TABLE. Например, некоторые запросы можно улучшить, увеличив целевое значение для определённых столбцов, особенно столбцов с нерегулярным распределением. Вы можете установить целевое значение равным нулю для столбцов, которые никогда не способствуют оптимизации запросов. Когда цель равна 0, ANALYZE игнорирует столбец. Например, следующая команда ALTER TABLE устанавливает цель статистики для столбца notes в таблице emp на ноль:
ALTER TABLE emp ALTER COLUMN notes SET STATISTICS 0;Цель статистики может быть установлена в диапазоне от 0 до 1000 или установлена на -1, чтобы вернуться к использованию цели статистики по умолчанию.
Установка цели статистики для родительской таблицы партиций влияет на дочерние партиции. Если вы установите статистику на 0 для некоторых столбцов в родительской таблице, статистика для тех же столбцов будет установлена на 0 для всех дочерних партиций. Однако, если вы позже добавите или замените другую дочернюю партицию, новая дочерняя партиция будет использовать либо цель статистики по умолчанию, либо, в случае замены, предыдущую цель статистики. Поэтому, если вы добавляете или обмениваете дочерние партиции, вы должны установить цели статистики для новой дочерней таблицы.
Базу данных RT.Warehouse можно настроить на автоматический запуск ANALYZE для таблицы, которая либо не имеет статистики, либо значительно изменилась при выполнении определённых операций с таблицей. Для партиционированных таблиц автоматический сбор статистики запускается только тогда, когда операция выполняется непосредственно над leaf-таблицей, после чего анализируется только leaf-таблица.
Автоматический сбор статистики имеет три режима:
Режим автоматического сбора статистики задаётся отдельно для команд, которые возникают внутри функции процедурного языка, и для команд, которые выполняются вне функции:
В режиме on_change ANALYZE запускается только в том случае, если количество затронутых строк превышает пороговое значение, заданное параметром конфигурации gp_autostats_on_change_threshold. Значение по умолчанию для этого параметра — очень большое значение, 2147483647, которое эффективно отключает автоматический сбор статистики; вы должны установить порог на более низкое число, чтобы включить его. Режим on_change может инициировать большие, неожиданные операции анализа, которые могут нарушить работу системы, поэтому не рекомендуется устанавливать его глобально. Это может быть полезно в сеансе, например, для автоматического анализа таблицы после загрузки.
Чтобы отключить автоматический сбор статистики вне функций, установите для параметра gp_autostats_mode значение none:
gpconfigure -c gp_autostats_mode -v noneЧтобы включить автоматический сбор статистики в функциях для таблиц, не имеющих статистики, измените gp_autostats_mode_in_functions на on_no_stats:
gpconfigure -c gp_autostats_mode_in_functions -v on_no_statsУстановите для параметра системной конфигурации log_autostats значение on, если вы хотите протоколировать операции автоматического сбора статистики.
Раздел содержит общую информацию об использовании служебных программ RT.Warehouse.
Когда вы ссылаетесь на адреса IPv6 в служебных программах RT.Warehouse или когда используете числовые IP-адреса вместо имён хостов в любой служебной программе управления, всегда заключайте IP-адрес в скобки. При указании IP-адреса в командной строке лучше всего избегать скобок или заключать их в одинарные кавычки. Например, используйте:
\[2620:0:170:610::11\]Или:
'[2620:0:170:610::11]'RT.Warehouse модифицировал некоторые программы внутреннего сервера PostgreSQL для обеспечения параллелизма и распределения системы RT.Warehouse. Вы получаете доступ к этим программам только через инструменты и утилиты управления RT.Warehouse. Не запускайте эти программы напрямую.
В следующей таблице указаны некоторые программы внутреннего сервера PostgreSQL и служебная команда RT.Warehouse, которые следует запускать вместо них.
Таблица 5— Программы внутреннего сервера RT.Warehouse
|
Программа PostgreSQL |
Описание |
Программа RT.Warehouse, которую следует использовать |
|---|---|---|
| initdb |
Программа вызывается gpinitsystem при инициализации массива RT.Warehouse. Он используется внутри компании для создания отдельных инстансов сегмента и инстанса мастера. |
gpinitsystem |
| ipcclean |
Не используется в RT.Warehouse. |
— |
| pg_basebackup |
Программа создаёт бинарную копию единственного инстанса базы данных. RT.Warehouse использует его для таких задач, как создание инстанса резервного мастера или восстановление зеркального сегмента, когда требуется полная копия. Не используйте эту утилиту для резервного копирования инстансов сегментов RT.Warehouse, поскольку она не создаёт резервные копии, согласованные с MPP. |
gpinitstandby, gprecoverseg |
| pg_controldata |
Не используется в RT.Warehouse. |
gpstate |
| pg_ctl |
Программа вызывается gpstart и gpstop при запуске или остановке массива RT.Warehouse. Она используется внутри для остановки и запуска инстансов отдельных сегментов и инстанса мастера параллельно и с правильными параметрами. |
gpstart, gpstop |
| pg_resetxlog |
Не используйте! Внимание. Эта программа может вызвать потерю данных или стать причиной их недоступности. Если эта программа используется, кластер необходимо повторно инициализировать и восстановить. |
— |
| postgres |
Исполняемый файл postgres — это фактический серверный процесс PostgreSQL, обрабатывающий запросы. |
Основной процесс postgres (postmaster) создаёт другие подпроцессы postgres и сеанс postgres по мере необходимости для обработки клиентских подключений. |
| postmaster |
postmaster запускает процесс прослушивания сервера базы данных postgres, который принимает клиентские соединения. В RT.Warehouse процесс прослушивания базы данных postgres выполняется на инстансе мастера RT.Warehouse и на каждом инстансе сегмента. |
В RT.Warehouse используйте gpstart и gpstop для одновременного запуска всех postmaster (процессов postgres) в системе в правильном порядке и с правильными параметрами. |
В разделе представлены утилиты командной строки, входящие в состав RT.Warehouse.
RT.Warehouse использует стандартные клиентские и серверные программы PostgreSQL и предоставляет дополнительные служебные программы для администрирования распределённой СУБД RT.Warehouse.
При установке сервера RT.Warehouse устанавливается несколько утилит.
Эти утилиты находятся в $GPHOME/bin.
Утилита, которая выполняет операции ANALYZE над таблицами инкрементально и одновременно. Для добавления оптимизированных таблиц analyzedb обновляет статистику только в том случае, если статистика не актуальна.
analyzedb -d dbname
{ -s schema |
{ -t schema.table
[ -i col1[, col2, ...] |
-x col1[, col2, ...] ] } |
{ -f | --file} config-file }
[ -l | --list ]
[ --gen_profile_only ]
[ -p parallel-level ]
[ --full ]
[ --skip_root_stats ]
[ -v | --verbose ]
[ --debug ]
[ -a ]
analyzedb { --clean_last | --clean_all }
analyzedb --version
analyzedb { -? | -h | --help }Утилита analyzedb обновляет статистику табличных данных для указанных таблиц в RT.Warehouse инкрементально и одновременно.
Выполняя операции ANALYZE, analyzedb создаёт снапшот метаданных таблицы и сохраняет его на диске на хосте мастера. Операция ANALYZE выполняется, только если таблица была изменена. Если таблица или партиция не изменялись с момента последнего анализа, analyzedb автоматически пропускает таблицу или партицию, поскольку они уже содержат актуальную статистику.
1) Для добавления оптимизированных таблиц, analyzedb обновляет статистику инкрементально, если статистика устарела. Например, если данные таблицы были изменены после сбора статистики для таблицы. Если статистики для таблицы нет, статистика собирается.
2) Для heap-таблиц статистика всегда обновляется.
Укажите параметр --full для обновления статистики таблицы, оптимизированной для добавления, даже если статистика таблицы актуальна.
По умолчанию analyzedb создаёт максимум 5 одновременных сеансов для параллельного анализа таблиц. Для каждого сеанса analyzedb выдаёт команду ANALYZE базе данных и указывает разные имена таблиц. Параметр ‑p управляет максимальным количеством одновременных сеансов.
Для партиционированной таблицы, оптимизированной для добавления, analyzedb проверяет корневую партицию партиционированной таблицы и leaf-партиции. При необходимости утилита обновляет статистику для устаревших партиций и корневой партиции.
Статистика корневой партиции требуется GPORCA. По умолчанию утилита analyzedb собирает статистику в корневой партиции партиционированной таблицы, если статистика не существует. Если какая-либо из leaf-партиций имеет устаревшую статистику, analyzedb также обновляет статистику корневой партиции. Стоимость обновления статистики корневого уровня сопоставима с анализом одной leaf-партиции. Вы можете указать параметр ‑-skip_root_stats, чтобы отключить сбор статистики в корневой партиции партиционированной таблицы.
Утилита analyzedb обновляет статистику оптимизированной таблицы, если таблица была изменена командами DML или DDL, включая INSERT, DELETE, UPDATE, CREATE TABLE, ALTER TABLE и TRUNCATE. Утилита определяет, была ли таблица изменена, сравнивая метаданные каталога таблиц с предыдущим снапшотом метаданных, сделанным во время предыдущей операции analyzedb. Снапшоты метаданных таблицы хранятся в виде файлов состояния в каталоге db_analyze/<db_name>/<timestamp> в каталоге основных данных RT.Warehouse.
Утилита не удаляет автоматически старую информацию о снапшотах. Со временем снапшоты могут занимать большой объём дискового пространства. Чтобы освободить место на диске, вы можете сохранить самую свежую информацию о снапшотах и удалить старые снапшоты. Вы также можете указать параметр --clean_last или --clean_all, чтобы удалить файлы состояния, созданные с помощью analyzedb.
Если вы не укажете таблицу, набор таблиц или схему, утилита analyzedb собирает статистику по мере необходимости по всем таблицам системного каталога и пользовательским таблицам в базе данных.
На внешние таблицы analyzedb не влияет.
Имена таблиц, содержащие пробелы, не поддерживаются.
Выполнение команды ANALYZE для таблицы без использования утилиты analyzedb не обновляет метаданные таблицы, которые использует утилита analyzedb для определения актуальности статистики таблицы.
Таблица 6 — Параметры analyzedb
|
Параметр |
Описание |
|---|---|
| --clean_last | Удаление файлов состояний, созданных последней операцией analyzedb. Все остальные параметры, кроме -d, игнорируются. |
| --clean_all | Удаление всех файлов состояний, сгенерированных analyzedb. Все остальные параметры, кроме -d, игнорируются. |
| -d dbname | Задаёт имя базы данных, содержащей таблицы для анализа. Если этот параметр не указан, имя базы данных считывается из переменной среды PGDATABASE. Если PGDATABASE не задана, используется имя пользователя, указанное для соединения. |
| --debug | Если параметр указан, устанавливается уровень ведения журнала для отладки. Во время выполнения команды информация об уровне отладки записывается в файл журнала и в командную строку. Информация включает команды, выполняемые утилитой, и продолжительность каждой операции ANALYZE. |
| -f config-file | --file config-file |
Текстовый файл, содержащий список таблиц для анализа. Можно указать относительный путь к файлу из текущего каталога. Файл содержит одну таблицу в строке. Имена таблиц должны быть дополнены именем схемы. Опционально список столбцов можно указать с помощью -i или -x. Никакие другие параметры в файле не допускаются. В командной строке должны быть указаны другие параметры, такие как --full. Только один из параметров может использоваться для указания файлов для анализа: -f или --file, -t или -s. При выполнении операций ANALYZE на несколько таблиц, analyzedb создаёт параллельные сеансы для параллельного анализа таблиц. Параметр -p управляет максимальным количеством одновременных сеансов. В следующем примере первая строка выполняет операцию ANALYZE для таблицы public.nation, вторая строка выполняет операцию ANALYZE только для столбцов l_shipdate и l_receiptdate в таблице public.lineitem. public.nation public.lineitem -i l_shipdate, l_receiptdate |
| --full | Выполнение операции ANALYZE для всех указанных таблиц. Операция выполняется, даже если статистика актуальна. |
| --gen_profile_only | Обновление снапшота analyzedb таблицы статистической информации без выполнения каких-либо операций ANALYZE. Если другие параметры определяют таблицы или схему, утилита обновляет информацию о снапшотах только для указанных таблиц. Укажите этот параметр, если команда ANALYZE была запущена для таблиц базы данных и вы хотите обновить analyzedb снапшот для таблиц. |
| -i col1, col2, ... | Опционально. Должен быть указан с параметром -t. Для таблицы, указанной с параметром -t, собирает статистику только для указанных столбцов. Можно указать только -i или -x. Оба варианта указать нельзя. |
| -l | --list | Перечисляет таблицы, которые были бы проанализированы с указанными параметрами. Операции ANALYZE не выполняются. |
| -p parallel-level | Количество таблиц, которые анализируются параллельно. parallel level может быть целым числом от 1 до 10 включительно. Значение по умолчанию — 5. |
| --skip_root_stats |
Для партиционированной таблицы пропустите обновление статистики корневых партиций, если требуется обновить только некоторые статистические данные leaf-партиций. Если обновляется статистика для партиционированной таблицы и вы знаете, какая статистика конечных партиций требует обновления, вы можете указать эти разделы и этот параметр для повышения производительности. |
| -s schema | Укажите схему для анализа. Все таблицы в схеме будут проанализированы. В командной строке можно указать только одно имя схемы. Только один из параметров может использоваться для указания файлов для анализа: -f или --file, -t или -s. |
| -t schema.table | Собирает статистику только по schema.table. Имя таблицы должно быть дополнено именем схемы. В командной строке можно указать только одно имя таблицы. Вы можете указать параметр -f, чтобы указать несколько таблиц в файле, или параметр -s, чтобы указать все таблицы в схеме. Только один из этих параметров может использоваться для указания файлов для анализа: -f или --file, -t или –s. |
| -x col1, col2, ... | Опционально. Должен быть указан с параметром -t. Для таблицы, указанной с параметром -t, исключить сбор статистики для указанных столбцов. Статистика собирается только по столбцам, которых нет в списке. Можно указать только -i или -x. Оба варианта указать нельзя. |
| -a | Бесшумный режим. Не запрашивать подтверждение пользователя. |
| -h | -? | --help | Отображает интерактивную справку. |
| -v | --verbose | Если параметр указан, устанавливается уровень ведения журнала как подробный для записи дополнительной информации в файл журнала и в командную строку во время выполнения команды. Информация включает в себя список всех таблиц, которые нужно проанализировать (включая дочерние leaf-партиции партиционированных таблиц). Вывод также включает продолжительность каждой операции ANALYZE. |
| --version | Отображает версию этой утилиты. |
Пример, который собирает статистику только по набору столбцов таблицы. В базе данных mytest собирается статистика по столбцам shipdate и receivetdate в таблице public.orders:
analyzedb -d mytest -t public.orders -i shipdate, receiptdateПример, который собирает статистику по таблице и исключает набор столбцов. В базе данных mytest собирается статистика по таблице public.foo и не собирается статистика по столбцам bar и test2.
analyzedb -d mytest -t public.foo -x bar, test2Пример, указывающий файл, содержащий список таблиц. Эта команда собирает статистику по таблицам, перечисленным в файле analysis-tables в базе данных mytest.
analyzedb -d mytest -f analyze-tablesЕсли вы не укажете таблицу, набор таблиц или схему, утилита analyzedb собирает статистику по мере необходимости для всех таблиц каталога и пользовательских таблиц в указанной базе данных. Эта команда обновляет статистику таблиц в таблицах системного каталога и пользовательских таблицах в базе данных mytest.
analyzedb -d mytestВы можете создать функцию PL/Python для запуска утилиты analyzedb как функции RT.Warehouse. В этом примере команда CREATE FUNCTION создаёт определяемую пользователем функцию PL/Python, которая запускает утилиту analyzedb и отображает вывод в командной строке. В качестве параметра функции укажите параметры analyzedb.
CREATE OR REPLACE FUNCTION analyzedb(params TEXT)
RETURNS VOID AS
$BODY$
import subprocess
cmd = ['analyzedb', '-a' ] + params.split()
p = subprocess.Popen(cmd, stdout=subprocess.PIPE, stderr=subprocess.STDOUT)
# verbose output of process
for line in iter(p.stdout.readline, ''):
plpy.info(line);
p.wait()
$BODY$
LANGUAGE plpythonu VOLATILE;Когда эта команда SELECT запускается пользователем gpadmin, служебная программа analyzedb выполняет операцию анализа таблицы public.mytable, которая находится в базе данных mytest.
SELECT analyzedb('-d mytest -t public.mytable') ;
|
Примечание. Для создания функции PL/Python процедурный язык PL/Python должен быть зарегистрирован как язык в базе данных. Например, эта команда CREATE LANGUAGE, запускаемая как gpadmin, регистрирует PL/Python как ненадежный язык: CREATE LANGUAGE plpythonu; |
Выполняет повторную кластеризацию таблиц, которые ранее были кластеризованы с помощью CLUSTER.
clusterdb [connection-option ...] [--verbose | -v] [--table | -t table] [[--dbname | -d] dbname]
clusterdb [connection-option ...] [--all | -a] [--verbose | -v]
clusterdb -? | --help
clusterdb -V | --versionКластеризация таблицы означает физическое переупорядочение таблицы на диске в соответствии с индексом, чтобы операции сканирования индекса могли обращаться к данным на диске в некотором последовательном порядке, тем самым повышая производительность поиска по индексу для запросов, использующих этот индекс.
Утилита clusterdb найдёт любые таблицы в базе данных, которые ранее были кластеризованы с помощью SQL-команды CLUSTER, и снова кластеризует их по тому же индексу, который использовался последним. Таблицы, которые никогда не были кластеризованы, не затрагиваются.
clusterdb — это оболочка для SQL-команды CLUSTER. Хотя кластеризация таблицы таким образом поддерживается в RT.Warehouse, это не рекомендуется, поскольку сама операция CLUSTER выполняется очень медленно.
Если вам действительно нужно упорядочить таблицу таким образом, чтобы повысить производительность запроса, используйте оператор CREATE TABLE AS для изменения порядка таблицы на диске вместо использования CLUSTER. Если вы выполните “кластеризацию” таблицы таким образом, clusterdb не будет иметь значения.
Таблица 7 — Параметры clusterdb
|
Параметр |
Описание |
|---|---|
| -a | --all | Кластеризация всей базы данных. |
| [-d] dbname | [--dbname=]dbname | Задаёт имя базы данных для кластеризации. Если параметр не указан, имя базы данных считывается из переменной среды PGDATABASE. Если она не установлена, используется имя пользователя, указанное для соединения. |
| -e | --echo | Просмотр команд, которые clusterdb генерирует и отправляет на сервер. |
| -q | --quiet | Не отображать ответ. |
| -t table | --table=table | Кластеризирует только указанную таблицу. Несколько таблиц можно кластеризовать, написав несколько ключей -t. |
| -v | --verbose | Распечатывает подробную информацию в процессе обработки. |
| -V | --version | Распечатывает версию clusterdb и выходит. |
| -? | --help | Показывает справку об аргументах командной строки clusterdb и выходит. |
Таблица 8 — Параметры подключения clusterdb
|
Параметр |
Описание |
|---|---|
| -h host | --host=host | Имя хоста машины, на которой работает мастер-сервер RT.Warehouse. Если параметр не указан, значение считывается из переменной среды PGHOST или по умолчанию используется localhost. |
| -p port | --port=port | Порт TCP, на котором мастер-сервер RT.Warehouse прослушивает соединения. Если параметр не указан, значение считывается из переменной среды PGPORT или по умолчанию используется 5432. |
| -U username | --username=username | Имя роли базы данных для подключения. Если параметр не указан, значение считывается из переменной среды PGUSER или по умолчанию используется имя текущей системной роли. |
| -w | --no-password | Никогда не запрашивать пароль. Если сервер требует аутентификации по паролю, а пароль недоступен другими средствами, такими как файл .pgpass, попытка подключения не удастся. Этот параметр может быть полезен в пакетных заданиях и скриптах, где нет пользователя, который мог бы ввести пароль. |
| -W | --password | Принудительный ввод пароля. |
| --maintenance-db=dbname | Задаёт имя базы данных для подключения, чтобы определить, какие другие базы данных следует кластеризовать. Если параметр не указан, в качестве значения будет использоваться база данных postgres, а если она не существует, будет использоваться template1. |
Для кластеризации базы данных test:
clusterdb testДля кластеризации одной таблицы foo в базе данных с именем xyzzy:
clusterdb --table foo xyzzybСоздаёт новую базу данных.
createdb [connection-option ...] [option ...] [dbname ['description']]
createdb -? | --help
createdb -V | --versioncreatedb создаёт новую базу данных в системе RT.Warehouse.
Обычно пользователь базы данных, выполняющий эту команду, становится владельцем новой базы данных. Однако можно указать другого владельца с помощью параметра -O, если у выполняющего пользователя есть соответствующие привилегии.
createdb — это оболочка для SQL-команды CREATE DATABASE.
Таблица 9 — Параметры createdb
|
Параметр |
Описание |
|---|---|
| dbname | Имя создаваемой базы данных. Имя должно быть уникальным среди всех других баз данных в системе RT.Warehouse. Если параметр не указан, значение считывается из переменной среды PGDATABASE, затем PGUSER или по умолчанию используется текущий системный пользователь. |
| description | Комментарий, который будет связан с вновь созданной базой данных. Описания, содержащие пробелы, должны быть заключены в кавычки. |
| -D tablespace | --tablespace=tablespace | Задаёт табличное пространство по умолчанию для базы данных. (Это имя обрабатывается как идентификатор в двойных кавычках.) |
| -e echo | Повторение команд, которые createdb генерирует и отправляет на сервер. |
| -E encoding | --encoding encoding | Кодировка набора символов для использования в новой базе данных. Укажите строковую константу (например, 'UTF8'), целочисленный номер кодировки или DEFAULT, чтобы использовать кодировку по умолчанию. |
| -l locale | --locale locale | Задаёт языковой стандарт, который будет использоваться в этой базе данных. Это эквивалентно указанию --lc-collate и --lc-ctype. |
| --lc-collate locale | Задаёт параметр LC_COLLATE, который будет использоваться в этой базе данных. |
| --lc-ctype locale | Задаёт параметр LC_CTYPE, который будет использоваться в этой базе данных. |
| --maintenance-db=dbname | Задаёт имя базы данных, к которой нужно подключиться при создании новой базы данных. Если параметр не указан, будет использоваться база данных postgres; если её не существует (или если это имя создаваемой новой базы данных), будет использоваться template1. |
| -O owner | --owner=owner | Имя пользователя базы данных, которому будет принадлежать новая база данных. По умолчанию это пользователь, который выполняет эту команду. (Это имя обрабатывается как идентификатор в двойных кавычках.) |
| -T template | --template=template | Имя шаблона, из которого будет создана новая база данных. По умолчанию template1. (Это имя обрабатывается как идентификатор в двойных кавычках.) |
| -V | --version | Распечатывает созданную версию и выходит. |
| -? | --help | Показывает справку об аргументах командной строки createdb и выходит. |
Параметры -D, -l, -E, -O и -T соответствуют параметрам базовой SQL-команды CREATE DATABASE.
Таблица 10 — Параметры подключения createdb
|
Параметр |
Описание |
|---|---|
| -h host | --host=host | Имя хоста машины, на которой работает мастер-сервер RT.Warehouse. Если параметр не указан, значение считывается из переменной среды PGHOST или по умолчанию используется localhost. |
| -p port | --port=port | Порт TCP, на котором мастер-сервер RT.Warehouse прослушивает соединения. Если параметр не указан, значение считывается из переменной среды PGPORT или по умолчанию используется 5432. |
| -U username | --username=username | Имя роли базы данных для подключения. Если параметр не указан, значение считывается из переменной среды PGUSER или по умолчанию используется имя текущей системной роли. |
| -w | --no-password | Никогда не запрашивать пароль. Если сервер требует аутентификации по паролю, а пароль недоступен другими средствами, такими как файл .pgpass, попытка подключения не удастся. Этот параметр может быть полезен в пакетных заданиях и скриптах, где нет пользователя, который мог бы ввести пароль. |
| -W | --password | Принудительный ввод пароля. |
Чтобы создать базу данных test с использованием параметров по умолчанию:
createdb testЧтобы создать базу данных demo с помощью мастера RT.Warehouse на хосте gpmaster, порт 54321, с использованием схемы кодирования LATIN1:
createdb -p 54321 -h gpmaster -E LATIN1 demoОпределяет новый процедурный язык для базы данных.
createlang [connection_option ...] [-e] langname [[-d] dbname]
createlang [connection-option ...] -l dbname
createlang -? | --help
createlang -V | --versionУтилита createlang добавляет в базу данных новый процедурный язык. createlang — это оболочка для SQL-команды CREATE EXTENSION.
|
Примечание. createlang устарел и может быть удалён в следующем выпуске. В RT.Warehouse 6.x использование createlang для добавления пакета процедурного языка приводит к ошибке. Вместо этого используйте команду CREATE EXTENSION. |
Пакеты процедурного языка, включенные в стандартный дистрибутив RT.Warehouse:
- PL/pgSQL;
- PL/Perl;
- PL/Python.
Язык PL/pgSQL по умолчанию зарегистрирован во всех базах данных.
RT.Warehouse также имеет обработчики языков для PL/Java и PL/R, но эти языки не устанавливаются вместе с RT.Warehouse.
Таблица 11 — Параметры createlang
|
Параметр |
Описание |
|---|---|
| langname | Задаёт имя устанавливаемого процедурного языка. (Это имя в нижнем регистре.) |
| [-d] dbname | [--dbname=]dbname | Задаёт базу данных, в которую следует добавить язык. По умолчанию используется настройка переменной среды PGDATABASE или то же имя, что и у текущего пользователя системы. |
| -e | --echo | Повторяет команды, которые createlang генерирует и отправляет на сервер. |
| -l dbname | --list dbname | Показывает список уже установленных языков в целевой базе данных. |
| -V | --version | Распечатывает версию createlang и выходит. |
| -? | --help | Показывает справку об аргументах командной строки createlang и завершает работу. |
Таблица 12 — Параметры подключения createlang
|
Параметр |
Описание |
|---|---|
| -h host | --host=host | Имя хоста компьютера, на котором работает мастер-сервер RT.Warehouse. Если параметр не указан, значение считывается из переменной среды PGHOST или по умолчанию используется localhost. |
| -p port | --port=port | Порт TCP, на котором мастер-сервер RT.Warehouse прослушивает соединения. Если параметр не указан, значение считывается из переменной среды PGPORT или по умолчанию 5432. |
| -U username | --username=username | Имя роли базы данных для подключения. Если параметр не указан, значение считывается из переменной среды PGUSER или по умолчанию используется имя текущей системной роли. |
| -w | --no-password | Никогда не запрашивать пароль. Если сервер требует аутентификации по паролю, а пароль недоступен другими средствами, такими как файл .pgpass, попытка подключения не удастся. Этот параметр может быть полезен в пакетных заданиях и скриптах, где нет пользователя, который мог бы ввести пароль. |
| -W | --password | Принудительный ввод пароля. |
Чтобы установить язык plperl в базу данных mytestdb:
createlang plperl mytestdbСоздаёт новую роль базы данных.
createuser [connection-option ...] [role_attribute ...] [-e] role_name
createuser -? | --help
createuser -V | --versioncreateuser создаёт новую роль RT.Warehouse. Для создания новых ролей вы должны быть суперпользователем или иметь право CREATEROLE. Вы должны подключиться к базе данных как суперпользователь, чтобы создавать новых суперпользователей.
Суперпользователи могут обойти все проверки прав доступа в базе данных, поэтому привилегии суперпользователя не следует предоставлять легкомысленно.
createuser — это оболочка для SQL-команды CREATE ROLE.
Таблица 13 — Параметры createuser
|
Параметр |
Описание |
|---|---|
| role_name | Имя создаваемой роли. Это имя должно отличаться от всех существующих ролей в данной установке RT.Warehouse. |
| -c number | --connection-limit=number | Устанавливает максимальное количество подключений для новой роли. По умолчанию ограничение не установлено. |
| -d | --createdb | Новой роли будет разрешено создавать базы данных. |
| -D | --no-createdb | Новой роли не будет разрешено создавать базы данных. Это значение по умолчанию. |
| -e | --echo | Повторяет команды, которые createuser генерирует и отправляет на сервер. |
| -E | --encrypted | Шифрует пароль роли, хранящийся в базе данных. Если не указано, используется пароль по умолчанию. |
| -i | --inherit | Новая роль автоматически унаследует привилегии ролей, членом которых она является. Это значение по умолчанию. |
| -I | --no-inherit | Новая роль не будет автоматически наследовать привилегии ролей, членом которых она является. |
| --interactive | Запрашивать имя пользователя, если оно не указано в командной строке, а также запрашивать, какой из параметров ‑d/-D, -r/-R, -s/-S не указан в командной строке. |
| -l | --login | Новой роли будет разрешён вход в RT.Warehouse. Это значение по умолчанию. |
| -L | --no-login | Новая роль не сможет войти в систему (роль на уровне группы). |
| -N | --unencrypted | Не шифрует пароль роли, хранящийся в базе данных. Если не указано, используется пароль по умолчанию. |
| -P | --pwprompt | Если параметр указан, createuser выдаст запрос на ввод пароля для новой роли. В этом нет необходимости, если вы не планируете использовать аутентификацию по паролю. |
| -r | --createrole | Новой роли будет разрешено создавать новые роли (привилегия CREATEROLE). |
| -R | --no-createrole | Новая роль не сможет создавать новые роли. Это значение по умолчанию. |
| -s | --superuser | Новая роль будет суперпользователем. |
| -S | --no-superuser | Новая роль не будет суперпользователем. Это значение по умолчанию. |
| -V | --version | Распечатывает версию createuser и выходит. |
| --replication | Новый пользователь будет иметь привилегию REPLICATION. |
| --no-replication | У нового пользователя не будет привилегии REPLICATION. |
| -? | --help | Показывает справку об аргументах командной строки createuser и выходит. |
Таблица 14 — Параметры подключения createuser
|
Параметр |
Описание |
|---|---|
| -h host | --host=host | Имя хоста машины, на которй работает мастер-сервер RT.Warehouse. Если параметр не указан, значение считывается из переменной среды PGHOST или по умолчанию используется localhost. |
| -p port | --port=port | Порт TCP, на котором мастер-сервер RT.Warehouse прослушивает соединения. Если параметр не указан, значение считывается из переменной среды PGPORT или по умолчанию 5432. |
| -U username | --username=username | Имя роли базы данных для подключения. Если параметр не указан, значение считывается из переменной среды PGUSER или по умолчанию используется имя текущей системной роли. |
| -w | --no-password | Никогда не запрашивать пароль. Если сервер требует аутентификации по паролю, а пароль недоступен другими средствами, такими как файл .pgpass, попытка подключения не удастся. Этот параметр может быть полезен в пакетных заданиях и скриптах, где нет пользователя, который мог бы ввести пароль. |
| -W | --password | Принудительный ввод пароля. |
Чтобы создать роль joe на сервере базы данных по умолчанию:
$ createuser joeЧтобы создать роль joe на сервере базы данных по умолчанию с запросом некоторых дополнительных атрибутов:
$ createuser --interactive joe
Shall the new role be a superuser? (y/n) n
Shall the new role be allowed to create databases? (y/n) n
Shall the new role be allowed to create more new roles? (y/n) n
CREATE ROLEЧтобы создать ту же роль, joe, используя параметры подключения с явно указанными атрибутами и опираясь на базовую команду:
createuser -h masterhost -p 54321 -S -D -R -e joe
CREATE ROLE joe NOSUPERUSER NOCREATEDB NOCREATEROLE INHERIT
LOGIN;
CREATE ROLEЧтобы создать роль joe как суперпользователя и сразу же назначить пароль admin123:
createuser -P -s -e joe
Enter password for new role: admin123
Enter it again: admin123
CREATE ROLE joe PASSWORD 'admin123' SUPERUSER CREATEDB
CREATEROLE INHERIT LOGIN;
CREATE ROLEВ приведённом выше примере новый пароль не отображается при вводе, но для ясности показано, что было введено. Однако пароль будет отображаться в отображаемой команде, как показано, если используется параметр -e.
Удаляет базу данных.
dropdb [connection-option ...] [-e] [-i] dbname
dropdb -? | --help
dropdb -V | --versiondropdb уничтожает существующую базу данных. Пользователь, выполняющий эту команду, должен быть суперпользователем или владельцем удаляемой базы данных.
dropdb — это оболочка для SQL-команды DROP DATABASE.
Таблица 15 — Параметры dropdb
|
Параметр |
Описание |
|---|---|
| dbname | Имя удаляемой базы данных. |
| -e | --echo | Повторяет команды, которые dropdb генерирует и отправляет на сервер. |
| -i | --interactive | Перед выполнением каких-либо деструктивных действий выдаёт запрос на подтверждение. |
| -V | --version | Распечатывает версию dropdb и выходит. |
| --if-exists | Не выдавать ошибку, если база данных не существует. В этом случае выдаётся уведомление. |
| -? | --help | Показывает справку об аргументах командной строки dropdb и выходит. |
Таблица 16 — Параметры подключения dropdb
|
Параметр |
Описание |
|---|---|
| -h host | --host=host | Имя хоста машины, на которой работает мастер-сервер RT.Warehouse. Если параметр не указан, значение считывается из переменной среды PGHOST или по умолчанию используется localhost. |
| -p port | --port=port | Порт TCP, на котором мастер-сервер RT.Warehouse прослушивает соединения. Если параметр не указан, значение считывается из переменной среды PGPORT или по умолчанию 5432. |
| -U username | --username=username | Имя роли базы данных для подключения. Если параметр не указан, значение считывается из переменной среды PGUSER или по умолчанию используется имя текущей системной роли. |
| -w | --no-password | Никогда не запрашивать пароль. Если сервер требует аутентификации по паролю, а пароль недоступен другими средствами, такими как файл .pgpass, попытка подключения не удастся. Этот параметр может быть полезен в пакетных заданиях и скриптах, где нет пользователя, который мог бы ввести пароль. |
| -W | --password | Принудительный ввод пароля. |
| --maintenance-db=dbname | Задаёт имя базы данных, к которой нужно подключиться, чтобы удалить целевую базу данных. Если параметр не указан, в качестве значения будет использоваться база данных postgres; если её не существует (или если это имя удаляемой базы данных), будет использоваться template1. |
Чтобы удалить базу данных с именем demo, используя параметры соединения по умолчанию:
dropdb demoЧтобы удалить базу данных с именем demo, используя параметры подключения, с проверкой и просмотром базовой команды:
dropdb -p 54321 -h masterhost -i -e demo
Database "demo" will be permanently deleted.
Are you sure? (y/n) y
DROP DATABASE "demo"
DROP DATABASEУдаляет процедурный язык.
droplang [connection-option ...] [-e] langname [[-d] dbname]
droplang [connection-option ...] [-e] -l dbname
droplang -? | --help
droplang -V | --versiondroplang удаляет существующий процедурный язык из базы данных.
droplang — это оболочка для SQL-команды DROP EXTENSION.
|
Примечание. droplang устарел и может быть удалён в следующем выпуске. В RT.Warehouse 6.x при использовании droplang для удаления пакета процедурного языка возникает ошибка. Вместо этого используйте команду DROP EXTENSION. |
Таблица 17 — Параметры droplang
|
Параметр |
Описание |
|---|---|
| langname | Задаёт имя процедурного языка, который нужно удалить. (Это имя в нижнем регистре.) |
| [-d] dbname | [--dbname=]dbname | Определяет, из какой базы данных следует удалить язык. По умолчанию используется настройка переменной среды PGDATABASE или то же имя, что и у текущего пользователя системы. |
| -e | --echo | Повторяет команды, которые droplang генерирует и отправляет на сервер. |
| -l | --list | Показывает список уже установленных языков в целевой базе данных. |
| -V | --version | Распечатывает версию dropplang и выходит. |
| -? | --help | Показывает справку об аргументах командной строки dropplang и выходит. |
Таблица 18 — Параметры подключения droplang
|
Параметр |
Описание |
|---|---|
| -h host | --host=host | Имя хоста машины, на которой работает мастер-сервер RT.Warehouse. Если параметр не указан, значение считывается из переменной среды PGHOST или по умолчанию используется localhost. |
| -p port | --port=port | Порт TCP, на котором мастер-сервер RT.Warehouse прослушивает соединения. Если параметр не указан, значение считывается из переменной среды PGPORT или по умолчанию 5432. |
| -U username | --username=username | Имя роли базы данных для подключения. Если параметр не указан, значение считывается из переменной среды PGUSER или по умолчанию используется имя текущей системной роли. |
| -w | --no-password | Никогда не запрашивать пароль. Если сервер требует аутентификации по паролю, а пароль недоступен другими способами, такими как файл .pgpass, попытка подключения не удастся. Этот параметр может быть полезен в пакетных заданиях и скриптах, где нет пользователя, который мог бы ввести пароль. |
| -W | --password | Принудительный ввод пароля. |
Чтобы удалить язык pltcl из базы данных mydatabase:
droplang pltcl mydatabaseУдаляет роль базы данных.
dropuser [connection-option ...] [-e] [-i] role_name
dropuser -? | --help
dropuser -V | --versiondropuser удаляет существующую роль из RT.Warehouse. Только суперпользователи и пользователи с привилегией CREATEROLE могут удалять роли. Чтобы удалить роль суперпользователя, вы сами должны быть суперпользователем.
dropuser — это оболочка для SQL-команды DROP ROLE.
Таблица 19 — Параметры dropuser
|
Параметр |
Описание |
|---|---|
| role_name | Название удаляемой роли. Вам будет предложено ввести имя, если оно не указано в командной строке и используется параметр -i/--interactive. |
| -e | --echo | Повторение команд, которые dropuser генерирует и отправляет на сервер. |
| -i | --interactive | Запрашивает подтверждение перед фактическим удалением роли и запрашивает имя роли, если оно не указано в командной строке. |
| --if-exists | Не выдаёт ошибку, если пользователь не существует. В этом случае выдаётся уведомление. |
| -V | --version | Распечатывает версию dropuser и выходит. |
| -? | --help | Показывает справку об аргументах командной строки dropuser и выходит. |
Таблица 20 — Параметры подключения dropuser
|
Параметр |
Описание |
|---|---|
| -h host | --host=host | Имя хоста машины, на которой работает мастер-сервер RT.Warehouse. Если параметр не указан, значение считывается из переменной среды PGHOST или по умолчанию используется localhost. |
| -p port | --port=port | Порт TCP, на котором мастер-сервер RT.Warehouse прослушивает соединения. Если параметр не указан, значение считывается из переменной среды PGPORT или по умолчанию 5432. |
| -U username | --username=username | Имя роли базы данных для подключения. Если параметр не указан, значение считывается из переменной среды PGUSER или по умолчанию используется имя текущей системной роли. |
| -w | --no-password | Никогда не запрашивать пароль. Если сервер требует аутентификации по паролю, а пароль недоступен другими способами, такими как файл .pgpass, попытка подключения не удастся. Этот параметр может быть полезен в пакетных заданиях и скриптахх, где нет пользователя, который мог бы ввести пароль. |
| -W | --password | Принудительный ввод пароля. |
Чтобы удалить роль joe с использованием параметров подключения по умолчанию:
dropuser joe
DROP ROLEЧтобы удалить роль joe с помощью параметров подключения, с проверкой и просмотром базовой команды:
dropuser -p 54321 -h masterhost -i -e joe
Role "joe" will be permanently removed.
Are you sure? (y/n) y
DROP ROLE "joe"
DROP ROLEАктивирует хост резервного мастера и делает его активным мастером для системы RT.Warehouse.
gpactivatestandby [-d standby_master_datadir] [-f] [-a] [-q]
[-l logfile_directory]
gpactivatestandby -v
gpactivatestandby -? | -h | --helpУтилита gpactivatestandby активирует хост резервного мастера и запускает его в качестве активного инстанса мастера для системы RT.Warehouse. Активированный резервный мастер фактически становится мастером RT.Warehouse, принимая клиентские соединения на главном порту.
Когда вы инициализируете резервный мастер, по умолчанию будет использоваться тот же порт, что и у активного мастера. Для получения информации о главном порте для резервного мастер-сервера см. gpinitstandby.
Вы должны запускать эту утилиту с хоста мастера, который вы активируете, а не с отказавшего хоста мастера, который вы отключаете. При запуске этой утилиты предполагается, что для системы настроен резервный мастер-хост (см. gpinitstandby).
Утилита выполнит следующие действия:
- Останавливает процесс синхронизации (walreceiver) на резервном мастере;
- Обновляет таблицы системного каталога резервного мастера с помощью журналов;
- Активирует резервный мастер в качестве нового активного мастера для системы;
- Перезапускает систему RT.Warehouse с новым мастер-хостом.
Резервный мастер-хост RT.Warehouse служит «горячим резервом» в случае выхода из строя основного мастер-хоста RT.Warehouse. Резервный мастер-сервер поддерживается в актуальном состоянии с помощью процессов репликации журнала транзакций (walsender и walreceiver), которые выполняются на хостах основного мастера и резервного мастера и обеспечивают синхронизацию данных между хостами основного и резервного мастера.
Если основной мастер выходит из строя, процесс репликации журнала завершается, а резервный мастер может быть активирован вместо него с помощью утилиты gpactivatestandby. После активации резервного мастера реплицированные журналы используются для восстановления состояния мастер-хоста RT.Warehouse на момент последней успешно совершенной транзакции.
Чтобы использовать gpactivatestandby для активации нового основного мастер-хоста, мастер-хост, который ранее служил в качестве основного мастер-хоста, не может быть запущен.
Утилита проверяет наличие файла postmaster.pid в каталоге данных отключённого мастер-хоста и, если она обнаруживает его, предполагает, что старый мастер-хост все ещё активен. В некоторых случаях вам может потребоваться удалить файл postmaster.pid из каталога данных отключённого мастер-хоста перед запуском gpactivatestandby (например, если процесс отключённого мастер-хоста был неожиданно завершён).
После активации резервного мастера запустите ANALYZE, чтобы обновить статистику запросов к базе данных. Например:
psql dbname -c 'ANALYZE;'После того, как вы активируете резервный мастер в качестве основного, в системе RT.Warehouse больше не будет настроен резервный мастер. Вы можете указать другой хост в качестве нового резервного с помощью утилиты gpinitstandby.
Таблица 21 — Параметры gpactivatestandby
|
Параметр |
Описание |
|---|---|
| -a | Не запрашивать у пользователя подтверждение. |
| -d standby_master_datadir | Абсолютный путь к каталогу данных для мастер-хоста, который вы активируете. Если этот параметр не указан, gpactivatestandby использует значение параметра среды MASTER_DATA_DIRECTORY, установленное на мастер-хосте, который вы активируете. Если этот параметр указан, она переопределяет любые настройки MASTER_DATA_DIRECTORY. Если каталог не может быть определён, утилита возвращает ошибку. |
| -f | Используйте этот параметр для принудительной активации резервного мастер-хоста. Используйте эту опцию, только если вы уверены, что хосты резервного мастера и основного мастера имеют связность. |
| -l logfile_directory | Каталог для записи файла журнала. По умолчанию ~/gpAdminLogs. |
| -q | Работа в тихом режиме. Вывод команды не отображается на экране, но все равно записывается в файл журнала. |
| -v | Отображает версию, статус, дату последнего обновления и контрольную сумму этой утилиты. |
| -? | -h | --help | Отображает интерактивную справку. |
Активируйте резервный мастер-хост и сделайте его активным инстансом мастера для системы RT.Warehouse (запускается с резервного мастер-хоста, который вы активируете):
gpactivatestandby -d /gpdataДобавляет зеркальные сегменты в систему RT.Warehouse, которая изначально была настроена без зеркалирования.
gpaddmirrors [-p port_offset] [-m datadir_config_file [-a]] [-s]
[-d master_data_directory] [-B parallel_processes] [-l logfile_directory]
[-v]
gpaddmirrors -i mirror_config_file [-a] [-d master_data_directory]
[-B parallel_processes] [-l logfile_directory] [-v]
gpaddmirrors -o output_sample_mirror_config [-s] [-m datadir_config_file]
gpaddmirrors -?
gpaddmirrors --versionУтилита gpaddmirrors настраивает инстансы зеркального сегмента для существующей системы RT.Warehouse, которая изначально была настроена только для инстансов первичного сегмента. Утилита создаст зеркальные инстансы и начнёт процесс онлайн-репликации между инстансами основного и зеркального сегментов. После того, как все зеркала будут синхронизированы с их основными, ваша система RT.Warehouse станет полностью избыточной.
|
Внимание. Во время онлайн-репликации RT.Warehouse должна находиться в состоянии покоя, рабочие нагрузки и другие запросы не должны выполняться. |
По умолчанию утилита запрашивает у вас расположение файловой системы, в которых она будет создавать каталоги данных зеркальных сегментов. Если вы не хотите, чтобы вас спрашивали, вы можете передать файл, содержащий расположение файловой системы, используя параметр ‑m.
Расположение и порты зеркала должны отличаться от местоположений и портов данных основного сегмента.
Утилита создаёт уникальный каталог данных для каждого инстанса зеркального сегмента в указанном месте, используя предопределённое соглашение об именах. Для инстансов зеркального сегмента должно быть объявлено такое же количество расположений файловой системы, как и для инстансов основного сегмента. Можно указать одно и то же имя каталога несколько раз, если вы хотите, чтобы ваши зеркальные каталоги данных создавались в одном и том же месте, или вы можете ввести другое местоположение данных для каждого зеркала. Введите абсолютный путь. Например:
Enter mirror segment data directory location 1 of 2 > /gpdb/mirror
Enter mirror segment data directory location 2 of 2 > /gpdb/mirrorИли:
Enter mirror segment data directory location 1 of 2 > /gpdb/m1
Enter mirror segment data directory location 2 of 2 > /gpdb/m2Кроме того, вы можете запустить утилиту gpaddmirrors и предоставить подробный файл конфигурации, используя параметр -i. Это полезно, если вы хотите, чтобы зеркальные сегменты находились на совершенно ином наборе хостов, чем ваши основные сегменты. Формат файла конфигурации зеркала:
<row_id>=<contentID>|<address>|<port>|<data_dir>Где row_id — это строка в файле, contentID — это идентификатор содержимого инстанса сегмента, address — это имя хоста или IP-адрес хоста сегмента, port — это порт связи, а data_dir — это каталог данных инстанса сегмента.
Например:
0=0|sdw1-1|60000|/gpdata/mir1/gp0
1=1|sdw1-1|60001|/gpdata/mir2/gp1Таблица системного каталога gp_segment_configuration может помочь вам определить текущую конфигурацию основного сегмента, чтобы вы могли спланировать конфигурацию зеркального сегмента. Например, выполните следующий запрос:
=# SELECT dbid, content, address as host_address, port, datadir
FROM gp_segment_configuration
ORDER BY dbid;При создании зеркал на альтернативных зеркальных хостах новые хосты зеркального сегмента должны быть предварительно установлены с программным обеспечением RT.Warehouse и настроены точно так же, как существующие хосты первичного сегмента.
Вы должны убедиться, что пользователь, запускающий gpaddmirrors (пользователь gpadmin), имеет права на запись в указанные каталоги данных. Вы можете создать эти каталоги на хостах сегментов и передать их соответствующему пользователю перед запуском gpaddmirrors.
|
Примечание. Эта утилита использует SSH-соединения между системами для выполнения своих задач. В больших развёртываниях RT.Warehouse, облачных развёртываниях или развёртываниях с большим количеством сегментов на хост эта утилита может превышать максимальный порог хоста для неаутентифицированных соединений. Рассмотрите возможность обновления параметра конфигурации SSH MaxStartups, чтобы увеличить этот порог. Дополнительные сведения о параметрах конфигурации SSH см. в документации по SSH для вашего дистрибутива Linux. |
Таблица 22 — Параметры gpaddmirrors
|
Параметр |
Описание |
|---|---|
| -a | Запуск в тихом режиме, без запроса информации. Если используется этот параметр, необходимо предоставить файл конфигурации с параметром -m или -i. |
| -B parallel_processes | Количество процессов настройки зеркала, запускаемых параллельно. Если не указано иное, утилита запустит до 10 параллельных процессов в зависимости от того, сколько инстансов зеркальных сегментов ей нужно настроить. |
| -d master_data_directory | Каталог основных данных. Если параметр не указан, будет использоваться значение, установленное для $MASTER_DATA_DIRECTORY. |
| -i mirror_config_file |
Файл конфигурации, содержащий по одной строке для каждого зеркального сегмента, который вы хотите создать. Для каждого основного сегмента в системе должен быть указан один зеркальный сегмент. Формат этого файла следующий (согласно атрибутам в таблице каталога gp_segment_configuration): Где row_id — это строка в файле, contentID — это идентификатор содержимого инстанса сегмента, address — это имя хоста или IP-адрес хоста сегмента, port — это порт связи, а data_dir — это каталог данных инстанса сегмента. |
| -l logfile_directory | Каталог для записи файла журнала. По умолчанию ~/gpAdminLogs. |
| -m datadir_config_file |
Файл конфигурации, содержащий список расположений файловой системы, в которых будут созданы каталоги зеркальных данных. Если параметр не указан, утилита запросит расположение. Каждая строка в файле указывает расположение каталога данных зеркала. Например:
|
| -o output_sample_mirror_config | Если вы не знаете, как разместить файл конфигурации зеркала, используемый параметром -i, вы можете запустить gpaddmirrors с данным параметром, чтобы сгенерировать образец файла конфигурации зеркала на основе конфигурации вашего основного сегмента. Утилита предложит вам указать расположение каталога данных зеркального сегмента (если вы не укажете его в файле с помощью -m). Затем вы можете отредактировать этот файл, чтобы при необходимости изменить имена хостов на альтернативные зеркальные хосты. |
| -p port_offset | Опционально. Это число используется для расчёта портов базы данных, используемых для зеркальных сегментов. Смещение по умолчанию — 1000. Назначения портов зеркала рассчитываются следующим образом: основной порт + смещение = порт зеркальной базы данных. Например, если основной сегмент имеет порт 50001, то его зеркало по умолчанию будет использовать порт базы данных 51001. |
| -s | Распределяет зеркальные сегменты по доступным хостам. По умолчанию набор зеркальных сегментов группируется вместе на альтернативном хосте из их основного набора сегментов. При распределении зеркал каждое зеркало размещается на разных хостах в массиве RT.Warehouse. Распространение разрешено только при наличии достаточного количества хостов в массиве (количество хостов больше, чем количество инстансов сегмента на хост). |
| -v | Устанавливает подробный вывод журнала. |
| --version | Отображает версию этой утилиты. |
| -? | Отображает интерактивную справку. |
Добавьте зеркалирование в существующую систему RT.Warehouse, используя тот же набор хостов, что и ваши основные данные. Вычислите порты зеркальной базы данных, добавив 100 к текущим номерам портов первичного сегмента:
$ gpaddmirrors -p 100Добавьте зеркалирование в существующую систему RT.Warehouse, используя набор хостов, отличный от ваших первичных данных:
$ gpaddmirrors -i mirror_config_fileГде mirror_config_file выглядит примерно так:
0=0|sdw1-1|52001|/gpdata/mir1/gp0
1=1|sdw1-2|52002|/gpdata/mir2/gp1
2=2|sdw2-1|52001|/gpdata/mir1/gp2
3=3|sdw2-2|52002|/gpdata/mir2/gp3Создайте образец файла конфигурации зеркала с параметром -o для использования с gpaddmirrors -i:
$ gpaddmirrors -o /home/gpadmin/sample_mirror_configСоздаёт резервную копию RT.Warehouse для использования с утилитой gprestore.
gpbackup --dbname database_name
[--backup-dir directory]
[--compression-level level]
[--data-only]
[--debug]
[--exclude-schema schema_name]
[--exclude-table schema.table]
[--exclude-table-file file_name]
[--include-schema schema_name]
[--include-table schema.table]
[--include-table-file file_name]
[--incremental [--from-timestamp backup-timestamp]]
[--jobs int]
[--leaf-partition-data]
[--metadata-only]
[--no-compression]
[--plugin-config config_file_location]
[--quiet]
[--single-data-file]
[--verbose]
[--version]
[--with-stats]
gpbackup --helpУтилита gpbackup выполняет резервное копирование содержимого базы данных в коллекцию файлов метаданных и файлов данных, которые можно использовать позже для восстановления базы данных с помощью gprestore. При резервном копировании базы данных вы можете указать параметры фильтрации на уровне таблицы и на уровне схемы для резервного копирования определённых таблиц. Например, вы можете комбинировать параметры уровня схемы и уровня таблицы для резервного копирования всех таблиц в схеме, кроме одной.
По умолчанию gpbackup выполняет резервное копирование объектов в указанной базе данных, а также глобальных системных объектов RT.Warehouse. Вы можете дополнительно указать параметр --with-globals с gprestore для восстановления глобальных объектов.
gpbackup по умолчанию сохраняет файлы метаданных объекта и файлы DDL для резервного копирования в каталоге основных данных RT.Warehouse. Сегменты RT.Warehouse используют команду COPY ... ON SEGMENT для сохранения данных для резервных копий таблиц в сжатых файлах данных CSV, расположенных в каталоге данных каждого сегмента.
Вы можете добавить параметр --backup-dir, чтобы скопировать все файлы резервных копий с главной RT.Warehouse и сегментировать хосты по абсолютному пути для дальнейшего использования. Предусмотрены дополнительные параметры для фильтрации набора резервных копий, чтобы включить или исключить определённые таблицы.
Вы можете создать инкрементную резервную копию с параметром ‑‑incremental. Инкрементные резервные копии эффективны, когда общий объём данных в таблицах, оптимизированных для добавления, или в партициях таблиц, которые изменились, невелик по сравнению с данными, которые не изменились.
С параметром по умолчанию --jobs (1 задание) каждая операция gpbackup использует одну транзакцию на мастер-хосте RT.Warehouse. Команда COPY ... ON SEGMENT выполняет задачу резервного копирования параллельно на каждом хосте сегмента. Процесс резервного копирования устанавливает блокировку ACCESS SHARE для каждой резервной копии таблицы. Во время процесса блокировки таблицы база данных должна находиться в состоянии покоя.
Когда операция резервного копирования завершается, gpbackup возвращает код состояния. См. Коды возврата.
Утилиту gpbackup нельзя запустить, пока gpexpand инициализирует новые сегменты. Резервные копии, созданные до расширения, невозможно восстановить с помощью gprestore после завершения расширения кластера.
gpbackup может отправлять уведомления о статусе по электронной почте после завершения операции резервного копирования. Вы указываете момент, когда утилита отправляет уведомление, и получателей электронной почты в файле конфигурации.
|
Примечание. Эта утилита использует SSH-соединения между системами для выполнения своих задач. В больших развёртываниях RT.Warehouse, облачных развёртываниях или развёртываниях с большим количеством сегментов на хост эта утилита может превышать максимальный порог хоста для неаутентифицированных соединений. Рассмотрите возможность обновления параметра конфигурации SSH MaxStartups, чтобы увеличить этот порог. Дополнительные сведения о параметрах конфигурации SSH см. в документации по SSH для вашего дистрибутива Linux. |
Таблица 23 — Параметры gpbackup
|
Параметр |
Описание |
|---|---|
| --dbname database_name | Обязательный параметр. Задаёт базу данных для резервного копирования. |
| --backup-dir directory | Опционально. Копирует все необходимые файлы резервных копий (файлы метаданных и файлы данных) в указанный каталог. Вы должны указать каталог как абсолютный путь (не относительный). Если вы не укажете этот параметр, файлы метаданных будут созданы на мастер-хосте RT.Warehouse в каталоге $MASTER_DATA_DIRECTORY/backups/YYYYMMDD/YYYYMMDDhhmmss/. Хосты сегментов создают файлы данных CSV в каталоге <seg_dir>/backups/YYYYMMDD/YYYYMMDDhhmmss/. Когда вы указываете настраиваемый каталог резервного копирования, файлы копируются по этим путям в подкаталогах каталога резервного копирования. Вы не можете комбинировать этот параметр с параметром --plugin-config. |
| --compression-level level | Опционально. Определяет уровень сжатия gzip (от 1 до 9), используемый для сжатия файлов данных. По умолчанию — 1. Обратите внимание, что gpbackup по умолчанию использует сжатие. |
| --data-only | Опционально. Выполняет резервное копирование только табличных данных в файлы CSV, но не выполняет резервное копирование файлов метаданных, необходимых для воссоздания таблиц и других объектов базы данных. |
| --debug | Опционально. Отображает подробные отладочные сообщения во время работы. |
| --exclude-schema schema_name | Опционально. Задаёт схему базы данных, которую нужно исключить из резервной копии. Вы можете указать этот параметр несколько раз, чтобы исключить несколько схем. Вы не можете комбинировать этот параметр с параметром ‑‑include-schema или параметром фильтрации таблиц, таким как --include-table. |
| --exclude-table schema.table | Опционально. Задаёт таблицу, которую нужно исключить из резервной копии. Таблица должна быть в формате <schema-name>.<table-name>. Если в имени таблицы или схемы используется любой символ, кроме строчной буквы, числа или символа подчеркивания, то вы должны заключить это имя в двойные кавычки. Вы можете указать этот параетр несколько раз. Вы не можете комбинировать этот параметр с параметром --exclude-schema или другим параметром фильтрации таблиц, таким как --include-table. Вы не можете использовать этот параметр в сочетании с --leaf-partition-data. Хотя вы можете указать имена leaf-партиций, gpbackup игнорирует имена партиций. |
| --exclude-table-file file_name | Опционально. Задаёт текстовый файл, содержащий список таблиц, которые нужно исключить из резервной копии. Каждая строка в текстовом файле должна определять одну таблицу в формате <schema-name>.<table-name>. Файл не должен содержать завершающих строк. Если в имени таблицы или схемы используется любой символ, кроме строчной буквы, числа или символа подчеркивания, то вы должны заключить это имя в двойные кавычки. Вы не можете комбинировать этот параметр с параметром --exclude-schema или другим параметром фильтрации таблиц, таким как --include-table. Вы не можете использовать этот параметр в сочетании с --leaf-partition-data. Хотя вы можете указать имена leaf-партиций в файле, указанном с помощью --exclude-table-file, gpbackup игнорирует имена партиций. |
| --include-schema schema_name | Опционально. Задаёт схему базы данных для включения в резервную копию. Вы можете указать этот параметр несколько раз, чтобы включить несколько схем. Если вы укажете этот параметр, любые схемы, не включённые в последующие параметры --include-schema, будут исключены из резервного набора. Вы не можете комбинировать этот параметр с параметрами --exclude-schema, --include-table или --include-table-file. |
| --include-table schema.table | Опционально. Задаёт таблицу для включения в резервную копию. Таблица должна быть в формате <schema-name>.<table-name>. Если в имени таблицы или схемы используется какой-либо символ, кроме строчной буквы, числа или символа подчеркивания, то вы должны заключить это имя в одинарные кавычки. Для получения информации о символах, которые поддерживаются в именах схем и таблиц, см. Схема и имена таблиц. Этот параметр можно указывать несколько раз. Вы не можете комбинировать этот параметр с параметром фильтрации схемы, например --include-schema, или другим параметром фильтрации таблиц, например --exclude-table-file. Вы также можете указать полное имя последовательности или представления. Если вы укажете этот параметр, утилита не будет автоматически создавать резервные копии зависимых объектов. Вы также должны явно указать требуемые зависимые объекты. Например, если вы создаёте резервную копию представления, вы должны также создать резервную копию таблиц, которые использует представление. Если вы создаёте резервную копию таблицы, которая использует последовательность, вы также должны создать резервную копию последовательности. Вы можете дополнительно указать имя leaf-партиции таблицы вместо имени таблицы, чтобы включить в резервную копию только определённые leaf-партиции с параметром --leaf-partition-data. При резервном копировании leaf-партиции выполняется резервное копирование данных leaf-партиции вместе с метаданными для партиционированной таблицы. |
| --include-table-file file_name | Опционально. Задаёт текстовый файл, содержащий список таблиц для включения в резервную копию. Каждая строка в текстовом файле должна определять одну таблицу в формате <schema-name>.<table-name>. Файл не должен содержать завершающих строк. См. в Схема и имена таблиц информацию о символах, которые поддерживаются в именах схем и таблиц. Любые таблицы, не указанные в этом файле, не включаются в резервный набор. Вы не можете комбинировать этот параметр с параметром фильтрации схемы, например --include-schema, или другим параметром фильтрации таблиц, например --exclude-table-file. Вы также можете указать полное имя последовательности или представления. Если вы укажете этот параметр, утилита не будет автоматически создавать резервные копии зависимых объектов. Вы также должны явно указать требуемые зависимые объекты. Например, если вы создаёте резервную копию представления, вы также должны указать таблицы, которые оно использует. Если вы указываете таблицу, в которой используется последовательность, вы также должны указать последовательность. Вы можете дополнительно указать имя leaf-партиции таблицы вместо имени таблицы, чтобы включить в резервную копию только leaf-партиции с параметром --leaf-partition-data. При резервном копировании leaf-партиции выполняется резервное копирование данных leaf-партиции вместе с метаданными для партиционированной таблицы. |
| --incremental | Укажите этот параметр, чтобы добавить инкрементную резервную копию в набор инкрементных резервных копий. Набор резервных копий — это полная резервная копия и одна или несколько инкрементных резервных копий. Резервные копии в наборе должны быть созданы с согласованным набором параметров резервного копирования, чтобы гарантировать, что набор резервных копий можно использовать в операции восстановления. По умолчанию gpbackup пытается найти самую последнюю существующую резервную копию с согласованным набором параметров. Если резервная копия является полной, утилита создаёт набор резервных копий. Если резервная копия является инкрементной, утилита добавляет резервную копию к существующему набору резервных копий. Инкрементная резервная копия добавляется как последняя резервная копия в набор резервных копий. Вы можете указать --from-timestamp, чтобы переопределить поведение по умолчанию. |
| --from-timestamp backup-timestamp | Опционально. Задаёт метку времени резервной копии. Указанная резервная копия должна иметь параметры резервного копирования, совместимые с создаваемой инкрементной резервной копией. Если указанная резервная копия является полной, утилита создает набор резервных копий. Если указанная резервная копия является инкрементальной, утилита добавляет инкрементную резервную копию к существующему набору резервных копий. В этом параметре необходимо указать --leaf-partition-data. Вы не можете комбинировать этот параметр с --data-only или --metadata-only. Резервная копия не создаётся, и утилита возвращает ошибку, если резервная копия не может добавить резервную копию к существующему набору инкрементных резервных копий или не может использовать резервную копию для создания. |
| --jobs int |
Опционально. Задаёт количество заданий, которые будут выполняться параллельно при резервном копировании таблиц. По умолчанию gpbackup использует 1 задание (подключение к базе данных). Увеличение этого числа может повысить скорость резервного копирования данных. При выполнении нескольких заданий каждое задание выполняет резервное копирование таблиц в отдельной транзакции. Например, если вы укажете --jobs 2, утилита создаст два процесса, каждый процесс запускает одну транзакцию, а утилита выполняет резервное копирование таблиц параллельно, используя два процесса. Внимание: если вы укажете значение больше 1, база данных должна находиться в состоянии покоя, пока утилита устанавливает блокировку таблиц, для которых выполняется резервное копирование. Если операции с базой данных выполняются с таблицами, резервные копии которых создаются в процессе блокировки таблицы, согласованность между таблицами, резервные копии которых создаются в различных транзакциях, не может быть гарантирована. Вы не можете использовать этот параметр в сочетании с параметрами --metadata-only, --single-data-file или --plugin-config. |
| --leaf-partition-data | Опционально. Для партиционированных таблиц создаёт один файл данных на каждую leaf-партицию вместо одного файла данных для всей таблицы (по умолчанию). Использование этого параметра также позволяет указать отдельные leaf-партиции для включения в резервную копию с параметром --include-table-file. Вы не можете использовать этот параметр в сочетании с --exclude-table-file или --exclude-table. |
| --metadata-only | Опционально. Создаёт только файлы метаданных (DDL), необходимые для воссоздания объектов базы данных, но не выполняет резервное копирование фактических данных таблицы. |
| --no-compression | Опционально. Не сжимать файлы CSV с данными таблицы. |
| --plugin-config config-file_location | Указывает расположение файла конфигурации подключаемого модуля gpbackup, текстового файла в формате YAML. Файл содержит информацию о конфигурации для приложения подключаемого модуля, которое gpbackup использует во время операции резервного копирования. Если вы укажете параметр --plugin-config при резервном копировании базы данных, вы должны указать этот параметр с информацией о конфигурации для соответствующего приложения подключаемого модуля при восстановлении базы данных из резервной копии. Этот параметр нельзя комбинировать с параметром --backup-dir. |
| --quiet | Опционально. Не отображать все сообщения журнала без предупреждений и ошибок. |
| --single-data-file |
Опционально. Создаёт один файл данных на каждом хосте сегмента для всех таблиц, резервные копии которых созданы в этом сегменте. По умолчанию каждый gpbackup создаёт один сжатый файл CSV для каждой таблицы, резервная копия которой выполняется в сегменте. Примечание. Если вы используете параметр --single-data-file для объединения резервных копий таблиц в один файл для каждого сегмента, вы не можете установить для параметра gprestore --jobs значение выше 1 для выполнения операции параллельного восстановления. |
| --verbose | Опционально. Печатает подробные сообщения журнала. |
| --version | Опционально. Распечатывает номер версии и выходит. |
| --with-stats | Опционально. Включает статистику плана запроса в резервный набор. |
| --help | Отображает интерактивную справку. |
Один из этих кодов возвращается после завершения gpbackup:
- 0 — резервное копирование выполнено без проблем;
- 1 — резервное копирование завершено с некритическими ошибками. Смотрите файл журнала для получения дополнительной информации.
- 2 — резервное копирование завершилось фатальной ошибкой. Смотрите файл журнала для получения дополнительной информации.
При указании параметра фильтрации таблиц --include-table или --include-table-file для вывода списка таблиц для резервного копирования, утилита gpbackup поддерживает резервное копирование схем или таблиц, когда имя содержит символы верхнего регистра или эти специальные символы.
~ # $ % ^ & * ( ) _ - + [ ] { } > < \ | ; : / ? ! ,
Если имя содержит верхний регистр или специальный символ и указано в командной строке с помощью --include-table, имя должно быть заключено в одинарные кавычки.
gpbackup --dbname test --include-table 'my#1schema'.'my_$42_Table'Когда таблица указана в файле для использования с --include-table-file, одинарные кавычки не требуются. Например, это содержимое текстового файла, который используется с --include-table-file для резервного копирования двух таблиц.
my#1schema.my_$42_Table
my#1schema.my_$590_Table
|
Примечание. Параметры --include-table и --include-table-file не поддерживают имена схем или таблиц, содержащие символы двойной кавычки ("), точку (.), новую строку (\n) или пробел ( ). |
Сделать резервную копию всех схем и таблиц в базе данных demo, включая глобальную статистику системных объектов RT.Warehouse:
$ gpbackup --dbname demoСделать резервную копию всех схем и таблиц в базе данных demo, кроме схемы twitter:
$ gpbackup --dbname demo --exclude-schema twitterСделать резервную копию только схемы twitter в базе данных demo:
$ gpbackup --dbname demo --include-schema twitterСделать резервную копию всех схем и таблиц в базе данных demo, включая глобальные системные объекты RT.Warehouse и статистику запросов, и скопировать все файлы резервных копий в каталог /home/gpadmin/backup:
$ gpbackup --dbname demo --with-stats --backup-dir /home/gpadmin/backupВ этом примере --include-schema с --exclude-table используется для резервного копирования схемы, за исключением одной таблицы:
$ gpbackup --dbname demo --include-schema mydata --exclude-table mydata.addressesВы не можете использовать параметр --exclude-schema с параметром фильтрации таблиц, например --include-table.
Утилита gpcheckcat проверяет таблицы каталога RT.Warehouse на несоответствия.
Утилита находится в $GPHOME/bin/lib.
gpcheckcat [ options] [ dbname]
Options:
-g dir
-p port
-P password
-U user_name
-S {none | only}
-O
-R test_name
-C catalog_name
-B parallel_processes
-v
-A
gpcheckcat -l
gpcheckcat -?Утилита gpcheckcat запускает несколько тестов, которые проверяют несоответствие каталога базы данных. Некоторые тесты нельзя запускать одновременно с другими операторами рабочей нагрузки, иначе их нельзя будет использовать. При запуске gpcheckcat перезапустите базу данных в ограниченном режиме, иначе gpcheckcat может сообщать о несоответствиях из-за текущих операций с базой данных, а не о фактическом количестве несоответствий. Если вы запускаете gpcheckcat без остановки работы базы данных, запустите его с параметром -O.
|
Примечание. Каждый раз, когда вы запускаете утилиту, она проверяет и удаляет потерянные временные схемы базы данных (временные схемы без идентификатора сеанса) в указанных базах данных. Утилита отображает результаты проверки временной схемы без родителя в командной строке, а также регистрирует результаты. |
Несоответствия каталога — это несоответствия, возникающие между системными таблицами RT.Warehouse. В общем, существует три типа несоответствий:
1) Несоответствия в системных таблицах на уровне сегмента. Например, несоответствие между системной таблицей, содержащей данные таблицы, и системной таблицей, содержащей данные столбцов. Другой вариант — системная таблица, содержащая дубликаты в столбце, который должен быть уникальным.
2) Несоответствия между одной и той же системной таблицей по сегментам. Например, в системной таблице отсутствует строка в одном сегменте, но в других сегментах эта строка есть. В качестве другого примера, значения конкретных данных столбца строки различаются для разных сегментов, например, права владельца таблицы или доступа к таблице.
3) Несоответствие между таблицей каталога и файловой системой. Например, файл существует в каталоге базы данных, но для него нет записи в таблице pg_class.
Таблица 24 — Параметры gpcheckcat
|
Параметр |
Описание |
|---|---|
| -A | Запускает gpcheckcat для всех баз данных в установке RT.Warehouse. |
| -B parallel_processes |
Количество процессов, запускаемых параллельно. Утилита gpcheckcat пытается определить количество одновременно используемых процессов (размер пакета). Утилита предполагает, что она может использовать буфер размером не менее 20 МБ для каждого процесса. Максимальное количество параллельных процессов — это количество инстансов сегмента RT.Warehouse. Утилита отображает количество используемых параллельных процессов, когда начинает проверку каталога. Примечание. Утилите может не хватить памяти, если количество возвращаемых ошибок превышает размер буфера. Если возникает ошибка нехватки памяти, вы можете уменьшить размер пакета с помощью параметра -B. Например, если утилита отображает размер пакета 936 и не хватает памяти, вы можете указать -B 468 для параллельного запуска 468 процессов. |
| -C catalog_table | Запускает тесты кросс-последовательности, внешнего ключа и ACL для указанной таблицы каталога. |
| -g data_director | Создаёт скрипт SQL для устранения несоответствий каталога. Скрипты помещаются в data_directory. |
| -l | Перечисляет тесты gpcheckcat. |
| -O | Запускает только тесты gpcheckcat, которые можно запускать в онлайн-режиме (без ограничений). |
| -p port | Этот параметр указывает порт, который используется RT.Warehouse. |
| -P password | Пароль пользователя, подключающегося к RT.Warehouse. |
| -R test_name |
Указывает тест для запуска. Некоторые тесты можно запускать только в том случае, если RT.Warehouse находится в ограниченном режиме. Это те тесты, которые можно выполнять:
Примечание. Существует несколько причин «осиротения» TOAST-таблицы, когда невозможно создать скрипта восстановления и требуется изменение каталога вручную. Одна из причин — если запись reltoastrelid в pg_class указывает на неправильную таблицу TOAST (несоответствие TOAST-таблицы). Другая причина — reltoastrelid в pg_class отсутствуют и запись pg_depend отсутствует (дважды «сиротская» TOAST-таблица). Если необходимо изменить каталог вручную, gpcheckcat отобразит подробные шаги, которые вы можете выполнить, чтобы обновить каталог.
|
| -S {none | only} | Укажите этот параметр, чтобы контролировать тестирование таблиц каталога, которые используются во всех базах данных в установке RT.Warehouse, например, pg_database. Значение none отключает тестирование таблиц общего каталога. Значение only проверяет только таблицы общего каталога. |
| -U user_name | Пользователь, подключающийся к RT.Warehouse. |
| -? | Отображает интерактивную справку. |
| -v | Отображает подробную информацию о выполненных тестах. |
Утилита определяет таблицы с отсутствующими атрибутами и отображает их в различных местах на выводе и в нестандартизированном формате. Утилита также отображает сводный список таблиц с отсутствующими атрибутами в формате database.schema.table.segment_id после отображения выходной информации.
Если gpcheckcat обнаруживает несогласованную информацию OID (Object ID, идентификатор объекта), он генерирует один или несколько файлов проверки, содержащих SQL-запрос. Вы можете запустить SQL-запрос, чтобы просмотреть подробную информацию о несоответствиях OID и исследовать несоответствия. Файлы создаются в каталоге, в котором запускается gpcheckcat.
Формат файла:
gpcheckcat.verify.dbname.catalog_table_name.test_name.TIMESTAMP.sqlПример файла проверки, созданный gpcheckcat при обнаружении несогласованных OID в таблице каталога pg_type в базе данных mydb:
gpcheckcat.verify.mydb.pg_type.missing_extraneous.20150420102715.sqlПример запроса из файла подтверждения:
SELECT *
FROM (
SELECT relname, oid FROM pg_class WHERE reltype
IN (1305822,1301043,1301069,1301095)
UNION ALL
SELECT relname, oid FROM gp_dist_random('pg_class') WHERE reltype
IN (1305822,1301043,1301069,1301095)
) alltyprelids
GROUP BY relname, oid ORDER BY count(*) desc ;Проверяет базовую производительность оборудования указанных хостов.
gpcheckperf -d test_directory [-d test_directory ...]
{-f hostfile_gpcheckperf | - h hostname [-h hostname ...]}
[-r ds] [-B block_size] [-S file_size] [-D] [-v|-V]
gpcheckperf -d temp_directory
{-f hostfile_gpchecknet | - h hostname [-h hostname ...]}
[ -r n|N|M [--duration time] [--netperf] ] [-D] [-v | -V]
gpcheckperf -?
gpcheckperf --versionУтилита gpcheckperf запускает сеанс на указанных хостах и выполняет следующие тесты производительности:
1) Тест производительности ввода-вывода диска (dd-тест) — для тестирования последовательной пропускной способности логического диска или файловой системы утилита использует команду dd, которая является стандартной утилитой UNIX. Она подсчитывает время, необходимое для записи и чтения большого файла на диск и с диска, и вычисляет производительность дискового ввода-вывода в мегабайтах в секунду (МБ/с). По умолчанию размер файла, который используется для теста, рассчитывается как удвоенный общий объём оперативной памяти (RAM) на хосте. Это гарантирует, что тест действительно тестирует дисковый ввод-вывод и не использует кэш памяти.
2) Тест пропускной способности памяти (потока) — для проверки пропускной способности памяти утилита использует программу тестирования STREAM для измерения устойчивой пропускной способности памяти (в МБ/с). Она проверяет, что производительность вашей системы не ограничена пропускной способностью памяти системы по сравнению с вычислительной производительностью ЦПУ. В приложениях с большим набором данных (например, в RT.Warehouse) низкая пропускная способность памяти является серьёзной проблемой для производительности. Если пропускная способность памяти значительно ниже теоретической пропускной способности ЦПУ, это может привести к тому, что ЦПУ будет тратить значительное количество времени на ожидание данных, поступающих из системной памяти.
3) Тест производительности сети (gpnetbench*) — для проверки производительности сети (и, следовательно, производительности соединения с RT.Warehouse) утилита запускает программу тестирования производительности сети, которая передает 5-секундный поток данных с текущего хоста на каждый удалённый хост, включённый в тест. Данные передаются параллельно каждому удалённому хосту, а минимальная, максимальная, средняя и медианная скорость передачи данных по сети указывается в мегабайтах в секунду (МБ/с). Если суммарная скорость передачи ниже ожидаемой (менее 100 МБ/с), вы можете запустить тест сети последовательно, используя параметр -r n, чтобы получить результаты для каждого хоста. Чтобы запустить полноматричный тест пропускной способности, вы можете указать -r M, который заставит каждый хост отправлять и получать данные с любого другого указанного хоста. Этот тест лучше всего использовать для проверки того, может ли коммутационная матрица выдерживать полноматричную рабочую нагрузку.
Чтобы указать хосты для тестирования, используйте параметр -f, чтобы указать файл, содержащий список имён хостов, или используйте параметр ‑h, чтобы указать имена отдельных хостов в командной строке. При выполнении теста производительности сети все записи в файле хоста должны относиться к сетевым интерфейсам в одной подсети. Если хосты вашего сегмента имеют несколько сетевых интерфейсов, настроенных в разных подсетях, запустите тест сети один раз для каждой подсети.
Вы также должны указать хотя бы один тестовый каталог (с -d). Пользователь, запускающий gpcheckperf, должен иметь доступ на запись в указанные тестовые каталоги на всех удалённых хостах. Для теста дискового ввода-вывода тестовые каталоги должны соответствовать каталогам данных вашего сегмента (основного и/или зеркального). Для тестирования пропускной способности памяти и сети требуется временный каталог для файлов тестовой программы.
Перед использованием gpcheckperf вы должны настроить доверенный доступ между хостами, участвующими в тесте производительности. Вы можете использовать утилиту gpssh-exkeys для обновления известных файлов хоста и обмена открытыми ключами между хостами, если вы этого еще не сделали. Обратите внимание, что gpcheckperf вызывает gpssh и gpscp, поэтому эти утилиты RT.Warehouse также должны быть в вашем $PATH.
Таблица 25 — Параметры gpcheckperf
|
Параметр |
Описание |
|---|---|
| -B block_size | Задаёт размер блока (в КБ или МБ) для использования при тестировании дискового ввода-вывода. Значение по умолчанию — 32 КБ, что соответствует размеру страницы RT.Warehouse. Максимальный размер блока — 1 МБ. |
| -d test_directory | Для теста дискового ввода-вывода указывает расположение каталогов файловой системы для тестирования. У вас должен быть доступ для записи в тестовый каталог на всех хостах, участвующих в тесте производительности. Вы можете использовать параметр -d несколько раз, чтобы указать несколько тестовых каталогов (например, для тестирования дискового ввода-вывода ваших основных и зеркальных каталогов данных). |
| -d temp_directory | Для сетевых и потоковых тестов указывает единственный каталог, в который файлы тестовой программы будут скопированы на время теста. У вас должен быть доступ на запись в этот каталог на всех хостах, участвующих в тесте. |
| -D | Сообщает результаты производительности для каждого хоста для тестов дискового ввода-вывода. По умолчанию в отчёт выводятся результаты только для хостов с минимальной и максимальной производительностью, а также общая и средняя производительность всех хостов. |
| --duration time | Задаёт продолжительность проверки сети в секундах (s), минутах (m), часах (h) или днях (d). По умолчанию — 15 секунд. |
| -f hostfile_gpcheckperf |
Для тестов дискового ввода-вывода и потоков указывает имя файла, содержащего одно имя хоста для каждого хоста, который будет участвовать в тесте производительности. Имя хоста является обязательным, и вы можете дополнительно указать альтернативное имя пользователя и/или номер порта SSH для каждого хоста. Синтаксис файла хоста — по одному хосту в строке следующим образом:
|
| -f hostfile_gpchecknet |
Для теста производительности сети все записи в файле хоста должны относиться к адресам хоста в одной подсети. Если хосты вашего сегмента имеют несколько сетевых интерфейсов, настроенных в разных подсетях, запустите тест сети один раз для каждой подсети. Например (файл хоста, содержащий сегментные имена адресов хоста для интерконнект-подсети 1):
|
| -h hostname | Задаёт одно имя хоста (или адрес хоста), который будет участвовать в тесте производительности. Вы можете использовать параметр -h несколько раз, чтобы указать несколько имён хостов. |
| --netperf | Указывает, что для выполнения теста сети следует использовать бинарный файл netperf вместо теста сети RT.Warehouse. Чтобы использовать этот параметр, вы должны загрузить netperf с http://www.netperf.org и установить его в $GPHOME/bin/lib на всех хостах RT.Warehouse (мастере и сегментах). |
| -r ds{n|N|M} |
Указывает, какие тесты производительности следует запустить. По умолчанию используется dsn:
|
| -S file_size | Задаёт общий размер файла, который будет использоваться для теста дискового ввода-вывода для всех каталогов, указанных с помощью -d. file_size должен в два раза превышать общий объём RAM на хосте. Если параметр не указан, значение по умолчанию рассчитывается как удвоенный общий объём RAM на хосте, на котором выполняется gpcheckperf. Это гарантирует, что тест действительно тестирует дисковый ввод-вывод и не использует кэш памяти. Вы можете указать размер в КБ, МБ или ГБ. |
| -v | -V | В подробном режиме -v (verbose) отображаются сообщения о ходе и состоянии тестов производительности по мере их выполнения. В очень подробном режиме –V (very verbose) отображаются все выходные сообщения, генерируемые этой утилитой. |
| --version | Отображает версию этой утилиты. |
| -? (help) | Отображает интерактивную справку. |
Запускает тесты дискового ввода-вывода и пропускной способности памяти на всех хостах в файле host_file, используя тестовые каталоги /data1 и /data2:
$ gpcheckperf -f hostfile_gpcheckperf -d /data1 -d /data2 -r dsЗапускает только тест ввода-вывода диска на хостах с именами sdw1 и sdw2, используя тестовый каталог /data1. Показывает результаты отдельных хостов и запускает в подробном режиме:
$ gpcheckperf -h sdw1 -h sdw2 -d /data1 -r d -D -vЗапускает тест параллельной сети, используя тестовый каталог /tmp, где hostfile_gpcheck_ic* указывает имена всех адресов хостов сетевого интерфейса в одной подсети интерконнекта:
$ gpcheckperf -f hostfile_gpchecknet_ic1 -r N -d /tmp
$ gpcheckperf -f hostfile_gpchecknet_ic2 -r N -d /tmpВыполнение того же теста, что и выше, но с использованием netperf вместо сетевого теста RT.Warehouse (обратите внимание, что netperf должен быть установлен в $GPHOME/bin/lib на всех хостах RT.Warehouse):
$ gpcheckperf -f hostfile_gpchecknet_ic1 -r N --netperf -d /tmp
$ gpcheckperf -f hostfile_gpchecknet_ic2 -r N --netperf -d /tmpУстанавливает параметры конфигурации сервера для всех сегментов в системе RT.Warehouse.
gpconfig -c param_name -v value [-m master_value | --masteronly]
| -r param_name [--masteronly]
| -l
[--skipvalidation] [--verbose] [--debug]
gpconfig -s param_name [--file | --file-compare] [--verbose] [--debug]
gpconfig --helpУтилита gpconfig позволяет вам устанавливать, отменять или просматривать параметры конфигурации из файлов postgresql.conf всех инстансов (мастера, сегментов и зеркал) в вашей системе RT.Warehouse. При установке параметра вы также можете указать другое значение для мастера, если это необходимо. Например, такие параметры, как max_connections, требуют настройки на мастере, отличной от той, которая используется для сегментов. Если вы хотите установить или отключить глобальный параметр или параметр только для мастера, используйте параметр --masteronly.
gpconfig можно использовать только для управления определёнными параметрами. Например, вы не можете использовать его для установки таких параметров, как порт, который должен быть отдельным для каждого инстанса сегмента. Используйте параметр -l (list), чтобы увидеть полный список параметров конфигурации, поддерживаемых gpconfig.
Когда gpconfig задаёт параметр конфигурации в файле postgresql.conf сегмента, новая установка параметра всегда отображается внизу файла. Когда вы используете gpconfig для удаления настройки параметра конфигурации, gpconfig комментирует параметр во всех сегментных файлах postgresql.conf, тем самым восстанавливая системные настройки по умолчанию. Например, если вы используете gpconfig, чтобы удалить (закомментировать) параметр, а затем добавить его обратно (установить новое значение), будет два экземпляра параметра; один закомментирован, а другой включён и вставлен в конец файла postgresql.conf.
После установки параметра необходимо перезапустить систему RT.Warehouse или перезагрузить файлы postgresql.conf, чтобы изменения вступили в силу. Требуется ли вам перезапуск или перезагрузка, зависит от параметра.
Чтобы показать текущие установленные значения параметра в системе, используйте параметр -s.
gpconfig использует следующие переменные среды для подключения к инстансу мастера RT.Warehouse и получения информации о конфигурации системы:
- PGHOST;
- PGPORT;
- PGUSER;
- PGPASSWORD;
- PGDATABASE.
Таблица 26 — Параметры gpconfig
|
Параметр |
Описание |
|---|---|
| -c | --change param_name | Изменяет настройку параметра конфигурации, добавляя новую настройку в конец файлов postgresql.conf. |
| -v | --value value | Значение, которое следует использовать для параметра конфигурации, указанного с параметром -c. По умолчанию это значение применяется ко всем сегментам, их зеркалам, мастеру и резервному мастеру. Утилита правильно цитирует значение при добавлении параметра в файлы postgresql.conf. Чтобы установить пустую строку вместо значения, введите пустые одинарные кавычки (''). |
| -m | --mastervalue master_value | Значение для мастера, используемое для параметра конфигурации, указанного с помощью параметра -c. Если параметр указан, значение применяется только к мастеру и резервному мастеру. Этот параметр можно использовать только с -v. |
| --masteronly | Если параметр указан, gpconfig будет редактировать только файл postgresql.conf мастера. |
| -r | --remove param_name | Удаляет настройку параметра конфигурации, закомментировав запись в файлах postgresql.conf. |
| -l | --list | Перечисляет все параметры конфигурации, поддерживаемые утилитой gpconfig. |
| -s | --show param_name | Показывает значение параметра конфигурации, используемого на всех инстансах (мастере и сегментах) в системе RT.Warehouse. Если значения параметра среди инстансов различаются, утилита отображает сообщение об ошибке. Запуск gpconfig с параметром -s считывает значения параметров непосредственно из базы данных, а не из файла postgresql.conf. Если вы используете gpconfig для установки параметров конфигурации для всех сегментов, а затем запускаете gpconfig -s для проверки изменений, вы всё равно можете увидеть предыдущие (старые) значения. Вы должны перезагрузить файлы конфигурации (gpstop -u) или перезапустить систему (gpstop -r), чтобы изменения вступили в силу. |
| --file | Для параметра конфигурации показывает значение из файла postgresql.conf для всех инстансов (мастера и сегментов) в системе RT.Warehouse. Если значения параметра среди инстансов различаются, утилита отображает сообщение. Должен быть указан с параметром -s. Например, параметр конфигурации statement_mem установлен на 64 МБ для пользователя с командой ALTER ROLE, а значение в файле postgresql.conf — 128 МБ. Выполнение команды gpconfig -s statement_mem --file отображает 128 МБ. Команда gpconfig -s statement_mem, запущенная пользователем, отображает 64 МБ. Невалидно с параметром --file-compare. |
| --file-compare | Для параметра конфигурации сравнивает текущее значение RT.Warehouse со значением в файлах postgresql.conf на хостах (мастере и сегментах). Значения в файлах postgresql.conf представляют значения RT.Warehouse при перезапуске. Если значения не совпадают, утилита отображает значения со всех хостов. Если все хосты имеют одинаковое значение, утилита отображает сводный отчёт. Невалидно с параметром --file. |
| --skipvalidation |
Переопределяет системные проверки gpconfig и позволяет вам работать с любым параметром конфигурации сервера, включая скрытые параметры и параметры с ограничениями, которые не могут быть изменены с помощью gpconfig. При использовании с параметром -l (list) показывает список ограниченных параметров. Предупреждение. Будьте предельно осторожны при настройке параметров конфигурации с помощью этого параметра. |
| --verbose | Отображает дополнительную информацию журнала во время выполнения команды gpconfig. |
| --debug | Устанавливает вывод журнала на уровень отладки. |
| -? | -h | --help | Отображает интерактивную справку. |
Установить для параметра max_connections значение 100 для всех сегментов и значение 10 для мастера:
gpconfig -c max_connections -v 100 -m 10Примеры синтаксиса, необходимого для обработки строкой оболочки bash:
gpconfig -c search_path -v '"\$user",public'
gpconfig -c dynamic_library_path -v '\$libdir'Параметры конфигурации добавить в файл postgresql.conf:
search_path='"$user",public'
dynamic_library_path='$libdir'Закомментировать все инстансы параметра конфигурации default_statistics_target и восстановить системное значение по умолчанию:
gpconfig -r default_statistics_targetПеречислить все параметры конфигурации, поддерживаемые gpconfig:
gpconfig -lПоказывать значения определённого параметра конфигурации в системе:
gpconfig -s max_connectionsУдаляет систему RT.Warehouse, которая была инициализирована с помощью gpinitsystem.
gpdeletesystem [-d master_data_directory] [-B parallel_processes]
[-f] [-l logfile_directory] [-D]
gpdeletesystem -?
gpdeletesystem -vУтилита gpdeletesystem выполняет следующие действия:
1) Останавливает все процессы postgres (инстансы сегментов и инстанс мастера).
2) Удаляет все каталоги данных.
Перед запуском gpdeletesystem:
1) Переместите все файлы резервных копий из каталогов данных сегментов и мастера.
2) Убедитесь, что RT.Warehouse запущена.
3) Если вы в данный момент находитесь в каталоге данных сегмента, смените каталог на другое место. Утилита выдаёт ошибку при запуске из каталога данных сегмента.
Эта утилита не удаляет программное обеспечение RT.Warehouse.
Таблица 27 — Параметры gpdeletesystem
|
Параметр |
Описание |
|---|---|
| -d master_data_directory | Задаёт каталог данных мастер-хоста. Если этот параметр не указан, используется значение переменной среды MASTER_DATA_DIRECTORY. Если параметр указан, он переопределяет любые настройки MASTER_DATA_DIRECTORY. Если master_data_directory не может быть определён, утилита возвращает ошибку. |
| -B parallel_processes | Количество сегментов для параллельного удаления. Если параметр не указан, утилита запустит до 60 параллельных процессов в зависимости от того, сколько инстансов сегментов необходимо удалить. |
| -f | Принудительное удаление, даже если файлы резервных копий найдены в каталогах данных. По умолчанию инстансы RT.Warehouse не удаляются при наличии файлов резервных копий. |
| -l logfile_directory | Каталог для записи файла журнала. По умолчанию ~/gpAdminLogs. |
| -D | Устанавливает уровень ведения журнала для отладки. |
| -? | Отображает интерактивную справку. |
| -v | Отображает версию, статус, дату последнего обновления и контрольную сумму утилиты. |
Удалить систему RT.Warehouse:
gpdeletesystem -d /gpdata/gp-1Удалить систему RT.Warehouse, даже если файлы резервных копий присутствуют:
gpdeletesystem -d /gpdata/gp-1 -fРасширяет существующую RT.Warehouse на новые хосты в системе.
gpexpand [{-f|--hosts-file} hosts_file]
| {-i|--input} input_file [-B batch_size]
| [{-d | --duration} hh:mm:ss | {-e|--end} 'YYYY-MM-DD hh:mm:ss']
[-a|-analyze]
[-n parallel_processes]
| {-r|--rollback}
| {-c|--clean}
[-v|--verbose] [-s|--silent]
[{-t|--tardir} directory ]
[-S|--simple-progress ]
gpexpand -? | -h | --help
gpexpand --version1) Вы вошли в систему как суперпользователь RT.Warehouse (gpadmin).
2) Новые хосты сегмента были установлены и настроены в соответствии с существующими хостами сегмента, а именно:
- Настроено оборудования и ОС;
- Установлено программное обеспечение RT.Warehouse;
- Создана учётная запись пользователя gpadmin;
- Произведён обмен ключами SSH.
3) Имеется достаточно дискового пространства на хостах сегмента, чтобы временно разместить копию самой большой таблицы.
4) При перераспределении данных RT.Warehouse должна работать в производственном режиме. RT.Warehouse не может работать в ограниченном режиме или в мастер-режиме. Параметры gpstart -R или -m не могут быть указаны для запуска RT.Warehouse.
|
Примечание. Данные утилиты нельзя запустить, пока gpexpand выполняет инициализацию сегмента: - gpbackup; - gpcheckcat; - gpconfig; - gppkg; - gprestore. |
Утилита gpexpand выполняет расширение системы в два этапа: инициализация инстанса сегмента и затем перераспределение данных таблицы.
На этапе инициализации gpexpand запускается с входным файлом, в котором указаны каталоги данных, значения dbid и другие характеристики инстансов нового сегмента. Вы можете создать входной файл вручную или следуя подсказкам в интерактивном режиме.
Если вы решили создать входной файл с помощью интерактивного режима, вы можете дополнительно указать файл, содержащий список хостов системы расширения. Если ваша платформа или командная оболочка ограничивает длину списка имён хостов, которые вы можете ввести при запросе в интерактивном режиме, указание хостов с помощью -f может быть обязательным.
Помимо инициализации инстансов сегмента, на этапе инициализации также создаётся схема расширения с именем gpexpand в базе данных postgres для хранения статуса операции расширения, включая подробный статус для таблиц.
На этапе перераспределения табличных данных gpexpand перераспределяет табличные данные, чтобы повторно сбалансировать данные между старым и новым инстансами сегментов.
|
Примечание. Перераспределение данных следует выполнять в часы низкой нагрузки. Распределение можно разделить на batch-пакеты в течение длительного периода. |
Чтобы начать этап распределения, запустите gpexpand с параметрами ‑d (duration) или -e (end time) или без параметров. Если вы укажете время окончания или продолжительность, утилита будет перераспределять таблицы в схеме расширения до тех пор, пока не будет достигнуто указанное время окончания или продолжительность. Если вы не укажете никаких параметров, то этап перераспределения утилиты будет продолжаться до тех пор, пока все таблицы в схеме расширения не будут реорганизованы. Каждая таблица реорганизуется с помощью команд ALTER TABLE, чтобы повторно сбалансировать таблицы по новым сегментам и установить для таблиц их исходную политику распределения. Если gpexpand завершает реорганизацию всех таблиц, он отображает сообщение об успешном завершении и завершается.
|
Примечание. Эта утилита использует SSH-соединения между системами для выполнения своих задач. В больших развёртываниях RT.Warehouse, облачных развёртываниях или развёртываниях с большим количеством сегментов на хост эта утилита может превышать максимальный порог хоста для неаутентифицированных соединений. Рассмотрите возможность обновления параметра конфигурации SSH MaxStartups, чтобы увеличить этот порог. Дополнительные сведения о параметрах конфигурации SSH см. в документации по SSH для вашего дистрибутива Linux. |
Таблица 28 — Параметры gpexpand
|
Параметр |
Описание |
|---|---|
| -a | --analyze | Запускает ANALYZE, чтобы обновить статистику таблицы после расширения. По умолчанию ANALYZE не запускается. |
| -B batch_size |
Размер batch-пакета удалённых команд для отправки на данный хост перед выполнением односекундной паузы. По умолчанию — 16. Допустимые значения — 1–128. Утилита gpexpand выдаёт ряд команд настройки, которые могут превышать максимальный порог хоста для неаутентифицированных подключений, как определено MaxStartups в конфигурации демона SSH. Пауза в одну секунду позволяет завершить аутентификацию до того, как gpexpand выдаст еще какие-либо команды. Значение по умолчанию обычно не нужно менять. Однако может потребоваться уменьшить максимальное количество команд, если gpexpand не работает с ошибками подключения, такими как 'ssh_exchange_identification: Connection closed by remote host.' |
| -c | --clean | Удаляет схему расширения. |
| -d | --duration hh:mm:ss | Продолжительность сеанса расширения от начала до конца. |
| -e | --end 'YYYY-MM-DD hh:mm:ss' | Дата и время окончания сеанса расширения. |
| -f | --hosts-file filename |
Задаёт имя файла, содержащего список новых хостов для расширения системы. Каждая строка файла должна содержать одно имя хоста. Этот файл может содержать имена хостов с указанием сетевых интерфейсов или без них. Утилита gpexpand обрабатывает оба случая, добавляя номера интерфейсов в конец имени хоста, если исходные хосты настроены с несколькими сетевыми интерфейсами. Примечание. Соглашение об именах хостов сегмента RT.Warehouse — sdwN, где sdw — префикс, а N — целое число. Например, sdw1, sdw2 и так далее. Для хостов с несколькими интерфейсами принято добавлять тире (-) и число к имени хоста. Например, sdw1-1 и sdw1-2 — это два имени интерфейса для хоста sdw1. |
| -i | --input input_file | Задаёт имя файла конфигурации расширения, который содержит по одной строке для каждого добавляемого сегмента в формате: hostname|address|port|datadir|dbid|content|preferred_role. |
| -n parallel_processes | Количество таблиц для одновременного распределения. Допустимые значения — от 1 до 96. Каждый процесс перераспределения таблиц требует двух соединений с базой данных: одно для изменения таблицы, а другое для обновления статуса таблицы в схеме расширения. Перед увеличением -n проверьте текущее значение параметра конфигурации сервера max_connections и убедитесь, что максимальный лимит подключений не превышен. |
| -r | --rollback | Откатывает неудачную операцию настройки расширения. |
| -s | --silent | Работает в тихом режиме. Не запрашивает подтверждение для продолжения предупреждений. |
| -S | --simple-progress | Если параметр указан, утилита gpexpand записывает только минимальную информацию о ходе выполнения в таблице gpexpand.expansion_progress RT.Warehouse. Утилита не записывает информацию о размере отношения и информацию о состоянии в таблицу gpexpand.status_detail. Указание этого параметра может повысить производительность за счёт уменьшения объёма информации о ходе выполнения, записываемой в таблицы gpexpand. |
| [-t | --tardir] directory | Полный путь к каталогу на хостах сегмента, куда утилита gpexpand копирует временный tar-файл. Этот файл содержит файлы RT.Warehouse, которые используются для создания инстансов сегментов. Каталог по умолчанию — это домашний каталог пользователя. |
| -v | --verbose | Подробный отладочный вывод. С этим параметром утилита выводит все DDL и DML, используемые для расширения базы данных. |
| --version | Отображает номер версии утилиты и выходит. |
| -? | -h | --help | Отображает интерактивную справку. |
Запустить gpexpand с входным файлом, чтобы инициализировать новые сегменты и создать схему расширения в базе данных postgres:
$ gpexpand -i input_fileЗапустить gpexpand на максимальную продолжительность шестьдесят часов, чтобы перераспределить таблицы в новые сегменты:
$ gpexpand -d 60:00:00Обслуживает файлы данных или записывает файлы данных из сегментов RT.Warehouse.
gpfdist [-d directory] [-p http_port] [-P last_http_port] [-l log_file]
[-t timeout] [-S] [-w time] [-v | -V] [-s] [-m max_length]
[--ssl certificate_path [--sslclean wait_time] ]
[-c config.yml]
gpfdist -? | --help
gpfdist --versiongpfdist — программа параллельного распространения файлов RT.Warehouse. Она используется читаемыми внешними таблицами и gpload для параллельного обслуживания файлов внешних таблиц для всех сегментов RT.Warehouse. Она используется внешними таблицами с возможностью записи для параллельного приёма выходных потоков из сегментов RT.Warehouse и их записи в файл.
|
Примечание. gpfdist и gpload совместимы только с основной версией RT.Warehouse, в которой они поставляются. Например, утилита gpfdist, установленная с RT.Warehouse 4.x, не может использоваться с RT.Warehouse 5.x или 6.x. |
Чтобы gpfdist мог использоваться внешней таблицей, в предложении LOCATION определения внешней таблицы должны быть указаны данные внешней таблицы с использованием протокола gpfdist://.
|
Примечание. Если для включения безопасности SSL указан параметр --ssl, создайте внешнюю таблицу с протоколом gpfdists://. |
Преимущество использования gpfdist заключается в том, что вам гарантируется максимальный параллелизм при чтении или записи во внешние таблицы, что обеспечивает наилучшую производительность, а также упрощает администрирование внешних таблиц.
Для доступных для чтения внешних таблиц gpfdist анализирует и равномерно передает файлы данных всем инстансам сегментов в системе RT.Warehouse, когда пользователи SELECT из внешней таблицы. Для внешних таблиц с возможностью записи gpfdist принимает параллельные выходные потоки из сегментов, когда пользователи INSERT во внешнюю таблицу, и записывает в выходной файл.
|
Примечание. Когда gpfdist считывает данные и обнаруживает ошибку форматирования данных, сообщение об ошибке включает номер строки, указывающий местонахождение ошибки форматирования. gpfdist пытается захватить строку, содержащую ошибку. Однако gpfdist может не захватить точную строку для некоторых ошибок форматирования. |
Для читаемых внешних таблиц, если файлы загрузки сжимаются с использованием gzip или bzip2 (имеют расширение файла .gz или .bz2), gpfdist распаковывает файлы перед загрузкой. Для внешних таблиц с возможностью записи gpfdist сжимает данные с помощью gzip, если целевой файл имеет расширение .gz.
|
Примечание. Сжатие не поддерживается для доступных для чтения и записи внешних таблиц, когда утилита gpfdist работает на платформах Windows. |
При чтении или записи данных с помощью протокола gpfdist или gpfdists RT.Warehouse включает X-GP-PROTO в заголовок запроса HTTP, чтобы указать, что запрос поступает из RT.Warehouse. Утилита отклоняет HTTP-запросы, не содержащие X-GP-PROTO в заголовке запроса.
Скорее всего, вы захотите запустить gpfdist на своих машинах ETL, а не на хостах, на которых установлена RT.Warehouse. Чтобы установить gpfdist на другой хост, просто скопируйте утилиту на этот хост и добавьте gpfdist в свой $PATH.
|
Примечание. При использовании IPv6 всегда заключайте числовой IP-адрес в скобки. |
Таблица 29 — Параметры gpfdist
|
Параметр |
Описание |
|---|---|
| -d directory | Каталог, из которого gpfdist будет обслуживать файлы для читаемых внешних таблиц или создавать выходные файлы для доступных для записи внешних таблиц. Если параметр не указан, по умолчанию используется текущий каталог. |
| -l log_file | Полный путь и имя файла журнала, в котором должны регистрироваться стандартные выходные сообщения. |
| -p http_port | Порт HTTP, на котором gpfdist будет обслуживать файлы. По умолчанию — 8080. |
| -P last_http_port | Последний номер порта в диапазоне номеров портов HTTP (от http_port до last_http_port включительно), на котором gpfdist будет пытаться обслуживать файлы. gpfdist обслуживает файлы по первому номеру порта в диапазоне, к которому он успешно привязывается. |
| -t timeout | Устанавливает время, отведённое RT.Warehouse для установления соединения с процессом gpfdist. По умолчанию — 5 секунд. Допустимые значения: от 2 до 7200 секунд (2 часа). Может потребоваться увеличить в системах с большим сетевым трафиком. |
| -m max_length |
Устанавливает максимально допустимую длину строки данных в байтах. По умолчанию — 32768. Параметр следует использовать, когда пользовательские данные содержат очень широкие строки (или когда появляется сообщение об ошибке line too long). Параметр не следует использовать иным способом, так как это увеличивает выделение ресурсов. Допустимый диапазон — от 32 КБ до 256 МБ (в системах Windows верхний предел составляет 1 МБ.) Примечание. Проблемы с памятью могут возникнуть, если вы укажете большую максимальную длину строки и запустите большое количество одновременных подключений gpfdist. Например, установка этого значения на максимум 256 МБ с 96 параллельными процессами gpfdist потребует примерно 24 ГБ памяти ((96 + 1) x 246 МБ). |
| -s |
Обеспечивает упрощённое ведение журнала. Когда указан этот параметр, в файл журнала gpfdist записываются только сообщения с уровнем WARN и выше. Сообщения уровня INFO не записываются в файл журнала. Если этот параметр не указан, все сообщения gpfdist записываются в файл журнала. Вы можете указать этот параметр, чтобы уменьшить количество информации, записываемой в файл журнала. |
| -S | Открывает файл для синхронного I/O с флагом O_SYNC. Любая запись фиксируется в результирующий блок дескриптора файла gpfdist до тех пор, пока данные не будут физически записаны на базовое оборудование. |
| -w time | Устанавливает количество секунд, в течение которых RT.Warehouse задерживает перед закрытием целевого файла, например, именованного канала. Значение по умолчанию — 0, т.е. без задержки. Максимальное значение — 7200 секунд (2 часа). Для RT.Warehouse с несколькими сегментами может быть задержка между сегментами при записи данных из разных сегментов в файл. Вы можете указать время ожидания, прежде чем RT.Warehouse закроет файл, чтобы гарантировать, что все данные будут записаны в файл. |
| --ssl certificate_path |
Добавляет SSL-шифрование к данным, передаваемым с помощью gpfdist. После выполнения gpfdist с параметром --ssl certificate_path единственный способ загрузить данные с этого файлового сервера — использовать протокол gpfdist://. Местоположение, указанное в certificate_path, должно содержать следующие файлы:
Корневой каталог (/) не может быть указан как certificate_path. |
| --sslclean wait_time | Когда утилита запускается с параметром --ssl, задаётся количество секунд, на которое утилита задерживается перед закрытием SSL-сеанса и очисткой SSL-ресурсов после того, как завершится запись данных в сегмент RT.Warehouse или из него. Значение по умолчанию — 0, т.е. без задержки. Максимальное значение — 500 секунд. При увеличении задержки скорость передачи снижается. В некоторых случаях может возникать данная ошибка при копировании больших объёмов данных: gpfdist server closed connection. Чтобы избежать ошибки, вы можете добавить задержку, например --sslclean 5. |
| -c config.yaml | Задаёт правила, которые gpfdist использует для выбора преобразования, применяемого при загрузке или извлечении данных. Файл конфигурации gpfdist — это документ YAML 1.1. Данный параметр недоступен на платформах Windows. |
| -v | В подробном (verbose) режиме отображаются сообщения о ходе и состоянии. |
| -V | В очень подробном (very verbose) режиме отображаются все выходные сообщения, генерируемые этой утилитой. |
| -? | Отображает интерактивную справку. |
| --version | Отображает версию этой утилиты. |
Параметр конфигурации сервера verify_gpfdists_cert определяет, включена ли проверка подлинности сертификата SSL, когда RT.Warehouse связывается с утилитой gpfdist для чтения или записи данных из внешнего источника данных. Вы можете установить для параметра значение false, чтобы отключить аутентификацию при тестировании связи между внешней таблицей RT.Warehouse и утилитой gpfdist, обслуживающей внешние данные. Если значение false, данные исключения SSL игнорируются:
1) Самоподписанный сертификат SSL, используемый gpfdist, не является доверенным для RT.Warehouse.
2) Имя хоста, содержащееся в сертификате SSL, не соответствует имени хоста, на котором выполняется gpfdist.
|
Внимание. Отключение проверки подлинности SSL-сертификата представляет угрозу безопасности, поскольку не проверяет SSL-сертификат gpfdists. |
Если утилита gpfdist зависает при отсутствии операций чтения или записи, вы можете создать дамп ядра в следующий раз, когда произойдет зависание, чтобы помочь отладить проблему. Задайте для переменной среды GPFDIST_WATCHDOG_TIMER количество секунд бездействия для ожидания перед принудительным завершением работы gpfdist. Когда переменная среда установлена и gpfdist зависает, утилита прекращает работу через указанное количество секунд, создаёт дамп ядра и отправляет информацию об аварийном завершении в файл журнала.
В этом примере переменная среда в системе Linux устанавливается так, что gpfdist завершает работу через 300 секунд (5 минут) бездействия.
export GPFDIST_WATCHDOG_TIMER=300Чтобы обслуживать файлы из указанного каталога через порт 8081 (и запускать gpfdist в фоновом режиме):
gpfdist -d /var/load_files -p 8081 &Чтобы запустить gpfdist в фоновом режиме и перенаправить вывод и ошибки в файл журнала:
gpfdist -d /var/load_files -p 8081 -l /home/gpadmin/log &Чтобы остановить gpfdist, когда он работает в фоновом режиме:
- Сначала найдите его идентификатор процесса:
ps ax | grep gpfdist- Затем завершите процесс, например:
kill 3456Добавляет и/или инициализирует хост резервного мастера для системы RT.Warehouse.
gpinitstandby { -s standby_hostname [-P port] | -r | -n } [-a] [-q]
[-D] [-S standby_data_directory] [-l logfile_directory]
gpinitstandby -v
gpinitstandby -?Утилита gpinitstandby добавляет инстанс резервного мастера в вашу систему RT.Warehouse. Если в вашей системе настроен существующий инстанс резервного мастера, используйте параметр -r, чтобы удалить его перед добавлением нового инстанса резервного мастера.
Перед запуском этой утилиты убедитесь, что программное обеспечение RT.Warehouse установлено на хосте резервного мастер и что вы обменялись ключами SSH между хостами. Рекомендуется установить в качестве порта мастера один и тот же номер порта на хосте мастера и хосте резервного мастера.
Данную утилиту следует запускать на активном в данный момент хосте основного мастера.
Утилита выполняет следующие действия:
1) Обновляет системный каталог RT.Warehouse для удаления информации о существующем резервном мастере (если указан параметр -r).
2) Обновляет системный каталог RT.Warehouse, чтобы добавить информацию об инстансе нового резервного мастера.
3) Редактирует файл pg_hba.conf мастера RT.Warehouse, чтобы разрешить доступ только что добавленному резервному мастеру.
4) Устанавливает инстанс резервного мастера на альтернативном хосте мастера.
5) Запускает процесс синхронизации.
Инстанс резервного мастера служит «горячим резервом» на случай, если основной мастер перестанет работать. Резервный мастер поддерживается в актуальном состоянии с помощью процессов репликации журнала транзакций (walsender и walreceiver), которые выполняются на хостах основного мастера и резервного мастера и обеспечивают синхронизацию данных между инстансами основного и резервного мастеров. Если основной мастер выходит из строя, процесс репликации журнала завершается, а резервный мастер может быть активирован вместо него с помощью утилиты gpactivatestandby. После активации резервного мастера реплицированные журналы используются для восстановления состояния инстанса мастера на момент последней успешно зафиксированной транзакции.
Активированный резервный мастер фактически становится мастером RT.Warehouse, принимая клиентские соединения на главном порту и выполняя обычные операции мастера, такие как обработка SQL-команд и управление ресурсами.
|
Внимание. Если утилите gpinitstandby ранее не удалось инициализировать резервный мастер, перед повторным запуском gpinitstandby необходимо удалить файлы в каталоге данных резервного мастера. Каталог данных резервного мастера не очищается после сбоя инициализации, поскольку он содержит файлы журнала, которые могут помочь в определении причины сбоя. В случае сбоя инициализации в каталоге хоста резервного мастера /tmp создаётся файл сводного отчёта. В файле отчёта перечислены каталоги на хосте резервного мастера, которые необходимо очистить. |
Таблица 30 — Параметры gpinitstandby
|
Параметр |
Описание |
|---|---|
| -a | Не запрашивать у пользователя подтверждение. |
| -D | Устанавливает уровень ведения журнала для отладки. |
| -l logfile_directory | Каталог для записи файла журнала. По умолчанию ~/gpAdminLogs. |
| -n | Укажите этот параметр, чтобы запустить резервный мастер RT.Warehouse, который был настроен, но остановлен по какой-либо причине. |
| -P port | Этот параметр указывает порт, который используется резервным мастером RT.Warehouse. По умолчанию используется тот же порт, который используется активным мастером RT.Warehouse. Если резервный мастер RT.Warehouse находится на том же хосте, что и активный мастер, порты должны быть разными. Если порты для активного и резервного мастера совпадают, а хост — один и тот же, утилита возвращает ошибку. |
| -q | Работает в тихом режиме. Вывод команды не отображается на экране, но всё равно записывается в файл журнала. |
| -r | Удаляет текущий настроенный инстанс резервного мастера из вашей системы RT.Warehouse. |
| -s standby_hostname | Имя хоста резервного мастера. |
| -S standby_data_directory |
Каталог данных, который будет использоваться для нового резервного мастера. По умолчанию используется тот же каталог, что и у активного мастера. Если резервный мастер находится на том же хосте, что и активный мастер, с помощью этого параметра необходимо указать другой каталог. |
| -v | Отображает версию, статус, дату последнего обновления и контрольную сумму этой утилиты. |
| -? | Отображает интерактивную справку. |
Добавить инстанс резервного мастера в свою систему RT.Warehouse и запустить процесс синхронизации:
gpinitstandby -s host09Запустить существующий инстанс резервного мастера и синхронизировать данные с текущим инстансом мастера:
gpinitstandby -n
|
Примечание. Не указывайте параметры -n и -s в одной команде. |
Добавить инстанс резервного мастера в систему RT.Warehouse, указав другой порт:
gpinitstandby -s myhost -P 2222Если вы указываете то же имя хоста, что и у активного мастер RT.Warehouse, вы также должны указать другой номер порта с параметром -P и каталог данных резервного мастера с параметром -S.
Удалить существующий резервный мастер из конфигурации системы RT.Warehouse:
gpinitstandby -rИнициализирует систему RT.Warehouse, используя параметры конфигурации, указанные в файле gpinitsystem_config.
gpinitsystem -c cluster_configuration_file
[-h hostfile_gpinitsystem]
[-B parallel_processes]
[-p postgresql_conf_param_file]
[-s standby_master_host
[-P standby_master_port]
[-S standby_master_datadir | --standby_datadir=standby_master_datadir]]
[-m number | --max_connections=number]
[-b size | --shared_buffers=size]
[-n locale | --locale=locale] [--lc-collate=locale]
[--lc-ctype=locale] [--lc-messages=locale]
[--lc-monetary=locale] [--lc-numeric=locale]
[--lc-time=locale] [-e password | --su_password=password]
[--mirror-mode={group|spread}] [-a] [-q] [-l logfile_directory] [-D]
[-I input_configuration_file]
[-O output_configuration_file]
gpinitsystem -v | --version
gpinitsystem -? | --helpУтилита gpinitsystem создаёт инстанс RT.Warehouse или записывает входной файл конфигурации, используя значения, определённые в файле конфигурации кластера, и любые предоставленные вами параметры командной строки. См. Формат файла конфигурации инициализации для получения дополнительной информации о файле конфигурации. Перед запуском этой утилиты убедитесь, что вы установили программное обеспечение RT.Warehouse на все хосты в массиве.
С параметром -O output_configuration_file gpinitsystem не создаёт новый инстанс базы данных, а вместо этого записывает всю предоставленную информацию о конфигурации в указанный выходной файл. Этот файл использует параметры QD_PRIMARY_ARRAY и PRIMARY_ARRAY для определения каждого члена с использованием его имени хоста, порта, каталога данных, префикса сегмента, идентификатора сегмента и идентификатора содержимого. Детали конфигурации массива могут быть изменены по мере необходимости для соответствия значениям, доступным в резервной копии RT.Warehouse, или могут просто использоваться для воссоздания той же конфигурации кластера в более позднее время. Файлы конфигурации, которые используют QD_PRIMARY_ARRAY и PRIMARY_ARRAY, должны быть переданы в gpinitsystem с использованием параметра -I input_configuration_file. См. Формат файла конфигурации инициализации для получения дополнительной информации.
В СУБД RT.Warehouse каждый инстанс базы данных (мастер и все сегменты) должен быть инициализирован на всех хостах в системе таким образом, чтобы все они могли работать вместе как единая СУБД. Утилита gpinitsystem выполняет инициализацию инстансов мастера и каждого сегмента RT.Warehouse, а также настраивает систему в целом.
Перед запуском gpinitsystem вы должны установить переменную среды $GPHOME так, чтобы она указывала на расположение вашей установки RT.Warehouse на хосте мастера и обменивалась SSH-ключами между адресами всех хостов в массиве с помощью gpssh-exkeys.
Эта утилита выполняет следующие задачи:
1) Проверяет правильность параметров в файле конфигурации.
2) Обеспечивает возможность установления соединения с каждым адресом хоста. Если адрес хоста не может быть достигнут, утилита завершит работу.
3) Проверяет настройки локали.
4) Отображает конфигурацию, которая будет использоваться, и запрашивает у пользователя подтверждение.
5) Инициализирует инстанс мастера.
6) Инициализирует инстанс резервного мастера (если указан).
7) Инициализирует инстансы основных сегментов.
8) Инициализирует инстансы резервных сегментов (если настроено зеркалирование).
9) Настраивает систему RT.Warehouse и проверяет наличие ошибок.
10) Запускает систему RT.Warehouse.
|
Примечание. Данная утилита использует SSH-соединения между системами для выполнения своих задач. В больших развёртываниях RT.Warehouse, облачных развёртываниях или развёртываниях с большим количеством сегментов на хост эта утилита может превышать максимальный порог хоста для неаутентифицированных соединений. Рассмотрите возможность обновления параметра конфигурации SSH MaxStartups, чтобы увеличить этот порог. Дополнительные сведения о параметрах конфигурации SSH смотрите в документации по SSH для вашего дистрибутива Linux. |
Таблица 31 — Параметры gpinitsystem
|
Параметр |
Описание |
|---|---|
| -a | Не запрашивать у пользователя подтверждение. |
| -B parallel_processes | Количество сегментов, которые нужно создать параллельно. Если не указано иное, утилита будет запускать до 4 параллельных процессов одновременно. |
| -c cluster_configuration_file | Обязательный. Полный путь и имя файла конфигурации, который содержит все определённые параметры для настройки и инициализации новой системы RT.Warehouse. Описание этого файла см. в Формат файла конфигурации инициализации Вы должны предоставить gpinitsystem либо параметр -c cluster_configuration_file, либо параметр -I input_configuration_file. |
| -D | Устанавливает уровень вывода журнала для отладки. |
| -h hostfile_gpinitsystem | Опционально. Полный путь и имя файла, содержащего адреса хостов ваших сегментов. Если не указан в командной строке, вы можете указать файл хоста с помощью параметра MACHINE_LIST_FILE в файле gpinitsystem_config. |
| -I input_configuration_file | Полный путь и имя файла входной конфигурации, который определяет элементы и сегменты RT.Warehouse с помощью параметров QD_PRIMARY_ARRAY и PRIMARY_ARRAY. Входной файл конфигурации обычно создается с помощью gpinitsystem с параметром -O output_configuration_file. Выдолжны предоставить gpinitsystem либо параметр -c cluster_configuration_file, либо параметр -I input_configuration_file. |
| -n locale | --locale=locale |
Устанавливает языковой стандарт по умолчанию, используемый RT.Warehouse. Если не указано иное, переменная среда LC_ALL, LC_COLLATE или LANG хоста мастера определяет языковой стандарт. Если они не установлены, по умолчанию используется язык C (POSIX). Идентификатор локали состоит из идентификатора языка и идентификатора региона, а также, необязательно, кодировки набора символов. Например, sv_SE — это шведский, как говорят в Швеции, en_US — американский английский, а fr_CA — французско-канадский. Если для языкового стандарта может быть полезно более одного набора символов, тогда спецификации будут выглядеть следующим образом: en_US.UTF-8 (спецификация языкового стандарта и кодировка набора символов). В большинстве систем команда locale покажет настройки среды локали, а locale -a покажет список всех доступных локалей. |
| --lc-collate=locale | Аналогично --locale, но устанавливает языковой стандарт, используемый для сопоставления (сортировки данных). Порядок сортировки нельзя изменить после инициализации RT.Warehouse, поэтому важно выбрать локаль сопоставления, совместимую с кодировками набора символов, которые вы планируете использовать для своих данных. Существует специальное имя сопоставления C или POSIX (сортировка по порядку байтов в отличие от сортировки по словарю). Параметры сортировки C могут использоваться с любой кодировкой символов. |
| --lc-ctype=locale | Аналогично --locale, но устанавливает языковой стандарт, используемый для классификации символов (какие последовательности символов допустимы и как они интерпретируются). Это невозможно изменить после инициализации базы данных RT.Warehouse, поэтому важно выбрать языковой стандарт классификации символов, совместимый с данными, которые вы планируете хранить в RT.Warehouse. |
| --lc-messages=locale | Аналогично --locale, но устанавливает языковой стандарт, используемый для вывода сообщений RT.Warehouse. Текущая версия RT.Warehouse не поддерживает несколько языков для выходных сообщений (все сообщения на английском языке), поэтому изменение этого параметра не повлияет. |
| --lc-monetary=locale | Аналогично --locale, но устанавливает языковой стандарт, используемый для форматирования денежных сумм. |
| --lc-numeric=locale | Аналогично --locale, но устанавливает языковой стандарт, используемый для форматирования чисел. |
| --lc-time=locale | Аналогично --locale, но устанавливает языковой стандарт, используемый для форматирования даты и времени. |
| -l logfile_directory | Каталог для записи файла журнала. По умолчанию ~/gpAdminLogs. |
| -m number | --max_connections=number | Устанавливает максимальное количество клиентских подключений, разрешённых мастеру. По умолчанию — 250. |
| -O output_configuration_file | При использовании с параметром -O gpinitsystem не создаёт новый кластер RT.Warehouse, а вместо этого записывает предоставленную информацию о конфигурации кластера в указанный файл output_configuration_file. Этот файл определяет элементы и сегменты RT.Warehouse, используя параметры QD_PRIMARY_ARRAY, PRIMARY_ARRAY и MIRROR_ARRAY, и позже может использоваться с -I input_configuration_file для инициализации нового кластера. |
| -p postgresql_conf_param_file | Опционально. Имя файла, содержащего настройки параметров postgresql.conf, которые вы хотите установить для RT.Warehouse. Эти настройки будут использоваться при инициализации отдельных инстансов мастера и сегмента. Вы также можете установить параметры после инициализации с помощью утилиты gpconfig. |
| -q | Работать в тихом режиме. Вывод команды не отображается на экране, но все равно записывается в файл журнала. |
| -b size | --shared_buffers=size | Устанавливает объём памяти, который инстанс сервера RT.Warehouse использует для буферов разделяемой памяти. Вы можете указать размер в килобайтах (КБ), мегабайтах (МБ) или гигабайтах (ГБ). По умолчанию — 125 МБ. |
| -s standby_master_host | Опционально. Если вы хотите настроить инстанс резервного мастера, укажите имя хоста с помощью этого параметра. Программное обеспечение RT.Warehouse уже должно быть установлено и настроено на этом хосте. |
| -P standby_master_port | Если вы настраиваете инстанс резервного мастера с помощью -s, укажите его номер порта с помощью этого параметра. Порт по умолчанию такой же, как и главный порт. Чтобы запустить резервный мастер и основной мастер на одном хосте, вы должны использовать этот параметр, чтобы указать другой порт для резервного. Программное обеспечение RT.Warehouse уже должно быть установлено и настроено на резервном хосте. |
| -S standby_master_datadir | --standby_dir=standby_master_datadir | Если вы настраиваете хост резервного мастера с помощью -s, используйте этот параметр, чтобы указать его каталог данных. Если вы настраиваете резервный мастер на том же хосте, что и инстанс мастера, основной мастер и резервный мастер должны иметь отдельные каталоги данных. |
| -e superuser_password | --su_password=superuser_password |
Используйте этот параметр, чтобы указать пароль для учётной записи суперпользователя RT.Warehouse (например, gpadmin). Если этот параметр не указан, учётной записи суперпользователя назначается пароль по умолчанию gparray. Вы можете использовать команду ALTER ROLE, чтобы изменить пароль позже. Рекомендуемые методы безопасности:
|
| --mirror_mode={group|spread} |
Используйте этот параметр, чтобы указать размещение инстансов зеркального сегмента на хостах сегмента. По умолчанию group группирует зеркальные сегменты для всех основных сегментов хоста на одном альтернативном хосте. spread распределяет зеркальные сегменты для основных сегментов на хосте по разным хостам в массиве RT.Warehouse. Распространение разрешено только в том случае, если количество хостов превышает количество инстансов сегмента на хост. |
| -v | --version | Распечатывает версию gpinitsystem и выходит. |
| -? | --help | Показывает справку об аргументах командной строки gpinitsystem и выходит. |
gpinitsystem требуется файл конфигурации кластера со следующими определёнными параметрами. Пример файла конфигурации инициализации можно найти в $GPHOME/docs/cli_help/gpconfigs/gpinitsystem_config.
Чтобы избежать конфликтов портов между RT.Warehouse и другими приложениями, номера портов RT.Warehouse не должны находиться в диапазоне, заданном параметром операционной системы net.ipv4.ip_local_port_range. Например, если net.ipv4.ip_local_port_range = 10000 65535, вы можете установить эти значения для номеров базовых портов RT.Warehouse.
PORT_BASE = 6000
MIRROR_PORT_BASE = 7000Таблица 32 — Параметры gpinitsystem_config
|
Параметр |
Описание |
|---|---|
| ARRAY_NAME | Обязательный. Имя настраиваемого массива. Вы можете использовать любое имя, какое захотите. Заключите имя в кавычки, если имя содержит пробелы. |
| MACHINE_LIST_FILE | Опционально. Может использоваться вместо параметра -h. Параметр указывает на файл, содержащий список имён хостов сегментов, составляющих систему RT.Warehouse. Предполагается, что хостом мастера является хост, с которого вы запускаете утилиту, и его не следует включать в этот файл. Если хосты вашего сегмента имеют несколько сетевых интерфейсов, этот файл будет включать все адреса хоста. Укажите абсолютный путь к файлу. |
| SEG_PREFIX | Обязательный. Параметр указывает префикс, который будет использоваться для именования каталогов данных на инстансах мастера и сегмента. Соглашение об именах каталогов данных в системе RT.Warehouse — SEG_PREFIXnumber, где number начинается с 0 для инстансов сегмента (мастер всегда -1). Так, например, если вы выберете префикс gpseg, каталог данных вашего инстанса мастера будет называться gpseg-1, а инстансы сегментов будут называться gpseg0, gpseg1, gpseg2, gpseg3 и так далее. |
| PORT_BASE | Обязательный. Параметр указывает базовое число, по которому вычисляются номера портов основного сегмента. Порт первого основного сегмента на хосте устанавливается как PORT_BASE, а затем увеличивается на единицу для каждого дополнительного основного сегмента на этом хосте. Допустимые значения от 1 до 65535. |
| DATA_DIRECTORY |
Обязательный. Здесь указываются места хранения данных, в которых утилита будет создавать каталоги данных основных сегментов. Количество местоположений в списке определяет количество основных сегментов, которые будут созданы для каждого физического хоста (если в файле хоста указано несколько адресов хоста, количество сегментов будет равномерно распределено по указанным адресам интерфейса). Можно указать одну и ту же область хранения данных несколько раз, если вы хотите, чтобы каталоги данных создавались в одном месте. Пользователь, который запускает gpinitsystem (например, пользователь gpadmin), должен иметь разрешение на запись в эти каталоги. Например, создать шесть основных сегментов для каждого хоста:
|
| MASTER_HOSTNAME | Обязательный. Имя хоста инстанса мастера. Это имя хоста должно точно совпадать с настроенным именем хоста машины (запустите команду hostname, чтобы определить правильное имя хоста). |
| MASTER_DIRECTORY | Обязательный. Параметр указывает место, где будет создан каталог данных на хосте мастера. Вы должны убедиться, что у пользователя, запускающего gpinitsystem (например, пользователя gpadmin), есть права на запись в этот каталог. |
| MASTER_PORT | Обязательный. Номер порта для инстанса мастера. Это номер порта, который пользователи и клиентские соединения будут использовать при доступе к системе RT.Warehouse. |
| TRUSTED_SHELL | Обязательный. Оболочка, которую утилита gpinitsystem использует для выполнения команд на удалённых хостах. Допустимые значения: ssh. Перед запуском утилиты gpinitsystem необходимо настроить среду доверенного хоста (для этого можно использовать gpssh-exkeys). |
| CHECK_POINT_SEGMENTS | Обязательный. Максимальное расстояние между контрольными точками журнала автоматической записи (WAL) в сегментах файла журнала (каждый сегмент обычно составляет 16 мегабайт). Это установит параметр checkpoint_segments в файле postgresql.conf для каждого инстанса сегмента в системе RT.Warehouse. |
| ENCODING | Обязательный. Используемая кодировка набора символов. Этот набор символов должен быть совместим с используемыми настройками --locale, особенно --lc-collate и --lc-ctype. RT.Warehouse поддерживает те же наборы символов, что и PostgreSQL. |
| DATABASE_NAME | Опционально. Имя базы данных RT.Warehouse, создаваемой после инициализации системы. Вы всегда можете создать базу данных позже, используя команду CREATE DATABASE или утилиту createdb. |
| MIRROR_PORT_BASE | Опционально. Параметр указывает базовый номер, по которому вычисляются номера портов зеркального сегмента. Порт первого зеркального сегмента на хосте устанавливается как MIRROR_PORT_BASE, а затем увеличивается на единицу для каждого дополнительного зеркального сегмента на этом хосте. Допустимые значения находятся в диапазоне от 1 до 65535 и не могут конфликтовать с портами, рассчитанными с помощью PORT_BASE. |
| MIRROR_DATA_DIRECTORY |
Опционально. Здесь указываются места хранения данных, где утилита будет создавать каталоги данных зеркальных сегментов. Для инстансов зеркального сегмента должно быть объявлено такое же количество каталогов данных, что и для инстансов основного сегмента (см. параметр DATA_DIRECTORY). Пользователь, который запускает gpinitsystem (например, пользователь gpadmin), должен иметь разрешение на запись в эти каталоги. Например:
|
| QD_PRIMARY_ARRAY, PRIMARY_ARRAY, MIRROR_ARRAY |
Эти параметры могут быть предоставлены только с использованием входного файла конфигурации с параметром gpinitsystem -I input_configuration_file. QD_PRIMARY_ARRAY, PRIMARY_ARRAY и MIRROR_ARRAY определяют хост мастера RT.Warehouse, а также основной и зеркальный инстансы на хостах сегмента, соответственно, используя формат: Мастер RT.Warehouse всегда использует значение -1 для идентификатора сегмента и идентификатора содержимого. Например: Вы можете использовать gpinitsystem -O output_configuration_file для заполненияQD_PRIMARY_ARRAY, PRIMARY_ARRAY, MIRROR_ARRAY с использованием хостов, каталогов данных, префикса сегмента и значений базового порта, которые вы предоставляете команде. В целях восстановления вы можете изменить идентификаторы сегмента и контента, чтобы они соответствовали значениям существующей резервной копии RT.Warehouse. |
| HEAP_CHECKSUM | Рпционально. Этот параметр определяет, использует ли gpinitsystem IP-адреса или имена хостов в файле pg_hba.conf при обновлении файла с адресами, которые могут подключаться к RT.Warehouse. Значение по умолчанию — 0, т.е. утилита использует IP-адреса при обновлении файла. При инициализации системы RT.Warehouse укажите HBA_HOSTNAMES = 1, чтобы утилита использовала имена хостов в файле pg_hba.conf. |
Инициализировать массив RT.Warehouse, предоставив файл конфигурации кластера и файл адреса хоста сегмента, и настроить конфигурацию зеркального распределённого отображения (--mirror-mode = spread):
$ gpinitsystem -c gpinitsystem_config -h hostfile_gpinitsystem --mirror-mode=spreadИнициализировать массив RT.Warehouse и установить удалённый пароль суперпользователя:
$ gpinitsystem -c gpinitsystem_config -h hostfile_gpinitsystem --su-password=mypasswordИнициализировать массив RT.Warehouse с дополнительным хостом резервного мастера:
$ gpinitsystem -c gpinitsystem_config -h hostfile_gpinitsystem -s host09Вместо инициализации массива RT.Warehouse записать предоставленную конфигурацию в выходной файл. Выходной файл использует параметры QD_PRIMARY_ARRAY и PRIMARY_ARRAY для определения хостов мастера и сегментов:
$ gpinitsystem -c gpinitsystem_config -h hostfile_gpinitsystem --mirror-mode=spread –O cluster_init.configИнициализировать RT.Warehouse, используя входной файл конфигурации (файл, который определяет массив RT.Warehouse), используя параметры QD_PRIMARY_ARRAY и PRIMARY_ARRAY:
$ gpinitsystem -I cluster_init.configВыполняет задание загрузки, как определено в файле управления в формате YAML.
gpload -f control_file [-l log_file] [-h hostname] [-p port]
[-U username] [-d database] [-W] [--gpfdist_timeout seconds]
[--no_auto_trans] [[-v | -V] [-q]] [-D]
gpload -?
gpload --versionКлиентская машина, на которой выполняется gpload, должна иметь следующее:
1) Python 2.6.2 или более новую версию, pygresql (интерфейс Python для PostgreSQL) и pyyaml. Обратите внимание, что Python и необходимые библиотеки Python включены в установку сервера RT.Warehouse, поэтому, если на машине, на которой выполняется gpload, установлена RT.Warehouse, отдельная установка Python не требуется.
|
Примечание. Загрузчики RT.Warehouse для Windows поддерживают только Python 2.5 (доступен по адресу https://www.python.org). |
2) Программа параллельного распределения файлов gpfdist установлена и находится в вашей $PATH. Данная программа находится в каталоге $GPHOME/bin вашего сервера RT.Warehouse.
3) Сетевой доступ ко всем хостам в массиве RT.Warehouse (мастер и сегменты) и от них.
4) Сетевой доступ к хостам, на которых находятся загружаемые данные (ETL-серверы), и от них.
gpload — это утилита загрузки данных, которая действует как интерфейс для функции параллельной загрузки внешней таблицы RT.Warehouse. Используя спецификацию загрузки, определённую в файле управления в формате YAML, gpload выполняет загрузку, вызывая параллельный файловый сервер RT.Warehouse (gpfdist), создавая определение внешней таблицы на основе определённых исходных данных и выполняя операцию INSERT, UPDATE или MERGE для загрузки исходных данных в целевую таблицу в базе данных.
|
Примечание. gpfdist и gpload совместимы только с основной версией RT.Warehouse, в которой они поставляются. Например, утилита gpfdist, установленная с RT.Warehouse 4.x, не может использоваться с RT.Warehouse 5.x или 6.x. |
|
Примечание. Операции MERGE и UPDATE не поддерживаются, если имя столбца целевой таблицы является зарезервированным ключевым словом, имеет заглавные буквы или включает любой символ, требующий кавычек ("") для идентификации столбца. |
Операция, включая любые SQL-команды, указанные в SQL-коллекции управляющего файла YAML (см. Формат файла управления), выполняется как одна транзакция, чтобы предотвратить несогласованность данных при выполнении нескольких одновременных операций загрузки в целевой таблице.
Таблица 33 — Параметры gpload
|
Параметр |
Описание |
|---|---|
| -f control_file | Обязательный. Файл YAML, содержащий подробные сведения о спецификации загрузки. См. Формат файла управления. |
| --gpfdist_timeout seconds | Устанавливает тайм-аут для программы параллельного распределения файлов gpfdist для отправки ответа. Введите значение от 0 до 30 секунд (значение 0 отключает таймауты). Обратите внимание, что вам может потребоваться увеличить это значение при работе в сетях с высоким трафиком. |
| -l log_file | Указывает, куда записывать файл журнала. По умолчанию ~/gpAdminLogs/gpload_YYYYMMDD. Дополнительные сведения о файле журнала см. Формат файла журнала. |
| --no_auto_trans |
Укажите --no_auto_trans, чтобы отключить обработку операции загрузки как одной транзакции, если вы выполняете одну операцию загрузки в целевой таблице. По умолчанию gpload обрабатывает каждую операцию загрузки как одну транзакцию, чтобы предотвратить несогласованность данных при выполнении нескольких одновременных операций над целевой таблицей. |
| -q | Работать в тихом режиме. Вывод команды не отображается на экране, но все равно записывается в файл журнала. |
| -D | Проверка наличия ошибок без выполнения загрузки. |
| -v | Показать подробный (verbose) вывод шагов загрузки по мере их выполнения. |
| -V | Показывает очень подробный (very verbose) вывод. |
| -? | Показать справку, затем выйти. |
| --version | Показать версию этой утилиты, затем выйти. |
Таблица 34 — Параметры подключения gpload
|
Параметр |
Описание |
|---|---|
| -d database | База данных для загрузки. Если параметр не указан, читает значение из файла управления загрузкой, переменной среды $PGDATABASE или по умолчанию используется текущее имя пользователя системы. |
| -h hostname | Задаёт имя хоста машины, на которой работает сервер мастера базы данных RT.Warehouse. Если параметр не указан, читает значение из файла управления загрузкой, переменной среды $PGHOST или по умолчанию localhost. |
| -p port | Задаёт TCP-порт, на котором сервер мастера базы данных RT.Warehouse прослушивает соединения. Если параметр не указан, значение считывается из файла управления загрузкой, переменной среды $PGPORT или по умолчанию 5432. |
| -U username | Имя роли базы данных для подключения. Если параметр не указан, значение считывается из файла управления загрузкой, переменной среды $PGUSER или по умолчанию используется имя текущего пользователя системы. |
| -W | Принудительный ввод пароля. Если параметр не указан, считывает пароль из переменной среды $PGPASSWORD или из файла паролей, указанного в $PGPASSFILE или в ~/.pgpass. Если они не установлены, gpload запросит пароль, даже если -W не указан. |
Управляющий файл gpload использует формат документа YAML 1.1, а затем реализует свою собственную схему для определения различных этапов операции загрузки RT.Warehouse. Контрольный файл должен быть действующим документом YAML.
Программа gpload обрабатывает документ управляющего файла по порядку и использует отступы (пробелы) для определения иерархии документа и отношений разделов друг с другом. Использование белого пространства имеет большое значение. Пробелы не должны использоваться просто для форматирования, а табуляции вообще не должны использоваться.
Базовая структура файла управления загрузкой:
---
VERSION: 1.0.0.1
DATABASE: db_name
USER: db_username
HOST: master_hostname
PORT: master_port
GPLOAD:
INPUT:
- SOURCE:
LOCAL_HOSTNAME:
- hostname_or_ip
PORT: http_port
| PORT_RANGE: [start_port_range, end_port_range]
FILE:
- /path/to/input_file
SSL: true | false
CERTIFICATES_PATH: /path/to/certificates
- FULLY_QUALIFIED_DOMAIN_NAME: true | false
- COLUMNS:
- field_name: data_type
- TRANSFORM: 'transformation'
- TRANSFORM_CONFIG: 'configuration-file-path'
- MAX_LINE_LENGTH: integer
- FORMAT: text | csv
- DELIMITER: 'delimiter_character'
- ESCAPE: 'escape_character' | 'OFF'
- NULL_AS: 'null_string'
- FORCE_NOT_NULL: true | false
- QUOTE: 'csv_quote_character'
- HEADER: true | false
- ENCODING: database_encoding
- ERROR_LIMIT: integer
- LOG_ERRORS: true | false
EXTERNAL:
- SCHEMA: schema | '%'
OUTPUT:
- TABLE: schema.table_name
- MODE: insert | update | merge
- MATCH_COLUMNS:
- target_column_name
- UPDATE_COLUMNS:
- target_column_name
- UPDATE_CONDITION: 'boolean_condition'
- MAPPING:
target_column_name: source_column_name | 'expression'
PRELOAD:
- TRUNCATE: true | false
- REUSE_TABLES: true | false
- STAGING_TABLE: external_table_name
- FAST_MATCH: true | false
SQL:
- BEFORE: "sql_command"
- AFTER: "sql_command"Таблица 35 — Параметры файла управления gpload
|
№ |
Параметр |
Описание |
|---|---|---|
| 1 | VERSION | Опционально. Версия схемы файла управления gpload. Текущая версия — 1.0.0.1. |
| 2 | DATABASE | Опционально. Указывает, к какой базе данных в системе RT.Warehouse подключиться. Если параметр не указан, по умолчанию используется $PGDATABASE, если установлено, или текущее имя пользователя системы. Вы также можете указать базу данных в командной строке, используя параметр -d. |
| 3 | USER |
Опционально. Указывает, какую роль базы данных использовать для подключения. Если параметр не указан, по умолчанию используется текущий пользователь или $PGUSER, если установлено. Вы также можете указать роль базы данных в командной строке, используя параметр -U. Если пользователь, запускающий gpload, не является суперпользователем RT.Warehouse, тогда ему должны быть предоставлены соответствующие права для обработки нагрузки. |
| 4 | HOST | Опционально. Задаёт имя хоста мастера RT.Warehouse. Если параметр не указан, по умолчанию используется localhost или $PGHOST, если установлено. Вы также можете указать имя хоста мастера в командной строке, используя параметр -h. |
| 5 | PORT | Опционально. Задаёт порт мастера RT.Warehouse. Если параметр не указан, по умолчанию 5432 или $PGPORT, если установлено. Вы также можете указать порт мастера в командной строке, используя параметр -p. |
| 6 | GPLOAD | Обязательный. Начинает раздел спецификации загрузки. В спецификации GPLOAD должны быть определены разделы INPUT и OUTPUT. |
| 6.1 | INPUT | Обязательный. Определяет расположение и формат загружаемых входных данных. gpload запустит один или несколько инстансов программы распределения файлов gpfdist на текущем хосте и создаст необходимые определения внешних таблиц в RT.Warehouse, которые указывают на исходные данные. Обратите внимание, что хост, с которого вы запускаете gpload, должен быть доступен по сети для всех хостов RT.Warehouse (мастера и сегментов). |
| 6.1.1 | SOURCE | Обязательный. Блок SOURCE спецификации INPUT определяет расположение исходного файла. В разделе INPUT может быть определено более одного блока SOURCE. Каждый определённый блок SOURCE соответствует одному инстансу программы распределения файлов gpfdist, которая будет запущена на локальной машине. Каждый определённый блок SOURCE должен иметь спецификацию FILE. |
| 6.1.1.1 | LOCAL_HOSTNAME | Опционально. Задаёт имя хоста или IP-адрес локальной машины, на которой работает gpload. Если эта машина сконфигурирована с несколькими сетевыми интерфейсными картами (NIC), вы можете указать имя хоста или IP-адрес каждой отдельной NIC, чтобы разрешить сетевому трафику использовать все NIC одновременно. По умолчанию используется только имя основного хоста или IP-адрес локальной машины. |
| 6.1.1.2 | PORT | Опционально. Задаёт конкретный номер порта, который должна использовать программа распределения файлов gpfdist. Вы также можете указать PORT_RANGE, чтобы выбрать доступный порт из указанного диапазона. Если определены и PORT, и PORT_RANGE, приоритет имеет PORT. Если ни PORT, ни PORT_RANGE не определены, по умолчанию выбирается доступный порт между 8000 и 9000. Если в LOCAL_HOSTNAME объявлено несколько имён хостов, этот номер порта используется для всех хостов. Эта конфигурация желательна, если вы хотите использовать все сетевые адаптеры для загрузки одного и того же файла или набора файлов в заданном месте каталога. |
| 6.1.1.3 | PORT_RANGE | Опционально. Может использоваться вместо PORT для предоставления диапазона номеров портов, из которых gpload может выбрать доступный порт для этого инстанса программы рапределения файлов gpfdist. |
| 6.1.1.4 | FILE | Обязательный. Задаёт расположение файла, именованного канала или каталога в локальной файловой системе, который содержит данные для загрузки. Вы можете объявить более одного файла, если данные имеют один и тот же формат во всех указанных файлах. Если файлы сжаты с использованием gzip или bzip2 (имеют расширение файла .gz или .bz2), файлы будут автоматически распакованы (при условии, что на вашем пути есть gunzip или bunzip2). При указании исходных файлов для загрузки вы можете использовать подстановочный знак (*) или другое сопоставление с образцом в стиле C для обозначения нескольких файлов. Предполагается, что указанные файлы относятся к текущему каталогу, из которого выполняется gpload (или вы можете объявить абсолютный путь). |
| 6.1.1.5 | SSL | Опционально. Указывает использование SSL-шифрования. Если для SSL установлено значение true, gpload запускает сервер gpfdist с параметром --ssl и использует протокол gpfdists://. |
| 6.1.1.6 | CERTIFICATES_PATH |
Требуется, если для SSL значение true; не может быть указан, если SSL имеет значение false или unspecified. Местоположение, указанное в CERTIFICATES_PATH, должно содержать следующие файлы: - Файл сертификата сервера server.crt. - Файл закрытого ключа сервера server.key. - Доверенные центры сертификации root.crt. Корневой каталог (/) не может быть указан как CERTIFICATES_PATH. |
| 6.1.2 | FULLY_QUALIFIED_DOMAIN_NAME | Опционально. Указывает, разрешает ли gpload для имён хостов полное доменное имя (FQDN) или локальное имя хоста. Если установлено значение true, для имён разрешается полное доменное имя. Если установлено значение false, разрешается локальное имя хоста. По умолчанию — false. В некоторых ситуациях может потребоваться полное доменное имя. Например, если система RT.Warehouse находится в другом домене, чем приложение ETL, к которому обращается gpload. |
| 6.1.3 | COLUMNS | Опционально. Задаёт схему файла(ов) исходных данных в формате field_name:data_type. Символ DELIMITER в исходном файле разделяет два поля (столбца) значений данных. Строка определяется символом перевода строки (0x0a). Если входные COLUMNS не указаны, то подразумевается схема выходной TABLE, что означает, что исходные данные должны иметь тот же порядок столбцов, количество столбцов и формат данных, что и целевая таблица. Отображение источника и цели по умолчанию основано на совпадении имён столбцов, как определено в этом разделе, и имён столбцов в целевой TABLE. Это сопоставление по умолчанию можно переопределить с помощью раздела MAPPING. |
| 6.1.4 | TRANSFORM | Опционально. Задаёт имя входного преобразования, передаваемого в gpload. |
| 6.1.5 | TRANSFORM_CONFIG | Требуется, если указан TRANSFORM. Задаёт расположение файла конфигурации преобразования, указанного выше в параметре TRANSFORM. |
| 6.1.6 | MAX_LINE_LENGTH | Опционально. Целое число, указывающее максимальную длину строки в данных преобразования XML, передаваемых в gpload. |
| 6.1.7 | FORMAT | Опционально. Задаёт формат файла(ов) исходных данных — обычный текст (TEXT) или формат значений, разделённых запятыми (CSV). Если не указано иное, по умолчанию используется TEXT. |
| 6.1.8 | DELIMITER | Опционально. Задаёт один символ ASCII, разделяющий столбцы в каждой строке данных. По умолчанию в режиме TEXT используется символ табуляции, в режиме CSV — запятая. Вы также можете указать непечатаемый символ ASCII или непечатаемый символ Юникода, например: "\x1B" или "\u001B". Синтаксис escape-строки, E'character-code', также поддерживается для непечатаемых символов. Символ ASCII или Unicode необходимо заключать в одинарные кавычки. Например: E'\x1B' или E'\u001B'. |
| 6.1.9 | ESCAPE | Задаёт одиночный символ, который используется для escape-последовательностей C (например, \n, \t, \100 и т.д.) И для escape-символов данных, которые в противном случае могли бы быть приняты как разделители строк или столбцов. Обязательно выберите escape-символ, который нигде не используется в ваших фактических данных столбца. Escape-символ по умолчанию \ (обратная косая черта) для файлов в текстовом формате и " (двойная кавычка) для файлов в формате CSV, однако можно указать другой символ для escape-представления. Также можно отключить escape в текст-форматированные файлы, указав в качестве escape-значения значение "OFF" .Это очень полезно для данных, таких как текстовые данные веб-журнала, которые содержат множество встроенных обратных косых черт, которые не предназначены для использования в качестве escape-символов. |
| 6.1.10 | NULL_AS | Опционально. Задаёт строку, представляющую нулевое значение. По умолчанию в режиме TEXT используется \N (обратная косая черта-N), а в режиме CSV — пустое значение без кавычек. Вы можете предпочесть пустую строку даже в режиме TEXT для случаев, когда вы не хотите отличать нули от пустых строк. Любой элемент данных источника, соответствующий этой строке, будет считаться нулевым значением. |
| 6.1.11 | FORCE_NOT_NULL | Опционально. В режиме CSV обрабатывает каждый указанный столбец так, как если бы он был заключен в кавычки и, следовательно, не имел значения NULL. Для нулевой строки по умолчанию в режиме CSV (ничего между двумя разделителями) это приводит к тому, что отсутствующие значения оцениваются как строки нулевой длины. |
| 6.1.11 | QUOTE | Требуется, если FORMAT имеет значение CSV. Задаёт кавычки для режима CSV. По умолчанию используется двойная кавычка ("). |
| 6.1.12 | HEADER | Опционально. Указывает, что первая строка в файле(ах) данных является строкой заголовка (содержит имена столбцов) и не должна включаться в качестве данных для загрузки. При использовании нескольких файлов источников данных все файлы должны иметь строку заголовка. По умолчанию предполагается, что входные файлы не имеют строки заголовка. |
| 6.1.13 | ENCODING |
Опционально. Кодировка набора символов исходных данных. Укажите строковую константу (например, 'SQL_ASCII'), целочисленный номер кодировки или 'DEFAULT', чтобы использовать клиентскую кодировку по умолчанию. Если не указано, используется клиентская кодировка по умолчанию. Примечание. Если вы измените значение ENCODING в существующем файле управления gpload, вы должны вручную удалить все внешние таблицы, которые создавались с использованием предыдущей конфигурации ENCODING. gpload не удаляет и не воссоздает внешние таблицы для использования нового ENCODING, если REUSE_TABLES имеет значение true. |
| 6.1.14 | ERROR_LIMIT | Опционально. Включает режим изоляции ошибок одной строки для этой операции загрузки. Если этот параметр включён, входные строки с ошибками формата будут отброшены при условии, что предельное количество ошибок не достигнуто ни в одном инстансе сегмента RT.Warehouse во время обработки ввода. Если предел ошибок не достигнут, все исправные строки будут загружены, а все строки с ошибками будут либо отброшены, либо захвачены как часть информации журнала ошибок. По умолчанию операция загрузки прерывается при первой обнаруженной ошибке. Обратите внимание, что изоляция ошибок одной строки применяется только к строкам данных с ошибками формата; например, лишние или отсутствующие атрибуты, атрибуты неправильного типа данных или недопустимые клиентские последовательности кодирования. Ошибки ограничений, такие как нарушения первичного ключа, все равно будут вызывать прерывание операции загрузки, если они встречаются. |
| 6.1.15 | LOG_ERRORS |
Опционально, если объявлен ERROR_LIMIT. Значение может быть true или false. Значение по умолчанию — false. Если значение true, строки с ошибками форматирования регистрируются во внутреннем журнале при работе в режиме изоляции ошибок одной строки. Вы можете проверить ошибки форматирования с помощью встроенной SQL-функции RT.Warehouse gp_read_error_log('table_name'). Если при загрузке данных обнаруживаются ошибки форматирования, gpload генерирует предупреждающее сообщение с именем таблицы, которая содержит информацию об ошибке, аналогичную этому сообщению. Если указан LOG_ERRORS: true, необходимо указать REUSE_TABLES: true, чтобы ошибки форматирования сохранялись в журналах ошибок RT.Warehouse. Если REUSE_TABLES: true не указано, информация об ошибке удаляется после операции gpload. Возвращается только сводная информация об ошибках форматирования. Вы можете удалить ошибки форматирования из журналов ошибок с помощью функции RT.Warehouse gp_truncate_error_log(). Примечание. Когда gpfdist считывает данные и обнаруживает ошибку форматирования данных, сообщение об ошибке включает номер строки, указывающий местонахождение ошибки форматирования. gpfdist пытается захватить строку, содержащую ошибку. Однако gpfdist может не захватить точную строку для некоторых ошибок форматирования. |
| 6.1.16 | EXTERNAL | Опционально. Определяет схему объектов базы данных внешних таблиц, созданных gpload. По умолчанию используется search_path RT.Warehouse. |
| 6.1.16.1 | SCHEMA | Требуется при объявлении EXTERNAL. Имя схемы внешней таблицы. Если схема не существует, возвращается ошибка. Если указан % (символ процента), используется схема имени таблицы, заданная параметром TABLE в разделе OUTPUT. Если в имени таблицы не указана схема, используется схема по умолчанию. |
| 6.2 | OUTPUT | Обязательный. Определяет значения целевой таблицы и конечных столбцов данных, которые должны быть загружены в базу данных. |
| 6.2.1 | TABLE | Обязательный. Имя целевой таблицы для загрузки. |
| 6.2.2 | MODE |
Опционально. Если не указано иное, по умолчанию используется INSERT. Доступны три режима загрузки: - INSERT — загружает данные в целевую таблицу, используя следующий метод: - UPDATE — обновляет UPDATE_COLUMNS целевой таблицы, в которой строки имеют значения атрибута MATCH_COLUMNS, равные значениям атрибута входных данных, а необязательный UPDATE_CONDITION имеет значение true. UPDATE не поддерживается, если имя столбца целевой таблицы является зарезервированным ключевым словом, имеет заглавные буквы или включает любой символ, требующий кавычек ("") для идентификации столбца; - MERGE — вставляет новые строки и обновляет UPDATE_COLUMNS существующих строк, где значения атрибута FOOBAR равны значениям входных данных, а необязательный MATCH_COLUMNS равен true. Новые строки идентифицируются, когда значение MATCH_COLUMNS в исходных данных не имеет соответствующего значения в существующих данных целевой таблицы. В этих случаях вставляется вся строка из исходного файла, а не только столбцы MATCH и UPDATE. Если есть несколько новых значений MATCH_COLUMNS, которые совпадают, будет вставлена только одна новая строка для этого значения. Используйте UPDATE_CONDITION, чтобы отфильтровать строки, которые нужно отбросить. MERGE не поддерживается, если имя столбца целевой таблицы является зарезервированным ключевым словом, имеет заглавные буквы или включает любой символ, требующий кавычек ("") для идентификации столбца. |
| 6.2.3 | MATCH_COLUMNS | Требуется, если MODE имеет значения UPDATE или MERGE. Задаёт столбцы, используемые в качестве условия соединения для обновления. Значение атрибута в указанном целевом столбце(ах) должно быть равно значению соответствующего столбца(ов) исходных данных, чтобы строка в целевой таблице была обновлена. |
| 6.2.4 | UPDATE_COLUMNS | Требуется, если MODE имеет значения UPDATE или MERGE. Задаёт столбцы для обновления для строк, которые соответствуют критерию MATCH_COLUMNS и необязательному UPDATE_CONDITION. |
| 6.2.5 | UPDATE_CONDITION | Опционально. Задаёт логическое условие (аналогичное тому, которое вы бы объявили в предложении WHERE), которое должно быть выполнено, чтобы строка в целевой таблице была обновлена (или вставлена в случае MERGE). |
| 6.2.6 | MAPPING |
Опционально. Если сопоставление указано, оно переопределяет сопоставление столбцов источника и назначения по умолчанию. Отображение источника и назначения по умолчанию основано на совпадении имён столбцов, как определено в разделе исходных COLUMNS, и имён столбцов целевой TABLE. Отображение задаётся как: или Где expression — это любое выражение, которое вы должны указать в списке SELECT запроса, например постоянное значение, ссылка на столбец, вызов оператора, вызов функции и прочее. |
| 7 | PRELOAD | Опционально. Задаёт операции, выполняемые перед операцией загрузки. Сейчас единственная операция предварительной загрузки — TRUNCATE. |
| 7.1 | TRUNCATE | Опционально. Если установлено значение true, gpload удалит все строки в целевой таблице перед её загрузкой. По умолчанию — false. |
| 7.2 | REUSE_TABLES | Опционально. Если установлено значение true, gpload не будет отбрасывать объекты внешних таблиц и объекты промежуточных таблиц, которые он создаёт. Эти объекты будут повторно использоваться для будущих операций загрузки, использующих те же спецификации загрузки. Это улучшает производительность непрерывных загрузок (текущих небольших загрузок в одну и ту же целевую таблицу). Если задано значение LOG_ERRORS: true, необходимо указать REUSE_TABLES: true, чтобы ошибки форматирования сохранялись в журналах ошибок RT.Warehouse. Если REUSE_TABLES: true не указано, информация об ошибке форматирования удаляется после операции gpload. Если external_table_name существует, утилита использует существующую таблицу. Утилита возвращает ошибку, если схема таблицы не соответствует схеме таблицы OUTPUT. |
| 7.3 | STAGING_TABLE |
Опционально. Укажите имя временной внешней таблицы, которая создается во время операции gpload. Внешняя таблица используется gpfdist. REUSE_TABLES: true также необходимо указать. Если REUSE_TABLES false или не указано, STAGING_TABLE игнорируется. По умолчанию gpload создаёт временную внешнюю таблицу со случайно сгенерированным именем. Если external_table_name содержит точку (.), gpload возвращает ошибку. Если таблица существует, утилита использует её. Утилита возвращает ошибку, если существующая схема таблицы не соответствует схеме таблицы OUTPUT. Утилита использует значение SCHEMA в разделе EXTERNAL как схему для external_table_name. Если значение SCHEMA равно %, схема для external_table_name такая же, как схема целевой таблицы, схема TABLE в разделе OUTPUT. Если SCHEMA не установлен, утилита выполняет поиск таблицы (используя схемы в базе данных search_path). Если таблица не найдена, в схеме PUBLIC по умолчанию создаётся external_table_name. |
| 7.4 | FAST_MATCH |
Опционально. Если установлено значение true, gpload ищет в базе данных соответствующие объекты внешних таблиц только при повторном использовании внешних таблиц. Утилита не проверяет имена столбцов внешней таблицы и типы столбцов в таблице каталога pg_attribute, чтобы гарантировать, что таблица может использоваться для операции gpload. Установите значение true, чтобы повысить производительность gpload при повторном использовании объектов внешней таблицы, а таблица каталога базы данных pg_attribute содержит большое количество строк. Утилита возвращает ошибку и завершает работу, если определения столбцов несовместимы. Значение по умолчанию — false, утилита проверяет имена столбцов определения внешней таблицы и типы столбцов. REUSE_TABLES: true также необходимо указать. Если REUSE_TABLES имеет значение false или не указано, а параметр FAST_MATCH: true указан, gpload возвращает предупреждающее сообщение. |
| 8 | SQL | Опционально. Определяет команды SQL для запуска до и/или после операции загрузки. Вы можете указать несколько команд BEFORE и/или AFTER. Перечислите команды в желаемом порядке выполнения. |
| 8.1 | BEFORE | Опционально. Команда SQL, выполняемая перед началом операции загрузки. Заключите команды в кавычки. |
| 8.2 | AFTER | Опционально. Команда SQL, запускаемая после завершения операции загрузки. Заключите команды в кавычки. |
Файлы журнала, выводимые gpload, имеют следующий формат:
timestamp|level|messageГде timestamp имеет вид: YYYY-MM-DD HH:MM:SS, level — это одно из DEBUG, LOG, INFO, ERROR, а message — обычное текстовое сообщение.
Некоторые сообщения INFO, которые могут представлять интерес в файлах журнала (где # соответствует фактическому количеству секунд, единицам данных или ошибочным строкам):
INFO|running time: #.## seconds
INFO|transferred #.# kB of #.# kB.
INFO|gpload succeeded
INFO|gpload succeeded with warnings
INFO|gpload failed
INFO|1 bad row
INFO|# bad rowsЕсли имена объектов вашей базы данных были созданы с использованием идентификатора, заключенного в двойные кавычки (идентификатора с разделителями), вы должны указать имя с разделителями в одинарных кавычках в управляющем файле gpload. Например, если вы создаёте таблицу следующим образом:
CREATE TABLE "MyTable" ("MyColumn" text);Ваш файл управления gpload в формате YAML будет ссылаться на приведённые выше имена таблиц и столбцов следующим образом:
- COLUMNS:
- '"MyColumn"': text
OUTPUT:
- TABLE: public.'"MyTable"'Если управляющий файл YAML содержит элемент ERROR_TABLE, который был доступен в RT.Warehouse 4.3.x, gpload регистрирует предупреждение о том, что ERROR_TABLE не поддерживается, а ошибки загрузки обрабатываются, как если бы для элементов LOG_ERRORS и REUSE_TABLE было установлено значение true. Строки с ошибками форматирования регистрируются во внутреннем журнале при работе в режиме изоляции ошибок одной строки.
Запустить задание загрузки, как определено в my_load.yml:
gpload -f my_load.ymlПример файла управления загрузкой:
---
VERSION: 1.0.0.1
DATABASE: ops
USER: gpadmin
HOST: mdw-1
PORT: 5432
GPLOAD:
INPUT:
- SOURCE:
LOCAL_HOSTNAME:
- etl1-1
- etl1-2
- etl1-3
- etl1-4
PORT: 8081
FILE:
- /var/load/data/*
- COLUMNS:
- name: text
- amount: float4
- category: text
- descr: text
- date: date
- FORMAT: text
- DELIMITER: '|'
- ERROR_LIMIT: 25
- LOG_ERRORS: true
OUTPUT:
- TABLE: payables.expenses
- MODE: INSERT
PRELOAD:
- REUSE_TABLES: true
SQL:
- BEFORE: "INSERT INTO audit VALUES('start', current_timestamp)"
- AFTER: "INSERT INTO audit VALUES('end', current_timestamp)"Ищет указанные записи в файлах журнала RT.Warehouse.
gplogfilter [timestamp_options] [pattern_options]
[output_options] [input_options] [input_file]
gplogfilter --help
gplogfilter --versionУтилиту gplogfilter можно использовать для поиска в файле журнала RT.Warehouse записей, соответствующих указанным критериям. Если входной файл не предоставлен, то gplogfilter будет использовать переменную среды $MASTER_DATA_DIRECTORY, чтобы найти файл журнала мастера RT.Warehouse в стандартном месте ведения журнала. Для чтения из стандартного ввода используйте тире (-) в качестве имени входного файла. Входные файлы могут быть сжаты с помощью gzip. Во входном файле запись журнала идентифицируется своей меткой времени в формате YYYY-MM-DD [hh:mm[:ss]].
Вы также можете использовать gplogfilter для поиска сразу во всех файлах журнала сегментов, запустив его через утилиту gpssh. Например, чтобы отобразить последние три строки каждого файла журнала сегмента:
gpssh -f seg_host_file
=> source /usr/local/greenplum-db/greenplum_path.sh
=> gplogfilter -n 3 /gpdata/*/pg_log/gpdb*.csvПо умолчанию вывод gplogfilter отправляется на стандартный вывод. Используйте параметр -o, чтобы отправить вывод в файл или каталог. Если вы укажете имя выходного файла, заканчивающееся на .gz, выходной файл будет сжат по умолчанию с использованием максимального сжатия. Если местом назначения вывода является каталог, выходному файлу даётся то же имя, что и входному файлу.
Таблица 36 — timestamp параметры gplogfilter
|
Параметр |
Описание |
|---|---|
| -b datetime | --begin=datetime |
Указывает начальную дату и время начала поиска записей журнала в формате YYYY-MM-DD [hh:mm[:ss]]. Если указано время, дату и время следует заключить в одинарные или двойные кавычки. В этом примере дата и время заключаются в одинарные кавычки:
|
| -e datetime | --end=datetime |
Указывает конечную дату и время завершения поиска записей журнала в формате YYYY-MM-DD [hh:mm[:ss]]. Если время указано, дату и время необходимо заключить в одинарные или двойные кавычки. В этом примере дата и время заключаются в одинарные кавычки:
|
| -d time | --duration=time | Задаёт продолжительность поиска записей журнала в формате [hh][:mm[:ss]]. При использовании без параметра -b или -e в качестве основы будет использоваться текущее время. |
Таблица 37 — pattern matching параметры gplogfilter
|
Параметр |
Описание |
|---|---|
| -c i [gnore] | r [espect] | --case=i [gnore] | r [espect] | Сопоставление буквенных символов по умолчанию чувствительно к регистру, если только не используется параметр --case=ignore. |
| -C 'string' | --columns='string' | Выбирает определённые столбцы из файла журнала. Задайте нужные столбцы в виде строки номеров столбцов, разделённых запятыми, которые начинаются с 1, где второй столбец 2, третий 3 и т.д. |
| -f 'string' | --find='string' | Находит записи журнала, содержащие указанную строку. |
| -F 'string' | --nofind='string' | Отклоняет записи журнала, содержащие указанную строку. |
| -m regex | --match=regex | Находит записи журнала, соответствующие указанному регулярному выражению Python. См. https://docs.python.org/library/re.html для синтаксиса регулярных выражений Python. |
| -M regex | --nomatch=regex | Отклоняет записи журнала, соответствующие указанному регулярному выражению Python. См. https://docs.python.org/library/re.html для синтаксиса регулярных выражений Python. |
| -t | --trouble | Находит только те записи журнала, в первой строке которых есть ERROR:, FATAL: или PANIC:. |
Таблица 38 — output параметры gplogfilter
|
Параметр |
Описание |
|---|---|
| -n integer | --tail=integer | Ограничивает вывод последним integer найденных подходящих записей журнала. |
| -s offset [limit] | --slice=offset [limit] | Из списка подходящих записей журнала возвращает ограниченное (limit) количество записей, начиная с номера offset записи, где offset равный нулю (0) обозначает первую запись в наборе результатов, а offset любого числа больше нуля отсчитывается от конца набора результатов. |
| -o output_file | --out=output_file | Записывает вывод в указанный файл или каталог вместо STDOUT. |
| -z 0-9 | --zip=0-9 | Сжимает выходной файл до указанного уровня сжатия с помощью gzip, где 0 — отсутствие сжатия, а 9 — максимальное сжатие. Если вы укажете имя выходного файла, заканчивающееся на .gz, выходной файл будет сжат по умолчанию с использованием максимального сжатия. |
| -a | --append | Если выходной файл уже существует, добавляется к файлу, а не перезаписывается. |
Таблица 39 — input параметры gplogfilter
|
Параметр |
Описание |
|---|---|
| input_file | Имя входного файла(ов) журнала для поиска. Если входной файл не указан, gplogfilter будет использовать переменную среды $MASTER_DATA_DIRECTORY для поиска файла журнала мастера RT.Warehouse. Для чтения из стандартного ввода используйте тире (-) в качестве имени входного файла. |
| -u | --unzip | Распаковать входной файл с помощью gunzip. Если имя входного файла заканчивается на .gz, по умолчанию он не будет сжат. |
| --help | Отображать интерактивную справку. |
| --version | Отображать версию этой утилиты. |
Отобразить последние три сообщения об ошибках в файле журнала мастера:
gplogfilter -t -n 3Показать все сообщения журнала в файле журнала мастера с отметкой времени за последние 10 минут:
gplogfilter -d :10Отображение сообщений журнала в файле журнала мастера, содержащем строку |con6 cmd11|:
gplogfilter -f '|con6 cmd11|'Используя gpssh, запустить gplogfilter на хостах сегмента и найти сообщения журнала в файлах журнала сегмента, содержащих строку con6, и сохраните вывод в файл.
gpssh -f seg_hosts_file -e 'source
/usr/local/greenplum-db/greenplum_path.sh ; gplogfilter -f
con6 /gpdata/*/pg_log/gpdb*.csv' > seglog.outВыполняет задания RT.Warehouse MapReduce, как определено в документе спецификации YAML.
gpmapreduce -f config.yaml [dbname [username]]
[-k name=value | --key name=value]
[-h hostname | --host hostname] [-p port| --port port]
[-U username | --username username] [-W] [-v]
gpmapreduce -x | --explain
gpmapreduce -X | --explain-analyze
gpmapreduce -V | --version
gpmapreduce -h | --helpПеред запуском данной программы необходимо следующее:
1) У вас должно быть задание MapReduce, определённое в файле YAML. См. gpmapreduce.yaml для получения дополнительной информации о формате и ключевых словах, поддерживаемых в файле конфигурации RT.Warehouse MapReduce YAML.
2) Вы должны быть суперпользователем RT.Warehouse, чтобы запускать задания MapReduce, написанные на Perl или Python.
3) Вы должны быть суперпользователем RT.Warehouse, чтобы запускать задания MapReduce с входными параметрами EXEC и FILE.
4) Вы должны быть суперпользователем RT.Warehouse, чтобы запускать задания MapReduce с вводом GPFDIST, если пользователю не предоставлены соответствующие права.
MapReduce— это модель программирования, разработанная Google для обработки и создания больших наборов данных на массиве обычных серверов. RT.Warehouse MapReduce позволяет программистам, знакомым с парадигмой MapReduce, писать функции map и reduce и отправлять их в параллельный механизм RT.Warehouse для обработки.
gpmapreduce — это программа RT.Warehouse MapReduce. Вы настраиваете задание RT.Warehouse MapReduce через файл конфигурации в формате YAML, который вы передаёте программе для выполнения параллельным механизмом RT.Warehouse. Система RT.Warehouse распределяет входные данные, выполняет программу через набор машин, обрабатывает сбои машин и управляет необходимой связью между машинами.
Таблица 40 — Параметры gpmapreduce
|
Параметр |
Описание |
|---|---|
| -f config.yaml | Обязательный. Файл YAML, содержащий определения заданий RT.Warehouse MapReduce. См. gpmapreduce.yaml, чтобы узнать о формате и содержании параметров, которые вы указываете в этом файле. |
| -? | --help | Показать справку, затем выйти. |
| -V | --version | Показать информацию о версии, затем выйти. |
| -v | --verbose | Показать подробный вывод. |
| -x | --explain | Не запускать задания MapReduce, а создать план выполнения. |
| -X | --explain-analyze | Запустить задания MapReduce и создать план выполнения и анализа. |
| -k | --keyname=value | Установить переменную YAML. Требуется значение. По умолчанию используется key, если имя переменной не указано. |
Таблица 41 — Параметры подключения gpmapreduce
|
Параметр |
Описание |
|---|---|
| -h host | --host host | Задаёт имя хоста машины, на которой работает сервер мастера RT.Warehouse. Если параметр не указан, значение считывается из переменной среды PGHOST или по умолчанию используется localhost. |
| -p port | --port port | Задает TCP-порт, на котором сервер мастера RT.Warehouse прослушивает соединения. Если параметр не указан, значение считывается из переменной среды PGPORT или по умолчанию 5432. |
| -U username | --username username | Имя роли базы данных для подключения. Если параметр не указан, значение считывается из переменной среды PGUSER или по умолчанию используется текущее имя пользователя системы. |
| -W | --password | Принудительно ввести пароль. |
Запустить задание MapReduce, как определено в my_mrjob.yaml, и подключиться к базе данных mydatabase:
gpmapreduce -f my_mrjob.yaml mydatabaseФайл конфигурации gpmapreduce.
%YAML 1.1
---
VERSION: 1.0.0.2
DATABASE: dbname
USER: db_username
HOST: master_hostname
PORT: master_port
DEFINE:
- INPUT:
NAME: input_name
FILE:
- hostname:/path/to/file
GPFDIST:
- hostname:port/file_pattern
TABLE: table_name
QUERY: SELECT_statement
EXEC: command_string
COLUMNS:
- field_name data_type
FORMAT: TEXT | CSV
DELIMITER: delimiter_character
ESCAPE: escape_character
NULL: null_string
QUOTE: csv_quote_character
ERROR_LIMIT: integer
ENCODING: database_encoding
- OUTPUT:
NAME: output_name
FILE: file_path_on_client
TABLE: table_name
KEYS:
- column_name
MODE: REPLACE | APPEND
- MAP:
NAME: function_name
FUNCTION: function_definition
LANGUAGE: perl | python | c
LIBRARY: /path/filename.so
PARAMETERS:
- nametype
RETURNS:
- nametype
OPTIMIZE: STRICT IMMUTABLE
MODE: SINGLE | MULTI
- TRANSITION | CONSOLIDATE | FINALIZE:
NAME: function_name
FUNCTION: function_definition
LANGUAGE: perl | python | c
LIBRARY: /path/filename.so
PARAMETERS:
- nametype
RETURNS:
- nametype
OPTIMIZE: STRICT IMMUTABLE
MODE: SINGLE | MULTI
- REDUCE:
NAME: reduce_job_name
TRANSITION: transition_function_name
CONSOLIDATE: consolidate_function_name
FINALIZE: finalize_function_name
INITIALIZE: value
KEYS:
- key_name
- TASK:
NAME: task_name
SOURCE: input_name
MAP: map_function_name
REDUCE: reduce_function_name
EXECUTE:
- RUN:
SOURCE: input_or_task_name
TARGET: output_name
MAP: map_function_name
REDUCE: reduce_function_name...Вы указываете задачи input, map и reduce, и output для программы RT.Warehouse MapReduce gpmapreduce в файле конфигурации в формате YAML. Данный раздел использует имя gpmapreduce.yaml для данного файла; вы можете выбрать собственное имя для файла.
Утилита gpmapreduce обрабатывает файл конфигурации YAML по порядку, используя отступы (пробелы) для определения иерархии документа и отношений между разделами. Использование белого пространства в файле является значительным.
Таблица 42 — Параметры gpmapreduce.yaml
|
№ |
Параметр |
Описание |
|---|---|---|
| 1 | VERSION | Обязательный. Версия YAML-спецификации RT.Warehouse MapReduce. Текущие поддерживаемые версии: 1.0.0.1, 1.0.0.2 и 1.0.0.3. |
| 2 | DATABASE | Опционально. Указывает, к какой базе данных в RT.Warehouse подключаться. Если параметр не указан, по умолчанию используется база данных по умолчанию или $PGDATABASE, если задано. |
| 3 | USER | Опционально. Указывает, какую роль базы данных использовать для подключения. Если параметр не указан, по умолчанию используется текущий пользователь или $PGUSER, если установлено. Вы должны быть суперпользователем RT.Warehouse, чтобы запускать функции, написанные на Python и Perl. Обычные пользователи базы данных могут запускать функции, написанные на Perl. Вы также должны быть суперпользователем базы данных, чтобы запускать задания MapReduce, которые содержат типы ввода FILE, GPFDIST и EXEC. |
| 4 | HOST | Опционально. Задаёт имя хоста мастера RT.Warehouse. Если параметр не указан, по умолчанию используется localhost или $PGHOST, если установлено. |
| 5 | PORT | Опционально. Задаёт порт мастера RT.Warehouse. Если параметр не указан, по умолчанию 5432 или $PGPORT, если установлено. |
| 6 | DEFINE | Обязательный. Последовательность определений для этого документа MapReduce. В разделе DEFINE должно быть хотя бы одно определение INPUT. |
| 6.1 | INPUT | Обязательный. Определяет входные данные. В каждом документе MapReduce должен быть определен хотя бы один вход. В документе разрешено несколько определений ввода, но каждое определение ввода может указывать только один из этих типов доступа: файл, ссылка на файл gpfdist, таблица в базе данных, команда SQL или команда операционной системы. См. gpfdist для получения информации об этой ссылке. |
| 6.1.1 | NAME | Имя для этого входа. Имена должны быть уникальными по отношению к именам других объектов в этом задании MapReduce (например, функция map, task, функция reduce и имена output). Кроме того, имена не могут конфликтовать с существующими объектами в базе данных (такими как таблицы, функции или представления). |
| 6.1.2 | FILE | Последовательность из одного или нескольких входных файлов в формате: seghostname:/path/to/filename. Вы должны быть суперпользователем RT.Warehouse, чтобы запускать задания MapReduce с вводом FILE. Файл должен находиться на хосте сегмента RT.Warehouse. |
| 6.1.3 | GPFDIST | Последовательность, идентифицирующая один или несколько запущенных файловых серверов gpfdist в формате hostname[:port]/file_pattern. Чтобы запускать задания MapReduce с вводом GPFDIST, вы должны быть суперпользователем RT.Warehouse. |
| 6.1.4 | TABLE | Имя существующей таблицы в базе данных. |
| 6.1.5 | QUERY | SQL-команда SELECT для запуска в базе данных. |
| 6.1.6 | EXEC | Команда операционной системы для запуска на хостах сегмента RT.Warehouse. По умолчанию команда запускается всеми инстансами сегмента в системе. Например, если у вас есть четыре инстанса сегмента на хост сегмента, команда будет запущена четыре раза на каждом хосте. Чтобы запускать задания MapReduce с входными данными EXEC, вы должны быть суперпользователем RT.Warehouse. |
| 6.1.7 | COLUMNS | Опционально. Столбцы указываются как: column_name [data_type]. Если не указан, по умолчанию используется value text. Символ DELIMITER разделяет два поля (столбца) значений данных. Строка определяется символом перевода строки (0x0a). |
| 6.1.8 | FORMAT | Опционально. Задаёт формат данных — текст с разделителями (TEXT) или формат значений, разделённых запятыми (CSV). Если формат данных не указан, по умолчанию используется TEXT. |
| 6.1.9 | DELIMITER | Опционально для входов FILE, GPFDIST и EXEC. Задаёт один символ, разделяющий значения данных. По умолчанию в режиме TEXT используется символ табуляции, в режиме CSV — запятая. Символ-разделитель должен появляться только между любыми двумя полями значений данных. Не ставьте разделитель в начале или в конце строки. |
| 6.1.10 | ESCAPE | Опционально для входов FILE, GPFDIST и EXEC. Задаёт одиночный символ, который используется для escape-последовательностей C (например, \n, \t, \100 и т.д.) И для escape-символов данных, которые в противном случае могли бы быть приняты как разделители строк или столбцов. Обязательно выберите escape-символ, который нигде не используется в ваших фактических данных столбца. Escape-символ по умолчанию \ (обратная косая черта) для файлов в текстовом формате и " (двойная кавычка) для файлов в формате CSV, однако можно указать другой символ для представления escape-символа. Также можно отключить escape, указав значение ‘OFF’ в качестве escape-значения. Это очень полезно для таких данных, как данные веб-журнала в текстовом формате, которые содержат множество встроенных обратных косых черт, которые не предназначены для использования в качестве escape-символов. |
| 6.1.11 | NULL | Опционально для входов FILE, GPFDIST и EXEC. Задаёт строку, представляющую нулевое значение. По умолчанию используется \N в формате TEXT и пустое значение без кавычек в формате CSV. Вы можете предпочесть пустую строку даже в режиме TEXT для случаев, когда вы не хотите отличать нули от пустых строк. Любой элемент входных данных, соответствующий этой строке, будет считаться нулевым значением. |
| 6.1.12 | QUOTE | Опционально для входов FILE, GPFDIST и EXEC. Задаёт кавычки для файлов в формате CSV. По умолчанию используется двойная кавычка ("). В файлах в формате CSV поля значений данных должны быть заключены в двойные кавычки, если они содержат запятые или встроенные новые строки. Поля, содержащие символы двойных кавычек, должны быть заключены в двойные кавычки, а встроенные двойные кавычки должны быть представлены парой последовательных двойных кавычек. Важно всегда открывать и закрывать кавычки правильно для правильного анализа строк данных. |
| 6.1.13 | ERROR_LIMIT | Если во входных строках есть ошибки формата, они будут отброшены при условии, что предельное количество ошибок не будет достигнуто ни на одном инстансе сегмента RT.Warehouse во время обработки ввода. Если предел ошибок не достигнут, все исправные строки будут обработаны, а все строки с ошибками будут отброшены. |
| 6.1.14 | ENCODING | Кодировка набора символов, используемая для данных. Укажите строковую константу (например, 'SQL_ASCII'), целое число кодировки или DEFAULT, чтобы использовать клиентскую кодировку по умолчанию. |
| 6.2 | OUTPUT | Опционально. Определяет, куда выводить форматированные данные этого задания MapReduce. Если вывод не определён, по умолчанию используется STDOUT (стандартный вывод клиента). Вы можете отправить вывод в файл на клиентском хосте или в существующую таблицу в базе данных. |
| 6.2.1 | NAME | Имя для этого выхода. Имя вывода по умолчанию — STDOUT. Имена должны быть уникальными по отношению к именам других объектов в этом задании MapReduce (например, функция map, task, функция reduce и имена output). Кроме того, имена не могут конфликтовать с существующими объектами в базе данных (такими как таблицы, функции или представления). |
| 6.2.2 | FILE | Задаёт расположение файла на клиентском компьютере MapReduce для вывода данных в формате: /path/to/filename. |
| 6.2.3 | TABLE | Задаёт имя таблицы в базе данных для вывода данных. Если эта таблица не существует до запуска задания MapReduce, она будет создана с использованием политики распределения, указанной с помощью KEYS. |
| 6.2.4 | KEYS | Опционально для вывода TABLE. Задаёт столбцы, которые будут использоваться в качестве ключа распределения RT.Warehouse. Если задача EXECUTE содержит определение REDUCE, то ключи REDUCE будут использоваться в качестве ключа распределения таблицы по умолчанию. В противном случае первый столбец таблицы будет использоваться как ключ распределения. |
| 6.2.5 | MODE | Опционально для вывода TABLE. Если не указан, по умолчанию таблица создаётся, если она ещё не существует, то выводится ошибка, если она существует. Объявление APPEND добавляет выходные данные в существующую таблицу (при условии, что схема таблицы соответствует выходному формату) без удаления каких-либо существующих данных. Объявление REPLACE удалит таблицу, если она существует, а затем создаст её заново. И APPEND, и REPLACE создадут новую таблицу, если таковая не существует. |
| 6.3 | MAP | Обязательный. Каждая функция MAP принимает данные, структурированные парами (key, value), обрабатывает каждую пару и генерирует ноль или более выходных пар (key, value). Затем инфраструктура RT.Warehouse MapReduce собирает все пары с одним и тем же ключом из всех выходных списков и группирует их вместе. Эти выходные данные затем передаются в задачу REDUCE, которая состоит из TRANSITION | CONSOLIDATE | FINALIZE функции. Существует одна предопределённая функция MAP с именем IDENTITY, которая возвращает пары (key, value) без изменений. Хотя (key, value) являются параметрами по умолчанию, вы можете указать другие прототипы по мере необходимости. |
| 6.4 | TRANSITION | CONSOLIDATE | FINALIZE |
TRANSITION, CONSOLIDATE и FINALIZE являются составными частями REDUCE. Функция TRANSITION требуется. Функции CONSOLIDATE и FINALIZE опциональны. По умолчанию все принимают state в качестве первого из своих входных PARAMETERS, но также могут быть определены другие прототипы. Функция TRANSITION выполняет итерацию по каждому значению данного ключа и накапливает значения в переменной state. Когда функция TRANSITION вызывается для первого значения ключа, state устанавливается на значение, указанное в INITIALIZE задания REDUCE (или значение состояния по умолчанию для типа данных). Переход принимает на вход два аргумента: текущее состояние редукции ключа и следующее значение, которое затем создаёт новое state. Если указана функция CONSOLIDATE, обработка TRANSITION выполняется на уровне сегмента перед перераспределением ключей по интерконнекту RT.Warehouse для окончательного агрегирования (двухфазное агрегирование). Перераспределяется только результирующее значение state для данного ключа, что приводит к снижению трафика интерконнекта и большему параллелизму. CONSOLIDATE обрабатывается как TRANSITION, за исключением того, что вместо (state + value) => state это (state + state) => state. Если функция указана FINALIZE, она принимает окончательное state, созданное CONSOLIDATE (если есть) или TRANSITION и выполняет окончательную обработку перед выдачей окончательного результата. Функции TRANSITION и CONSOLIDATE не могут возвращать набор значений. Если вам нужно задание REDUCE для возврата набора, то FINALIZE необходимо для преобразования конечного состояния в набор выходных значений. |
| 6.4.1 | NAME | Обязательный. Имя функции. Имена должны быть уникальными по отношению к именам других объектов в этом задании MapReduce (например, имена функций, задач, ввода и вывода). Вы также можете указать имя функции, встроенной в RT.Warehouse. При использовании встроенной функции не указывайте LANGUAGE или FUNCTION. |
| 6.4.2 | FUNCTION | Опционально. Задаёт полное тело функции на указанном LANGUAGE. Если FUNCTION не указано, то используется встроенная функция базы данных, соответствующая NAME. |
| 6.4.3 | LANGUAGE | Требуется при использовании FUNCTION. Задаёт язык реализации, используемый для интерпретации функции. В этом выпуске есть языковая поддержка perl, python и C. При вызове встроенной функции базы данных не следует указывать LANGUAGE. |
| 6.4.4 | LIBRARY | Требуется, если LANGUAGE имеет значение C (не разрешено для других функций языка). Чтобы использовать этот атрибут, VERSION должна быть 1.0.0.2. Указанный файл библиотеки должен быть установлен до запуска задания MapReduce, и он должен существовать в одном месте файловой системы на всех хостах RT.Warehouse (мастере и сегментах). |
| 6.4.5 | PARAMETERS |
Опционально. Входные параметры функции. Тип по умолчанию — text.
|
| 6.4.6 | RETURNS |
Опционально. Тип возврата по умолчанию — text.
|
| 6.4.7 | OPTIMIZE |
Опциональные параметры оптимизации для функции:
|
| 6.4.8 | MODE |
Опционально. Задаёт количество строк, возвращаемых функцией:
|
| 6.5 | REDUCE |
Обязательный. Определение REDUCE называет функции TRANSITION | CONSOLIDATE | FINALIZE, которые включают сокращение пар (key, value) до окончательного набора результатов. Есть также несколько предопределённых заданий REDUCE, которые вы можете выполнить, и все они работают над столбцом с именем value:
|
| 6.5.1 | NAME | Обязательный. Имя данного задания REDUCE. Имена должны быть уникальными по отношению к именам других объектов в этом задании MapReduce (имена функций, задач, входов и выходов). Кроме того, имена не могут конфликтовать с существующими объектами в базе данных (такими как таблицы, функции или представления). |
| 6.5.2 | TRANSITION | Обязательный. Имя функции TRANSITION. |
| 6.5.3 | CONSOLIDATE | Опционально. Имя функции CONSOLIDATE. |
| 6.5.4 | FINALIZE | Опционально. Имя функции FINALIZE. |
| 6.5.5 | INITIALIZE | Опционально для типов данных text и float. Обязателен для всех остальных типов данных. Значение по умолчанию для text — ''. Значение по умолчанию для float — 0.0. Устанавливает значение начального state функции TRANSITION. |
| 6.5.6 | KEYS | Опционально. По умолчанию [key, *]. При использовании сокращения по нескольким столбцам может потребоваться указать, какие столбцы являются ключами, а какие — столбцами значений. По умолчанию все входные столбцы, которые не передаются в функцию TRANSITION, являются ключевыми столбцами, а столбец с именем key всегда является ключевым столбцом, даже если он передаётся в функцию TRANSITION. Специальный индикатор * указывает на все столбцы, не переданные в функцию TRANSITION. Если этого индикатора нет в списке ключей, то все несовпадающие столбцы отбрасываются. |
| 6.6 | TASK | Опционально. TASK определяет полный сквозной этап INPUT/MAP/REDUCE в конвейере заданий RT.Warehouse MapReduce. Он похож на EXECUTE, за исключением того, что не выполняется сразу. Объект задачи может называться INPUT для дальнейших этапов обработки. |
| 6.6.1 | NAME | Обязательный. Название этой задачи. Имена должны быть уникальными по отношению к именам других объектов в этом задании MapReduce (например, функция map, функция reduce, имена input и output). Кроме того, имена не могут конфликтовать с существующими объектами в базе данных (такими как таблицы, функции или представления). |
| 6.6.2 | SOURCE | Имя INPUT или другой TASK. |
| 6.6.3 | MAP | Опционально. Имя функции MAP. Если параметр не указан, по умолчанию используется IDENTITY. |
| 6.6.4 | REDUCE | Опционально. Имя функции REDUCE. Если параметр не указан, по умолчанию используется IDENTITY. |
| 7 | EXECUTE | Обязательный. EXECUTE определяет заключительный этап INPUT/MAP/ REDUCE в конвейере задания RT.Warehouse MapReduce. |
| 7.1 | RUN | — |
| 7.1.1 | SOURCE | Обязательный. Имя INPUT или TASK. |
| 7.1.2 | TARGET | Опционально. Имя OUTPUT. Выход по умолчанию — STDOUT. |
| 7.1.3 | MAP | Опционально. Имя функции MAP. Если параметр не указан, по умолчанию используется IDENTITY. |
| 7.1.4 | REDUCE | Опционально. Имя функции REDUCE. По умолчанию — IDENTITY. |
Перемещает инстансы зеркального сегмента в новое место.
gpmovemirrors -i move_config_file [-d master_data_directory]
[-l logfile_directory]
[-B parallel_processes] [-v]
gpmovemirrors -?
gpmovemirrors --versionУтилита gpmovemirrors перемещает инстансы зеркальных сегментов в новые места. Вы можете переместить зеркала в новые места, чтобы оптимизировать распределение или хранение данных.
Перед перемещением сегментов утилита проверяет, являются ли они зеркалами, и что соответствующие им основные сегменты включены и находятся в режиме синхронизации или повторной синхронизации.
По умолчанию утилита запросит у вас расположение файловой системы, куда она переместит каталоги данных зеркальных сегментов.
Вы должны убедиться, что пользователь, запускающий gpmovemirrors (пользователь gpadmin), имеет права на запись в указанные местоположения каталога данных. Вы можете создать эти каталоги на хостах сегментов и chown их соответствующему пользователю перед запуском gpmovemirrors.
Таблица 43 — Параметры gpmovemirrors
|
Параметр |
Описание |
|---|---|
| -B parallel_processes | Количество сегментов зеркала, перемещаемых параллельно. Если параметр не указан, утилита запустит до 4 параллельных процессов в зависимости от того, сколько инстансов зеркального сегмента необходимо переместить. |
| -d master_data_directory | Каталог основных данных. Если параметр не указан, будет использоваться значение, установленное для $MASTER_DATA_DIRECTORY. |
| -i move_config_file |
Файл конфигурации, содержащий информацию о том, какие зеркальные сегменты нужно переместить и куда их переместить. Для каждого основного сегмента в системе должен быть указан один зеркальный сегмент. Каждая строка внутри файла конфигурации имеет следующий формат (согласно атрибутам в таблице каталога gp_segment_configuration): Где contentID — это идентификатор содержимого инстанса сегмента, address — имя хоста или IP-адрес хоста сегмента, port — это порт связи, а data_dir — это каталог данных инстанса сегмента. |
| -l logfile_directory | Каталог для записи файла журнала. По умолчанию ~/gpAdminLogs. |
| -v | Устанавливает подробный (verbose) вывод журнала. |
| --version | Отображает версию этой утилиты. |
| -? | Отображает интерактивную справку. |
Переместить зеркала из существующей системы RT.Warehouse на другой набор хостов:
$ gpmovemirrors -i move_config_fileГде move_config_file выглядит примерно так:
1|sdw2|50001|/data2/mirror/gpseg1 sdw3|50001|/data/mirror/gpseg1
2|sdw2|50001|/data2/mirror/gpseg2 sdw4|50001|/data/mirror/gpseg2
3|sdw3|50001|/data2/mirror/gpseg3 sdw1|50001|/data/mirror/gpseg3Устанавливает базу данных gpperfmon и дополнительно включает агенты сбора данных.
gpperfmon_install --port gpdb_port
[--enable --password gpmon_password [--pgpass path_to_file]]
[--verbose]
gpperfmon_install --help | -h | -?Утилита gpperfmon_install автоматизирует шаги, необходимые для включения агентов сбора данных. Для запуска этой утилиты вы должны быть системным пользователем RT.Warehouse (gpadmin). Параметр --port обязателен. При использовании параметра --enable также требуется параметр --password. Используйте параметр --port, чтобы указать порт инстанса мастера RT.Warehouse. При использовании параметра ‑‑enable необходимо перезапустить RT.Warehouse после завершения работы утилиты.
При запуске без параметра --enable утилита просто создаёт базу данных gpperfmon (база данных, используемая для хранения системных метрик, собранных агентами сбора данных). При запуске с параметром --enable утилита также выполняет следующие дополнительные задачи, необходимые для включения агентов сбора данных мониторинга производительности:
1) Создаёт роль суперпользователя gpmon в RT.Warehouse. Агентам сбора данных эта роль требуется для подключения к базе данных и записи своих данных. Роль суперпользователя gpmon по умолчанию использует аутентификацию с паролем с шифрованием MD5. Используйте параметр --password, чтобы установить пароль суперпользователя gpmon.
2) Обновляет файл $MASTER_DATA_DIRECTORY/pg_hba.conf. Утилита добавляет эти строки в файл аутентификации хостов (pg_hba.conf):
local gpperfmon gpmon md5
host all gpmon 127.0.0.1/28 md5
host all gpmon ::1/128 md5Вторая и третья строки, записи host, предоставляют gpmon доступ ко всем базам данных RT.Warehouse.
|
Примечание. Может потребоваться отредактировать строки в файле pg_hba.conf после запуска утилиты gpperfmon_install, чтобы ограничить доступ роли gpmon к базам данных или изменить метод аутентификации. После редактирования файла запустите gpstop -u, чтобы перезагрузить файл в RT.Warehouse. 1) Чтобы ограничить доступ gpmon только к базе данных gpperfmon, отредактируйте записи host в файле pg_hba.conf. Для пользователя gpmon измените второе поле с all на gpperfmon: 2) Утилита gpperfmon_install использует метод аутентификации MD5 по умолчанию. RT.Warehouse может быть дополнительно сконфигурирована для использования хэш-алгоритма SHA-256 для вычисления хэшей паролей, сохранённых в системном каталоге. Это несовместимо с методом аутентификации подлинности MD5, который ожидает хэш-код MD5 или пароль в виде открытого текста в системном каталоге. По этой причине, если вы включили хэш-алгоритм SHA-256 в базе данных, вы должны отредактировать файл pg_hba.conf после запуска утилиты gpperfmon_install. Для записей host измените метод аутентификации для роли gpmon с md5 на password: Метод аутентификации password представляет для аутентификации пароль пользователя в виде открытого текста и не должен использоваться в ненадежной сети. |
3) Обновляет файл паролей (.pgpass). Чтобы позволить агентам сбора данных подключаться в качестве роли gpmon без запроса пароля, у вас должен быть файл паролей, в котором есть запись для пользователя gpmon. Утилита добавляет следующую запись в ваш файл паролей (если файл не существует, утилита создаст его):
*:5432:gpperfmon:gpmon:gpmon_passwordЕсли ваш файл паролей находится не в папке по умолчанию (~/.pgpass), используйте параметр --pgpass, чтобы указать местоположение файла.
4) Устанавливает параметры конфигурации сервера для базы данных gpperfmon. Чтобы агенты сбора данных начали сбор данных, должны быть включены следующие параметры. Утилита устанавливает следующие параметры в файлах конфигурации postgresql.conf RT.Warehouse:
- gp_enable_gpperfmon=on (во всех файлах postgresql.conf);
- gpperfmon_port=8888 (во всех файлах postgresql.conf);
- gp_external_enable_exec=on (в файле мастера postgresql.conf).
Агенты сбора данных можно настроить, задав параметры в файле конфигурации gpperfmon.conf. Подробнее см. Конфигурация агента сбора данных.
Таблица 44 — Параметры gpperfmon_install
|
Параметр |
Описание |
|---|---|
| --enable | Помимо создания базы данных gpperfmon, выполняет дополнительные шаги, необходимые для включения агентов сбора данных. Если указан параметр --enable, утилита также создаст и настроит учётную запись суперпользователя gpmon и установит параметры конфигурации сервера gpperfmon в файлах postgresql.conf. |
| --password gpmon_password | Обязательно, если указан --enable. Устанавливает пароль суперпользователя gpmon. Недопустимо, если не указан ‑‑enable. |
| --port gpdb_port | Обязательный. Задаёт порт подключения сервера мастера RT.Warehouse. |
| --pgpass path_to_file | Опционально, если указан --enable. Если файл паролей находится не в местоположении по умолчанию ~/.pgpass, указывает местоположение файла паролей. |
| --verbose | Задаёт подробный уровень ведения журнала. |
| --help | -h | -? | Отображает интерактивную справку. |
В файле $MASTER_DATA_DIRECTORY/gpperfmon/conf/gpperfmon.conf хранятся параметры конфигурации для агентов сбора данных. Чтобы изменения конфигурации этих параметров вступили в силу, необходимо сохранить файл gpperfmon.conf, а затем перезапустить сервер RT.Warehouse (gpstop -r).
Файл gpperfmon.conf содержит следующие параметры конфигурации.
Таблица 45 — Параметры gpperfmon.conf
|
Параметр |
Описание |
|---|---|
| log_location | Задаёт расположение каталога для файлов журнала gpperfmon. По умолчанию это $MASTER_DATA_DIRECTORY/gpperfmon/logs. |
| min_query_time |
Задаёт минимальное время выполнения запроса в секундах для сбора статистики. Все запросы, которые выполняются дольше этого значения, регистрируются в таблице query_history. Для запросов с более коротким временем выполнения исторические данные не собираются. По умолчанию — 20 секунд. Если вы знаете, что хотите собирать данные для всех запросов, вы можете установить для этого параметра низкое значение. Однако установка минимального времени выполнения запроса равным нулю позволяет собирать данные даже для тривиальных запросов и может создать большой объём данных, которые могут оказаться бесполезными. |
| max_log_size |
Этот параметр не включён в gpperfmon.conf, но его можно добавить в этот файл. Чтобы файлы журнала не увеличивались до чрезмерного размера, вы можете добавить параметр max_log_size в gpperfmon.conf. Значение этого параметра измеряется в байтах. Например: С данной настройкой файлы журнала накапливаются до 10 МБ, прежде чем система перейдёт к новому файлу журнала. |
| partition_age | Количество месяцев, в течение которых данные статистики gpperfmon будут храниться. Значение по умолчанию — 0, что означает, что разделы никогда не удаляются автоматически. |
| quantum |
Задаёт время в секундах между обновлениями от агентов сбора данных на всех сегментах. Допустимые значения: 10, 15, 20, 30 и 60. По умолчанию — 15 секунд. Если вы предпочитаете менее детальное представление о производительности или хотите собирать и анализировать минимальные объёмы данных для системных метрик, выберите более высокий уровень. Чтобы собирать данные чаще, выберите меньшее значение. |
| harvest_interval | Время в секундах между сбором данных. Сбор данных перемещает последние данные из внешних (_tail) таблиц gpperfmon в соответствующие файлы истории. По умолчанию — 120. Минимальное значение — 30. |
| ignore_qexec_packet | Не рекомендуется. Если установлено значение true, агенты сбора данных не собирают данные о производительности в базы данных gpperfmon таблицах queries_*: rows_out, cpu_elapsed, cpu_currpct, skew_cpu и skew_rows. Значение по умолчанию, true, уменьшает объём памяти, потребляемой процессом gpmmon. Установите для этого параметра значение false, если вам требуются эти дополнительные данные о производительности. |
| smdw_aliases |
Этот параметр позволяет указать дополнительные имена хостов для резервного мастера. Например, если у резервного мастера есть две сетевые карты, вы можете ввести:
|
База данных gpperfmon требует роли gpmon. После создания базы данных gpperfmon и роли gpmon вы можете изменить пароль для роли gpmon:
1) Войдите в RT.Warehouse как суперпользователь и измените пароль gpmon с помощью команды ALTER ROLE.
# ALTER ROLE gpmon WITH PASSWORD 'new_password' ;2) Обновите пароль в файле .pgpass. Расположение файла по умолчанию — домашний каталог gpadmin (~/.pgpass). Файл .pgpass содержит строку с паролем gpmon.
*:5432:gpperfmon:gpmon:new_passwordСистема мониторинга gpperfmon требует инициализации после запуска. Информация о мониторинге появляется через несколько минут, а не сразу после установки и запуска системы gpperfmon.
Создать только базу данных gpperfmon:
$ su - gpadmin
$ gpperfmon_install --port 5432Создать базу данных gpperfmon, создать суперпользователя gpmon и включить агенты сбора данных:
$ su - gpadmin
$ gpperfmon_install --enable --password changeme --port 5432
$ gpstop -rУстанавливает расширения RT.Warehouse в формате .gppkg, такие как PL/Java, PL/R и MADlib, а также их зависимости во всем кластере.
gppkg [-i package | -u package | -r name-version | -c]
[-d master_data_directory] [-a] [-v]
gppkg --migrate GPHOME_old GPHOME_new [-a] [-v]
gppkg [-q | --query] query_option
gppkg -? | --help | -h
gppkg --versionУтилита RT.Warehouse Package Manager (gppkg) устанавливает расширения RT.Warehouse вместе с любыми зависимостями на всех хостах в кластере. Она также автоматически установит расширения на новые хосты в случае расширения системы и восстановления сегмента.
|
Примечание. После серьёзного обновления RT.Warehouse необходимо снова загрузить и установить все расширения gppkg. |
Таблица 46 — Параметры gppkg
|
Параметр |
Описание |
|---|---|
| -a | Не запрашивать у пользователя подтверждение. |
| -c | --clean | Согласовывает состояние пакета кластера с состоянием хоста мастера. Запуск этого параметра после неудачной или частичной установки/удаления гарантирует, что состояние установки пакета будет согласованным во всем кластере. |
| -d master_data_directory | Каталог данных мастера. Если параметр не указан, будет использоваться значение, установленное для $MASTER_DATA_DIRECTORY. |
| -i package | --install=package | Устанавливает данный пакет. Это включает в себя все шаги до и после установки и установку любых зависимостей. |
| --migrate GPHOME_old GPHOME_new |
Переносит пакеты из отдельного $GPHOME. Переносит пакеты из одной версии RT.Warehouse в другую. Например: При переносе пакетов должны быть выполнены следующие требования:
|
| -q | --query query_option |
Предоставляет информацию, указанную в query_option, об установленных пакетах. За один раз можно указать только один query_option. Ниже перечислены возможные значения параметров для query_option, где <package_file> — имя пакета:
|
| -r name-version | --remove=name-version | Удаляет указанный пакет. |
| -u package | --update=package |
Обновляет данный пакет. Внимание. Процесс обновления пакета включает удаление всех предыдущих версий системных объектов, связанных с пакетом. Например, удаляются предыдущие версии общих библиотек. После процесса обновления функция базы данных завершится ошибкой при её вызове, если функция ссылается на файл пакета, который был удалён. |
| --version | Отображает версию этой утилиты. |
| -v | --verbose | Задаёт подробный уровень ведения журнала. |
| -? | -h | --help | Отображает интерактивную справку. |
Восстанавливает основной или зеркальный инстанс сегмента, который был помечен как отключённый (если зеркалирование включено).
gprecoverseg [-p new_recover_host[,...]] | -i recover_config_file] [-d master_data_directory]
[-B parallel_processes] [-F [-s]] [-a] [-q]
[--no-progress] [-l logfile_directory]
gprecoverseg -r
gprecoverseg -o output_recover_config_file
[-p new_recover_host[,...]]
gprecoverseg -? | --help
gprecoverseg --versionВ системе с включёнными зеркалами утилита gprecoverseg реактивирует отказавший инстанс сегмента и идентифицирует изменённые файлы базы данных, требующие ресинхронизации. После того, как gprecoverseg завершит этот процесс, система перейдёт в режим ресинхронизации, пока восстановленный сегмент не будет обновлён. Система активна и полностью работоспособна во время ресинхронизации.
Во время инкрементного восстановления (параметр -F не указан), если gprecoverseg обнаруживает инстанс сегмента с отключённым зеркалированием в системе с включёнными зеркалами, утилита сообщает, что зеркалирование отключено для сегмента, и не пытается восстановить этот инстанс сегмента, и продолжает процесс восстановления.
Инстанс сегмента может выйти из строя по нескольким причинам, например, из-за сбоя хоста, сбоя сети или сбоя диска. Когда инстанс сегмента выходит из строя, его статус отмечается как отключённый в системном каталоге RT.Warehouse, а его зеркало активируется в режиме отслеживания изменений. Чтобы снова запустить отказавший инстанс сегмента, необходимо сначала исправить проблему, из-за которой произошёл сбой, а затем восстановить инстанс сегмента в RT.Warehouse с помощью gprecoverseg.
Для восстановления сегмента с помощью gprecoverseg необходимо наличие активного зеркала для восстановления. Для систем, в которых не включено зеркалирование, или в случае двойного сбоя (одновременное отключение основного и зеркального сегмента), необходимо вручную предпринять шаги для восстановления отказавших инстансов сегмента, а затем выполнить перезагрузку системы, чтобы сегменты снова были работоспособны Например, эта команда перезапускает систему.
gpstop -rПо умолчанию отказавший сегмент восстанавливается на месте, что означает, что система возвращает сегмент в работоспособный режим на том же хосте и в том же месте каталога данных, на котором он был изначально настроен. В этом случае используйте следующий формат файла конфигурации восстановления (с помощью -i).
<failed_host_address>|<port>|<data_directory>В некоторых случаях это может быть невозможно (например, если хост был физически повреждён и не может быть восстановлен). В этой ситуации gprecoverseg позволяет вам восстанавливать отказавшие сегменты на новый хост (используя -p), в альтернативном местоположении каталога данных на ваших оставшихся живых хостах сегментов (используя -s) или предоставляя файл конфигурации восстановления (используя -i) в следующем формате. Слово SPACE указывает расположение необходимого места. Не добавляйте дополнительных пробелов.
<failed_host_address>|<port>|<data_directory>SPACE
<recovery_host_address>|<port>|<data_directory>Таблица системного каталога gp_segment_configuration может помочь вам определить текущую конфигурацию сегмента, чтобы вы могли спланировать конфигурацию восстановления зеркала. Например, выполните следующий запрос:
=# SELECT dbid, content, address, port, datadir
FROM gp_segment_configuration
ORDER BY dbid;На новом восстановленном хосте сегмента должен быть предварительно установлено программное обеспечение RT.Warehouse, а также он должен быть настроен точно так же, как существующие хосты сегмента. Запасной каталог данных должен существовать на всех хостах текущего настроенного сегмента и иметь достаточно места на диске для размещения отказавших сегментов.
В процессе восстановления сегмент снова помечается как активный в системном каталоге RT.Warehouse, а затем запускается процесс ресинхронизации, чтобы актуализировать состояние транзакций сегмента с учётом последних изменений. Система активна и доступна во время ресинхронизации. Чтобы проверить статус выполнения процесса ресинхронизации:
gpstate -mТаблица 47 — Параметры gprecoverseg
|
Параметр |
Описание |
|---|---|
| -a | Не запрашивать у пользователя подтверждение. |
| -B parallel_processes | Количество сегментов для параллельного восстановления. Если не указано иное, утилита запустит до 16 параллельных процессов в зависимости от того, сколько инстансов сегментов необходимо восстановить. |
| -d master_data_directory | Опционально. Каталог данных хоста мастера. Если параметр не указан, будет использоваться значение, установленное для $MASTER_DATA_DIRECTORY. |
| -F |
Опционально. Выполните полную копию (full recovery) инстанса активного сегмента, чтобы восстановить отказавший сегмент. По умолчанию копируются только те инкрементные изменения, которые произошли во время остановки сегмента. Для больших баз данных полное восстановление может занять много времени, поэтому gprecoverseg отображает текущую оценку хода завершения копирования для каждого сегмента. Ход выполнения для каждого сегмента обновляется раз в секунду с использованием управляющих кодов ANSI для обновления строки для каждого сегмента на месте. Если вы перенаправляете вывод gprecoverseg в файл или если escape-коды ANSI не работают правильно на вашем терминале, вы можете включить параметр -s в командную строку, чтобы Не включать escape-коды ANSI. Это выводит новую строку один раз в секунду для каждого сегмента. Включите параметр --no-progress, чтобы полностью отключить отчёты о ходе выполнения. Внимание. Полное восстановление удаляет каталог данных инстанса сегмента, вышедшего из строя, перед копированием данных из активного (текущего основного) инстанса сегмента. Перед выполнением полного восстановления убедитесь, что сбой сегмента не привёл к повреждению данных и что все проблемы с диском сегмента хоста устранены. Кроме того, для полного восстановления утилита не восстанавливает пользовательские файлы, которые хранятся в каталоге данных инстанса сегмента, даже если пользовательские файлы также находятся в активном инстансе сегмента. Вы должны восстановить пользовательские файлы вручную. Например, при использовании протокола gpfdists (gpfdist с SSL-шифрованием) для управления внешними данными, файлы сертификатов клиента требуются в каталоге инстанса сегмента $PGDATA/gpfdists. Эти файлы не восстанавливаются. |
| -i recover_config_file |
Задаёт имя файла с подробностями о неисправных сегментах, которые необходимо восстановить. Каждая строка в файле имеет следующий формат. Слово SPACE указывает расположение необходимого пробела. Не добавляйте дополнительные пробелы. Комментарии Строки, начинающиеся с символа #, рассматриваются как комментарии и игнорируются. Сегменты для восстановления Каждая строка после первой указывает сегмент для восстановления. Эта строка может иметь один из двух форматов. В случае восстановления на месте введите в строке одну группу полей, разделённых двоеточиями. Например: Для восстановления в новое место введите две группы полей, разделённых пробелом в строке. Требуемый пробел обозначается SPACE. Не добавляйте дополнительных пробелов.
Примеры Восстановление одного зеркала на прежнее место. Восстановление одного зеркала на новый хост. Получение образца файла Вы можете использовать параметр -o для вывода образца файла конфигурации восстановления, который будет использоваться в качестве отправной точки. |
| -l logfile_directory | Каталог для записи файла журнала. По умолчанию ~/gpAdminLogs. |
| -o output_recover_config_file | Задаёт имя файла и расположение для вывода образца файла конфигурации восстановления. В выходном файле перечислены не рабочие в настоящее время сегменты и их расположение для восстановления по умолчанию в формате, который требуется параметром -i. Используйте вместе с параметром -p, чтобы вывести образец файла для восстановления на другом хосте. При необходимости этот файл можно отредактировать, чтобы указать альтернативные места для восстановления. |
| -p new_recover_host[,...] | Задаёт запасной хост вне текущего настроенного массива RT.Warehouse, на котором нужно восстановить вышедшие из строя сегменты. В случае нескольких отказавших хостов сегмента вы можете указать список, разделённый запятыми. На запасном хосте должно быть установлено и настроено программное обеспечение RT.Warehouse, а также должна быть установлена такая же конфигурация оборудования и ОС, как и у хостов текущего сегмента (та же версия ОС, локали, учётная запись пользователя gpadmin, созданные каталоги данных, обмен ключами ssh, количество сетевых интерфейсов, соглашение об именах сетевых интерфейсов и т.д.). |
| -q | Работать в тихом режиме. Вывод команды не отображается на экране, но всё равно записывается в файл журнала. |
| -r | После восстановления сегмента инстансы сегмента не могут быть возвращены в предпочтительную роль, которую они получили во время инициализации системы. Это может оставить систему в потенциально несбалансированном состоянии, поскольку некоторые хосты сегментов могут иметь больше активных сегментов, чем оптимально для максимальной производительности системы. Этот параметр перебалансирует основные и зеркальные сегменты, возвращая им их предпочтительные роли. Все сегменты должны быть действительными и синхронизированными перед запуском gprecoverseg -r. Если есть какие-либо незавершённые запросы, они будут отменены и откачены назад. |
| -s | Показывать прогресс pg_basebackup последовательно, а не in-place. Полезно при записи в файл или если tty не поддерживает escape-последовательности. По умолчанию прогресс отображается in-place. |
| --no-progress | Не отображать отчёты о ходе выполнения от утилиты pg_basebackup. По умолчанию отображается прогресс базового резервного копирования. |
| -v | Устанавливает подробный (verbose) вывод журнала. |
| --version | Отображает версию этой утилиты. |
| -? (help) | Отображает интерактивную справку. |
Восстановить все отказавшие инстансы сегмента на месте:
$ gprecoversegПеребалансировать свою систему RT.Warehouse после восстановления, вернув все сегменты к их предпочтительной роли. Сначала убедиться, что все сегменты включены и синхронизированы.
$ gpstate -m
$ gprecoverseg -rВосстановить все вышедшие из строя инстансы сегмента на вновь настроенный хост резервного сегмента:
$ gprecoverseg -i recover_config_fileВывести файл конфигурации восстановления по умолчанию:
$ gprecoverseg -o /home/gpadmin/recover_config_fileПерезагружает данные таблицы RT.Warehouse, сортируя данные по указанным столбцам.
gpreload -d database [-p port] {-t | --table-file} path_to_file [-a]
gpreload -h
gpreload --versionУтилита gpreload перезагружает данные таблицы с отсортированными данными столбцов. Для таблиц, которые были созданы с параметром хранения таблиц appendoptimized=TRUE и включённым сжатием, перезагрузка данных с отсортированными данными может улучшить сжатие таблицы. Вы указываете список таблиц, которые нужно перезагрузить, и столбцы таблицы, которые нужно отсортировать, в текстовом файле.
Сжатие улучшается за счёт сортировки данных, когда данные в столбце имеют относительно небольшое количество различных значений по сравнению с общим количеством строк.
Для перезагружаемой таблицы порядок сортировки столбцов может повлиять на сжатие. Столбцы с наименьшим количеством различных значений должны быть перечислены первыми. Например, если указать штат, а затем город, сжатие будет лучше, чем если указать город и штат.
public.cust_table: state, city
public.cust_table: city, stateДля получения информации о формате файла, используемого с gpreload, см. параметр --table-file.
Чтобы повысить производительность перезагрузки, перед перезагрузкой данных необходимо удалить индексы перезагружаемых таблиц.
Выполнение команды ANALYZE после перезагрузки данных таблицы может потребовать производительности из-за изменения в распределении данных перезагруженных данных.
Для каждой таблицы утилита копирует данные таблицы во временную таблицу, обрезает существующие данные таблицы и вставляет данные из временной таблицы в таблицу в указанном порядке сортировки. Каждая перезагрузка таблицы выполняется за одну транзакцию.
Для партиционированной таблицы вы можете перезагрузить данные дочерней leaf-партиции. Однако данные вставляются из корневой партиции таблицы, которая получает блокировку ROW EXCLUSIVE для всей таблицы.
Таблица 48 — Параметры gpreload
|
Параметр |
Описание |
|---|---|
| -a | Опционально. Если параметр указан, утилита gpreload не запрашивает подтверждения у пользователя. |
| -d database | База данных, содержащая таблицы для перезагрузки. Утилита gpreload подключается к базе данных как пользователь, запускающий утилиту. |
| -p port | Порт мастера RT.Warehouse. Если параметр не указан, используется значение переменной среды PGPORT. Если значение недоступно, возвращается ошибка. |
| {-t | --table-file } path_to_file |
Местоположение и имя файла, содержащего список имён таблиц с указанием схемы для перезагрузки и имена столбцов для изменения порядка из RT.Warehouse. Поддерживаются только определённые пользовательские таблицы. Представления или таблицы системного каталога не поддерживаются. Если для таблицы, указанной в файле, определены индексы, gpreload предложит продолжить. В каждой строке указывается имя таблицы и список столбцов для сортировки. Данный формат требуется для каждой строки в файле: За именем таблицы следует двоеточие (:), а затем хотя бы одно имя столбца. Если вы указываете более одного столбца, разделяйте имена столбцов запятыми. Столбцы сортируются по возрастанию. Укажите ключевое слово desc после имени столбца, чтобы отсортировать столбец в порядке убывания. Подстановочные символы не поддерживаются. Если в файле есть ошибки, gpreload сообщает о первой ошибке и завершает работу. Никакие данные не перезагружаются. В следующем примере перезагружаются три таблицы: В первой таблице public.clients данные в столбце rep_id отсортированы по убыванию. Данные в других столбцах отсортированы по возрастанию. |
| --version | Отображает версию этой утилиты. |
| -? | Отображает интерактивную справку. |
В этом примере команда перезагружает таблицы в базе данных mytest, перечисленные в файле data-tables.txt.
gpreload -d mytest --table-file data-tables.txtВосстановите резервную копию RT.Warehouse, созданную с помощью утилиты gpbackup. По умолчанию gprestore использует резервные копии файлов метаданных и файлов DDL, расположенных в каталоге данных хоста мастера RT.Warehouse, с табличными данными, хранящимися локально на хостах сегментов в файлах данных CSV.
gprestore --timestamp YYYYMMDDHHMMSS
[--backup-dir directory]
[--create-db]
[--debug]
[--exclude-schema schema_name]
[--exclude-table schema.table]
[--exclude-table-file file_name]
[--include-schema schema_name]
[--include-table schema.table]
[--include-table-file file_name]
[--data-only | --metadata-only]
[--jobs int]
[--on-error-continue]
[--plugin-config config_file_location]
[--quiet]
[--redirect-db database_name]
[--verbose]
[--version]
[--with-globals]
[--with-stats]
gprestore --helpЧтобы использовать gprestore для восстановления из набора резервных копий, необходимо включить параметр --timestamp, чтобы указать точное значение метки времени (YYYYMMDDHHMMSS) восстанавливаемого набора резервных копий. Если вы указали настраиваемый --backup-dir для объединения файлов резервных копий, включите тот же параметр --backup-dir с gprestore, чтобы найти файлы резервных копий.
Если указанная вами резервная копия является инкрементной, вам понадобится полный набор файлов резервных копий (полная резервная копия и все необходимые инкрементные резервные копии). gprestore гарантирует, что полный набор резервных копий доступен перед попыткой восстановления резервной копии.
|
Внимание. Для наборов инкрементных резервных копий резервные копии должны быть на одном устройстве. Например, весь набор резервных копий должен находиться в системе Data Domain. |
При восстановлении из набора резервных копий gprestore выполняет восстановление в базу данных с тем же именем, что и имя, указанное при создании набора резервных копий. Если целевая база данных существует и восстанавливаемая таблица существует в базе данных, операция восстановления не выполняется. Включите параметр --create-db, если целевая база данных не существует в кластере. При желании вы можете восстановить набор резервных копий в другую базу данных с помощью параметра --redirect-db.
При восстановлении набора резервных копий, который содержит данные из некоторых leaf-партиций партиционированных таблиц, партиционированная таблица восстанавливается вместе с данными для leaf-партиций. Например, вы создаёте резервную копию с параметром gpbackup --include-table-file, и в текстовом файле перечислены некоторые leaf-партиции партиционированной таблицы. При восстановлении резервной копии создаётся партиционированная таблица и восстанавливаются данные только для leaf-партиций, перечисленных в файле.
Системные объекты RT.Warehouse автоматически включаются в набор резервных копий gpbackup, но эти объекты восстанавливаются только в том случае, если вы включили параметр --with-globals в gprestore. Точно так же, если вы создали резервную копию статистики плана запроса с помощью параметра --with-stats, вы можете восстановить эту статистику, указав --with-stats для gprestore. По умолчанию восстанавливаются только объекты базы данных из резервного набора.
Производительность операций восстановления можно повысить, создав несколько параллельных соединений для восстановления табличных данных и метаданных. По умолчанию gprestore использует 1 соединение, но вы можете увеличить это число с помощью параметра --jobs для больших операций восстановления.
Когда операция восстановления завершается, gprestore возвращает код состояния.
gprestore может отправлять уведомления о статусе по электронной почте после завершения операции резервного копирования. Вы указываете, когда утилита отправляет почту, и получателей электронной почты в файле конфигурации.
|
Примечание. Эта утилита использует соединения защищенной оболочки (SSH) между системами для выполнения своих задач. В больших развёртываниях RT.Warehouse, облачных развёртываниях или развёртываниях с большим количеством сегментов на хост эта утилита может превышать максимальный порог хоста для неаутентифицированных соединений. Рассмотрите возможность обновления параметра конфигурации SSH MaxStartups, чтобы увеличить этот лимит. |
Таблица 49 — Параметры gprestore
|
Параметр |
Описание |
|---|---|
| --timestamp YYYYMMDDHHMMSS | Обязательный. Задаёт метку времени для восстанавливаемого набора резервных копий gpbackup. По умолчанию gprestore пытается найти файлы метаданных для отметки времени на хосте мастера RT.Warehouse в каталоге $MASTER_DATA_DIRECTORY/backups/YYYYMMDD/YYYYMMDDhhmmss/ и файлы данных CSV в каталоге хоста каждого сегмента <seg_dir>/backups/YYYYMYMDMss/YYYYMYMDSS. |
| --backup-dir directory | Опциональный. Источник всех файлов резервных копий (файлов метаданных и файлов данных) из указанного каталога. Вы должны указать каталог как абсолютный путь (не относительный). Если вы не укажете этот параметр, gprestore попытается найти файлы метаданных для метки времени на хосте мастера RT.Warehouse в каталоге $MASTER_DATA_DIRECTORY/backups/YYYYMMDD/YYYYMMDDhhmmss/. Файлы данных CSV должны быть доступны в каталоге каждого сегмента <seg_dir>/backups/YYYYMMDD/YYYYMMDDhhmmss/. Включите этот параметр при указании настраиваемого каталога резервного копирования с помощью gpbackup. Этот параметр нельзя комбинировать с параметром --plugin-config. |
| --create-db | Опциональный. Создаёт базу данных перед восстановлением метаданных объекта базы данных. База данных создаётся путём клонирования пустой стандартной системной базы данных template0. |
| --data-only | Опциональный. Восстанавливает данные таблиц из резервной копии, созданной с помощью утилиты gpbackup, без создания таблиц базы данных. Этот параметр предполагает, что таблицы существуют в целевой базе данных. Чтобы восстановить данные для определённого набора таблиц из набора резервных копий, вы можете указать параметр для включения таблиц или схем или исключения таблиц или схем. Укажите параметр --with-stats, чтобы восстановить статистику таблиц из резервной копии. Набор резервных копий должен содержать данные таблицы, которые необходимо восстановить. Например, резервная копия, созданная с параметром gpbackup --metadata-only, не содержит табличных данных. Чтобы восстановить только таблицы базы данных без восстановления данных таблицы, см. параметр --metadata-only. |
| --debug | Опциональный. Отображает подробные сообщения и сообщения журнала отладки во время операции восстановления. |
| --exclude-schema schema_name | Опциональный. Задаёт схему базы данных, которую нужно исключить из операции восстановления. Вы можете указать этот параметр несколько раз, чтобы исключить несколько схем. Вы не можете комбинировать этот параметр с параметром --include-schema или параметром фильтрации таблиц, таким как --include-table. |
| --exclude-table schema.table | Опциональный. Задаёт таблицу, которую нужно исключить из операции восстановления. Таблица должна быть в формате <schema-name>.<table-name>. Если в имени таблицы или схемы используется какой-либо символ, кроме строчной буквы, числа или символа подчёркивания, то вы должны заключить это имя в двойные кавычки. Вы можете указать эту опцию несколько раз. Если таблицы нет в резервном наборе, операция восстановления завершится неудачно. Вы не можете указать leaf-партицию партиционированной таблицы. Вы не можете комбинировать этот параметр с параметром --exclude-schema или другим параметром фильтрации таблицы, например --include-table. |
| --exclude-table-file file_name | Опциональный. Задаёт текстовый файл, содержащий список таблиц, которые следует исключить из операции восстановления. Каждая строка в текстовом файле должна определять одну таблицу в формате <schema-name>.<table-name>. Файл не должен содержать завершающих строк. Если в имени таблицы или схемы используется какой-либо символ, кроме строчной буквы, числа или символа подчёркивания, то вы должны заключить это имя в двойные кавычки. Если таблицы нет в резервном наборе, операция восстановления завершится ошибкой. Вы не можете указать leaf-партицию партиционированной таблицы. Вы не можете комбинировать этот параметр с параметром --exclude-schema или другим параметром фильтрации таблицы, например --include-table. |
| --include-schema schema_name | Опциональный. Задаёт схему базы данных для восстановления. Вы можете указать этот параметр несколько раз, чтобы включить несколько схем. Если вы укажете этот параметр, все указанные вами схемы должны быть доступны в резервном наборе. Любые схемы, которые не включены в последующие параметры --include-schema, исключаются из операции восстановления. Если схема, которую вы указываете для включения, существует в базе данных, утилита выдаёт ошибку и продолжает операцию. Утилита не работает, если восстанавливаемая таблица существует в базе данных. Вы не можете использовать эту опцию, если объекты в наборе резервных копий зависят от нескольких схем. |
| --include-table schema.table | Опциональный. Задаёт таблицу для восстановления. Таблица должна быть в формате <schema-name>.<table-name>. Если в имени таблицы или схемы используется какой-либо символ, кроме строчной буквы, числа или символа подчёркивания, то вы должны заключить это имя в двойные кавычки. Вы можете указать эту опцию несколько раз. Вы не можете указать leaf-партицию партиционированной таблицы. Вы также можете указать полное имя последовательности или представления. Если вы укажете эту опцию, утилита не будет автоматически восстанавливать зависимые объекты. Вы также должны явно указать требуемые зависимые объекты. Например, если вы восстанавливаете представление, вы должны также восстановить таблицы, которые оно использует. Если вы восстанавливаете таблицу, в которой используется последовательность, вы также должны восстановить последовательность. Зависимые объекты должны существовать в резервном наборе. Этот параметр нельзя комбинировать с параметром фильтрации схемы, например --include-schema, или другим параметром фильтрации таблиц, например --exclude-table-file. |
| --include-table-file file_name | Опциональный. Задаёт текстовый файл, содержащий список таблиц для восстановления. Каждая строка в текстовом файле должна определять одну таблицу в формате <schema-name>.<table-name>. Файл не должен содержать завершающих строк. Если в имени таблицы или схемы используется любой символ, кроме строчной буквы, числа или символа подчёркивания, то вы должны заключить это имя в двойные кавычки. Любые таблицы, не перечисленные в этом файле, исключаются из операции восстановления. Вы не можете указать leaf-партицию партиционированной таблицы. Вы также можете указать полное имя последовательности или представления. Если вы укажете эту опцию, утилита не будет автоматически восстанавливать зависимые объекты. Вы также должны явно указать требуемые зависимые объекты. Например, если вы восстанавливаете представление, вы также должны указать таблицы, которые оно использует. Если вы указываете таблицу, в которой используется последовательность, вы также должны указать последовательность. Зависимые объекты должны существовать в резервном наборе. Если вы используете параметр --include-table-file, gprestore не создаёт роли и не устанавливает владельца таблиц. Утилита восстанавливает индексы и правила таблиц. Триггеры также восстанавливаются, но не поддерживаются в RT.Warehouse. |
| --jobs int |
Опциональный. Задаёт количество параллельных подключений для использования при восстановлении табличных данных и метаданных. По умолчанию gprestore использует 1 соединение. Увеличение этого числа может повысить скорость восстановления данных. Примечание. Если вы использовали параметр gpbackup --single-data-file для объединения резервных копий таблиц в один файл для каждого сегмента, вы не можете установить для параметра --jobs значение выше 1 для выполнения операции параллельного восстановления. |
| --metadata-only | Опциональный. Создаёт таблицы базы данных из резервной копии, созданной с помощью утилиты gpbackup, но не восстанавливает данные таблицы. Этот параметр предполагает, что таблицы не существуют в целевой базе данных. Чтобы создать определённый набор таблиц из резервного набора, вы можете указать параметр для включения таблиц или схем или исключения таблиц или схем. Укажите параметр --with-globals, чтобы восстановить системные объекты RT.Warehouse. Набор резервных копий должен содержать DDL для таблиц, подлежащих восстановлению. Например, резервная копия, созданная с параметром gpbackup --data-only, не содержит DDL для таблиц. Чтобы восстановить данные таблицы после создания таблиц базы данных, см. параметр --data-only. |
| --on-error-continue | Опциональный. Укажите этот параметр, чтобы продолжить операцию восстановления в случае возникновения ошибки SQL при создании метаданных базы данных (таких как таблицы, роли или функции) или при восстановлении данных. Если возникает ошибка другого типа, утилита закрывается. Утилита отображает сводку ошибок и записывает информацию об ошибках в файл журнала gprestore и продолжает операцию восстановления. По умолчанию выход выполняется при первой ошибке. |
| --plugin-config config-file_location | Укажите расположение файла конфигурации подключаемого модуля gpbackup, текстового файла в формате YAML. Файл содержит информацию о конфигурации для приложения подключаемого модуля, которое gprestore использует во время операции восстановления. Если вы укажете параметр --plugin-config при резервном копировании базы данных, вы должны указать эту опцию с информацией о конфигурации для соответствующего приложения подключаемого модуля при восстановлении базы данных из резервной копии. Этот параметр нельзя комбинировать с параметром --backup-dir. |
| --quiet | Опциональный. Подавить все сообщения журнала без предупреждений и ошибок. |
| --redirect-db database_name | Опциональный. Восстановление в указанную database_name вместо базы данных, для которой была создана резервная копия. |
| --verbose | Опциональный. Отображает подробные сообщения журнала во время операции восстановления. |
| --version | Опциональный. Распечатывает номер версии и завершается. |
| --with-globals | Опциональный. Восстанавливает системные объекты RT.Warehouse из набора резервных копий в дополнение к объектам базы данных. |
| --with-stats | Опциональный. Восстанавливает статистику плана запроса из резервного набора. |
| --help | Отображает интерактивную справку. |
Один из этих кодов возвращается после завершения работы gprestore:
- 0 — восстановление выполнено без проблем;
- 1 — восстановление завершено с нефатальными ошибками;
- 2 — восстановление завершилось фатальной ошибкой.
Создать базу данных demo и восстановить все схемы и таблицы в резервном наборе для указанной временной метки:
$ dropdb demo
$ gprestore --timestamp 20171103152558 --create-dbВосстановить набор резервных копий в базе данных demo2 вместо базы данных demo, для которой была создана резервная копия:
$ createdb demo2
$ gprestore --timestamp 20171103152558 --redirect-db demo2Восстановить глобальные метаданные RT.Warehouse и статистику плана запроса в дополнение к объектам базы данных:
$ gprestore --timestamp 20171103152558 --create-db --with-globals --with-statsВосстановить, используя файлы резервных копий, которые были созданы в каталоге /home/gpadmin/backup, создав 8 параллельных подключений:
$ gprestore --backup-dir /home/gpadmin/backups/ --timestamp 20171103153156 --create-db --jobs 8Восстановить только схему wikipedia, включённую в набор резервных копий:
$ dropdb demo
$ gprestore --include-schema wikipedia --backup-dir /home/gpadmin/backups/ --timestamp 20171103153156 --create-dbЕсли вы выполняете восстановление из набора инкрементных резервных копий, все необходимые файлы в наборе резервных копий должны быть доступны для gprestore. Например, следующие ключи отметок времени указывают набор добавочных резервных копий. 20170514054532 — это полная резервная копия, а остальные — инкрементные.
20170514054532 (full backup)
20170714095512
20170914081205
20171114064330
20180114051246Следующая команда gprestore указывает метку времени 20121114064330. Для выполнения восстановления должна быть доступна инкрементная резервная копия с метками времени 20120714095512 и 20120914081205 и полная резервная копия.
gprestore --timestamp 20121114064330 --redirect-db mystest --create-dbКопирует файлы сразу между несколькими хостами.
gpscp { -f hostfile_gpssh | -h hostname [-h hostname ...] }
[-J character] [-v] [[user@]hostname:]file_to_copy [...]
[[user@]hostname:]copy_to_path
gpscp -?
gpscp --versionУтилита gpscp позволяет копировать один или несколько файлов с указанных хостов на другие указанные хосты одной командой, используя SCP (безопасное копирование, secure copy). Например, вы можете скопировать файл с хоста мастера RT.Warehouse на все хосты сегментов одновременно.
Чтобы указать хосты, участвующие в сеансе SCP, используйте параметр ‑f, чтобы указать файл, содержащий список имён хостов, или используйте параметр -h, чтобы указать имена отдельных хостов в командной строке. Требуется хотя бы одно имя хоста (-h) или файл хоста (‑f). Параметр -J позволяет вам указать один символ для замены hostname в copy from и copy to строки назначения. Если -J не указан, символ подстановки по умолчанию — знак равенства (=). Например, следующая команда скопирует .bashrc с локального хоста в /home/gpadmin на всех хостах, указанных в hostfile_gpssh:
gpscp -f hostfile_gpssh .bashrc =:/home/gpadminЕсли имя пользователя не указано в списке хостов или с user@ в пути к файлу, gpscp скопирует файлы как текущий авторизованный пользователь. Чтобы определить текущего пользователя, вошедшего в систему, выполните команду whoami. По умолчанию gpscp переходит к $HOME пользователя сеанса на удалённых хостах после входа в систему. Чтобы файл был скопирован в правильное место на удалённых хостах, рекомендуется использовать абсолютные пути.
Перед использованием gpscp вы должны настроить доверенный доступ между хостами, участвующими в сеансе SCP. Вы можете использовать утилиту gpssh-exkeys для обновления известных файлов хоста и обмена открытыми ключами между хостами, если вы этого еще не сделали.
Таблица 50 — Параметры gpscp
|
Параметр |
Описание |
|---|---|
| -f hostfile_gpssh |
Задаёт имя файла, содержащего список хостов, которые будут участвовать в этом сеансе SCP. Синтаксис файла хоста — по одному хосту в строке следующим образом: <hostname> |
| -h hostname | Задаёт одно имя хоста, который будет участвовать в этом сеансе SCP. Вы можете использовать параметр -h несколько раз, чтобы указать несколько имён хостов. |
| -J character | Параметр -J позволяет указать один символ для замены имени хоста в строках назначения и копировании из них. Если -J не указан, символ подстановки по умолчанию — знак равенства (=). |
| -v | Опционально. Сообщает дополнительные сообщения в дополнение к выходным данным команды SCP. |
| file_to_copy | Обязательный. Имя файла (или абсолютный путь) к файлу, который вы хотите скопировать на другие хосты (или места расположения файлов). Это может быть файл на локальном хосте или на другом названном хосте. |
| copy_to_path | Обязательный. Путь, по которому вы хотите скопировать файл(ы) на указанные хосты. Если абсолютный путь не используется, файл будет скопирован относительно $HOME пользователя сеанса. Вы также можете использовать знак равенства '=' (или другой символ, указанный вами с параметром -J) вместо hostname. Затем это будет заменено на каждое имя хоста, указанное в предоставленном файле хоста (-f) или с параметром -h. |
| -? | Отображает интерактивную справку. |
| --version | Отображает версию этой утилиты. |
Скопировать файл с именем installer.tar на все хосты в файл hostfile_gpssh.
gpscp -f hostfile_gpssh installer.tar =:/Скопировать файл с именем myfuncs.so в указанное место на хостах с именами sdw1 и sdw2:
gpscp -h sdw1 -h sdw2 myfuncs.so =:/usr/local/greenplum-db/libОбеспечивает SSH-доступ сразу к нескольким хостам.
gpssh { -f hostfile_gpssh | - h hostname [-h hostname ...] } [-s] [-e]
[-d seconds] [-t multiplier] [-v]
[bash_command]
gpssh -?
gpssh --versionУтилита gpssh позволяет запускать команды bash-оболочки на нескольких хостах одновременно, используя SSH (secure shell). Вы можете выполнить одну команду, указав её в командной строке, или перевести команду для входа в интерактивный сеанс командной строки.
Чтобы указать хосты, участвующие в сеансе SSH, используйте параметр ‑f, чтобы указать файл, содержащий список имён хостов, или используйте параметр -h, чтобы указать имена отдельных хостов в командной строке. Требуется хотя бы одно имя хоста (-h) или файл хоста (‑f). Обратите внимание, что текущий хост не включён в сеанс по умолчанию, чтобы включить локальный хост, вы должны явно объявить его в списке хостов, участвующих в сеансе.
Перед использованием gpssh необходимо настроить доверенный доступ между хостами, участвующими в сеансе SSH. Вы можете использовать утилиту gpssh-exkeys для обновления известных файлов хоста и обмена открытыми ключами между хостами, если вы этого ещё не сделали.
Если вы не укажете команду в командной строке, gpssh перейдёт в интерактивный режим. В командной строке gpssh (=>) вы можете ввести команду, как в обычной командной строке терминала bash, и команда будет выполняться на всех хостах, участвующих в сеансе. Чтобы завершить интерактивный сеанс, нажмите CTRL + D на клавиатуре или введите exit или quit.
Если имя пользователя не указано в файле хоста, gpssh будет выполнять команды от имени текущего вошедшего в систему пользователя. Чтобы определить текущего пользователя, вошедшего в систему, выполните команду whoami. По умолчанию gpssh переходит в $HOME пользователя сеанса на удалённых хостах после входа в систему. Чтобы команды выполнялись правильно на всех удалённых хостах, вы всегда должны вводить абсолютные пути.
Если вы столкнулись с проблемами тайм-аута сети при использовании gpssh, вы можете использовать параметры -d и -t или установить параметры в файле gpssh.conf для управления временем, которое gpssh использует при проверке начального ssh-соединения. Для получения информации о файле конфигурации см. Файл конфигурации gpssh.
Таблица 51 — Параметры gpssh
|
Параметр |
Описание |
|---|---|
| bash_command | Команда оболочки bash, выполняемая на всех хостах, участвующих в этом сеансе (необязательно заключена в кавычки). Если не указан, gpssh запускает интерактивный сеанс. |
| -d seconds |
Опционально. Задаёт время ожидания в секундах перед началом взаимодействия gpssh с ssh. По умолчанию — 0.05. Этот параметр переопределяет значение delaybeforesend, указанное в файле конфигурации gpssh.conf. Увеличение этого значения может вызвать длительное время ожидания во время запуска gpssh. |
| -e | Опционально. Отображает команды, переданные каждому хосту, и их результат при работе в неинтерактивном режиме. |
| -f hostfile_gpssh | Задаёт имя файла, содержащего список хостов, которые будут участвовать в этом сеансе SSH. Синтаксис файла хоста — по одному хосту на строку. |
| -h hostname | Задаёт одно имя хоста, который будет участвовать в этом сеансе SSH. Вы можете использовать параметр -h несколько раз, чтобы указать несколько имён хостов. |
| -s | Опционально. Если параметр указан, перед выполнением любых команд на целевом хосте, gpssh отправляет файл greenplum_path.sh в каталог, указанный в переменной среды $GPHOME. Этот параметр действителен как для интерактивного режима, так и для однокомандного режима. |
| -t multiplier | Опционально. Десятичное число больше 0 (нуля), которое является множителем для тайм-аута, который gpssh использует при проверке валидации ssh. По умолчанию — 1. Этот параметр переопределяет значение prompt_validation_timeout, указанное в файле конфигурации gpssh.conf. Увеличение этого значения имеет небольшое влияние во время запуска gpssh. |
| -v | Опционально. Сообщает дополнительные сообщения в дополнение к выходным данным команды при работе в неинтерактивном режиме. |
| --version | Отображает версию этой утилиты. |
| -? (help) | Отображает интерактивную справку. |
Файл gpssh.conf содержит параметры, позволяющие настроить время, которое gpssh использует при проверке начального ssh-соединения. Эти параметры влияют на сетевое соединение до того, как сеанс gpssh выполнит команды с ssh. Расположение файла определяется переменной среды MASTER_DATA_DIRECTORY. Если переменная среды не определена или файл gpssh.conf не существует, gpssh использует значения по умолчанию или значения, установленные с помощью параметров -d и -t.
Файл gpssh.conf — это текстовый файл, состоящий из раздела [gpssh] и параметров. В строке # (знак решётки) обозначает начало комментария. Это пример файла gpssh.conf.
[gpssh]
delaybeforesend = 0.05
prompt_validation_timeout = 1.0
sync_retries = 5Таблица 52 — Параметры gpssh.conf
|
Параметр |
Описание |
|---|---|
| delaybeforesend = seconds | Задаёт время ожидания в секундах до начала взаимодействия gpssh с ssh. По умолчанию — 0.05. Увеличение этого значения может вызвать длительное время ожидания при запуске gpssh. Параметр -d переопределяет этот параметр. |
| prompt_validation_timeout = multiplier | Десятичное число больше 0 (нуля), которое является множителем для тайм-аута, который gpssh использует при проверке приглашения ssh. Увеличение этого значения оказывает небольшое влияние на запуск gpssh. По умолчанию — 1. Параметр -t переопределяет этот параметр. |
| sync_retries = attempts | Неотрицательное целое число, указывающее максимальное количество попыток gpssh подключения к удалённому хосту RT.Warehouse. По умолчанию — 3. Если значение равно 0, gpssh возвращает ошибку, если первоначальная попытка подключения не удалась. Увеличение количества попыток также увеличивает время между повторами попыток. Этот параметр нельзя настроить с помощью параметра командной строки. Параметр -t также влияет на время между повторами попыток. Увеличение этого значения может компенсировать низкую производительность сети или проблемы с производительностью хоста сегмента, такие как высокая загрузка ЦПУ или ввода-вывода. Однако, если соединение не может быть установлено, увеличенное значение также увеличивает задержку при возврате ошибки. |
Запустить интерактивный групповой сеанс SSH со всеми хостами, перечисленными в файле hostfile_gpssh:
$ gpssh -f hostfile_gpsshВ интерактивной командной строке gpssh запустить shell-команду на всех хостах, участвующих в этом сеансе.
=> ls -a /data/primary/*Выйти из интерактивного сеанса:
=> exit
=> quitЗапустить неинтерактивный групповой сеанс SSH с хостами с именами sdw1 и sdw2 и передать gpssh файл, содержащий несколько команд с именем command_file:
$ gpssh -h sdw1 -h sdw2 -v -e < command_fileВыполнить одиночные команды в неинтерактивном режиме на хостах sdw2 и localhost:
$ gpssh -h sdw2 -h localhost -v -e 'ls -a /data/primary/*'
$ gpssh -h sdw2 -h localhost -v -e 'echo $GPHOME'
$ gpssh -h sdw2 -h localhost -v -e 'ls -1 | wc -l'Обменивается открытыми SSH-ключами между хостами.
gpssh-exkeys -f hostfile_exkeys | -h hostname [-h hostname ...]
gpssh-exkeys -e hostfile_exkeys -x hostfile_gpexpand
gpssh-exkeys -?
gpssh-exkeys --versionУтилита gpssh-exkeys обменивается SSH-ключами между указанными именами хостов (или адресами хостов). Это позволяет устанавливать SSH-соединения между хостами RT.Warehouse и сетевыми интерфейсами без запроса пароля. Утилита используется для первоначальной подготовки системы RT.Warehouse для доступа по SSH без пароля, а также для подготовки дополнительных хостов для доступа по SSH без пароля при расширении системы RT.Warehouse.
Ключи обмениваются как текущий авторизованный пользователь. Вы запускаете утилиту на хосте мастера как пользователь gpadmin (пользователь, которому назначена ваша установка RT.Warehouse). Утилиты управления RT.Warehouse требуют, чтобы пользователь gpadmin был создан на всех хостах в системе RT.Warehouse, а утилиты должны иметь возможность подключаться от имени этого пользователя ко всем хостам без запроса пароля.
Вы также можете использовать gpssh-exkeys для включения SSH без пароля для дополнительных пользователей, например, root.
Утилита gpssh-exkeys имеет следующие предварительные требования:
Вы можете включить "1-n passwordless SSH" с помощью команды ssh-copy-id, чтобы добавить открытый ключ пользователя в файл authorized_keys каждого хоста. Утилита gpssh-exkeys включает "n-n passwordlessSSH", что позволяет пользователю подключаться по SSH с любого хоста к любому другому хосту в кластере без пароля.
Чтобы указать хосты, участвующие в обмене ключами SSH, используйте параметр -f, чтобы указать файл, содержащий список имён хостов (рекомендуется), или используйте параметр -h, чтобы указать имена отдельных хостов в командной строке. Требуется хотя бы одно имя хоста (‑h) или файл хоста (-f). Обратите внимание, что локальный хост включён в обмен ключами по умолчанию.
Чтобы указать новые хосты расширения, которые будут добавлены в существующую систему RT.Warehouse, используйте параметры -e и ‑x. Параметр -e указывает файл, содержащий список существующих хостов в системе, которые постоянно обменивались ключами SSH. Параметр -x указывает файл, содержащий список новых хостов, которые должны участвовать в обмене ключами SSH.
Утилита gpssh-exkeys выполняет обмен ключами, используя следующие шаги:
Таблица 53— Параметры gpssh-exkeys
|
Параметр |
Описание |
|---|---|
| -e hostfile_exkeys | При расширении системы это имя и расположение файла, содержащего все настроенные имена хостов и адреса хостов (имена интерфейсов) для каждого хоста в вашей текущей системе RT.Warehouse (мастера, резервного мастера и сегментов), по одному имени в строке без пустых строк или лишних пробелов. Хосты, указанные в этом файле, не могут быть указаны в файле хоста, используемом с -x. |
| -f hostfile_exkeys | Задаёт имя и расположение файла, содержащего все настроенные имена хостов и адреса хостов (имена интерфейсов) для каждого хоста в вашей системе RT.Warehouse (мастера, резервного мастера и сегментов), по одному имени в строке без пустых строк или лишних пробелов. |
| -h hostname | Задаёт одно имя хоста (или адрес хоста), которое будет участвовать в обмене ключами SSH. Вы можете использовать параметр -h несколько раз, чтобы указать несколько имён хостов и адресов хостов. |
| --version | Отображает версию этой утилиты. |
| -x hostfile_gpexpand | При расширении системы это имя и расположение файла, содержащего все настроенные имена хостов и адреса хостов (имена интерфейсов) для каждого нового хоста сегмента, который вы добавляете в свою систему RT.Warehouse, по одному имени в строке без пустых строк или лишних пробелов. Хосты, указанные в этом файле, не могут быть указаны в файле хоста, используемом с -e. |
| -? | Отображает интерактивную справку. |
Обменяться ключами SSH между всеми именами хостов и адресами, перечисленными в файле hostfile_exkeys:
$ gpssh-exkeys -f hostfile_exkeysОбменяться ключами SSH между хостами sdw1, sdw2 и sdw3:
$ gpssh-exkeys -h sdw1 -h sdw2 -h sdw3Обменяться ключами SSH между существующими хостами sdw1, sdw2 и sdw3 и новыми хостами sdw4 и sdw5 в рамках операции расширения системы:
$ cat hostfile_exkeys
mdw
mdw-1
mdw-2
smdw
smdw-1
smdw-2
sdw1
sdw1-1
sdw1-2
sdw2
sdw2-1
sdw2-2
sdw3
sdw3-1
sdw3-2
$ cat hostfile_gpexpand
sdw4
sdw4-1
sdw4-2
sdw5
sdw5-1
sdw5-2
$ gpssh-exkeys -e hostfile_exkeys -x hostfile_gpexpandЗапускает систему RT.Warehouse.
gpstart [-d master_data_directory] [-B parallel_processes] [-R]
[-m] [-y] [-a] [-t timeout_seconds] [-l logfile_directory]
[--skip-heap-checksum-validation]
[-v | -q]
gpstart -? | -h | --help
gpstart --versionУтилита gpstart используется для запуска процессов сервера RT.Warehouse. Когда вы запускаете систему RT.Warehouse, вы фактически запускаете сразу несколько процессов слушателя сервера баз данных postgres (мастер и все инстансы сегментов). Утилита gpstart обрабатывает запуск отдельных инстансов. Каждый инстанс запускается параллельно.
При первом запуске администратор запускает утилиту gpstart, утилита создает файл кэша хостов с именем .gphostcache в домашнем каталоге пользователя. Впоследствии утилита использует этот список хостов для более эффективного запуска системы. Если в систему добавляются новые хосты, вы должны вручную удалить этот файл из домашнего каталога пользователя gpadmin. Утилита создаст новый файл кэша хостов при следующем запуске.
Как часть процесса запуска, утилита проверяет согласованность настройки контрольной суммы кучи (heap) между инстансом мастера RT.Warehouse и инстансами сегмента, включённых или отключённых на всех инстансах. Если контрольная сумма heap в инстансах различается, возвращается ошибка, и RT.Warehouse не запускается. Проверка может быть отключена, указав параметр --skip-heap-checkum-validation.
|
Примечание. Прежде чем вы сможете запустить систему RT.Warehouse, вы должны инициализировать систему с помощью gpinitsystem. Включение или отключение контрольных сумм heap устанавливается при инициализации системы и не может быть изменено после инициализации. |
Таблица 54— Параметры gpstart
|
Параметр |
Описание |
|---|---|
| -a | Не запрашивать у пользователя подтверждение. |
| -B parallel_processes | Количество сегментов для параллельного запуска. Если параметр не указан, утилита запустит до 64 параллельных процессов в зависимости от того, сколько инстансов сегмента ей нужно запустить. |
| -d master_data_directory | Опционально. Каталог данных хоста мастера. Если параметр не указан, будет использоваться значение, установленное для $MASTER_DATA_DIRECTORY. |
| -l logfile_directory | Каталог для записи файла журнала. По умолчанию ~/gpAdminLogs. |
| -m |
Опционально. Запускает только инстанс мастера, что может быть полезно для задач обслуживания. Этот режим позволяет подключаться к мастеру только в режиме утилит. Например: Согласованность настройки контрольной суммы кучи (heap) на инстансе мастера и инстансах сегмента не проверяется. |
| -q | Работать в тихом режиме. Вывод команды не отображается на экране, но все равно записывается в файл журнала. |
| -R | Запускает RT.Warehouse в ограниченном режиме (подключение разрешено только суперпользователям базы данных). |
| --skip-heap-checksum-validation |
Во время запуска утилита не проверяет согласованность настройки контрольной суммы кучи (heap) для инстанса мастера RT.Warehouse и инстансов сегмента. По умолчанию гарантируется, что настройка контрольной суммы heap одинакова для всех инстансов, включённых или отключённых. Внимание. Запуск RT.Warehouse без этой проверки может привести к потере данных. Используйте этот параметр для запуска RT.Warehouse только тогда, когда необходимо игнорировать ошибки проверки контрольной суммы кучи для восстановления данных или устранения ошибок. |
| -t timeout_seconds | Задаёт тайм-аут в секундах для ожидания запуска инстанса сегмента. Если инстанс сегмента был аварийно завершён (например, из-за сбоя питания или прерывания процесса слушателя базы данных postgres), запуск может занять больше времени из-за процесса восстановления и проверки базы данных. Если параметр не указан, время ожидания по умолчанию составляет 60 секунд. |
| -v | Отображает подробные сообщения о состоянии, прогрессе и ошибках, выводимые утилитой. |
| -y | Опционально. Не запускать хост резервного мастера. По умолчанию запускается хост резервного мастера и процесс синхронизации. |
| -? | -h | --help | Отображает интерактивную справку. |
| --version | Отображает версию этой утилиты. |
Запустить систему RT.Warehouse:
gpstartЗапустить систему RT.Warehouse в ограниченном режиме (разрешить соединения только суперпользователя):
gpstart -RЗапустить только инстанс мастера RT.Warehouse и подключиться в режиме утилит:
gpstart -m PGOPTIONS='-c gp_session_role=utility' psqlПоказывает состояние работающей системы RT.Warehouse.
gpstate [-d master_data_directory] [-B parallel_processes]
[-s | -b | -Q | -e] [-m | -c] [-p] [-i] [-f] [-v | -q] | -x
[-l log_directory]
gpstate -? | -h | --helpУтилита gpstate отображает информацию о запущенном инстансе RT.Warehouse. Существует дополнительная информация, которую вы можете захотеть узнать о системе RT.Warehouse, поскольку она состоит из нескольких инстансов (сегментов) базы данных PostgreSQL, охватывающих несколько машин. Утилита gpstate предоставляет дополнительную информацию о состоянии системы RT.Warehouse, например:
Таблица 55— Параметры gpstate
|
Параметр |
Описание |
|---|---|
| -b | Опционально. Отображает краткое описание состояния системы RT.Warehouse. Это вариант по умолчанию. |
| -B parallel_processes | Количество сегментов для параллельной проверки. Если параметр не указан, утилита запустит до 60 параллельных процессов в зависимости от того, сколько инстансов сегментов необходимо проверить. |
| -c | Опционально. Отображает маппинг основных сегментов на соответствующие им зеркальные сегменты. |
| -d master_data_directory | Опционально. Каталог данных мастера. Если не указан, будет использоваться значение, установленное для $MASTER_DATA_DIRECTORY. |
| -e |
Показать подробную информацию о парах основных и зеркальных сегментов, которые имеют потенциальные проблемы, такие как:
|
| -f | Отображает сведения о хосте резервного мастера, если он настроен. |
| -i | Отображает информацию о версии программного обеспечения RT.Warehouse для каждого инстанса. |
| -l logfile_directory | Каталог для записи файла журнала. По умолчанию ~/gpAdminLogs. |
| -m | Опционально. Перечисляет инстансы зеркальных сегментов в системе, их текущую роль и состояние синхронизации. |
| -p | Перечисляет номера портов, используемые в системе RT.Warehouse. |
| -q | Опционально. Работать в тихом режиме. За исключением предупреждающих сообщений, вывод команды не отображается на экране. Однако эта информация по-прежнему записывается в файл журнала. |
| -Q | Опционально. Проверяет статус сегмента в системном каталоге на хосте мастера. Не запрашивает статус сегментов. |
| -s | Опционально. Отображает подробную информацию о состоянии системы RT.Warehouse. |
| -v | Опционально. Отображает сообщения об ошибках и выводит подробную информацию о состоянии и прогрессе. |
| -x | Опционально. Отображает подробную информацию о ходе и состоянии расширения системы RT.Warehouse. |
| -? | -h | --help | Отображает интерактивную справку. |
Следующие поля вывода сообщаются gpstate -s для мастера:
Таблица 56— Выходные данные gpstate –s для мастера
|
Выходные данные |
Описание |
|---|---|
| Master host | Имя хоста мастера. |
| Master postgres process ID | PID процесса слушателя базы данных мастера. |
| Master data directory | Расположение в файловой системе каталога данных мастера. |
| Master port | Порт процесса слушателя базы данных postgres мастера. |
| Master current role |
dispatch — обычный режим работы. utility — режим обслуживания. |
| Greenplum array configuration type |
standard — одна сетевая карта (NIC) на хост. multi-home — несколько сетевых карт (NIC) на хост. |
| Greenplum initsystem version | Версия RT.Warehouse при первой инициализации системы. |
| Greenplum current version | Текущая версия RT.Warehouse. |
| Postgres version | Версия PostgreSQL, на которой основана RT.Warehouse. |
| Greenplum mirroring status | Физическое зеркалирование или нет. |
| Master standby | Имя хоста резервного мастера. |
| Standby master state | Статус резервного мастера: активный (active) или пассивный (passive). |
gpstate -s сообщает следующие поля вывода для каждого сегмента:
Таблица 57— Выходные данные gpstate –s для сегментов
|
Выходные данные |
Описание |
|---|---|
| Hostname | Системное имя хоста. |
| Address | Сетевой адрес имени хоста (имя сетевой карты (NIC)). |
| Datadir | Расположение в файловой системе каталога данных сегмента. |
| Port | Номер порта процесса слушателя базы данных postgres. |
| Current Role | Текущая роль сегмента: зеркало (mirror) или основной (primary). |
| Preferred Role | Роль во время инициализации системы: зеркало (mirror) или основной (primary). |
| Mirror Status |
Статус пары основного и зеркального сегментов:
|
| Change tracking data size | В режиме change tracking размер файла журнала изменений (может увеличиваться и уменьшаться по мере применения сжатия). |
| Estimated total data to synchronize | В режиме resynchronization предполагаемый размер данных, оставшихся для синхронизации. |
| Data synchronized | В режиме resynchronization предполагаемый размер данных, которые уже были синхронизированы. |
| Estimated resync progress with mirror | В режиме resynchronization предполагаемый процент завершения. |
| Estimated resync end time | В режиме resynchronization расчётное время для завершения. |
| File postmaster.pid | Статус файла блокировки postmaster.pid: found или missing. |
| PID from postmaster.pid file | PID, найденныйв файле postmaster.pid. |
| Lock files in /tmp | Файл блокировки порта сегмента для его процесса postgres создаётся в /tmp (файл удаляется, когда сегмент завершает работу). |
| Active PID | Идентификатор активного процесса сегмента. |
| Master reports status as | Статус сегмента, как указано в системном каталоге: up или down. |
| Database status | Статус RT.Warehouse для входящих запросов: up, down, или suspended. Состояние suspended означает, что активность базы данных временно приостанавливается, пока сегмент переходит из одного состояния в другое. |
Следующие поля вывода сообщаются gpstate -f для статуса резервного мастера:
Таблица 58— Выходные данные gpstate –f для резервного мастера
|
Выходные данные |
Описание |
|---|---|
| Standby address | Имя хоста резервного мастера. |
| Standby data dir | Расположение в файловой системе каталога данных резервного мастера. |
| Standby port | Порт процесса прослушивателя базы данных postgres резервного мастера. |
| Standby PID | ID процесса резервного мастера. |
| Standby status | Состояние резервного мастера: standby host passive. |
| WAL Sender State | Состояние потоковой передачи журнала предзаписи (WAL): streaming, startup, backup, catchup. |
| Sync state | Состояние синхронизации отправителя WAL: sync. |
| Sent Location | Местоположение отправленной записи журнала транзакций отправителя WAL (xlog). |
| Flush Location | Место сброса записи xlog приёмника WAL. |
| Replay Location | Резервное место воспроизведения записи xlog. |
Показать подробную информацию о состоянии системы RT.Warehouse:
gpstate -sСделать быструю проверку неработающих сегментов в системном каталоге хоста мастера:
gpstate -QПоказать информацию об инстансах зеркального сегмента:
gpstate -mПоказать информацию о конфигурации резервного мастера:
gpstate -fОтобразить информацию о версии программного обеспечения RT.Warehouse:
gpstate -iОстанавливает или перезапускает систему RT.Warehouse.
gpstop [-d master_data_directory] [-B parallel_processes]
[-M smart | fast | immediate] [-t timeout_seconds] [-r] [-y] [-a]
[-l logfile_directory] [-v | -q]
gpstop -m [-d master_data_directory] [-y] [-l logfile_directory] [-v | -q]
gpstop -u [-d master_data_directory] [-l logfile_directory] [-v | -q]
gpstop --host host_name [-d master_data_directory] [-l logfile_directory]
[-t timeout_seconds] [-a] [-v | -q]
gpstop --version
gpstop -? | -h | --helpУтилита gpstop используется для остановки серверов баз данных, входящих в систему RT.Warehouse. Когда вы останавливаете систему RT.Warehouse, вы фактически останавливаете сразу несколько процессов сервера баз данных postgres (мастер и все инстансы сегментов). Утилита gpstop обрабатывает завершение работы отдельных инстансов. Каждый инстансов выключается параллельно.
Режим выключения по умолчанию (-M smart) ожидает завершения текущих клиентских подключений перед завершением выключения. Если какие-либо соединения остаются открытыми по истечении периода тайм-аута или если вы прерываете соединение с помощью CTRL-C, gpstop выводит список открытых соединений и подсказывает, следует ли продолжать ожидание завершения соединений или выполнить быстрое или немедленное завершение работы. Период ожидания по умолчанию составляет 120 секунд и может быть изменён с помощью параметра -t timeout_seconds.
Укажите -M fast режим выключения, чтобы откатить все выполняющиеся транзакции и разорвать любые соединения перед завершением работы.
С параметром -u утилита загружает изменения, внесённые в файл мастера pg_hba.conf или в параметры конфигурации среды выполнения в файле мастера postgresql.conf, без прерывания обслуживания. Обратите внимание, что любые активные сеансы не будут принимать изменения, пока они не подключатся к базе данных.
Таблица 59— Параметры gpstop
|
Параметр |
Описание |
|---|---|
| -a | Не запрашивать подтверждение у пользователя. |
| -B parallel_processes | Количество сегментов, которые нужно остановить параллельно. Если параметр не указан, утилита запустит до 64 параллельных процессов в зависимости от того, сколько инстансов сегмента ей необходимо остановить. |
| -d master_data_directory | Опционально. Каталог данных хоста мастера. Если не указан, будет использоваться значение, установленное для $MASTER_DATA_DIRECTORY. |
| --host host_name |
Утилита завершает работу инстансов сегмента RT.Warehouse на указанном хосте, чтобы разрешить обслуживание хоста. Каждый инстанс основного сегмента на хосте отключается, а связанный инстанс зеркального сегмента повышается до основного сегмента, если зеркальный сегмент находится на другом хосте. Инстансы зеркальных сегментов на хосте выключаются. Инстансы сегментов не выключаются, и утилита возвращает ошибку в следующих случаях:
Этот параметр нельзя указывать с параметрами -m, -r, -u или ‑y. Примечание. Утилита gprecoverseg восстанавливает инстансы сегментов. Запуск команды gprecoverseg запускает сегменты как зеркала, а затем возвращает сегменты в их предпочтительную роль (основные сегменты). |
| -l logfile_directory | Каталог для записи файла журнала. По умолчанию ~/gpAdminLogs. |
| -m | Опционально. Завершает работу инстанса мастера RT.Warehouse, запущенного в режиме обслуживания. |
| -M fast | Быстрое выключение. Любые текущие транзакции прерываются и откатываются. |
| -M immediate | Немедленное отключение. Любые выполняющиеся транзакции прерываются. Этот режим завершает все процессы postgres, не позволяя серверу базы данных завершить обработку транзакции или очистить любые временные или находящиеся в процессе рабочие файлы. |
| -M smart | Умное выключение. Это режим выключения по умолчанию. gpstop ожидает отключения активных пользовательских подключений и затем завершает работу. Если какие-либо пользовательские подключения остаются открытыми после периода тайм-аута (или если вы прерываете их нажатием CTRL-C), gpstop выводит список открытых пользовательских подключений и предлагает продолжить ожидание завершения подключений или выполнить быстрое или немедленное завершение работы. |
| -q | Работа в тихом режиме. Вывод команды не отображается на экране, но все равно записывается в файл журнала. |
| -r | Перезагрузить после завершения выключения. |
| -t timeout_seconds | Задаёт порог тайм-аута (в секундах) для ожидания завершения работы инстанса сегмента. Если инстанс сегмента не завершает работу в течение указанного количества секунд, gpstop отображает сообщение, указывающее, что один или несколько сегментов всё ещё находятся в процессе завершения работы и что вы не можете перезапустить RT.Warehouse, пока инстансы сегмента не будут остановлены. Этот параметр полезен в ситуациях, когда выполняется gpstop и есть очень большие транзакции, которые необходимо откатить. Для отката таких крупных транзакций может потребоваться более минуты, а время ожидания по умолчанию превышает 120 секунд. |
| -u | Этот параметр перезагружает файлы pg_hba.conf мастера и сегментов, а также параметры времени выполнения файлов postgresql.conf, но не завершает работу массива RT.Warehouse. Используйте этот параметр, чтобы активировать новые настройки конфигурации после редактирования postgresql.conf или pg_hba.conf. Обратите внимание, что это относится только к параметрам конфигурации, которые определены как параметры времени выполнения. |
| -v | Отображает подробные сообщения о состоянии, прогрессе и ошибках, выводимые утилитой. |
| -y | Не останавливает процесс резервного мастера. По умолчанию резервный мастер останавливается. |
| -? | -h | --help | Отображает интерактивную справку. |
| --version | Отображает версию этой утилиты. |
Остановить систему RT.Warehouse в интеллектуальном режиме:
gpstopОстановить систему RT.Warehouse в быстром режиме:
gpstop -M fastОстановить все инстансы сегментов, а затем перезапустить систему:
gpstop -rОстановить инстанс мастера, запущенный в режиме обслуживания:
gpstop -mПосле внесения изменений в конфигурацию перезагрузить файлы postgresql.conf и pg_hba.conf, но не завершать работу массива RT.Warehouse:
gpstop -uОтображает информацию о вашей операционной системе.
gpsys1 [ -a | -m | -p ]
gpsys1 -?
gpsys1 --versiongpsys1 отображает платформу и установленную память (в байтах) текущего хоста. Например:
linux 1073741824Таблица 60— Параметры gpsys1
|
Параметр |
Описание |
|---|---|
| -a | Показывает информацию о платформе и памяти для текущего хоста. Это значение по умолчанию. |
| -m | Показывает только установленную системную память в байтах. |
| -p | Показывает только платформу ОС. Платформа может быть linux, darwin или sunos5. |
| -? | Отображает интерактивную справку. |
| --version | Отображает версию этой утилиты. |
Показать информацию о текущей операционной системе хоста:
gpsys1Получает информацию об установленной версии RT.Warehouse.
pg_config [option ...]
pg_config -? | --help
pg_config --versionУтилита pg_config распечатывает параметры конфигурации текущей установленной версии RT.Warehouse. Она предназначена, например, для использования программными пакетами, которые хотят взаимодействовать с RT.Warehouse, чтобы облегчить поиск необходимых файлов заголовков и библиотек. Обратите внимание, что информация, распечатанная с помощью pg_config, только о мастере RT.Warehouse.
Если указано более одного параметра, информация печатается в указанном порядке, по одному элементу в строке. Если параметры не указаны, вся доступная информация печатается с этикетками.
Таблица 61— Параметры pg_config
|
Параметр |
Описание |
|---|---|
| --bindir | Выводит расположение исполняемых файлов пользователя. Используйте этот параметр, например, чтобы найти программу psql. Обычно это то же место, где находится программа pg_config. |
| --docdir | Выводит расположение файлов документации. |
| --includedir | Выводит расположение файлов C-заголовков клиентских интерфейсов. |
| --pkgincludedir | Выводит расположение других файлов C-заголовков. |
| --includedir-server | Выводит расположение файлов C-заголовков для программирования сервера. |
| --libdir | Выводит расположение библиотек объектного кода. |
| --pkglibdir | Выводит расположение динамически загружаемых модулей или место, где сервер будет их искать. (Другие файлы данных, зависящие от архитектуры, также могут быть установлены в этом каталоге.) |
| --localedir | Выводит расположение файлов поддержки локали. |
| --mandir | Выводит расположение страниц руководства. |
| --sharedir | Выводит расположение файлов поддержки, не зависящих от архитектуры. |
| --sysconfdir | Выводит расположение общесистемных файлов конфигурации. |
| --pgxs | Выводит расположение make-файлов расширения. |
| --configure | Выводит параметры, которые были заданы скрипту настройки при настройке RT.Warehouse для сборки. |
| --cc | Выводит значение переменной CC, которая использовалась для сборки RT.Warehouse. Параметр показывает используемый компилятор C. |
| --cppflags | Выводит значение переменной CPPFLAGS, которая использовалась для сборки RT.Warehouse. Параметр показывает переключатели компилятора C, необходимые во время предварительной обработки. |
| --cflags | Выводит значение переменной CFLAGS, которая использовалась для сборки RT.Warehouse. Параметр показывает переключатели компилятора C. |
| --cflags_sl | Выводит значение переменной CFLAGS_SL, которая использовалась для сборки RT.Warehouse. Параметр показывает дополнительные переключатели компилятора C, используемые для создания общих библиотек. |
| --ldflags | Выводит значение переменной LDFLAGS, которая использовалась для сборки RT.Warehouse. Параметр показывает переключатели компоновщика. |
| --ldflags_ex | Выводит значение переменной LDFLAGS_EX, которая использовалась для сборки RT.Warehouse. Параметр показывает переключатели компоновщика, которые использовались только для сборки исполняемых файлов. |
| --ldflags_sl | Выводит значение переменной LDFLAGS_SL, которая использовалась для сборки RT.Warehouse. Параметр показывает переключатели компоновщика, используемые только для создания общих библиотек. |
| --libs | Выводит значение переменной LIBS, которая использовалась для сборки RT.Warehouse. Обычно параметр содержит ключи -l для внешних библиотек, связанных с RT.Warehouse. |
| --version | Выводит версию RT.Warehouse. |
Чтобы воспроизвести конфигурацию сборки текущей установки RT.Warehouse, выполните следующую команду:
eval ./configure 'pg_config --configure'Вывод pg_config --configure содержит кавычки оболочки, поэтому аргументы с пробелами представлены правильно. Следовательно, для получения правильных результатов необходимо использовать eval.
Извлекает базу данных в отдельный файл скрипта или другой архивный файл.
pg_dump [connection-option ...] [dump_option ...] [dbname]
pg_dump -? | --help
pg_dump -V | --versionpg_dump — это стандартная утилита PostgreSQL для резервного копирования базы данных, которая также поддерживается в RT.Warehouse. Создаёт единый (непараллельный) файл дампа. Для регулярного резервного копирования RT.Warehouse лучше использовать утилиту резервного копирования RT.Warehouse gpbackup для обеспечения максимальной производительности.
Используйте pg_dump, если вы переносите свои данные в систему базы данных другого вендора или в другую систему RT.Warehouse с другой конфигурацией сегментов (например, если система, в которую вы мигрируете, имеет большее или меньшее количество инстансов сегментов). Для восстановления вы должны использовать соответствующую утилиту pg_restore (если файл дампа находится в формате архива) или вы можете использовать клиентскую программу, такую как psql (если файлдампа находится в текстовом формате).
Поскольку pg_dump совместима с обычной PostgreSQL, её можно использовать для переноса данных в RT.Warehouse. Утилита pg_dump в RT.Warehouse очень похожа на утилиту pg_dump PostgreSQL, со следующими исключениями и ограничениями:
pg_dump делает последовательные резервные копии, даже если Одновременно с этим база данных используется. pg_dump не блокирует доступ к базе данных других пользователей (на чтение или запись).
При использовании с одним из форматов архивных файлов и в сочетании с pg_restore, pg_dump предоставляет гибкий механизм архивирования и передачи. pg_dump можно использовать для резервного копирования всей базы данных, затем pg_restore можно использовать для проверки архива и/или выбора частей базы данных для восстановления. Наиболее гибкими форматами выходных файлов являются формат custom (-Fc) и формат directory (-Fd). Они позволяют выбирать и переупорядочивать все заархивированные элементы, поддерживают параллельное восстановление и сжаты по умолчанию. Формат directory — единственный формат, поддерживающий параллельные дампы.
|
Примечание. Параметр --ignore-version устарел и будет удален в следующем выпуске. |
Таблица 62— dbname параметры pg_dump
|
Параметр |
Описание |
|---|---|
| dbname | Задаёт имя базы данных для дампа. Если параметр не указан, используется переменная среды PGDATABASE. Если она не установлена, используется имя пользователя, указанное для соединения. |
Таблица 63— dump параметры pg_dump
|
Параметр |
Описание |
| -a | --data-only | Выгружает только данные, а не схему (определения данных). Выгружаются данные таблицы и значения последовательности. Этот параметр аналогичен, но по историческим причинам не идентичен, указанию параметра --section=data. |
| -b | --blobs |
Включает большие объекты в дамп. Это поведение по умолчанию, за исключением случаев, когда указаны параметры --schema, --table или --schema-only. Параметр -b полезен только при добавлении больших объектов в дампы, где была запрошена конкретная схема или таблица. Обратите внимание, что большие бинарные объекты (blobs) считаются данными и поэтому будут включены, когда используется --data-only, но не когда --schema-only. Примечание. RT.Warehouse не поддерживает функцию больших объектов PostgreSQL для потоковой передачи пользовательских данных, которые хранятся в структурах больших объектов. |
| -c | --clean | Добавляет команды в текстовый файл вывода для очистки (удаления) объектов базы данных перед выводом команд для их создания. (Восстановление может привести к появлению сообщений о некоторых безобидных ошибках, если какие-либо объекты не присутствуют в целевой базе данных.) Обратите внимание, что объекты не удаляются до начала операции дампа, а команды DROP добавляются в выходные файлы дампа DDL, чтобы при использовании этих файлов для восстановления команды DROP запускались до команд CREATE. Этот параметр имеет смысл использовать только для обычного текстового формата. Для форматов архивов вы можете указать параметр при вызове pg_restore. |
| -C | --create | Начинает вывод с команды для создания самой базы данных и повторного подключения к созданной базе данных. (Используя скрипт этой формы, не имеет значения, к какой базе данных в целевой установке вы подключаетесь перед запуском скрипта.) Если также указан параметр --clean, скрипт удаляет и воссоздает целевую базу данных перед повторным подключением к ней. Этот параметр имеет смысл использовать только для обычного текстового формата. Для форматов архивов вы можете указать параметр при вызове pg_restore. |
| -E encoding | --encoding=encoding | Создаёт дамп в указанной кодировке набора символов. По умолчанию дамп создается в кодировке базы данных. (Другой способ получить тот же результат — установить для переменной среды PGCLIENTENCODING желаемую кодировку дампа.) |
| -f file | --file=file | Отправляет вывод в указанный файл. Этот параметр можно не указывать для форматов вывода на основе файлов, и в этом случае используется стандартный вывод. Однако он должен быть указан для формата вывода в каталог, где указывается целевой каталог вместо файла. В этом случае pg_dump создаёт каталог, который не должен существовать раньше. |
| -F p|c|d|t | --format=plain|custom|directory|tar |
Выбирает формат вывода. Формат может быть одним из следующих:
|
| -i | --ignore-version |
Примечание. Эта опция устарела и будет удалена в следующем выпуске. Игнорировать несоответствие версий между pg_dump и сервером базы данных. pg_dump может выгружать данные с серверов, на которых запущены предыдущие версии RT.Warehouse (или PostgreSQL), но очень старые версии могут больше не поддерживаться. Используйте этот параметр, если вам нужно отменить проверку версии. |
| -j njobs | --jobs=njobs |
Запускает дамп параллельно, одновременно выгружая njobs таблиц. Этот параметр сокращает время дампа, но также увеличивает нагрузку на сервер базы данных. Вы можете использовать этот параметр только с форматом вывода каталога (directory), потому что это единственный формат вывода, в котором несколько процессов могут записывать свои данные одновременно. Примечание. Параллельные дампы с использованием pg_dump распараллеливаются только на хосте диспетчера запросов (мастере), а не на хостах исполнителя (сегмента) запроса, как в случае использования gpbackup. pg_dump откроет njobs + 1 соединений с базой данных, поэтому убедитесь, что ваш параметр max_connections достаточно высок, чтобы вместить все соединения. Запрос исключительных блокировок объектов базы данных при запуске параллельного дампа может привести к сбою дампа. Причина в том, что процесс мастера pg_dump запрашивает общие блокировки на объектах, которые рабочие процессы собираются сбрасывать позже, чтобы гарантировать, что никто не удалит их и не заставит их уйти во время выполнения дампа. Если другой клиент затем запрашивает исключительную блокировку для таблицы, эта блокировка не будет предоставлена, но будет поставлена в очередь в ожидании освобождения общей блокировки процесса мастера. Следовательно, любой другой доступ к таблице также не будет предоставлен и будет помещён в очередь после запроса исключительной блокировки. Это включает в себя рабочий процесс, пытающийся выгрузить таблицу. Без всяких мер предосторожности это была бы классическая тупиковая ситуация. Чтобы обнаружить этот конфликт, рабочий процесс pg_dump запрашивает другую разделяемую блокировку с помощью параметра NOWAIT. Если рабочему процессу не предоставлена эта разделяемая блокировка, значит, кто-то еще должен был запросить исключительную блокировку тем временем, и нет возможности продолжить создание дампа, поэтому у pg_dump нет другого выбора, кроме как прервать создание дампа. Для согласованного резервного копирования сервер базы данных должен поддерживать синхронизированные снапшоты — функцию, которая была представлена в RT.Warehouse 6.0. С помощью этой функции клиенты базы данных могут гарантировать, что они видят один и тот же набор данных, даже если они используют разные соединения. pg_dump -j использует несколько соединений с базой данных; он подключается к базе данных один раз с процессом мастера и ещё раз для каждого рабочего задания. Без функции синхронизированного снапшота разные рабочие задания не будут гарантированно видеть одни и те же данные в каждом соединении, что может привести к несогласованному резервному копированию. Если вы хотите запустить параллельный дамп сервера до версии 6.0, вам необходимо убедиться, что содержимое базы данных не меняется с момента подключения мастера к базе данных до момента подключения последнего рабочего задания к базе данных. Самый простой способ сделать это — остановить любые процессы изменения данных (DDL и DML), обращающиеся к базе данных, перед запуском резервного копирования. Вам также необходимо указать параметр --no-synchronized-snapshots при запуске pg_dump -j для сервера RT.Warehouse до версии 6.0. |
| -n schema | --schema=schema | Выгружает только схемы, соответствующие шаблону схемы; выбирается как сама схема, так и все содержащиеся в ней объекты. Если этот параметр не указан, все несистемные схемы в целевой базе данных будут сброшены. Можно выбрать несколько схем, написав несколько ключей -n. Кроме того, параметр схемы интерпретируется как шаблон в соответствии с теми же правилами, которые используются командами psql \d, поэтому несколько схем также можно выбрать, написав подстановочные символы в шаблоне. При использовании подстановочных символов будьте осторожны при необходимости заключать образец в кавычки, чтобы оболочка не расширяла подстановочные знаки. Примечание. Если указан -n, pg_dump не пытается сбросить дамп любых других объектов базы данных, от которых может зависеть выбранная схема (схемы). Следовательно, нет гарантии, что результаты дампа конкретной схемы могут быть успешно восстановлены сами по себе в чистую базу данных. Примечание. Объекты, не относящиеся к схеме, такие как blob- объекты, не выгружаются, если указан параметр -n. Вы можете добавить blob-объекты обратно в дамп с помощью --blobs. |
| -N schema | --exclude-schema=schema | Не выгружает схемы, соответствующие шаблону схемы. Шаблон интерпретируется по тем же правилам, что и -n. -N можно указывать более одного раза, чтобы исключить схемы, соответствующие любому из нескольких шаблонов. Когда заданы оба параметра -n и -N, происходит сброс только тех схем, которые соответствуют хотя бы одному переключателю ‑n, но не соответствуют переключателям -N. Если -N отображается без -n, то схемы, соответствующие -N, исключаются из обычного дампа. |
| -o | --oids | Дамп идентификаторов объектов (OID) как часть данных для каждой таблицы. Использование этого параметра не рекомендуется для файлов, которые должны быть восстановлены в RT.Warehouse. |
| -O | --no-owner | Не выводить команды для установки владения объектами в соответствии с исходной базой данных. По умолчанию pg_dump выдаёт операторы ALTER OWNER или SET SESSION AUTHORIZATION, чтобы установить владельца созданных объектов базы данных. Эти операторы завершатся ошибкой при запуске скрипта, если он не запущен суперпользователем (или тем же пользователем, которому принадлежат все объекты в скрипте). Чтобы создать скрипт, который может быть восстановлен любым пользователем, но предоставит этому пользователю право владения всеми объектами, укажите -O. Этот параметр имеет смысл только для обычного текстового формата. Для форматов архивов вы можете указать параметр при вызове pg_restore. |
| -s | --schema-only | Выгружает только определения объекта (схему), но не данные. Этот параметр противоположен --data-only. Это похоже на указание --section=pre-data --section=post-data, но по историческим причинам не идентично ему. (Не путайте его с параметром --schema, в котором слово «схема» используется в другом значении.) Чтобы исключить данные таблицы только для подмножества таблиц в базе данных, см. --exclude-table-data. |
| -S username | --superuser=username | Указывает имя пользователя суперпользователя, которое будет использоваться при отключении триггеров. Это актуально, только если используется --disable-triggers. Лучше оставить это без внимания и вместо этого запустить полученный скрипт от имени суперпользователя. Примечание. RT.Warehouse не поддерживает пользовательские триггеры. |
| -t table | --table=table |
Выгружает только таблицы (или представления, или последовательности, или сторонние таблицы), соответствующие шаблону таблицы. Укажите таблицу в формате schema.table. Можно выбрать несколько таблиц, написав несколько ключей ‑t. Кроме того, параметр table интерпретируется как шаблон в соответствии с теми же правилами, которые используются командами psql\d, поэтому несколько таблиц также можно выбрать, записав в шаблон подстановочные символы. При использовании подстановочных символов будьте осторожны при необходимости заключать образец в кавычки, чтобы оболочка не расширяла подстановочные знаки. Ключи -n и -N не действуют, когда используется -t, потому что таблицы, выбранные -t, будут сброшены независимо от этих переключателей, а объекты, не являющиеся таблицами, не будут сброшены. Примечание. Если указан -t, pg_dump не пытается сбросить дамп любых других объектов базы данных, от которых может зависеть выбранная таблица (таблицы). Следовательно, нет гарантии, что результаты дампа конкретной таблицы могут быть успешно восстановлены сами по себе в чистую базу данных. Кроме того, -t нельзя использовать для указания раздела дочерней таблицы. Чтобы создать дамп партиционированной таблицы, вы должны указать имя родительской таблицы. |
| -T table | --exclude-table=table | Не выгружает таблицы, соответствующие шаблону таблицы. Шаблон интерпретируется по тем же правилам, что и для -t. -T можно указывать более одного раза, чтобы исключить таблицы, соответствующие любому из нескольких шаблонов. Когда заданы оба параметра -t и -T, происходит сброс только тех таблиц, которые соответствуют хотя бы одному переключателю -t, но не соответствуют параметрам -T. Если -T отображается без -t, то таблицы, соответствующие -T, исключаются из обычного дампа. |
| -v | --verbose | Задаёт подробный режим. pg_dump будет выводить подробные комментарии к объекту и время запуска/остановки в файл дампа, а также сообщения о ходе выполнения до стандартной ошибки. |
| -V | --version | Распечатывает версию pg_dump и выходит. |
| -x | --no-privileges | --no-acl | Запрещает сброс прав доступа (команды GRANT/REVOKE). |
| -Z 0..9 | --compress=0..9 |
Указывает используемый уровень сжатия. Ноль означает отсутствие сжатия. Для пользовательского формата архива параметр определяет сжатие отдельных табличных данных сегментов, и по умолчанию сжатие выполняется на умеренном уровне. Для вывода обычного текста установка ненулевого уровня сжатия приводит к сжатию всего выходного файла, как если бы он был передан через gzip. Но по умолчанию сжатие не установлено. Формат tar-архива в настоящее время вообще не поддерживает сжатие. |
| --binary-upgrade | Этот параметр предназначен для использования утилит обновления in-place. Его использование для других целей не рекомендуется и не поддерживается. Поведение параметра может измениться в будущих выпусках без предварительного уведомления. |
| --column-inserts | --attribute-inserts | Выгружает данные как команды INSERT с явными именами столбцов (INSERT INTOtable (column, ...) VALUES ...). Это сделает восстановление очень медленным; в основном это полезно для создания дампов, которые могут быть загружены в базы данных, не основанные на PostgreSQL. Однако, поскольку этот параметр генерирует отдельную команду для каждой строки, ошибка при перезагрузке строки приводит к потере только этой строки, а не всего содержимого таблицы. |
| --disable-dollar-quotin | Этот параметр отключает использование долларовых кавычек для тел функций и заставляет их заключать в кавычки с использованием стандартного строкового синтаксиса SQL. |
| --disable-triggers |
Этот параметр актуален только при создании дампа только с данными. Он предписывает pg_dump включать команды для временного отключения триггеров в целевых таблицах на время перезагрузки данных. Используйте этот параметр, если у вас есть триггеры для таблиц, которые вы не хотите вызывать во время перезагрузки данных. Команды, выдаваемые для --disable-triggers, должны выполняться от имени суперпользователя. Таким образом, вы также должны указать имя суперпользователя с -S или, желательно, быть осторожным, чтобы запустить получившийся скрипт как суперпользователь. Этот параметр имеет смысл только для обычного текстового формата. Для форматов архивов вы можете указать параметр при вызове pg_restore. Примечание. RT.Warehouse не поддерживает пользовательские триггеры. |
| --exclude-table-data=table |
Не выгружает данные для любых таблиц, соответствующих шаблону таблицы. Шаблон интерпретируется по тем же правилам, что и для -t. --exclude-table-data можно указывать более одного раза, чтобы исключить таблицы, соответствующие любому из нескольких шаблонов. Этот параметр полезен, когда вам нужно определение конкретной таблицы, даже если вам не нужны данные в ней. Чтобы исключить данные для всех таблиц в базе данных, см. --schema-only. |
| --if-exists | Использует условные команды (например, добавление предложения IF EXISTS) при очистке объектов базы данных. Этот параметр недействителен, если также не указан --clean. |
| --inserts | Выгружает данные как команды INSERT (а не COPY). Это сделает восстановление очень медленным; в основном это полезно для создания дампов, которые могут быть загружены в базы данных, не основанные на PostgreSQL. Однако, поскольку этот параметр генерирует отдельную команду для каждой строки, ошибка при перезагрузке строки приводит к потере только этой строки, а не всего содержимого таблицы. Обратите внимание, что восстановление может полностью завершиться неудачно, если вы изменили порядок столбцов. Параметр --column-inserts безопасен от изменений порядка столбцов, хотя и медленнее. |
| --lock-wait-timeout=timeout | Не ждать бесконечно, чтобы получить блокировки разделяемой таблицы в начале дампа. Вместо этого выполняет сбой, если не удалось заблокировать таблицу в течение указанного timeout. Указывает время ожидания в миллисекундах. |
| --no-security-labels | Не дампить защитные наклейки. |
| --no-synchronized-snapshots | Этот параметр позволяет запускать pg_dump -j для сервера RT.Warehouse до 6.0; см. документацию по параметру -j для получения более подробной информации. |
| --no-tablespaces |
Не выводит команды для выбора табличных пространств. С этим параметром все объекты будут созданы в том табличном пространстве, которое используется по умолчанию во время восстановления. Этот параметр имеет смысл только для обычного текстового формата. Для форматов архивов вы можете указать параметр при вызове pg_restore. |
| --no-unlogged-table-data | Не выгружает содержимое незарегистрированных таблиц. Этот параметр не влияет на то, сбрасываются ли определения таблиц (схемы); он только подавляет сброс данных таблицы. Данные в незарегистрированных таблицах всегда исключаются при выгрузке с резервного сервера. |
| --quote-all-identifiers | Принудительное цитирование всех идентификаторов. Этот параметр рекомендуется при выгрузке базы данных с сервера, основная версия RT.Warehouse которого отличается от версии pg_dump, или когда выходные данные предназначены для загрузки на сервер другой основной версии. По умолчанию pg_dump цитирует только идентификаторы, которые являются зарезервированными словами в его собственной основной версии. Иногда это приводит к проблемам совместимости при работе с серверами других версий, которые могут иметь несколько другие наборы зарезервированных слов. Использование --quote-all-identifiers предотвращает такие проблемы за счёт более трудного для чтения скрипта дампа. |
| --section=sectionname |
Выгружает только названную партицию. Имя партиции может быть pre-data, data или post-data. Этот параметр можно указывать несколько раз, чтобы выбрать несколько партиций. По умолчанию дампятся все партиции. Партиция data содержит фактические данные таблицы и значения последовательности. Элементы post-data включают определения индексов, триггеров, правил и ограничений, кроме проверенных ограничений. Элементы pre-data включают все другие элементы определения данных. |
| --serializable-deferrable |
Использует сериализуемую транзакцию для дампа, чтобы гарантировать, что используемый снапшот совместим с более поздними состояниями базы данных; но делает это, дождавшись точки в потоке транзакций, в которой не может быть никаких аномалий, чтобы не было риска сбоя дампа или отката других транзакций с помощью serialization_failure. Этот вариант невыгоден для дампа, который предназначен только для аварийного восстановления. Он может быть полезен для дампа, используемого для загрузки копии базы данных для отчётов или загрузки общей копии только для чтения, в то время как исходная база данных продолжает обновляться. Без этого дамп может отражать состояние, которое не согласуется с каким-либо последовательным выполнением транзакций, в конечном итоге совершённых. Например, если используются методы пакетной обработки, пакет может отображаться как закрытый в дампе, но не отображаются все элементы, входящие в пакет. Этот параметр не будет иметь никакого значения, если при запуске pg_dump нет активных транзакций чтения-записи. Если транзакции чтения-записи активны, начало дампа может быть отложено на неопределённый период времени. После запуска производительность с переключателем или без него такая же. Примечание. Поскольку RT.Warehouse не поддерживает сериализуемые транзакции, параметр --serializable-deferrable не действует в RT.Warehouse. |
| --use-set-session-authorization | Выводит стандартные SQL-команды SET SESSION AUTHORIZATION вместо команд ALTER OWNER, чтобы определить владельца объекта. Это делает дамп более совместимым со стандартами, но в зависимости от истории объектов в дампе может не восстанавливаться должным образом. Дамп с использованием SET SESSION AUTHORIZATION потребует прав суперпользователя для правильного восстановления, тогда как ALTER OWNER требует меньших прав. |
| --gp-syntax | --no-gp-syntax | Используйте --gp-syntax для вывода синтаксиса RT.Warehouse в операторах CREATE TABLE. Это позволяет сбрасывать политику распределения (условия DISTRIBUTED BY или DISTRIBUTED RANDOMLY) таблицы RT.Warehouse, что полезно для восстановления в других системах RT.Warehouse. По умолчанию синтаксис RT.Warehouse включается при подключении к системе RT.Warehouse и исключается при подключении к обычной системе PostgreSQL. |
| --function-oids oids |
Дамп функции (функций), указанной в списке идентификаторов объектов oids. Примечание. Этот параметр предназначен исключительно для использования другими утилитами администрирования; его использование для каких-либо других целей не рекомендуется и не поддерживается. Поведение параметра может измениться в будущих выпусках без предварительного уведомления. |
| --relation-oids oids |
Выгружает отношения, указанные в списке идентификаторов объектов oids. Примечание. Этот параметр предназначен исключительно для использования другими утилитами администрирования; его использование для каких-либо других целей не рекомендуется и не поддерживается. Поведение опции может измениться в будущих выпусках без предварительного уведомления. |
| -? | --help | Показывает справку об аргументах командной строки pg_dump и выходит. |
Таблица 64 — connection параметры pg_dump
|
Параметр |
Описание |
|---|---|
| -d dbname | --dbname=dbname |
Задаёт имя базы данных для подключения. Этот параметр эквивалентен указанию dbname в качестве первого аргумента командной строки, не являющегося параметром. Если этот параметр содержит знак = или начинается с допустимого префикса URI (postgresql:// или postgres://), он рассматривается как строка conninfo. Для получения дополнительной информации см. Строки подключения в документации PostgreSQL. |
| -h host | --host=host | Имя хоста машины, на которой работает сервер мастера базы данных RT.Warehouse. Если не указан, считывается из переменной среды PGHOST или по умолчанию используется localhost. |
| -p port | --port=port | Порт TCP, на котором сервер мастера базы данных RT.Warehouse ожидает подключений. Если не указан, считывается из переменной среды PGPORT или по умолчанию 5432. |
| -U username | --username=username | Имя роли базы данных для подключения. Если не указан, считывается из переменной среды PGUSER или по умолчанию используется имя текущей системной роли. |
| -W | --password | Принудительно ввести пароль. |
| -w | --no-password | Никогда не запрашивать пароль. Если сервер требует аутентификации по паролю, а пароль недоступен другими средствами, такими как файл .pgpass, попытка подключения не удастся. Этот параметр может быть полезен в пакетных заданиях и скриптах, где нет пользователя для ввода пароля. |
| --role=rolename | Задаёт имя роли, которая будет использоваться для создания дампа. Этот параметр заставляет pg_dump выдавать команду SET ROLE rolename после подключения к базе данных. Это полезно, когда аутентифицированный пользователь (указанный параметром -U) не имеет прав, необходимых для pg_dump, но может переключиться на роль с необходимыми правами. Некоторые установки имеют политику, запрещающую вход непосредственно в систему как суперпользователь, и использование этого параметра позволяет делать дамп без нарушения политики. |
Если выбран дамп только данных и используется параметр --disable-triggers, pg_dump выдаёт команды для отключения триггеров в пользовательских таблицах перед вставкой данных и команды для их повторного включения после того, как данные были вставлены. Если восстановление остановлено посередине, системные каталоги могут остаться в неправильном состоянии.
Файл дампа, созданный pg_dump, не содержит статистики, используемой оптимизатором для принятия решений по планированию запросов. Таким образом, после восстановления из файла дампа рекомендуется запустить ANALYZE, чтобы обеспечить оптимальную производительность.
Активность pg_dump в базе данных обычно собирается сборщиком статистики. Если это нежелательно, вы можете установить для параметра track_counts значение false с помощью PGOPTIONS или команды ALTER USER.
Поскольку pg_dump может использоваться для передачи данных в более новые версии RT.Warehouse, можно ожидать, что вывод pg_dump будет загружен в версии RT.Warehouse более новые, чем версия pg_dump. pg_dump также может выполнять дамп из версий RT.Warehouse, более старых, чем её собственная версия. Однако pg_dump не может выполнять дамп из версий RT.Warehouse новее, чем её собственная основная версия; он откажется даже от попытки, а не рискнёт сделать недопустимый дамп. Кроме того, не гарантируется, что вывод pg_dump может быть загружен на сервер более старой основной версии — даже если дамп был взят с сервера этой версии. Загрузка файла дампа на старый сервер может потребовать ручного редактирования файла дампа, чтобы удалить синтаксис, не понятый старому серверу. В случаях перекрёстных версий рекомендуется использовать параметр --quote-all-identifiers, так как он может предотвратить проблемы, возникающие из-за изменения списков зарезервированных слов в разных версиях RT.Warehouse.
Выгрузить базу данных mydb в файл SQL-скрипта:
pg_dump mydb > db.sqlЧтобы перезагрузить такой скрипт в (только что созданную) базу данных с именем newdb:
psql -d newdb -f db.sqlСделать дамп RT.Warehouse в формате tar и включить информацию о политике распределения:
pg_dump -Ft --gp-syntax mydb > db.tarЧтобы выгрузить базу данных в архивный файл произвольного формата:
pg_dump -Fc mydb > db.dumpЧтобы выгрузить базу данных в архив в формате каталога:
pg_dump -Fd mydb -f dumpdirЧтобы выгрузить базу данных в архив формата каталога параллельно с 5 рабочими заданиями:
pg_dump -Fd mydb -j 5 -f dumpdirЧтобы перезагрузить архивный файл в (только что созданную) базу данных с именем newdb:
pg_restore -d newdb db.dumpЧтобы выгрузить одну таблицу с именем mytab:
pg_dump -t mytab mydb > db.sqlЧтобы указать имя в верхнем или смешанном регистре в -t и связанных переключателях, вам нужно заключить имя в двойные кавычки; иначе он будет сложен в нижний регистр. Но двойные кавычки — это особенность оболочки, поэтому они, в свою очередь, должны быть заключены в кавычки. Таким образом, чтобы выгрузить одну таблицу со смешанным именем, вам понадобится что-то вроде:
pg_dump -t '"MixedCaseName"' mydb > mytab.sqlИзвлекает все базы данных в системе RT.Warehouse в один файл скрипта или другой архивный файл.
pg_dumpall [connection-option ...] [dump_option ...]
pg_dumpall -? | --help
pg_dumpall -V | --versionpg_dumpall — это стандартная утилита PostgreSQL для резервного копирования всех баз данных в инстансе RT.Warehouse (или PostgreSQL), которая также поддерживается в RT.Warehouse. Она создаёт единый (непараллельный) файл дампа. Для регулярного резервного копирования RT.Warehouse лучше использовать утилиту резервного копирования RT.Warehouse gpbackup для достижения наилучшей производительности.
pg_dumpall создаёт один файл скрипта, содержащий SQL-команды, которые можно использовать в качестве входных данных для psql для восстановления баз данных. Это делается путём вызова pg_dump для каждой базы данных. pg_dumpall также выгружает глобальные объекты, общие для всех баз данных (pg_dump не сохраняет эти объекты). В настоящее время в них входит информация о пользователях и группах базы данных, а также разрешениях на доступ, которые применяются к базам данных в целом.
Поскольку pg_dumpall считывает таблицы из всех баз данных, вам скорее всего придётся подключиться как суперпользователь базы данных, чтобы создать полный дамп. Также вам потребуются привилегии суперпользователя для выполнения сохраненного скрипта, чтобы иметь возможность добавлять пользователей и группы, а также создавать базы данных.
Скрипт SQL будет записан в стандартный вывод. Используйте [-f | --file] или операторы оболочки, чтобы перенаправить его в файл.
pg_dumpall требуется несколько раз подключиться к серверу мастера RT.Warehouse (один раз для каждой базы данных). Если вы используете аутентификацию по паролю, вероятно, каждый раз будет запрашивать пароль. В таких случаях удобно иметь файл ~/.pgpass.
|
Примечание. Параметр --ignore-version устарел и будет удалён в следующем выпуске. |
Таблица 65— dump параметры pg_dumpall
|
Параметр |
Описание |
|---|---|
| -a | --data-only | Выгружает только данные, а не схему (определения данных). Этот параметр имеет смысл только для обычного текстового формата. Для форматов архивов вы можете указать параметр при вызове pg_restore. |
| -c | --clean | Выводит команды для очистки (удаления) объектов базы данных до (команд для) их создания. Этот параметр имеет смысл только для обычного текстового формата. Для форматов архивов вы можете указать параметр при вызове pg_restore. |
| -f filename | --file=filename | Отправляет вывод в указанный файл. |
| -g | --globals-only | Дамп только глобальных объектов (ролей и табличных пространств), без баз данных. |
| -i | --ignore-version |
Примечание. Этот параметр устарел и будет удалён в следующем выпуске. Игнорирует несоответствие версий между pg_dump и сервером базы данных. pg_dump может выгружать данные с серверов, на которых запущены предыдущие версии RT.Warehouse (или PostgreSQL), но очень старые версии могут больше не поддерживаться. Используйте этот параметр, если вам нужно отменить проверку версии. |
| -o | --oids | Дамп идентификаторов объектов (OID) как часть данных для каждой таблицы. Использование этого параметра не рекомендуется для файлов, которые должны быть восстановлены в RT.Warehouse. |
| -O | --no-owner | Не выводит команды для установки владения объектами в соответствии с исходной базой данных. По умолчанию pg_dump выдаёт операторы ALTER OWNER или SET SESSION AUTHORIZATION, чтобы установить владельца созданных объектов базы данных. Эти операторы завершатся ошибкой при запуске скрипта, если он не запущен суперпользователем (или тем же пользователем, которому принадлежат все объекты в скрипте). Чтобы создать скрипт, который может быть восстановлен любым пользователем, но предоставит этому пользователю право владения всеми объектами, укажите -O. Этот параметр имеет смысл только для обычного текстового формата. Для форматов архивов вы можете указать параметр при вызове pg_restore. |
| -r | --roles-only | Дампит только роли, а не базы данных или табличные пространства. |
| -s | --schema-only | Выгружает только определения объекта (схему), но не данные. |
| -S username | --superuser=username |
Указывает имя пользователя суперпользователя, которое будет использоваться при отключении триггеров. Это актуально, только если используется --disable-triggers. Лучше оставить это без внимания и вместо этого запустить полученный скрипт от имени суперпользователя. Примечание. RT.Warehouse не поддерживает пользовательские триггеры. |
| -t | --tablespaces-only | Дампит только табличные пространства, а не базы данных или роли. |
| -v | --verbose | Задаёт подробный режим. pg_dump будет выводить подробные комментарии к объекту и время запуска/остановки в файл дампа, а также сообщения о ходе выполнения до стандартной ошибки. |
| -V | --version | Распечатывает версию pg_dumpall и выходит. |
| -x | --no-privileges | --no-acl | Запрещает сброс прав доступа (команды GRANT/REVOKE). |
| --binary-upgrade | Этот параметр предназначен для использования утилит обновления in-place. Его использование для других целей не рекомендуется и не поддерживается. Поведение параметра может измениться в будущих выпусках без предварительного уведомления. |
| --column-inserts | --attribute-inserts | Выводит данные в виде команд INSERT с явными именами столбцов (INSERT INTO table (column, ...) VALUES ...). Это сделает восстановление очень медленным; в основном это полезно для создания дампов, которые могут быть загружены в базы данных, не основанные на PostgreSQL. Кроме того, поскольку этот параметр генерирует отдельную команду для каждой строки, ошибка при перезагрузке строки приводит к потере только этой строки, а не всего содержимого таблицы. |
| --disable-dollar-quoting | Этот параметр отключает использование долларовых кавычек для тел функций и заставляет их заключать в кавычки с использованием стандартного строкового синтаксиса SQL. |
| --disable-triggers |
Этот параметр актуален только при создании дампа только с данными. Он указывает pg_dumpall включать команды для временного отключения триггеров в целевых таблицах на время перезагрузки данных. Используйте его, если у вас есть триггеры для таблиц, которые вы не хотите вызывать во время перезагрузки данных. Команды, выдаваемые для --disable-triggers, должны выполняться от имени суперпользователя. Таким образом, вы также должны указать имя суперпользователя с -S или, желательно, быть осторожным, чтобы запустить получившийся скрипт как суперпользователь. Примечание. RT.Warehouse не поддерживает пользовательские триггеры. |
| --inserts | Выгружает данные как команды INSERT (а не COPY). Это сделает восстановление очень медленным; в основном это полезно для создания дампов, которые могут быть загружены в базы данных, не основанные на PostgreSQL. Кроме того, поскольку этот параметр генерирует отдельную команду для каждой строки, ошибка при перезагрузке строки приводит к потере только этой строки, а не всего содержимого таблицы. Обратите внимание, что восстановление может полностью завершиться неудачно, если вы изменили порядок столбцов. Параметр --column-inserts безопасен от изменений порядка столбцов, хотя и медленнее. |
| --lock-wait-timeout=timeout | Не ждать бесконечно, чтобы получить блокировки разделяемой таблицы в начале дампа. Вместо этого произойдёт сбой, если не удалось заблокировать таблицу в течение указанного времени ожидания. Тайм-аут может быть указан в любом из форматов, принимаемых SET statement_timeout. Допустимые значения зависят от версии сервера, с которого выполняется дамп, но все версии RT.Warehouse принимают целое число миллисекунд. |
| --no-security-labels | Не сбрасывать защитные наклейки. |
| --no-tablespaces | Не выводите команды для выбора табличных пространств. С этой опцией все объекты будут созданы в том табличном пространстве, которое используется по умолчанию во время восстановления. |
| --no-unlogged-table-data | Не выгружайте содержимое незарегистрированных таблиц. Эта опция не влияет на то, сбрасываются ли определения таблиц (схемы); он только подавляет сброс данных таблицы. |
| --quote-all-identifiers | Принудительное цитирование всех идентификаторов. Этот вариант рекомендуется при выгрузке базы данных с сервера, основная версия RT.Warehouse которого отличается от версии pg_dumpall, или когда выходные данные предназначены для загрузки на сервер другой основной версии. По умолчанию pg_dumpall цитирует только те идентификаторы, которые являются зарезервированными словами в его собственной основной версии. Иногда это приводит к проблемам совместимости при работе с серверами других версий, которые могут иметь несколько другие наборы зарезервированных слов. Использование --quote-all-identifiers предотвращает такие проблемы за счёт более трудного для чтения сценария дампа. |
| --resource-queues | Дамп определений очереди ресурсов. |
| --resource-groups | Дамп определений групп ресурсов. |
| --use-set-session-authorization | Выведите стандартные команды SET SESSION AUTHORIZATION вместо команд ALTER OWNER, чтобы определить владельца объекта. Это делает дамп более совместимым со стандартами, но в зависимости от истории объектов в дампе может не восстанавливаться должным образом. Дамп с использованием SET SESSION AUTHORIZATION потребует прав суперпользователя для правильного восстановления, тогда как ALTER OWNER требует меньших прав. |
| --gp-syntax | Выведите синтаксис базы данных RT.Warehouse в операторах CREATE TABLE. Это позволяет сбрасывать политику распространения (условия DISTRIBUTED BY или DISTRIBUTED RANDOMLY) таблицы базы данных RT.Warehouse, что полезно для восстановления в других системах баз данных RT.Warehouse. |
| --no-gp-syntax | Не выводите предложения о распределении таблиц в операторах CREATE TABLE. |
| -? | --help | Показать справку об аргументах командной строки pg_dumpall и выйти. |
Таблица 66 — connection параметры pg_dump
|
Параметр |
Описание |
|---|---|
| -d connstr | --dbname=connstr |
Задает параметры, используемые для подключения к серверу, в виде строки подключения. Для получения дополнительной информации см. Строки подключения в документации PostgreSQL. Параметр называется --dbname для согласованности с другими клиентскими приложениями, но поскольку pg_dumpall необходимо подключаться ко многим базам данных, имя базы данных в строке подключения будет проигнорировано. Используйте параметр -l, чтобы указать имя базы данных, используемой для создания дампа глобальных объектов, и узнать, какие другие базы данных следует сбросить. |
| -h host | --host=host | Имя хоста компьютера, на котором работает главный сервер базы данных RT.Warehouse. Если не указано, считывается из переменной среды PGHOST или по умолчанию используется localhost. |
| -l dbname | --database=dbname | Задает имя базы данных, к которой нужно подключиться для создания дампа глобальных объектов. Если не указано, используется база данных postgres. Если база данных postgres не существует, используется база данных template1. |
| -p port | --port=port | Порт TCP, на котором главный сервер базы данных RT.Warehouse прослушивает соединения. Если не указано, считывается из переменной среды PGPORT или по умолчанию 5432. |
| -U username | --username= username | Имя роли базы данных для подключения. Если не указано, считывается из переменной среды PGUSER или по умолчанию используется имя текущей системной роли. |
| -w | --no-password | Никогда не запрашивайте пароль. Если сервер требует аутентификации по паролю, а пароль недоступен другими средствами, такими как файл .pgpass, попытка подключения не удастся. Эта опция может быть полезна в пакетных заданиях и сценариях, где нет пользователя для ввода пароля. |
| -W | --password | Принудительно ввести пароль. |
| --role=rolename | Задает имя роли, которая будет использоваться для создания дампа. Эта опция заставляет pg_dumpall выдавать команду SET ROLE rolename после подключения к базе данных. Это полезно, когда аутентифицированный пользователь (указанный параметром -U) не имеет прав, необходимых для pg_dumpall, но может переключиться на роль с необходимыми правами. Некоторые установки имеют политику, запрещающую вход непосредственно в систему как суперпользователь, и использование этой опции позволяет делать дамп без нарушения политики. |
Поскольку pg_dumpall вызывает внутри себя pg_dump, некоторые диагностические сообщения будут относиться к pg_dump.
После восстановления целесообразно запустить ANALYZE для каждой базы данных, чтобы у планировщика запросов была полезная статистика. Вы также можете запустить Vacuumdb -a -z для анализа всех баз данных.
pg_dumpall требует, чтобы все необходимые каталоги табличных пространств существовали до восстановления; в противном случае создание базы данных не удастся для баз данных в местах, отличных от заданных по умолчанию.
Чтобы выгрузить все базы данных:
pg_dumpall > db.outЧтобы перезагрузить базы данных из этого файла, вы можете использовать:
psql template1 -f db.outЧтобы сбрасывать только глобальные объекты (включая очереди ресурсов):
pg_dumpall -g --resource-queuesВосстанавливает базу данных из архивного файла, созданного pg_dump.
pg_restore [connection-option ...] [restore_option ...] filename
pg_restore -? | --help
pg_restore -V | --versionpg_restore — это утилита для восстановления базы данных из архива, созданного pg_dump в любом формате кроме текстового. Она выполняет команды, необходимые для восстановления базы данных в том состоянии, в котором она находилась на момент сохранения. Файлы архивов позволяют pg_restore выбирать, какие данные необходимо восстановить, или даже изменять порядок объектов перед восстановлением.
pg_restore может работать в двух режимах. Если указано имя базы данных, содержимое архива восстанавливается непосредственно в базу данных. В противном случае создаётся скрипт с SQL-командами, необходимыми для восстановления базы данных, и записывается в файл или на стандартный вывод. Содержание созданного скрипта эквивалентно выводу pg_dump в формате текста. Поэтому некоторые параметры, управляющие выводом, аналогичны параметрам pg_dump.
pg_restore не может восстановить информацию, которой нет в архивном файле. Например, если архив был создан с использованием параметра «выгрузить данные как команды INSERT», pg_restore не сможет загрузить данные с помощью операторов COPY.
|
Примечание. Параметр --ignore-version устарел и будет удалён в следующем выпуске. |
Таблица 67 — filename параметры pg_restore
|
Параметр |
Описание |
|---|---|
| filename | Указывает расположение файла архива (или каталога — для архива в формате каталога), который нужно восстановить. Если параметр не указан, используется стандартный ввод. |
Таблица 68 — restore параметры pg_restore
|
Параметр |
Описание |
|---|---|
| -a | --data-only |
Восстанавливает только данные, без схемы (определений данных). Данные таблицы и значения последовательности восстанавливаются, если они есть в архиве. Этот параметр аналогичен указанию --section=data, но по историческим причинам не идентичен. |
| -c | --clean | Очищает (drop) объекты базы данных перед их восстановлением. (Это может привести к появлению некоторых безобидных сообщений об ошибках, если какие-либо объекты не присутствуют в целевой базе данных.) |
| -C | --create |
Создаёт базу данных перед восстановлением в неё. Если также указан параметр --clean, удаляет и заново создаёт целевую базу данных перед подключением к ней. Когда используется этот параметр, база данных, заданная параметром -d, используется только для выполнения начальных команд DROP DATABASE и CREATE DATABASE. Все данные восстанавливаются в базу данных, имя которой записано в архив. |
| -d dbname | --dbname=dbname | Подключается к заданной базе данных и производит восстановление данных непосредственно в эту базу данных. Эта утилита, как и большинство других утилит RT.Warehouse, также использует переменные среды, поддерживаемые libpq. Однако она не читает PGDATABASE, если имя базы данных не указано. |
| -e | --exit-on-error | Завершает работу, если при отправке SQL-команд в базу данных возникла ошибка. По умолчанию восстановление продолжается, а по его завершению отображается количество возникших ошибок. |
| -f outfilename | --file=outfilename | Задаёт выходной файл для сгенерированного скрипта или для списка объектов, полученного при использовании -l. По умолчанию используется стандартный вывод. |
| -F c|d|t | --format={custom | directory | tar} |
Задаёт формат архива, созданного pg_dump. Формат указывать не обязательно, поскольку pg_restore определяет формат автоматически. Если формат задаётся, то используется одно из следующих значений:
|
| -i | --ignore-version |
Примечание. Этот параметр устарел и будет удалён в следующем выпуске. Игнорирует проверки версии базы данных. |
| -I index | --index=index | Восстанавливает определение только заданного индекса. |
| -j | --number-of-jobs | --jobs=number-of-jobs |
Запускает наиболее трудоёмкие операции pg_restore (те, которые загружают данные, создают индексы или создают ограничения), используя несколько параллельных заданий. Этот вариант может значительно сократить время восстановления большой базы данных на сервере, работающем на многопроцессорной машине. Каждое задание представляет собой отдельный процесс или поток, в зависимости от операционной системы, и использует отдельное соединение с сервером. Оптимальное значение для этого параметра зависит от аппаратной конфигурации сервера, клиента и сети. Также имеют значение количество процессорных ядер и конфигурацию дискового хранилища. В качестве начального значения можно выбрать количество процессорных ядер на сервере, а при увеличении данного значения восстановление может происходить быстрее. Слишком высокие значения приведут к снижению производительности из-за перегрузки. Этот параметр поддерживает только с архивом в формате custom. Входной файл должен быть обычным файлом (не, например, каналом ввода). Этот параметр игнорируется при генерации скрипта (т.е. когда отсутствует прямое подключение к серверу базы данных). Кроме того, несколько заданий нельзя использовать вместе с параметром --single-transaction. |
| -l | --list | Выводит содержимое архива. Выходные данные этой операции можно использовать в качестве ввода для параметра -L для ограничения и изменения порядка восстанавливаемых объектов. |
| -L list-file | --use-list=list-file |
Восстанавливает только объекты, которые перечислены в list-file и в том порядке, в котором они представлены в файле. Обратите внимание, что если параметры фильтрации, такие как -n или -t, используются с -L, они дополнительно ограничивают восстанавливаемые объекты. list-file обычно представляет собой отредактированный результат вывода предыдущей операции -l. Строки файла можно перемещать или удалять, а также можно закомментировать, поставив точку с запятой (;) в начале строки. |
| -n schema | --schema=schema | Восстанавливает только те объекты, которые находятся в указанной схеме. Этот параметр можно комбинировать с параметром -t для восстановления только определённой таблицы. |
| -O | --no-owner | Не генерирует команды, восстанавливающие владение объектами в соответствии с исходной базой данных. По умолчанию pg_restore генерирует команды ALTER OWNER или SET SESSION AUTHORIZATION, чтобы восстановить исходных владельцев создаваемых объектов схемы. Эти команды завершатся ошибкой, если начальное соединение с базой данных не будет выполнено суперпользователем (или пользователем, которому принадлежат все объекты в скрипте). Чтобы получить скрипт, который сможет восстановить любой подключающийся пользователь (но при этом он станет владельцем всех созданных объектов), используется -O. |
| -P 'function-name(argtype [, ...])' | --function='function-name(argtype [, ...])' | Восстанавливает только указанную функцию. Имя функции должно быть заключено в кавычки. Важно указать имя функции и аргументы точно так, как они записаны в оглавлении файла дампа (как показано параметром --list). |
| -s | --schema-only |
Восстанавливает только схему (определения данных), без данных, в том объёме, в котором схемы присутствуют в архиве. Этот параметр противоположен по действию параметру --data-only. Этот параметр похож на указание --section=pre-data --section=post-data, но по историческим причинам не идентичен ему. (Не путайте этот параметр с параметром --schema, в котором слово «схема» используется в другом значении.) |
| -S username | --superuser=username |
Задаёт имя суперпользователя, которое будет использоваться для отключения триггеров. Использование этого параметра актуально, только если используется --disable-triggers. Примечание. RT.Warehouse не поддерживает пользовательские триггеры. |
| -t table | --table=table | Восстанавливает определение и/или данные только указанной таблицы. Несколько таблиц могут быть указаны с помощью нескольких ключей -t. Этот параметр можно комбинировать с параметром -n, чтобы указать схему. |
| -T trigger | --trigger=trigger |
Восстанавливает только указанный триггер. Примечание. RT.Warehouse не поддерживает пользовательские триггеры. |
| -v | --verbose | Включает режим подробных сообщений. |
| -V | --version | Выводит версию pg_restore и завершает работу. |
| -x | --no-privileges | --no-acl | Не восстанавливает права доступа (т.е. не выполняет команды GRANT/REVOKE). |
| -1 | --single-transaction | Выполняет восстановление в рамках одной транзакции. Этот параметр подразумевает, что либо все команды будут выполнены успешно, либо никакие изменения не будут применены. |
| --disable-triggers |
Этот параметр актуален только при выполнении восстановления только данных. При его использовании pg_restore выполняет команды для отключения триггеров в целевых таблицах на время загрузки данных. Используйте этот параметр, если у вас имеются триггеры для таблиц, которые вы не хотите вызывать во время загрузки данных. Команды, генерируемые --disable-triggers, должны выполняться от имени суперпользователя. Поэтому вы также должны указать имя суперпользователя с помощью параметра -S или, что предпочтительней, запустить pg_restore как суперпользователь. Примечание. RT.Warehouse не поддерживает пользовательские триггеры. |
| --no-data-for-failed-tables |
По умолчанию данные таблицы восстанавливаются, даже если команда создания таблицы завершилась с ошибкой (например, потому что таблица уже существует). При выборе этого параметра данные для такой таблицы не восстанавливаются. Такое поведение полезно, когда целевая таблица уже содержит необходимые данные. Указание этого параметра предотвращает загрузку повторяющихся или устаревших данных. Этот параметр эффективен только при восстановлении непосредственно в базу данных, но не при создании вывода в формате SQL-скрипта. |
| --no-security-labels | Не генерирует команды, восстанавливающие метки безопасности, даже если они содержатся в архиве. |
| --no-tablespaces | Не генерирует команды для указания табличных пространств. С данным параметром все объекты будут созданы в том табличном пространстве, которое используется по умолчанию во время восстановления. |
| --section=sectionname |
Восстанавливает только указанный раздел. В качестве sectionname можно указать следующие значения:
Этот параметр можно указывать несколько раз, чтобы выбрать несколько разделов. По умолчанию восстанавливаются все разделы. |
| --use-set-session-authorization | Генерирует стандартизированные команды SET SESSION AUTHORIZATION вместо команд ALTER OWNER, чтобы назначить владельца объекта. Использование этого параметра делает дамп более стандартизированным, но в может не восстановиться корректно в зависимости от истории объектов в дампе. |
| -? | --help | Показывает справку об аргументах командной строки pg_restore и завершается. |
Таблица 69 — connection параметры pg_restore
|
Параметр |
Описание |
|---|---|
| -h host | --host host | Имя хоста машины, на котором работает сервер мастера RT.Warehouse. Если параметр не указан, значение считывается из переменной среды PGHOST или по умолчанию используется localhost. |
| -p port | --port port | TCP-порт, на котором сервер мастера RT.Warehouse принимает подключения. Если параметр не указан, значение считывается из переменной среды PGPORT или по умолчанию используется 5432. |
| -U username | --username username | Имя системной роли, используемое для подключения к базе данных. Если параметр не указан, значение считывается из переменной среды PGUSER или по умолчанию используется имя текущей системной роли. |
| -w | --no-password | Не выводить запрос на ввод пароля. Если сервер требует аутентификацию по паролю, а пароль недоступен с помощью других средств, таких как файл .pgpass, попытка подключения не удастся. Этот параметр может быть полезен в пакетных заданиях и скриптах, где нет пользователя, который вводит пароль. |
| -W | --password | Принудительно запрашивать пароль перед подключением к базе данных. |
| --role=rolename | Задаёт имя роли, которая будет использоваться для восстановления. При использовании этого параметра pg_restore будет генерировать команду SET ROLE rolename после подключения к базе данных. Это полезно, когда аутентифицированный пользователь (указанный параметром -U) не имеет прав, необходимых для pg_restore, но может переключиться на роль с необходимыми правами. Некоторые установки имеют политику, запрещающую вход непосредственно в систему как суперпользователь, и использование этого параметра позволяет выполнять восстановление без нарушения политики. |
Если в вашей установке база данных template1 имеет какие-либо локальные дополнения, убедитесь, что pg_restore осуществляет вывод в действительно пустую базу данных; в противном случае вы, вероятно, получите ошибки из-за повторяющихся определений добавленных объектов. Чтобы создать пустую базу данных без каких-либо локальных дополнений, используйте template0, а не template1, например:
CREATE DATABASE foo WITH TEMPLATE template0;При восстановлении данных в уже существующие таблицы и использовании параметра --disable-triggers, pg_restore генерирует команды для отключения триггеров в пользовательских таблицах перед вставкой данных, а затем генерирует команды для их повторного включения после того, как данные были вставлены. Если восстановление прервётся в процессе, системные каталоги могут остаться в некорректном состоянии.
См. также pg_dump для получения подробной информации об её ограничениях.
После восстановления целесообразно запустить ANALYZE для каждой восстановленной таблицы, чтобы планировщик запросов получил актуальную статистику.
Предположим, мы выгрузили базу данных с именем mydb в файл дампа формата custom:
pg_dump -Fc mydb > db.dumpЧтобы удалить базу данных и воссоздать её из дампа:
dropdb mydb
pg_restore -C -d template1 db.dumpЧтобы перезагрузить дамп в новую базу данных с именем newdb. Обратите внимание, что параметр -C не используется в примере, вместо этого мы подключаемся напрямую к базе данных, в которую нужно восстановить. Также обратите внимание, что мы клонируем новую базу данных из template0, а не из template1, чтобы убедиться, что она изначально пуста:
createdb -T template0 newdb
pg_restore -d newdb db.dumpЧтобы изменить порядок объектов базы данных, сначала необходимо выгрузить оглавление архива:
pg_restore -l db.dump > db.listФайл оглавления состоит из заголовка и одной строки для каждого элемента, например,
; Archive created at Mon Sep 14 13:55:39 2009
; dbname: DBDEMOS
; TOC Entries: 81
; Compression: 9
; Dump Version: 1.10-0
; Format: CUSTOM
; Integer: 4 bytes
; Offset: 8 bytes
; Dumped from database version: 8.3.5
; Dumped by pg_dump version: 8.3.8
;
; Selected TOC Entries:
;
3; 2615 2200 SCHEMA - public pasha
1861; 0 0 COMMENT - SCHEMA public pasha
1862; 0 0 ACL - public pasha
317; 1247 17715 TYPE public composite pasha
319; 1247 25899 DOMAIN public domain0 pasha2Комментарии начинаются с точки с запятой (;), а числа в начале строк обозначают внутренний идентификатор архива, присвоенный каждому элементу архива. Строки в файле можно закомментировать, удалить и изменить порядок. Например:
10; 145433 TABLE map_resolutions postgres
;2; 145344 TABLE species postgres
;4; 145359 TABLE nt_header postgres
6; 145402 TABLE species_records postgres
;8; 145416 TABLE ss_old postgresТаким образом данный файл может использоваться в качестве входных данных для pg_restore для восстановления только элементов 10 и 6 в указанном порядке:
pg_restore -L db.list db.dumpУправляет пулами соединений с базой данных.
pgbouncer [OPTION ...] pgbouncer.ini
OPTION
[ -d | --daemon ]
[ -R | --restart ]
[ -q | --quiet ]
[ -v | --verbose ]
[ {-u | --user}=username ]
pgbouncer [ -V | --version ] | [ -h | --help ]PgBouncer — это менеджер пула соединений для RT.Warehouse и PostgreSQL. PgBouncer поддерживает пул соединений для каждого пользователя базы данных и комбинации баз данных. PgBouncer либо создаёт новое соединение с базой данных для клиента, либо повторно использует имеющееся соединение для того же пользователя и базы данных. Когда клиент отключается, PgBouncer возвращает соединение в пул для повторного использования.
PgBouncer поддерживает стандартный интерфейс подключения, используемый PostgreSQL и RT.Warehouse. Клиентское приложение RT.Warehouse (например, psql) должно подключиться к хосту и порту, на котором работает PgBouncer, а не напрямую к хосту и порту мастера RT.Warehouse.
Настройка PgBouncer и его доступ к RT.Warehouse осуществляется через файл конфигурации. При запуске команды pgbouncer необходимо указать имя файла конфигурации, обычно pgbouncer.ini. Этот файл содержит информацию о местонахождении RT.Warehouse. Файл pgbouncer.ini также определяет процесс, пул соединений, авторизованных пользователей и конфигурацию аутентификации для PgBouncer, помимо прочих параметров конфигурации.
По умолчанию процесс pgbouncer выполняется как приоритетный процесс. При желании вы можете запустить pgbouncer как фоновый (демон) процесс, используя параметр -d.
Процесс pgbouncer принадлежит пользователю операционной системы, который запускает этот процесс. При желании вы можете указать другое имя пользователя, под которым будет запускаться pgbouncer.
PgBouncer включает административную консоль, подобную psql. Авторизованные пользователи могут подключаться к виртуальной базе данных для мониторинга и управления PgBouncer. Вы можете управлять процессом демона PgBouncer через административную консоль. Вы также можете использовать консоль для обновления и перезагрузки конфигурации PgBouncer во время его работы без остановки и перезапуска процесса.
Для получения дополнительной информации о PgBouncer обратитесь к PgBouncer FAQ.
Таблица 70— Параметры pgbouncer
|
Параметр |
Описание |
|---|---|
| -d | --daemon |
Запускает PgBouncer как демон (фоновый процесс). По умолчанию PgBouncer запускается как процесс переднего плана. При запуске в качестве демона PgBouncer отображает сообщения запуска на стандартный вывод. Чтобы данные сообщения не отображались, используйте параметр -q при запуске PgBouncer. Чтобы остановить процесс PgBouncer, который был запущен как демон, введите команду SHUTDOWN из административной консоли PgBouncer. |
| -R | --restart |
Перезапускает PgBouncer, используя указанные аргументы командной строки. Соединения с базами данных (кроме TLS) поддерживаются во время перезапуска. Соединения TLS не поддерживаются, они сбрасываются. Чтобы перезапустить PgBouncer как демон, укажите параметры -Rd. Примечание. Перезагрузка возможна только в том случае, если операционная система поддерживает сокеты Unix и конфигурация unix_socket_dir PgBouncer не отключена. |
| -q | --quiet | Тихий режим. Не выводит сообщения в stdout. |
| -v | --verbose | Увеличивает уровень детализации сообщений. Параметр можно указывать несколько раз. |
| {-u | --user}=username | Переключается на указанного пользователя при запуске процесса PgBouncer. |
| -V | --version | Выводит версию и завершается. |
| -h | --help | Выводит справку по команде и завершается. |
Файл конфигурации PgBouncer.
[databases]
db = ...
[pgbouncer]
...
[users]
...В файле конфигурации pgbouncer.ini указываются параметры конфигурации PgBouncer и определяются параметры конфигурации для конкретного пользователя.
Файл конфигурации PgBouncer (обычно называется pgbouncer.ini) имеет формат .ini. Файлы в формате .ini состоят из разделов, параметров и значений. Имена разделов заключаются в квадратные скобки, например, [section_name]. Параметры и значения указываются в формате key=value. Строки, начинающиеся с точки с запятой (;) или знака решётки (#), считаются строками комментариев и игнорируются.
Файл конфигурации PgBouncer может содержать директивы %include, которые определяют, что необходимо прочитать и обработать дополнительный файл конфигурации. Директивы включения позволяет разделить файл конфигурации на отдельные части. Например:
%include filenameЕсли указанный файл не задаётся абсолютным путём, его расположение воспринимается относительно текущего рабочего каталога.
Файл конфигурации PgBouncer включает следующие разделы, подробно описанные ниже:
Раздел [databases] содержит пары key=value, где key — это имя базы данных, а value — это строка подключения для libpq в виде пары key=value.
Имя базы данных может содержать символы [0-9A-Za-z_.-] без кавычек. Имена, содержащие другие символы, должны быть заключены в стандартные кавычки идентификаторов SQL:
Имя базы данных * — это резервная база данных. PgBouncer использует значение этого ключа как строку подключения для запрошенной базы данных. Автоматически созданные записи базы данных, подобные этим, очищаются, если они остаются бездействующими дольше времени, указанного в параметре autodb_idle_timeout.
Следующие параметры могут быть включены в value, чтобы указать расположение базы данных.
Таблица 71— Параметры подключения к базе данных
|
Параметр |
Описание |
|---|---|
| dbname |
Имя целевой базы данных. По умолчанию — указанное клиентом имя базы данных. |
| host |
Имя или IP-адрес хоста мастера RT.Warehouse. Имена хостов разрешаются в момент подключения. Если DNS возвращает несколько результатов, они используются циклически. Результат DNS кэшируется, а параметр dns_max_ttl определяет, когда истекает срок действия записи в кэше. По умолчанию — не установлено, соединение осуществляется через сокет Unix. |
| port |
Порт мастера RT.Warehouse. По умолчанию — 5432 |
| user, password |
Если задан user=, все подключения к целевой базе данных инициируются от имени указанного пользователя, в результате чего создается один пул подключений для базы данных. Если параметр user= не установлен, PgBouncer пытается войти в целевую базу данных с именем пользователя, переданным клиентом. В этой ситуации будет отдельный пул для каждого пользователя, который подключается к базе данных. |
| auth_user | Если указан параметр auth_user, любой пользователь, который не указан в auth_file, аутентифицируется путём запроса к представлению базы данных pg_shadow. PgBouncer выполняет этот запрос как пользователь auth_user базы данных RT.Warehouse. Пароль auth_user должен быть установлен в auth_file. |
| client_encoding | Запрашивает у сервера использование указанной клиентской кодировки (client_encoding). |
| datestyle | Запрашивает у сервера использование указанного стиля даты (datestyle). |
| timezone | Запрашивает у сервера использование указанного часового пояса (timezone). |
Используйте следующие параметры для конфигурации пула для конкретной базы данных.
Таблица 72— Параметры конфигурации пула
|
Параметр |
Описание |
|---|---|
| pool_size | Устанавливает максимальный размер пулов для этой базы данных. Если параметр не установлен, используется значение default_pool_size. |
| connect_query | Запрос, который должен быть выполнен после установления соединения, но перед тем, как разрешить использование соединения любым клиентам. Если запрос вызывает ошибки, они регистрируются, но в противном случае игнорируются. |
| pool_mode | Устанавливает режим пула для этой базы данных. Если параметр не установлен, используется режим pool_mode по умолчанию. |
| max_db_connections | Устанавливает максимальное количество соединений PgBouncer для этой базы данных. Общее количество подключений для всех пулов для этой базы данных не будет превышать это значение. |
Таблица 73— Параметры общей настройки
|
Параметр |
Описание |
|---|---|
| logfile |
Расположение файла журнала. Файл журнала остаётся открытым. После ротации журнала выполните kill -HUP pgbouncer или запустите RELOAD; в административной консоли PgBouncer. По умолчанию — не задан. |
| pidfile |
Имя pid-файла. Без указания pidfile вы не можете запустить PgBouncer как фоновый (демон) процесс. По умолчанию — не задан. |
| listen_addr |
Список адресов интерфейсов, на которых PgBouncer прослушивает TCP-соединения. Вы также можете указать *, что означает прослушивание всех интерфейсов. Если параметр не установлен, разрешены только соединения через сокеты Unix. Указывать адреса можно числами (IPv4/IPv6) или по имени. По умолчанию — не задан. |
| listen_port |
Порт, который слушает PgBouncer. Задаётся для сокетов TCP и для сокетов Unix. По умолчанию — 6432. |
| unix_socket_dir |
Указывает расположение сокетов Unix. Применяется как к прослушивающим сокетам, так и к подключениям к серверам. Если задана пустая строка, сокеты Unix отключены. Требуется для онлайн-перезагрузки (параметр -R). По умолчанию — /tmp. |
| unix_socket_mode |
Режим файловой системы для сокета Unix. По умолчанию — 0777. |
| unix_socket_group |
Имя группы для сокета Unix. По умолчанию — не задан. |
| user |
Если параметр указан, указывает пользователя Unix, на которого необходимо переключиться после запуска. Этот параметр работает, только если PgBouncer запускается от имени root или PgBouncer уже запущен от имени указанного пользователя. По умолчанию — не задан. |
| auth_file |
Имя файла, содержащего имена пользователей и пароли для загрузки. Формат файла такой же, как у файла pg_auth RT.Warehouse. По умолчанию — не задан. |
| auth_hba_file |
Файл конфигурации HBA, который используется в том случае, когда auth_type равен hba. См. формат файла HBA в документации PgBouncer для получения информации о поддержке PgBouncer формата файла аутентификации HBA. По умолчанию — не задан. |
| auth_type |
Определяет, как аутентифицировать пользователей:
|
| auth_query |
Запрос на извлечение пароля пользователя из базы данных. Если пользователь не существует в auth_file и запись базы данных включает auth_user, этот запрос запускается в базе данных как auth_user для поиска пользователя. Обратите внимание, что запрос выполняется внутри целевой базы данных, поэтому, если функция используется, её необходимо установить в каждую базу данных. По умолчанию — SELECT usename, passwd FROM pg_shadow WHERE usename=$1. |
| auth_user |
Если параметр auth_user указан, любой пользователь, не указанный в auth_file, может аутентифицироваться с помощью запроса auth_query из представления базы данных pg_shadow. PgBouncer выполняет этот запрос как пользователь RT.Warehouse auth_user. Пароль auth_user должен быть установлен в auth_file. Для прямого доступа к pg_shadow требуются права администратора RT.Warehouse. Предпочтительно, чтобы пользователь, не имеющий прав администратора, вместо этого вызывал функцию SECURITY DEFINER. |
| pool_mode |
Указывает, когда соединение с сервером может быть повторно использовано другими клиентами:
|
| max_client_conn |
Максимальное разрешённое количество клиентских подключений. При увеличении следует также увеличить пределы дескрипторов файлов. Фактическое количество используемых файловых дескрипторов будет превышать max_client_conn. Теоретический максимум, используемый, когда каждый пользователь подключается к серверу под своим именем пользователя, составляет: Если пользователь базы данных указан в строке подключения, то все пользователи подключаются под одним и тем же именем пользователя. Тогда теоретический максимум подключений составляет: Теоретический максимум никогда не должен быть достигнут, если только кто-то специально не создаёт для него нагрузку. Тем не менее, это означает, что вы должны установить для количества файловых дескрипторов безопасное высокое значение. Найдите ulimit в документации по вашей операционной системе. По умолчанию — 100. |
| default_pool_size |
Возможное число подключений к серверу для пары пользователь/база данных. Значение можно переопределить в конфигурации для каждой базы данных. По умолчанию — 20. |
| min_pool_size |
Добавляет больше серверных подключений к пулу, если оно меньше этого числа. Это улучшает поведение, когда обычная нагрузка падает, а затем внезапно повышается после периода полного бездействия. По умолчанию — 0 (отключено). |
| reserve_pool_size |
Количество дополнительных подключений для пула. При значении 0 резерв отсутствует. По умолчанию — 0 (отключено). |
| reserve_pool_timeout |
Если клиент не обслуживается в течение указанного количества секунд, PgBouncer разрешает использование дополнительных подключений из резервного пула. Значение 0 отключает эту функцию. По умолчанию — 5.0. |
| max_db_connections |
Максимальное количество подключений к базе данных. Когда достигается заданный предел, закрытие клиентского подключения в одном пуле не позволяет сразу установить подключение к серверу для другого пула, потому что подключение к серверу для первого пула все ещё открыто. После закрытия соединения с сервером (по тайм-ауту неактивности) новое соединение с сервером будет открыто для ожидающего пула. По умолчанию — unlimited. |
| max_user_connections | Максимальное количество подключений на пользователя. Когда достигается заданный предел, закрытие клиентского соединения с одним пулом не позволяет сразу установить соединение для другого пула, потому что соединение для первого пула все ещё открыто. После закрытия соединения для первого пула (по тайм-ауту неактивности) новое серверное соединение будет открыто для ожидающего пула. |
| server_round_robin |
По умолчанию PgBouncer повторно использует подключения к серверу в порядке LIFO (last-in, first-out), так что наибольшую нагрузку получают несколько последних соединений. Это обеспечивает наилучшую производительность, когда базу данных обслуживает один сервер. Но если за IP-адресом базы данных имеется балансировщик TCP-соединений, то лучше, если PgBouncer также будет использовать соединения таким образом для достижения равномерной нагрузки. По умолчанию — 0. |
| ignore_startup_parameters |
По умолчанию PgBouncer принимает только параметры, которые он может отслеживать в стартовых пакетах: client_encoding, datestyle, timezone и standard_conforming_strings. Все остальные параметры вызывают ошибку. Чтобы принимались другие параметры, укажите их здесь, чтобы PgBouncer мог их игнорировать. По умолчанию — empty. |
| disable_pqexec |
Отключает протокол простых запросов (PQexec, Simple Query protocol). В отличие от протокола расширенных запросов (Extended Query protocol), протокол простых запросов позволяет использовать несколько запросов в одном пакете, что позволяет использовать некоторые классы атак с использованием SQL-инъекций. Отключение протокола может повысить безопасность. Это означает, что будут иметь возможность работать только клиенты, которые используют исключительно протокол расширенных запросов. По умолчанию — 0. |
| application_name_add_host |
Добавляет адрес хоста клиента и его порт в параметр имени приложения, задаваемый при установлении соединения. Это помогает определить источник некорректных запросов. Параметр перезаписывается без обнаружения, если приложение выполняет команду SET application_name после подключения. По умолчанию — 0. |
| conffile |
Показывает расположение текущего файла конфигурации. Изменение этого параметра приведёт к тому, что PgBouncer будет использовать другой файл конфигурации для следующих команд RELOAD/SIGHUP. По умолчанию — файл из командной строки |
| service_name |
Используется при регистрации службы win32. По умолчанию — pgbouncer. |
| job_name | Алиас для service_name. |
Таблица 74— Параметры журнала
|
Параметр |
Описание |
|---|---|
| syslog |
Включает и выключает запись в syslog. По умолчанию — 0. |
| syslog_ident |
Имя, с которым события передаются в syslog. По умолчанию — pgbouncer. |
| syslog_facility |
Субъект, который будет указываться в событиях, отправляемых в syslog. Возможные значения: auth, authpriv, daemon, user, local0-7. По умолчанию — daemon. |
| log_connections |
Зарегистрирует в журнале успешные входы в систему. По умолчанию — 1. |
| log_disconnections |
Регистрирует в журнале отключения с указанием причин. По умолчанию — 1. |
| log_pooler_errors |
Регистрирует сообщения об ошибках, которые пул отправляет клиентам. По умолчанию — 1. |
| stats_period |
Указывает интервал записи агрегированной статистики в журнал. По умолчанию — 60. |
Таблица 75— Параметры управления доступом к консоли
|
Параметр |
Описание |
|---|---|
| admin_users |
Разделённый запятыми список пользователей базы данных, которым разрешено подключаться и выполнять все команды в консоли администрирования PgBouncer. Игнорируется, когда auth_type=any, и в этом случае любой пользователь может подключаться в качестве администратора. По умолчанию — empty. |
| stats_users |
Разделённый запятыми список пользователей базы данных, которым разрешено подключаться и выполнять запросы только на чтения на консоли. Сюда входят все команды SHOW, кроме SHOW FDS. По умолчанию — empty. |
Таблица 76— Параметры проверки активности соединений, таймаутов
|
Параметр |
Описание |
|---|---|
| server_reset_query |
Запрос, направляемый на сервер при освобождении соединения перед тем, как оно станет доступным для других клиентов. В этот момент никакая транзакция не выполняется, поэтому запрос не должен включать команды ABORT или ROLLBACK. Запрос должен очистить все изменения, внесённые в сеанс базы данных, чтобы следующий клиент получил соединение в чётко определённом состоянии. По умолчанию установленная команда DISCARD ALL очищает все, но не оставляет следующему клиенту предварительно кэшированного состояния. Когда используется пул транзакций, server_reset_query должен быть пустым, поскольку клиенты не должны использовать какие-либо свойства сеанса. Если клиенты действительно используют свойства сеанса, они будут прерваны, потому что пул транзакций не гарантирует, что следующий запрос будет выполняться в том же соединении. По умолчанию — DISCARD ALL; |
| server_reset_query_always |
Определяет, следует ли запускать server_reset_query во всех режимах пула. Когда этот параметр выключен (по умолчанию), server_reset_query будет запускаться только в пулах, которые находятся в режиме пула сеансов. Соединения в режиме пула транзакций не должны требовать запроса сброса состояния. По умолчанию — 0. |
| server_check_delay |
Определяет, как долго сохранять освобожденные соединения доступными для повторного использования без выполнения запросов проверки работоспособности. Если 0, то запрос выполняется всегда. По умолчанию — 30.0. |
| server_check_query |
Простой бездействующий запрос для проверки сохранения соединения с сервером. Если строка пуста, проверка соединения отключена. По умолчанию — SELECT 1; |
| server_lifetime |
pgbouncer будет закрывать неиспользуемое серверное подключение, существующее дольше заданного времени (в секундах). Значение 0 означает, что соединение будет использоваться только один раз, а затем будет закрыто. По умолчанию — 3600.0. |
| server_idle_timeout |
Если соединение с сервером простаивает больше указанного количества секунд, оно разрывается. Если этот параметр установлен на 0, тайм-аут отключён. По умолчанию — 600.0. |
| server_connect_timeout |
Если соединение и вход в систему не завершатся за указанное количество секунд, соединение будет закрыто. По умолчанию — 15.0. |
| server_login_retry |
Если вход в систему завершается неудачно из-за сбоя в connect() или аутентификации, pgbouncer будет ждать указанное количество секунд перед повторной попыткой подключения. По умолчанию — 15.0. |
| client_login_timeout |
Если клиент подключается, но не может войти в систему за указанное количество секунд, он отключается. Требуется в основном, чтобы «мёртвые» подключения не задерживали операцию SUSPEND и, как следствие, перезагрузку «на лету». По умолчанию — 60.0. |
| autodb_idle_timeout |
Если пулы баз данных, созданные автоматически (через *), не использовались указанное количество секунд, они освобождаются. Их статистика также сбрасывается. По умолчанию — 3600.0. |
| dns_max_ttl |
Определяет, как долго в секундах кэшировать запросы DNS. Если поиск в DNS возвращает несколько ответов, PgBouncer будет использовать их по очереди. Фактическое значение TTL DNS игнорируется. По умолчанию — 15.0. |
| dns_nxdomain_ttl |
Определяет, как долго можно кэшировать ошибки и запросы DNS NXDOMAIN в секундах. По умолчанию — 15.0. |
| dns_zone_check_period |
Определяет интервал проверки, изменений серийных номеров зон. PgBouncer может собрать список DNS-зон из имён хостов (все после первой точки), а затем периодически проверять, не изменились ли серийные номера зон. Если изменения обнаружены, все имена хостов в этой зоне ищутся снова. Если какой-либо IP-адрес хоста изменяется, его соединения становятся недействительными. Работает только с библиотекой UDNS и c-ares (--with-udns или --with-cares для настройки). По умолчанию — 0,0 (disabled). |
Таблица 77— Параметры TLS
|
Параметр |
Описание |
|---|---|
| client_tls_sslmode |
Режим TLS, выбираемый для подключений от клиентов. По умолчанию соединения TLS отключены. Если параметр указан, client_tls_key_file и client_tls_cert_file также должны быть настроены для установки ключа и сертификата, которые PgBouncer использует для приёма клиентских подключений.
|
| client_tls_key_file |
Закрытый ключ для PgBouncer для приёма клиентских подключений. По умолчанию — не указан. |
| client_tls_cert_file |
Файл корневого сертификата для проверки сертификатов клиентов. По умолчанию — не указан. |
| client_tls_ca_file |
Корневой сертификат для проверки сертификатов клиентов. По умолчанию — не указан. |
| client_tls_protocols |
Какие версии протокола TLS разрешены. Допустимые значения: tlsv1.0, tlsv1.1, tlsv1.2. Краткие обозначения: all (tlsv1.0, tlsv1.1, tlsv1.2), secure (tlsv1.2), legacy (all). По умолчанию — all. |
| client_tls_ciphers | По умолчаниюt — fast. |
| client_tls_ecdhcurve |
Имя эллиптической кривой для обмена ключами ECDH. Допустимые значения: none (DH отключён), auto (256-битный ECDH), curve name. По умолчанию — auto. |
| client_tls_dheparams |
Тип обмена ключами DHE. Допустимые значения: none (DH отключён), auto (2048-битный DH), legacy (1024-битный DH). По умолчанию — auto. |
| server_tls_sslmode |
Режим TLS для подключения к серверам RT.Warehouse и PostgreSQL. По умолчанию соединения TLS отключены.
|
| server_tls_ca_file |
Путь к файлу корневого сертификата, который используется для проверки сертификатов сервера RT.Warehouse и PostgreSQL. По умолчанию — не установлено. |
| server_tls_key_file |
Закрытый ключ для PgBouncer для аутентификации на сервере RT.Warehouse или PostgreSQL. По умолчанию — не установлено. |
| server_tls_cert_file |
Сертификат на закрытый ключ. Серверы RT.Warehouse или PostgreSQL могут его проверить. По умолчанию — не установлено. |
| server_tls_protocols |
Определяет, какие версии протокола TLS разрешены. Допустимые значения: tlsv1.0, tlsv1.1, tlsv1.2. Краткие обозначения: all (tlsv1.0, tlsv1.1, tlsv1.2); secure (tlsv1.2); legacy (all). По умолчанию — all. |
| server_tls_ciphers | По умолчанию — fast. |
Установка следующих таймаутов может вызвать непредвиденные ошибки.
Таблица 78— Параметры опасных таймаутов
|
Параметр |
Описание |
|---|---|
| query_timeout |
Запросы, выполняющиеся дольше указанного времени (секунд), отменяются. Этот параметр следует использовать только с немного меньшим значением чем в statement_timeout на стороне сервера, чтобы улавливать запросы с проблемами сети. По умолчанию — 0.0 (disabled). |
| query_wait_timeout |
Максимальное время в секундах, в течение которого запросы могут ожидать выполнения. Если запросу не назначено соединение в течение этого времени, клиент отключается. Это используется для предотвращения перехвата соединений неотвечающими серверами. По умолчанию — 120. |
| client_idle_timeout |
Клиентские соединения, бездействующие дольше этого количества секунд, закрываются. Это значение должно быть больше, чем таймаут подключения на стороне клиента, и использоваться только для сетевых проблем. По умолчанию — 0.0 (disabled). |
| idle_transaction_timeout |
Если клиент находился в состоянии «простоя в транзакции» дольше этого времени (секунд), он отключается. По умолчанию — 0.0 (disabled). |
Таблица 79— Низкоуровневые параметры сети
|
Параметр |
Описание |
|---|---|
| pkt_buf |
Размер внутреннего буфера для пакетов. Влияет на размер отправляемых TCP-пакетов и общее использование памяти. Фактически пакеты libpq могут быть больше этого размера, поэтому нет необходимости устанавливать значение большим. По умолчанию — 4096. |
| max_packet_size |
Максимальный размер пакетов, которые принимает PgBouncer. Один пакет — это либо один запрос, либо одна строка набора результатов. Полный набор результатов может быть больше. По умолчанию — 2147483647. |
| listen_backlog |
Параметр отставания для системного вызова listen(2). Он определяет, сколько новых безответных попыток подключения хранится в очереди. Когда очередь заполнена, дальнейшие попытки подключения сбрасываются. По умолчанию — 128. |
| sbuf_loopcnt |
Определяет, сколько раз обрабатывать данные по одному соединению, прежде чем перейти к другому. Без этого ограничения одно соединение с большим набором результатов может задержать PgBouncer на долгое время. Один цикл обрабатывает один объём данных pkt_buf. 0 означает отсутствие ограничений. По умолчанию — 5. |
| suspend_timeout |
Определяет, сколько секунд ждать сброса буфера во время выполнения SUSPEND или перезапуска (-R). Соединение разрывается, если сбросить не удалось. По умолчанию — 10. |
| tcp_defer_accept |
Подробнее об этом и других параметрах TCP см. справочную страницу tcp(7). По умолчанию — 45 в Linux, иначе — 0. |
| tcp_socket_buffer | По умолчанию — не установлено. |
| tcp_keepalive |
Включает базовую поддержку активности с настройками ОС по умолчанию. В Linux системные значения по умолчанию: tcp_keepidle=7200, tcp_keepintvl=75, tcp_keepcnt=9. По умолчанию — 1. |
| tcp_keepcnt | По умолчанию — не установлено. |
| tcp_keepidle | По умолчанию — не установлено. |
| tcp_keepintvl | По умолчанию — не установлено. |
Этот раздел содержит пары key=value, где key — это имя пользователя, а value — это строка подключения для libpq в виде пары key=value.
Таблица 80— Параметры пула
|
Параметр |
Описание |
|---|---|
| pool_mode | Устанавливает режим пула для всех подключений указанного пользователя. Если параметр не задан, используется значение базы данных или pool_mode по умолчанию. |
[databases]
postgres = host=127.0.0.1 dbname=postgres auth_user=gpadmin
[pgbouncer]
pool_mode = session
listen_port = 6543
listen_addr = 127.0.0.1
auth_type = md5
auth_file = users.txt
logfile = pgbouncer.log
pidfile = pgbouncer.pid
admin_users = someuser
stats_users = stat_collectorИспользовать параметры подключения, переданные клиентом:
[databases]
* =
[pgbouncer]
listen_port = 6543
listen_addr = 0.0.0.0
auth_type = trust
auth_file = bouncer/users.txt
logfile = pgbouncer.log
pidfile = pgbouncer.pid
ignore_startup_parameters=options[databases]
; foodb over unix socket
foodb =
; redirect bardb to bazdb on localhost
bardb = host=127.0.0.1 dbname=bazdb
; access to destination database will go with single user
forcedb = host=127.0.0.1 port=300 user=baz password=foo client_encoding=UNICODE datestyle=ISOКонсоль администрирования PgBouncer.
psql -p port pgbouncerКонсоль администрирования PgBouncer доступна через psql. Чтобы войти в консоль, необходимо подключиться к порту PgBouncer и виртуальной базе данных с именем pgbouncer.
Пользователи, перечисленные в параметрах admin_users и stats_users конфигурации pgbouncer.ini, имеют права входить в консоль администрирования PgBouncer.
Вы можете управлять соединениями между PgBouncer и RT.Warehouse с консоли. Вы также можете установить параметры конфигурации PgBouncer.
Таблица 81— Параметры pgbouncer-admin
|
Параметр |
Описание |
|---|---|
| -p port | Номер порта PgBouncer. |
pgbouncer=# SHOW help;
NOTICE: Console usage
DETAIL:
SHOW HELP|CONFIG|DATABASES|POOLS|CLIENTS|SERVERS|VERSION
SHOW FDS|SOCKETS|ACTIVE_SOCKETS|LISTS|MEM
SHOW DNS_HOSTS|DNS_ZONES
SHOW STATS|STATS_TOTALS|STATS_AVERAGES
SET key = arg
RELOAD
PAUSE [<db>]
RESUME [<db>]
DISABLE <db>
ENABLE <db>
KILL <db>
SUSPEND
SHUTDOWNСледующие административные команды PgBouncer управляют запущенным процессом pgbouncer.
Таблица 82— Команды администрирования
|
Команда |
Описание |
|---|---|
| PAUSE [db] |
Если база данных не указана, PgBouncer пытается отключиться от всех серверов, сначала ожидая завершения всех запросов. Команда не выполнится, пока все запросы не будут завершены. Эта команда должна использоваться для подготовки к перезапуску базы данных. Если указано имя базы данных, PgBouncer приостанавливает только эту базу данных. Если вы запустите команду PAUSE db, а затем команду PAUSE, чтобы приостановить все базы данных, вы должны выполнить две команды RESUME, одну для всех баз данных и одну для указанной базы данных. |
| SUSPEND | Все буферы сокетов очищаются, и PgBouncer перестаёт прослушивать данные на них. Команда не выполнится, пока все буферы не очистятся. Эта команда должна использоваться для перезагрузки pgbouncer «на лету».. |
| RESUME [db] |
Останавливает работу после предыдущей команды PAUSE или SUSPEND. Если база данных была указана для команды PAUSE, база данных также должна быть указана с помощью команды RESUME. После приостановки всех баз данных с помощью команды PAUSE возобновление одной базы данных с помощью RESUME db не поддерживается. |
| DISABLE db | Отклоняет все новые клиентские подключения к базе данных. |
| ENABLE db | Разрешает новые клиентские подключения к базе данных. |
| KILL db | Немедленно отключает все клиентские и серверные подключения к указанной базе данных. |
| SHUTDOWN | Останавливает процесс PgBouncer. Чтобы выйти из сеанса командной строки psql, введите \q. |
| RELOAD | Процесс PgBouncer перезагружает текущий файл конфигурации и обновляет изменяемые настройки. |
| SET key=value | Отменяет указанный параметр конфигурации. См. команду SHOW CONFIG;. |
Категории команды SHOW отображают различные типы информации PgBouncer. Вы можете указать одну из следующих категорий:
Таблица 83— Информация об активном сокете
|
Столбец |
Описание |
|---|---|
| type | S — для сервера, C — для клиента. |
| user | Имя пользователя, которое pgbouncer использует для подключения к серверу. |
| database | Имя базы данных. |
| state | Состояние подключения к серверу: active, used или idle. |
| addr | IP-адрес сервера PostgreSQL. |
| port | Порт сервера PostgreSQL. |
| local_addr | Исходный адрес подключения на локальной машине. |
| local_port | Исходный порт подключения на локальной машине. |
| connect_time | Время установления подключения. |
| request_time | Время выдачи последнего запроса. |
| wait | Время ожидания. |
| wait_us | Время ожидания (микросекунды). |
| ptr | Адрес внутреннего объекта для данного соединения. Используется как уникальный идентификатор. |
| link | Адрес клиентского подключения, с которым связан сервер. |
| remote_pid | Идентификатор обслуживающего серверного процесса (PID) |
| tls | Информация о TLS-подключении. |
| recv_pos | Позиция приёма в буфере ввода-вывода. |
| pkt_pos | Парсинг позиции в буфере ввода-вывода. |
| pkt_remain | Количество пакетов, оставшихся в сокете. |
| send_pos | Позиция отправки в пакете. |
| send_remain | Общая длина пакета, оставшегося для отправки. |
| pkt_avail | Объём буфера ввода-вывода, оставшийся для анализа. |
| send_avail | Количество буфера ввода-вывода, оставшегося для отправки. |
Таблица 84— Клиенты
|
Столбец |
Описание |
|---|---|
| type | C — для клиента. |
| user | Пользователь, подключённый со стороны клиента. |
| database | Имя базы данных. |
| state | Состояние клиентского соединения: active, used, waiting или idle. |
| addr | IP-адрес клиента или unix для подключения через сокет. |
| port | Порт, к которому подключён клиент. |
| local_addr | Конечный адрес подключения на локальной машине. |
| local_port | Конечный порт подключения на локальной машине.. |
| connect_time | Время установления подключения. |
| request_time | Время последнего запроса клиента. |
| wait | Текущая длительность ожидания (в секундах). |
| wait_us | Дробная часть текущей длительности ожидания (в микросекундах). |
| ptr | Адрес внутреннего объекта для данного подключения. Используется как уникальный идентификатор. |
| link | Адрес подключения к серверу, с которым связан клиент. |
| remote_pid | Идентификатор процесса (PID), в случае, если клиент подключается через сокет UNIX и ОС может выдать этот идентификатор. |
| tls | Клиентский контекст TLS. |
Список текущих настроек параметров PgBouncer.
Таблица 85— Конфигурация
|
Столбец |
Описание |
|---|---|
| key | Имя переменной конфигурации. |
| value | Значение переменной конфигурации. |
| changeable | Либо yes, либо no. Показывает, можно ли изменить переменную во время работы. Если no, переменную можно изменить только во время перезагрузки. |
Таблица 86— Базы данных
|
Столбец |
Описание |
|---|---|
| name | Имя настроенной записи базы данных. |
| host | Хост, к которому подключается pgbouncer. |
| port | Порт, к которому подключается pgbouncer. |
| database | Фактическое имя базы данных, к которой подключается pgbouncer. |
| force_user | Когда пользователь указан в строке соединения, подключение между pgbouncer и сервером базы данных должно устанавливаться от его имени, вне зависимости от пользователя на стороне клиента. |
| pool_size | Максимальное количество подключений к серверу. |
| reserve_pool | Количество дополнительных подключений, которые могут быть созданы, если размер пула достигнет pool_size. |
| pool_mode | Переопределение pool_mode для базы данных либо NULL, если должен использоваться режим по умолчанию. |
| max_connections | Максимальное количество подключений для всех пулов для этой базы данных. |
| current_connections | Общее количество подключений для всех пулов для этой базы данных. |
| paused | 1 — если база данных находится в состоянии паузы, 0 — иначе. |
| disabled | 1 — если база данных находится в отключённом состоянии, 0 — иначе. |
Таблица 87— Хосты DNS в кэше
|
Столбец |
Описание |
|---|---|
| hostname | Имя хоста. |
| ttl | Сколько секунд до следующего поиска. |
| addrs | Список адресов, разделённых запятыми. |
Таблица 88— Зоны DNS в кэше
|
Столбец |
Описание |
|---|---|
| zonename | Название зоны. |
| serial | Текущий серийный номер DNS. |
| count | Имена хостов, принадлежащие этой зоне. |
SHOW FDS — это внутренняя команда, используемая для перезапуска через Интернет, например, при обновлении до новой версии PgBouncer. Он отображает список используемых файловых дескрипторов и их внутреннее состояние. Эта команда блокирует внутренний цикл событий, поэтому её не следует выполнять, пока используется PgBouncer.
При подключении пользователя с именем pgbouncer через сокет Unix из процесса с UID, совпадающим с UID текущего процесса, ему передаются реальные файловые дескрипторы.
Таблица 89— FDS
|
Столбец |
Описание |
|---|---|
| fd | Числовое значение файлового дескриптора. |
| task | Предназначение. Одно из значений — pooler, client или server. |
| user | Пользователь соединения, использующий указанный файловый дескриптор. |
| database | База данных подключения, использующий указанный файловый дескриптор. |
| addr | IP-адрес соединения, использующий указанный файловый дескриптор; unix, если используется сокет Unix. |
| port | Порт, используемый соединением с использованием файлового дескриптора. |
| cancel | Ключ отмены для этого подключения. |
| link | Файловый дескриптор ответной стороны сервера/клиента. NULL, если подключение простаивает. |
| client_encoding | Кодировка, используемая для базы данных. |
| std_strings | Контролирует, обрабатывают ли обычные строковые литералы ('...') обратную косую черту буквально, как указано в стандарте SQL. |
| datestyle | Формат отображения значений даты и времени. |
| timezone | Часовой пояс для интерпретации и отображения отметок времени. |
| password | Пароль auth_user. |
Показывает следующую статистику PgBouncer в двух столбцах: метку элемента и значение.
Таблица 90— Количество элементов PgBouncer
|
Элемент |
Описание |
|---|---|
| databases | Количество баз данных. |
| users | Количество пользователей. |
| pools | Количество пулов. |
| free_clients | Количество свободных клиентов. |
| used_clients | Количество занятых клиентов. |
| login_clients | Количество клиентов в статусе login. |
| free_servers | Количество свободных серверов. |
| used_servers | Количество занятых серверов. |
| dns_names | Количество DNS-имён. |
| dns_zones | Количество зон DNS. |
| dns_queries | Количество DNS-запросов. |
| dns_pending | Количество запросов DNS «на лету». |
Показывает информацию о кэш-памяти для этих кэшей PgBouncer:
Таблица 91— Кэш in-memory
|
Столбец |
Описание |
|---|---|
| name | Имя кэша. |
| size | Размер одного слота в кэше. |
| used | Количество используемых слотов в кэше. |
| free | Количество доступных слотов в кэше. |
| memtotal | Общее количество байтов, используемых кэшем. |
Новая запись в пуле создаётся для каждой пары (база данных, пользователь).
Таблица 92— Пулы
|
Столбец |
Описание |
|---|---|
| database | Имя базы данных. |
| user | Имя пользователя. |
| cl_active | Клиентские подключения, которые связаны с сервером и могут обрабатывать запросы. |
| cl_waiting | Клиентские подключения, которые отправили запросы, но ещё не получили подключение к серверу. |
| sv_active | Число подключений к серверу, связанных с клиентом. |
| sv_idle | Число неиспользуемых серверных соединений, которые можно сразу использовать для клиентских запросов. |
| sv_used | Число серверных соединений, которые простаивают дольше server_check_delay. Запрос server_check_query должен быть запущен на них, прежде чем их можно будет использовать. |
| sv_tested | Число подключений к серверу, для которых в данный момент выполняются запросы server_reset_query или server_check_query. |
| sv_login | Число серверных соединений, которые в данный момент находятся в процессе входа. |
| maxwait | Время ожидания первого (самого старого) клиента в очереди в секундах. Если он начинает увеличиваться, текущий пул серверов не обрабатывает запросы достаточно быстро. Причина может быть в перегрузке сервера или слишком маленьком значении pool_size. |
| maxwait_us | Дробная часть максимального времени ожидания (в микросекундах). |
| pool_mode | Действующий режим пула. |
Таблица 93— Серверы
|
Столбец |
Описание |
|---|---|
| type | S — для сервера. |
| user | ID пользователя, который pgbouncer использует для подключения к серверу. |
| database | Имя базы данных. |
| state | Состояние подключения к серверу pgbouncer: active, used или idle. |
| addr | IP-адрес сервера RT.Warehouse или PostgreSQL. |
| port | Порт сервера RT.Warehouse или PostgreSQL. |
| local_addr | Исходный адрес подключения на локальной машине. |
| local_port | Исходный порт подключения на локальной машине. |
| connect_time | Время установления подключения. |
| request_time | Время выдачи последнего запроса. |
| wait | Текущая длительность ожидания (в секундах). |
| wait_us | Дробная часть текущей длительности ожидания (в микросекундах). |
| ptr | Адрес внутреннего объекта для этого подключения. Используется как уникальный идентификатор. |
| link | Адрес клиентского соединения, с которым связан сервер. |
| remote_pid | Идентификатор обслуживающего серверного процесса (PID). Если соединение осуществляется через сокет Unix и ОС поддерживает получение информации об идентификаторе процесса, это идентификатор ОС. В противном случае он извлекается из пакета для отмены, отправленного сервером, который должен быть PID, если сервером является PostgreSQL, но это будет случайное число, если сервером является другой PgBouncer. |
| tls | Информация о TLS-подключении. |
Показывает статистику.
Таблица 94— Статистика
|
Столбец |
Описание |
|---|---|
| database | База данных, для которой представлена статистика. |
| total_xact_count | Общее количество транзакций SQL, объединённых PgBouncer. |
| total_query_count | Общее количество SQL-запросов, объединённых PgBouncer. |
| total_received | Общий объём сетевого трафика (в байтах), который получил pgbouncer. |
| total_sent | Общий объём сетевого трафика (в байтах), который передал pgbouncer. |
| total_xact_time | Общее количество микросекунд, потраченных PgBouncer при подключении к RT.Warehouse в транзакции, либо в режиме ожидания в транзакции, либо при выполнении запросов. |
| total_query_time | Общее количество микросекунд, потраченных pgbouncer при активном подключении к серверу базы данных. |
| total_wait_time | Время, затраченное (в микросекундах) клиентами на ожидание сервера. |
| avg_xact_count | Среднее количество транзакций SQL, объединённых PgBouncer. |
| avg_query_count | Среднее количество запросов в секунду за последний статистический период. |
| avg_recv | Среднее количество полученных (от клиентов) байт в секунду. |
| avg_sent | Среднее количество отправленных (клиентам) байт в секунду. |
| avg_xact_time | Средняя продолжительность транзакции в микросекундах. |
| avg_query_time | Средняя продолжительность запроса в микросекундах. |
| avg_wait_time | Время, затраченное клиентами на ожидание сервера в микросекундах (в среднем в секунду). |
Подмножество SHOW STATS, показывающее средние значения для выбранной статистики.
Подмножество SHOW STATS, показывающее общие значения для выбранной статистики.
Таблица 95— Пользователи
|
Столбец |
Описание |
|---|---|
| name | Имя пользователя. |
| pool_mode | Пользовательское переопределение pool_mode или NULL, если вместо него будет использоваться значение по умолчанию. |
Показывает информацию о версии PgBouncer.
|
Примечание. Эта справочная документация основана на документации PgBouncer 1.8.1. |
Интерактивный интерфейс командной строки для RT.Warehouse.
psql [option ...] [dbname [username]]psql — это терминальный интерфейс для RT.Warehouse. Он позволяет вводить запросы в интерактивном режиме, отправлять их в RT.Warehouse и просматривать результаты запросов. Как вариант, ввод может быть из файла. Кроме того, он предоставляет ряд метакоманд и различные функции, подобные оболочке, для облегчения написания скриптов и автоматизации широкого спектра задач.
Таблица 96— Параметры psql
|
Параметр |
Описание |
|---|---|
| -a | --echo-all | Вывод всех непустых строк ввода в стандартный вывод по мере их чтения. (Это не относится к строкам, читаемым в интерактивном режиме.) Это эквивалентно установке переменной ECHO в all. |
| -A | --no-align | Переключение в режим невыровненного вывода. (Режим вывода по умолчанию выровнен.). |
| -c 'command' | --command='command' |
Указывает, что psql должен выполнить указанную командную строку, а затем завершиться. Это полезно в скриптах оболочки. Команда должна быть либо командной строкой, которая полностью интерпретируется сервером, либо одной командой с обратной косой чертой. Таким образом, с этим параметром нельзя смешивать метакоманды SQL и psql. Для этого вы можете передать строку в psql, например: (\\ — разделитель метакоманды) Если командная строка содержит несколько SQL-команд, они обрабатываются в одной транзакции, только если в строку не включены явные команды BEGIN/COMMIT, разделяющие её на несколько транзакций. Это отличается от поведения, когда та же строка подаётся на стандартный ввод psql. Кроме того, возвращается только результат последней SQL-команды. |
| -d dbname | --dbname=dbname |
Задаёт имя базы данных для подключения. Это эквивалентно указанию dbname в качестве первого аргумента командной строки, не являющегося параметром. Если этот параметр содержит знак = или начинается с допустимого префикса URI (postgresql:// или postgres://), он рассматривается как строка conninfo. Для получения дополнительной информации см. Строки подключения в документации PostgreSQL. |
| -e | --echo-queries | Копирует все SQLкоманды, отправленные на сервер, также на стандартный вывод. |
| -E | --echo-hidden | Отображает фактические запросы, генерируемые \d и другими командами с обратной косой чертой. Вы можете использовать это для изучения внутренних операций psql. Это эквивалентно установке значения on переменной ECHO_HIDDEN. |
| -f filename | --file=filename |
Использует filename в качестве источника команд вместо интерактивного чтения команд. После обработки файла psql завершает работу. Это во многом эквивалентно метакоманде \i. Если имя файла - (дефис), то стандартный ввод читается до индикации EOF или метакоманды \q. Обратите внимание, однако, что Readline в этом случае не используется (как если бы был указан -n). Использование этого параметра немного отличается от записи psql < filename. В общем, оба варианта будут делать то, что вы ожидаете, но использование -f включает некоторые полезные функции, такие как сообщения об ошибках с номерами строк. Также существует небольшая вероятность того, что использование этого параметра снизит затраты на запуск. С другой стороны, вариант, использующий перенаправление ввода оболочки (теоретически), гарантированно даст точно такой же результат, который вы получили бы, если бы вводили все вручную. |
| -F separator | --field-separator=separator | Использует указанный разделитель в качестве разделителя полей для невыровненного вывода. |
| -H | --html | Переключает в режим вывода HTML. |
| -l | --list | Выводит список всех доступных баз данных и завершается. Другие параметры, не связанные с соединением, игнорируются. |
| -L filename | --log-file=filename | В дополнение к обычному выводу, записывает вывод результатов всех запросов в указанный файл. |
| -n | --no-readline | Отключает использование Readline для редактирования командной строки и использования истории команд. Может быть полезно для выключения расширенных действий клавиши табуляции при вырезании и вставке. |
| -o filename | --output=filename | Записывает вывод результатов всех запросов в указанный файл. |
| -P assignment | --pset=assignment | Позволяет указать параметры печати в стиле \pset в командной строке. Обратите внимание, что здесь вы должны разделять имя и значение знаком равенства вместо пробела. Таким образом, чтобы установить формат вывода в LaTeX, вы можете написать -P format=latex. |
| -q | --quiet | Указывает, что psql должен работать без вывода дополнительных сообщений. По умолчанию он выводит приветственные сообщения и различные информационные сообщения. Если используется этот параметр, ничего из этого не происходит. Это полезно использовать с параметром -c. Это эквивалентно установке значения on переменной QUIET. |
| -R separator | --record-separator=separator | Использует указанный разделитель в качестве разделителя записей для невыровненного режима вывода. |
| -s | --single-step | Запуск в пошаговом режиме. Это означает, что пользователю предлагается перед отправкой каждой команды на сервер возможность отменить выполнение. Используйте это для отладки скриптов. |
| -S | --single-line | Запуск в однострочном режиме, где новая строка завершает команду SQL, как и точка с запятой. |
| -t | --tuples-only | Отключает вывод имён столбцов и результирующей строки с количеством выбранных записей. Эта команда эквивалентна \pset tuples_only и предоставляется для удобства. |
| -T table_options | --table-attr= table_options | Позволяет указать параметры, которые будут помещены в тег таблицы HTML. Подробности смотрите в \pset. |
| -v assignment | --set=assignment | --variable= assignment | Выполняет присвоение переменной, как метакоманда \set. Обратите внимание, что вы должны разделить имя и значение, если они есть, знаком равенства в командной строке. Чтобы отключить переменную, не ставьте знак равенства. Чтобы установить переменную с пустым значением, используйте знак равенства, но опустите значение. Эти присваивания выполняются на очень ранней стадии запуска, поэтому переменные, зарезервированные для внутренних целей, могут быть перезаписаны позже. |
| -V | --version | Выводит версию psql и завершает работу. |
| -x | --expanded | Включает режим развёрнутого вывода таблицы. |
| -X | --no-psqlrc | Не читать стартовые файлы (ни общесистемный файл psqlrc, ни пользовательский файл ~/.psqlrc). |
| -z | --field-separator-zero | Устанавливает нулевой байт в качестве разделителя полей для невыровненного режима вывода. |
| -0 | --record-separator-zero | Установить нулевой байт в качестве разделителя записей для невыровненного режима вывода. Это полезно для взаимодействия, например, с xargs -0. |
| -1 | --single-transaction |
Когда psql выполняет скрипт, добавление этого параметра обёртывает BEGIN/COMMIT вокруг скрипта, чтобы выполнить его как одну транзакцию. Это гарантирует, что либо все команды будут выполнены успешно, либо никакие изменения не будут применены. Если сам скрипт использует BEGIN, COMMIT или ROLLBACK, этот параметр не даст желаемых результатов. Кроме того, если скрипт содержит какую-либо команду, которая не может быть выполнена внутри блока транзакции, указание этого параметра приведет к сбою этой команды (и, следовательно, всей транзакции). |
| -? | --help | Показывает справку об аргументах командной строки psql и завершает работу. |
Таблица 97— Параметры подключения psql
|
Параметр |
Описание |
|---|---|
| -h host | --host=host |
Имя хоста машины, на которой работает сервер мастера RT.Warehouse. Если параметр не указан, значение считывается из переменной среды PGHOST или по умолчанию используется localhost. При запуске psql на хосте мастера, если значение хоста начинается с косой черты, он используется как каталог для сокета UNIX-домена. |
| -p port | --port=port | Порт TCP, на котором сервер мастера RT.Warehouse прослушивает соединения. Если параметр не указан, значение считывается из переменной среды PGPORT или по умолчанию 5432. |
| -U username | --username=username | Имя системной роли, используемое для подключения к базе данных. Если параметр не указан, значение считывается из переменной среды PGUSER или по умолчанию используется имя текущей системной роли. |
| -W | --password | Принудительно запрашивать пароль перед подключением к базе данных. psql автоматически запрашивает пароль всякий раз, когда сервер запрашивает аутентификацию по паролю. Однако в настоящее время обнаружение запроса пароля не является полностью надёжным, поэтому этот параметр принудительно выводит запрос. Если запрос пароля не выдаётся, а сервер требует аутентификации по паролю, попытка подключения не удастся. |
| -w --no-password |
Не выдавать запрос на ввод пароля. Если сервер требует аутентификации по паролю, а пароль нельзя получить из других источников, например из файла .pgpass, попытка подключения не удастся. Этот параметр может быть полезен в пакетных заданиях и скриптах, где нет пользователя, который вводит пароль. Примечание. Этот параметр действует на протяжении всей сессии, поэтому он влияет на использование метакоманды \connect, а также на первую попытку подключения. |
Если psql завершилась нормально, она возвращает командной оболочке 0; 1 — если произошла фатальная ошибка (нехватка памяти, файл не найден); 2 — если соединение с сервером было неудачным и сеанс был не интерактивным; 3 — если произошла ошибка в скрипте и в установленной переменной ON_ERROR_STOP.
psql — это клиентское приложение для RT.Warehouse. Для подключения к базе данных вам необходимо знать имя целевой базы данных, имя хоста и номер порта сервера мастера RT.Warehouse, а также имя пользователя базы данных, от имени которого вы хотите подключиться. Эти свойства можно задать через аргументы командной строки, а именно -d, -h, -p и -U соответственно. Если найден аргумент, не принадлежащий ни одному параметру, он будет интерпретирован как имя базы данных (или имя пользователя, если имя базы данных уже указано). Не все эти параметры задавать обязательно; у них есть разумные значения по умолчанию. Если вы опустите имя хоста, psql будет подключаться через сокет UNIX-домена к серверу мастера на локальном хосте или к localhost через TCP/IP на машинах, у которых нет сокетов UNIX-домена. Номер порта мастера по умолчанию — 5432. Если вы используете другой порт для мастера, вы должны указать порт. Имя пользователя базы данных по умолчанию — это имя пользователя вашей операционной системы, как и имя базы данных, по умолчанию. Обратите внимание, что вы не можете просто подключиться к любой базе данных под любым именем пользователя. Узнать о ваших правах доступа можно у администратора базы данных.
Если значения по умолчанию некорректные, вы можете сэкономить время на вводе параметров подключения, установив для любого из них или всех параметров в переменные среды PGAPPNAME, PGDATABASE, PGHOST, PGPORT и PGUSER соответствующие значения.
Также удобно иметь файл ~/.pgpass, чтобы избежать регулярного ввода паролей. Этот файл должен находиться в вашем домашнем каталоге и содержать строки следующего формата:
hostname:port:database:username:passwordРазрешения на .pgpass должны запрещать любой доступ всем или группе (например: chmod 0600 ~/.pgpass). Если разрешения менее строгие, файл будет проигнорирован. (Однако в настоящее время права доступа к файлам не проверяются на клиентах Microsoft Windows.)
Альтернативный способ указать параметры подключения — это строка conninfo или URI, который используется вместо имени базы данных. Этот механизм даёт расширенные возможности для управления подключением. Например:
$ psql "service=myservice sslmode=require"
$ psql postgresql://gpmaster:5433/mydb?sslmode=requireВы также можете использовать LDAP для получения параметров подключения, как описано в Получение параметров подключения LDAP в документации PostgreSQL. См. Ключевые слова параметров в документации PostgreSQL для получения дополнительной информации обо всех доступных вариантах подключения.
Если соединение не может быть установлено по какой-либо причине (недостаточные права, сервер не работает и т.д.), psql вернёт ошибку и завершится.
Если хотя бы один из стандартного ввода или стандартного вывода является терминалом, то psql устанавливает для клиентской кодировки значение auto, которое определит соответствующую клиентскую кодировку из локальных настроек (переменная среды LC_CTYPE в системах Unix). Если это не сработает так, как ожидалось, кодировку клиента можно переопределить с помощью переменной среды PGCLIENTENCODING.
При нормальной работе psql предоставляет подсказку с именем базы данных, к которой в настоящее время подключён psql, за которой следует строка => для обычного пользователя или =# для суперпользователя. Например:
testdb=>
testdb=#В командной строке пользователь может вводить команды SQL. Обычно введённые строки отправляются на сервер, когда встречается точка с запятой, завершающая команду. Конец строки не завершает команду. Это позволяет разбивать команды на несколько строк для лучшего понимания. Если команда была отправлена и выполнена без ошибок, результат команды отобразится на экране.
Если к базе данных, которая не приведена в соответствие шаблону безопасного использования схем, имеют доступ недоверенные пользователи, начинайте сеанс с удаления доступных им для записи схем из пути поиска (search_path). Для этого можно добавить options=-csearch_path= в строку подключения или выполнить команду SELECT pg_catalog.set_config('search_path', '', false) перед другими SQL-командами. Это касается не только psql, но и любых других интерфейсов для выполнения произвольных SQL-команд.
Все, что вы вводите в psql, которое начинается с обратной косой черты и не берётся в кавычки, является метакомандой psql, которая обрабатывается самим psql. Эти команды помогают сделать psql более полезным для администрирования или написания скриптов.
Формат команды psql следующий: обратная косая черта (\), сразу за которой следует команда, а затем любые аргументы. Аргументы отделяются от команды и друг от друга любым количеством пробелов.
Чтобы включить пробел в значение аргумента, вы можете заключить его в одинарные кавычки. Чтобы включить одинарную кавычку в значение аргумента, напишите две одинарные кавычки в тексте в одинарных кавычках. Кроме того, все, что содержится в одинарных кавычках, подлежит замене в стиле языка C: для \n (новая строка), \t (табуляция), \b (пробел), \r (возврат каретки), \f (подача страницы), \digits (восьмеричное число) и \xdigits (шестнадцатеричное число). Обратная косая черта перед любым другим символом в тексте в одинарных кавычках заключает в кавычки этот единственный символ, каким бы он ни был.
Внутри аргумента текст, заключённый в обратные кавычки (`), воспринимается как командная строка, которая передается в оболочку. Вывод команды (с удалённым завершающим символом новой строки) заменяет текст в обратных кавычках.
Если в аргументе появляется двоеточие (:) без кавычек, за которым следует имя переменной psql, оно заменяется значением переменной, как описано в Интерполяция SQL.
Некоторые команды принимают в качестве аргумента идентификатор SQL (например, имя таблицы). Эти аргументы следуют синтаксическим правилам SQL: буквы без кавычек переводятся в нижний регистр, а двойные кавычки (") защищают буквы от преобразования регистра и позволяют включать пробелы в идентификатор. В двойных кавычках парные двойные кавычки сокращаются до одинарных двойных кавычек в получившееся имя. Например, FOO"BAR"BAZ интерпретируется как fooBARbaz, а "A weird"" name" становится A weird" name.
Синтаксический анализ аргументов останавливается, когда возникает другая обратная косая черта без кавычек. Это считается началом новой метакоманды. Специальная последовательность \\ (две обратные косые черты) отмечает конец аргументов и продолжает анализ SQL-команд, если они есть. Таким образом, SQL-команды и psql можно свободно смешивать в одной строке. Но в любом случае аргументы метакоманды не могут продолжаться за пределами конца строки.
Определены следующие метакоманды:
Таблица 98— Метакоманды
|
Мета-команда |
Описание |
|---|---|
| \a | Если текущий формат вывода таблицы невыровненный, он переключается на выровненный режим. Если текущий режим выровненный, то устанавливается невыровненный. Эта команда сохранена для обратной совместимости. См. \pset для более общего решения. |
| \c | \connect [dbname [username] [host] [port]] | conninfo |
Устанавливает новое соединение с RT.Warehouse. Используемые параметры соединения могут быть указаны либо с использованием позиционного синтаксиса, либо с использованием строк подключения conninfo, как подробно описано в Строках подключения libpq. Если команда опускает имя базы данных, пользователя, хост или порт, новое соединение может повторно использовать значения из предыдущего соединения. По умолчанию повторно используются значения из предыдущего соединения, за исключением обработки строки conninfo. Передача первого аргумента -reuse-previous=on или -reuse-previous=off отменяет это значение по умолчанию. Если команда не задаёт и не использует повторно конкретный параметр, используется значение по умолчанию libpq. Указание любого из dbname, username, host или port как есть — эквивалентно пропуску этого параметра. Если новое соединение установлено успешно, предыдущее соединение закрывается. Если попытка подключения не удалась, предыдущее подключение будет сохранено, только если psql находится в интерактивном режиме. При выполнении скрипта неинтерактивно, обработка немедленно прекращается с ошибкой. Это различное поведение было выбрано для удобства пользователя для защиты от опечаток и для защиты от случайных действий скриптов некорректно выбранной базе данных. Примеры:
|
| \C [title] | Устанавливает заголовок всех таблиц, которые выводятся в результате запроса, или отменяет любой такой заголовок. Эта команда эквивалентна \pset title. |
| \cd [directory] | Изменяет текущий рабочий каталог. Без аргументов устанавливается домашний каталог текущего пользователя. Чтобы распечатать текущий рабочий каталог, используйте \!pwd. |
| \conninfo | Отображает информацию о текущем соединении, включая имя базы данных, имя пользователя, тип соединения (сокет домена UNIX, TCP/IP и т.д.), хост и порт. |
| \copy {table [(column_list)] | (query)} {from | to} {'filename' | program 'command' | stdin | stdout | pstdin | pstdout} [with] (option [, ...]) ] |
Выполняет внешнюю (клиентскую) копию. Это операция, которая запускает SQL-команду COPY, но вместо того, чтобы сервер считывал или записывал указанный файл, psql считывает или записывает файл и пересылает данные между сервером и локальной файловой системой. Это означает, что доступ к файлам и привилегии принадлежат локальному пользователю, а не серверу, и привилегии суперпользователя SQL не требуются. Когда указана program, psql выполняет command, а данные от или к command маршрутизируются между сервером и клиентом. Это означает, что привилегии выполнения принадлежат локальному пользователю, а не серверу, и привилегии суперпользователя SQL не требуются. \copy ... from stdin | to stdout читает/записывает на основе ввода и вывода команды соответственно. Все строки читаются из того же источника, который выдал команду, до тех пор, пока не встретится \. или поток не достигает EOF. Вывод отправляется в то же место, что и вывод команды. Для чтения/записи стандартного ввода или вывода psql, используйте pstdin или pstdout. Этот параметр полезен для заполнения таблиц прямо в файл SQL-скрипта. Синтаксис команды аналогичен синтаксису SQL-команды COPY, а option должен указывать на один из параметров SQL-команды COPY. Обратите внимание, что из-за этого к команде \copy применяются особые правила синтаксического анализа. В частности, не применяются правила подстановки переменных и экранирование обратной косой черты. Эта операция не так эффективна, как SQL-команда COPY, поскольку все данные должны проходить через соединение клиент-сервер. |
| \copyright | Показывает авторские права и условия распространения PostgreSQL, на котором основана RT.Warehouse. |
| \d [relation_pattern] | \d+ [relation_pattern] | \dS [relation_pattern] |
Для каждого отношения (таблица, внешняя таблица, представление, индекс, последовательность или сторонняя таблица) или составного типа, соответствующего relation_pattern, показывает все столбцы, их типы, табличное пространство (если не по умолчанию) и любые специфические атрибуты, такие как NOT NULL или по умолчанию. Также выводятся связанные индексы, ограничения, правила и триггеры. Для сторонних таблиц также отображается связанный сторонний сервер.
Для многораздельных таблиц команда \d или \d+, указанная с корневой таблицей разделов или дочерней таблицей разделов, отображает информацию о таблице, включая ключи разделов, на текущем уровне таблицы разделов. Команда \d+ также отображает непосредственные дочерние разделы таблицы и показывает, является ли дочерний раздел внешней таблицей или обычной таблицей. Для таблиц, оптимизированных для добавления, и таблиц, ориентированных на столбцы, \d+ отображает параметры хранения для таблицы. Для таблиц, оптимизированных для добавления, параметры отображаются для таблицы. Для таблиц, ориентированных на столбцы, параметры хранения отображаются для каждого столбца.
Примечание. Если \d используется без аргумента шаблона, он эквивалентен \dtvsE, который покажет список всех видимых таблиц, представлений, последовательностей и сторонних таблиц. |
| \da[S] [aggregate_pattern] | Выводит перечень агрегатных функций вместе с типами данных, с которыми они работают. Если указан aggregate_pattern, выводятся только агрегаты, имена которых соответствуют указанному шаблону. По умолчанию выводятся только объекты, созданные пользователем; для включения системных объектов необходимо задать шаблон или добавить модификатор S. |
| \db[+] [tablespace_pattern] | Выводит перечень всех доступных табличных пространств и их соответствующих путей. Если указан tablespace_pattern, выводятся только табличные пространства, имена которых соответствуют указанному шаблону. Если к имени команды добавлен +, для каждого объекта дополнительно выводятся связанные разрешения. |
| \dc[S+] [conversion_pattern] | Выводит перечень преобразований между кодировками наборов символов. Если указан conversion_pattern, выводятся только преобразования, имена которых соответствуют указанному шаблону. По умолчанию выводятся только объекты, созданные пользователем; для включения системных объектов необходимо задать шаблон или добавить модификатор S. Если к имени команды добавлен +, для каждого объекта дополнительно выводятся соответствующие описания. |
| \dC[+] [pattern] | Выводит перечень приведений типов. Если указан pattern, выводятся только те приведения, исходный или целевой типы которых соответствуют указанному шаблону. Если к имени команды добавлен +, для каждого объекта дополнительно выводятся соответствующие описания. |
| \dd[S] [pattern] |
Выводит описания объектов следующих типов: constraint, operator class, operator family, rule и trigger. Описания остальных объектов можно посмотреть соответствующими командами с обратной косой чертой для этих типов объектов. \dd выводит описания объектов, соответствующих pattern, или доступных объектов указанных типов, если аргумент не задан. Но в любом случае выводятся только объекты, имеющие описание. По умолчанию отображаются только объекты, созданные пользователем; для включения системных объектов необходимо задать шаблон или добавить модификатор S. Описания объектов могут быть созданы с помощью SQL-команды COMMENT. |
| \ddp [pattern] |
Выводит перечень прав доступа по умолчанию. Выводится запись для каждой роли (и схемы, если применимо), для которой настройки привилегий по умолчанию были изменены по сравнению со встроенными значениями по умолчанию. Если указан pattern, выводятся только записи, имя роли или имя схемы которых соответствует указанному шаблону. Команда ALTER DEFAULT PRIVILEGES используется для установки прав доступа по умолчанию. |
| \dD[S+] [domain_pattern] | Выводит перечень доменов. Если указан domain_pattern, выводятся только домены, имена которых соответствуют указанному шаблону. По умолчанию отображаются только объекты, созданные пользователем; для включения системных объектов необходимо задать шаблон или добавить модификатор S. Если к имени команды добавлен +, каждый объект выводится с соответствующими разрешениями и описанием. |
| \dEistPv[S+] [external_table | index | sequence | table | parent table | view] | Имя данной команды не настоящее: буквы E, i, s, t, P и v обозначают соответственно внешнюю таблицу, индекс, последовательность, таблицу, родительскую таблицу и представление. Вы можете указать любую букву или все эти буквы в любом порядке, чтобы получить список объектов этих типов. Например, \dit выведет перечень индексов и таблиц. Если к имени команды добавляется +, каждый объект выводится с указанием его физического размера на диске и соответствующего описания, если таковое имеется. Если указан шаблон, выводятся только объекты, имена которых соответствуют этому шаблону. По умолчанию отображаются только объекты, созданные пользователем; для включения системных объектов необходимо задать шаблон или добавить модификатор S. |
| \des[+] [foreign_server_pattern] | Выводит перечень сторонних серверов. Если указан foreign_server_pattern, выводятся только те серверы, имя которых соответствует этому шаблону. Если используется форма \des+, отображается полное описание каждого сервера, включая ACL сервера, тип, версию, параметры и описание. |
| \det[+] [foreign_table_pattern] | Выводит перечень всех сторонних таблиц. Если указан foreign_table_pattern, выводятся только записи, имя таблицы или имя схемы которых соответствуют этому шаблону. Если используется форма \det+, также выводятся общие параметры и описание сторонней таблицы. |
| \deu[+] [user_mapping_pattern] |
Выводит перечень сопоставлений пользователей. Если указан user_mapping_pattern, выводятся только те сопоставления, имена пользователей которых соответствуют указанному шаблону. Если используется форма \deu+, дополнительно выводится информация о каждом сопоставлении. Предупреждение. \deu+ может также отображать имя пользователя и пароль удалённого пользователя, поэтому следует проявлять осторожность, чтобы не разглашать их. |
| \dew[+] [foreign_data_wrapper_pattern] | Выводит перечень оболочек сторонних данных. Если указан foreign_data_wrapper_pattern, выводятся только те оболочки сторонних данных, имя которых соответствует указанному шаблону. Если используется форма \dew+, дополнительно выводятся ACL, параметры и описание оболочки сторонних данных. |
| \df[antwS+] [function_pattern] | Выводит перечень функций с типами данных их результатов, аргументов и классификацией: agg (агрегат), normal, trigger или window. Чтобы отображать только функции определённого типа(ов), добавьте в команду соответствующие буквы a, n, t или w. Если указан function_pattern, выводятся только функции, имена которых соответствуют этому шаблону. Если используется форма \df+, дополнительно выводится информация о каждой функции, включая изменчивость, классификация по безопасности, язык, исходный код и описание. По умолчанию выводятся только объекты, созданные пользователем; для включения системных объектов необходимо задать шаблон или добавить модификатор S. |
| \dF[+] [pattern] | Выводит перечень конфигураций текстового поиска. Если указан pattern, выводятся только конфигурации, имена которых соответствуют этому шаблону. Если используется форма \dF+, выводится полное описание каждой конфигурации, включая базовый синтаксический анализатор текстового поиска и список словарей для каждого типа фрагмента синтаксического анализатора. |
| \dFd[+] [pattern] | Выводит перечень словарей текстового поиска. Если указан pattern, выводятся только словари, имена которых соответствуют этому шаблону. Если используется форма \dFd+, дополнительно выводится информация о каждом выбранном словаре, включая базовый шаблон текстового поиска и значения параметров. |
| \dFp[+] [pattern] | Выводит перечень парсеров текстового поиска. Если указан pattern, выводятся только синтаксические анализаторы, имена которых соответствуют этому шаблону. Если используется форма \dFp+, выводится полное описание каждого синтаксического анализатора, включая основные функции и список распознанных типов фрагментов. |
| \dFt[+] [pattern] | Выводит перечень шаблонов текстового поиска. Если указан pattern, выводятся только шаблоны, имена которых соответствуют этому шаблону. Если используется форма \dFt+, дополнительно выводится информация о каждом шаблоне, включая имена основных функций. |
| \dg[+] [role_pattern] | Выводит перечень ролей базы данных. (Поскольку понятия «пользователи» и «группы» были объединены в «роли», эта команда теперь эквивалентна \du.) Если указан role_pattern, выводятся только те роли, имена которых соответствуют этому шаблону. Если используется форма \dg+, дополнительно выводится информация о каждой роли; в настоящее время это комментарий для каждой роли. |
| \dl |
Это алиас для \lo_list, который выводит перечень больших объектов. Примечание. RT.Warehouse не поддерживает функцию больших объектов PostgreSQL для потоковой передачи пользовательских данных, которые хранятся в структурах больших объектов. |
| \dL[S+] [pattern] | Выводит перечень процедурных языков. Если указан pattern, выводятся только языки, имена которых соответствуют этому шаблону. По умолчанию выводятся только языки, созданные пользователем; для включения системных объектов необходимо добавить модификатор S. Если к имени команды добавляется +, каждый язык выводится с указанием его обработчика вызовов, валидатора, прав доступа и информации о том, является ли он системным объектом. |
| \dn[S+] [schema_pattern] | Выводит перечень всех доступных схем (пространств имен). Если указан schema_pattern, выводятся только схемы, имена которых соответствуют этому шаблону. По умолчанию выводятся только объекты, созданные пользователем; для включения системных объектов необходимо указать шаблон или добавить модификатор S. Если к имени команды добавлен +, каждый объект выводится с соответствующими разрешениями и описанием, если таковое имеется. |
| \do[S] [operator_pattern] | Выводит перечень доступных операторов с их операндами и типами возвращаемых значений. Если указан operator_pattern, выводятся только операторы, имена которых соответствуют этому шаблону. По умолчанию выводятся только объекты, созданные пользователем; для включения системных объектов необходимо указать шаблон или добавить модификатор S. |
| \dO[S+] [pattern] | Выводит перечень правил сортировки. Если указан pattern, выводятся только правила, имена которых соответствуют шаблону. По умолчанию выводятся только объекты, созданные пользователем; для включения системных объектов необходимо указать шаблон или добавить модификатор S. Если к имени команды добавлен +, каждое правило сортировки выводится с соответствующим описанием, если таковое имеется. Обратите внимание, что выводятся только правила, которые можно использовать с кодировкой текущей базы данных, поэтому результаты могут отличаться в разных базах данных одной и той же установки. |
| \dp [relation_pattern_to_show_privileges] | Выводит перечень таблиц, представлений и последовательностей с соответствующими правами доступа. Если указан relation_pattern_to_show_privileges, выводятся только таблицы, представления и последовательности, имена которых соответствуют этому шаблону. Команды GRANT и REVOKE используются для установки прав доступа. |
| \drds [role-pattern [database-pattern]] |
Выводит перечень специфических параметров конфигурации. Данные параметры могут быть специфическими для роли, специфическими для базы данных, или обеих. role-pattern и database-pattern используются для выбора конкретных ролей и баз данных для вывода в перечень соответственно. Если шаблон не указан или указано *, все параметры конфигурации, в том числе не относящиеся к ролям или базам данных. Команды ALTER ROLE и ALTER DATABASE используются для определения параметров конфигурации, специфических для роли или базы данных. |
| \dT[S+] [datatype_pattern] | Выводит перечень типов данных. Если указан datatype_pattern, выводятся только типы, имена которых соответствуют этому шаблону. Если к имени команды добавлен +, каждый тип выводится с его внутренним именем и размером, его допустимыми значениями, если это тип enum, и соответствующими правами доступа. По умолчанию выводятся только объекты, созданные пользователем; для включения системных объектов необходимо указать шаблон или добавить модификатор S. |
| \du[+] [role_pattern] | Выводит перечень ролей базы данных. (Поскольку понятия «пользователи» и «группы» были объединены в «роли», эта команда теперь эквивалентна \dg.) Если указан role_pattern, выводятся только те роли, имена которых соответствуют этому шаблону. Если используется форма \du+, дополнительно выводится информация о каждой роли; в настоящее время это комментарий для каждой роли. |
| \dx[+] [extension_pattern] | Выводит перечень установленных расширений. Если указан extension_pattern, выводятся только те расширения, имена которых соответствуют этому шаблону. Если используется форма \dx+, выводятся все объекты, принадлежащие каждому соответствующему расширению. |
| \dy[+] [pattern] |
Выводит перечень триггеров событий. Если указан pattern, выводятся только те триггеры, имена которых соответствуют шаблону. Если к имени команды добавлен +, каждый объект выводится вместе с соответствующим описанием. Примечание. База данных RT.Warehouse не поддерживает пользовательские триггеры. |
| \e | \edit [filename] [line_number] |
Если указано filename, файл редактируется; после выхода из редактора его содержимое копируется обратно в буфер текущего запроса. Если filename не указано, буфер текущего запроса копируется во временный файл, который затем редактируется таким же образом. Новое содержимое буфера запроса повторно анализируется в соответствии с обычными правилами psql, т.е. весь буфер обрабатывается как одна строка. (Т.е. вы не можете выполнять скрипты таким образом. Используйте для этого \i.) Это также означает, что если запрос заканчивается или содержит точку с запятой, он немедленно выполняется. В других случаях он просто будет ждать в буфере запроса; введите точку с запятой или \g, чтобы передать его, или \r, чтобы отменить. Если указан номер строки, psql поместит курсор на указанную строку файла или буфера запроса. Обратите внимание: если задан единственный аргумент, состоящий из цифр, psql предполагает, что это номер строки, а не имя файла. См. Переменные окружения для получения информации о настройке и настройке вашего редактора. |
| \echo text [ ... ] |
Выводит аргументы в стандартный вывод, разделённые одним пробелом и с добавленным в конце переводом строки. Это может быть полезно для вывода скриптов. Если первым аргументом является -n без кавычек, то перевод строки в конце не ставится. Примечание. Если вы используете команду \o для перенаправления вывода запроса, вы можете использовать \qecho вместо этой команды. |
| \ef [function_description [line_number]] |
Эта команда извлекает из базы определение заданной функции в форме команды CREATE OR REPLACE FUNCTION и открывает его на редактирование. Редактирование осуществляется таким же образом, как и при выполнении \edit. После выхода из редактора изменённая команда остаётся в буфере запроса; введите точку с запятой или \g, чтобы отправить её серверу, либо \r, чтобы отменить. Для функции может быть задано только имя или имя и аргументы, например foo(integer, text). Типы аргументов необходимы, если существует более чем одна функция с тем же именем. Если функция не указана, для редактирования предоставляется пустой шаблон CREATE FUNCTION. Если указан номер строки, psql поместит курсор в указанную строку тела функции. (Обратите внимание, что тело функции обычно не начинается с первой строки файла.) См. Переменные окружения для получения информации о настройке и настройке вашего редактора. |
| \encoding [encoding] | Устанавливает кодировку набора символов клиента. Без аргумента эта команда показывает текущую кодировку. |
| \f [field_separator_string] | Устанавливает разделитель полей для невыровненного вывода запроса. По умолчанию используется вертикальная черта (|). См. также \pset для общего способа установки параметров вывода. |
|
\g [filename] \g [ | command ] |
Отправляет содержимое буфера текущего запроса на сервер и, при необходимости, сохраняет выходные данные запроса в filename или направляет выходные данные в command. Файл или команда записываются только в том случае, если запрос успешно возвращает 0 или более строк, а не в случае сбоя запроса или SQL-команды, не возвращающей данные. \g без аргумента по сути эквивалентен точке с запятой. \g с аргументом — это одноразовая альтернатива команде \o. |
| \gset [prefix] |
Отправляет буфер текущего запроса на сервер для выполнения и сохраняет результат запроса в переменных psql. Выполняемый запрос должен возвращать ровно одну строку. Каждый столбец строки сохраняется в отдельной переменной, названной так же, как столбец. Например: Если результат столбца NULL, то вместо присвоения значения соответствующая переменная удаляется. Если запрос завершается ошибкой или не возвращает одну строку, то никакие переменные не меняются. |
| \h | \help [sql_command] | Выводит справку по синтаксису указанной sql_command. Если команда не указана, psql выведет список всех команд, для которых доступна справка по синтаксису. Если в качестве команды указана звёздочка (*), то отображается справка по синтаксису для всех SQL-команд. Для упрощения ввода команды, состоящей из нескольких слов, можно не заключать её в кавычки. |
| \H | \html | Включает вывод запросов в формате HTML. Если формат HTML уже включён, происходит переключение обратно на выровненный формат. Эта команда предназначена для совместимости и удобства, но о настройке других параметров вывода см. \pset. |
| \i | \include filename |
Читает ввод из файла filename и выполняет его, как если бы он был набран на клавиатуре. Если имя filename задано как - (дефис), то стандартный ввод читается до индикации EOF или метакоманды \q. Это можно использовать, чтобы совмещать интерактивный ввод с вводом из файлов. Обратите внимание, что поведение Readline будет использоваться, только если оно активно на самом внешнем уровне. Если вы хотите видеть строки на экране по мере их чтения, вы должны установить для переменной ECHO значение all. |
| \ir | \include_relative filename | Команда \ir похожа на \i, но по-разному интерпретирует относительные имена файлов. При выполнении в интерактивном режиме обе команды ведут себя идентично. Однако при вызове из скрипта \ir интерпретирует имена файлов относительно каталога, в котором расположен скрипт, а не текущего рабочего каталога. |
| \l[+] | \list[+] [pattern] | Выводит перечень баз данных на сервере и показывает их имена, владельцев, кодировки набора символов и права доступа. Если указан pattern, выводятся только базы данных, имена которых соответствуют этому шаблону. Если к имени команды добавлен +, также отображаются размеры базы данных, табличные пространства по умолчанию и описания. (Информация о размере доступна только для баз данных, к которым может подключиться текущий пользователь.) |
| \lo_export loid filename |
Читает большой объект с указанным OID loid из базы данных и записывает его в filename. Обратите внимание, что это немного отличается от серверной функции lo_export, которая действует с правами пользователя, от имени которого работает сервер базы данных, и в файловой системе сервера. Используйте \lo_list, чтобы узнать OID большого объекта. Примечание. RT.Warehouse не поддерживает функцию больших объектов PostgreSQL для потоковой передачи пользовательских данных, которые хранятся в структурах больших объектов. |
| \lo_import large_object_filename [comment] |
Сохраняет файл в большом объекте. При желании он связывает данный комментарий с объектом. Пример: Ответ указывает, что большой объект получил идентификатор объекта (OID) 152801, который может быть использован для доступа к вновь созданному объекту в будущем. По этой причине рекомендуется всегда связывать понятный комментарий с каждым объектом. Затем их можно увидеть с помощью команды \lo_list. Обратите внимание, что эта команда немного отличается от команды lo_import на стороне сервера, поскольку она действует как локальный пользователь в локальной файловой системе, а не как пользователь сервера в файловой системе. Примечание. RT.Warehouse не поддерживает функцию больших объектов PostgreSQL для потоковой передачи пользовательских данных, которые хранятся в структурах больших объектов. |
| \lo_list |
Выводит перечень всех больших объектов, хранящихся в настоящее время в базе данных, вместе с любыми комментариями к ним. Примечание. RT.Warehouse не поддерживает функцию больших объектов PostgreSQL для потоковой передачи пользовательских данных, которые хранятся в структурах больших объектов. |
| \lo_unlink largeobject_oid |
Удаляет из базы данных большой объект указанного OID. Используйте \lo_list, чтобы узнать OID большого объекта. Примечание. RT.Warehouse не поддерживает функцию больших объектов PostgreSQL для потоковой передачи пользовательских данных, которые хранятся в структурах больших объектов. |
|
\o | \out [ filename ] \o | \out [ | command ] |
Сохраняет результаты запроса в файл filename или передаёт результаты команде оболочки command. Если аргумент не указан, вывод запроса перенаправляется на стандартный вывод. Результаты запроса включают все таблицы, ответы на команды и уведомления, полученные от сервера базы данных, а также вывод различных команд с обратной косой чертой, которые обращаются к базе данных (например, \d), но не сообщения об ошибках. Чтобы совмещать вывод текста между результатами запроса, используйте \qecho. |
| \p | Печатает содержимое буфера текущего запроса в стандартный вывод. |
| \password [username] | Изменяет пароль указанного пользователя (по умолчанию текущего пользователя). Эта команда запрашивает новый пароль, шифрует его и отправляет на сервер как команду ALTER ROLE. Это гарантирует, что новый пароль не появится в открытом виде в истории команд, журнале сервера или где-либо ещё. |
| \prompt [ text ] name |
Предлагает пользователю ввести значение, которое назначается переменной name. Можно указать текст подсказки text. (Для подсказок, состоящих из нескольких слов, заключите текст в одинарные кавычки.) По умолчанию \prompt использует терминал для ввода и вывода. Однако, если используется параметр командной строки -f, \prompt использует стандартный ввод и стандартный вывод. |
| \pset [print_option [value]] |
Эта команда устанавливает параметры, влияющие на вывод таблиц результатов запроса. print_option описывает, какой параметр должен быть установлен. Семантика value варьируется в зависимости от выбранного параметра. Для некоторых параметров пропуск value приводит к тому, что значение параметра будет переключено или сброшено, как описано в разделе о конкретном параметре. Если такое поведение не упоминается, то пропуск value просто приводит к отображению текущего значения параметра. \pset без аргументов отображает текущее состояние всех параметров команды. Настраиваемые параметры:
После установки целевой ширины используйте команду \pset format wrapped, чтобы включить формат wrapped.
Когда значение border больше нуля, параметр linestyle также определяет символы, которыми будут рисоваться границы. Обычные символы ASCII работают везде, но символы Юникода смотрятся лучше на терминалах, распознающих их.
Для \pset есть различные команды быстрого доступа. См. \a, \C, \f, \H, \t, \T и \x. |
| \q | \quit | Выход из psql. При использовании в скрипте прекращается только выполнение этого скрипта. |
| \qecho text [ ... ] | Эта команда идентична \echo, за исключением того, что вывод будет записан в канал вывода запроса, как установлено \o. |
| \r | \reset | Сбрасывает (очищает) буфер запроса. |
| \s [filename] | Записывает историю командной строки psql в filename. Если filename не указано, история записывается на стандартный вывод (с использованием постраничника, когда уместно). Эта команда недоступна, если psql был собран без поддержки Readline. |
| \set [name [value [ ... ]]] |
Устанавливает переменной psql name указанное значение value или, если указано более одного значения, объединению их всех. Если указан только один аргумент, значением переменной становится пустая строка. Для сброса переменной используйте команду \unset. \set без аргументов выводит имена и значения всех текущих переменных psql. Имена переменных могут содержать буквы, цифры и знаки подчёркивания. Подробнее см. Переменные. Имена переменных чувствительны к регистру. Хотя вы можете установить любую переменную, какую захотите, psql рассматривает несколько переменных как особые. Они задокументированы в теме о переменных. Эта команда не связана с SQL-командой SET. |
| \setenv name [ value ] |
Задаёт для имени name переменной среды значение value или, если value не указано, удаляет переменную среды. Пример:
|
| \sf[+] function_description |
Эта команда извлекает из базы и выводит определение заданной функции в форме команды CREATE OR REPLACE FUNCTION. Определение выводится в текущий канал вывода запроса, как установлено \o. Для функции может быть задано только имя или имя и аргументы, например foo(integer, text). Типы аргументов необходимы, если существует более чем одна функция с тем же именем. Если к имени команды добавляется +, то выходные строки нумеруются, причём первой строкой тела функции является строка 1. |
| \t [novalue | on | off] | Включает/выключает отображение имён столбцов и результирующей строки с количеством выбранных записей для запросов. Значения on и off устанавливают отображение кортежей независимо от текущего значения. Эта команда эквивалентна \pset tuples_only и предоставляется для удобства. |
| \T table_options | Задаёт атрибуты, которые будут помещены в тег table в формате вывода HTML. Эта команда эквивалентна \pset tableattr table_options. |
| \timing [novalue | on | off] | Без параметра переключает отображение выполнения каждого оператора SQL в миллисекундах на противоположное. Значения on и off устанавливают отображение времени независимо от текущей настройки. |
| \unset name | Сбрасывает (удаляет) name переменной psql. |
|
\w | \write filename \w | \write | command |
Выводит буфер текущего запроса в файл filename или передаёт его команде оболочки command. |
| \watch [seconds] | Многократно выполняет текущий запрос в буфере (как \g), пока не будет прервана или не возникнет ошибка. Аргумент seconds задаёт количество секунд ожидания между выполнениями запроса (по умолчанию — 2). |
| \x [ on | off | auto ] | Устанавливает или переключает режим развёрнутого вывода таблицы. Это эквивалентно \pset expanded. |
| \z [pattern] |
Выводит перечень таблиц, представлений и последовательностей с их правами доступа. Если указан pattern, выводятся только таблицы, представления и последовательности, имена которых соответствуют ему. Это псевдоним для \dp. |
| \! [command] | Без аргументов запускает подчинённую оболочку; когда эта оболочка завершается, psql продолжает работу. Если добавлен аргумент, запускает команду оболочки command. Аргументы далее не интерпретируются; оболочка увидит их как есть. В частности, не применяются правила замены переменных и экранирование обратной косой черты. |
| \? | Показывает справочную информацию о командах psql с обратной косой чертой. |
Различные команды \d принимают параметр шаблона, чтобы указать имя (имена) объекта для отображения. В простейшем случае шаблон — это просто точное имя объекта. Символы в шаблоне обычно переводятся в нижний регистр, как и в именах SQL-объектов; например, \dt FOO выведет таблицу с именем foo. Как и в именах SQL, размещение шаблона в двойных кавычках предотвратить перевод в нижний регистр. Для включения символа двойной кавычки в шаблон используются два символа двойных кавычек подряд внутри шаблона в двойных кавычках. Опять же, это соответствует правилам для SQL-идентификаторов. Например, \dt "FOO""BAR" отобразит таблицу с именем FOO"BAR (не foo"bar). В отличие от обычных правил для SQL-имён, вы можете заключить в двойные кавычки только часть шаблона, например, \dt FOO"FOO"BAR выведет таблицу с именем fooFOObar.
Если в шаблоне указано *, это соответствует любой последовательности символов (включая отсутствие символов), а указание ? в качестве шаблона соответствует любому одному символу. (Эта нотация сопоставима с шаблонами имён файлов оболочки UNIX.) Например, \dt int* выводит все таблицы, имена которых начинаются с int. Но в двойных кавычках * и ? теряют своё специальное значение и становятся обычными символами.
Шаблон, содержащий точку (.), интерпретируется как шаблон имени схемы, за которым следует шаблон имени объекта. Например, \dt foo*.bar* отображает все таблицы, имена которых включают bar, и расположенные в схемах, имена которых начинаются с foo. Шаблону, не содержащему точку, могут соответствовать только объекты текущей схемы. Опять же, точка внутри двойных кавычек теряет своё специальное значение.
Опытные пользователи могут использовать нотации регулярных выражений. Все специальные символы регулярных выражений работают, как указано в документации PostgreSQL по регулярным выражениям, за исключением: ., которая используется как разделитель, как упоминалось выше; * , которая переводится в нотацию регулярных выражений; * и ? соответствуют .. Вы можете при необходимости эмулировать эти символы шаблона, указав ? для эмуляции ., (R+|) для эмуляции R* или (R|) для эмуляции R?. Помните, что шаблон должен совпадать с именем целиком, в отличие от обычной интерпретации регулярных выражений. Укажите * в начале и/или в конце, если вы не хотите, чтобы шаблон был привязан. Обратите внимание, что внутри двойных кавычек, все специальные символы регулярных выражений теряют своё специальное значение и соответствуют сами себе. Также, специальные символы регулярных выражений не действуют в шаблонах для имён операторов (т. е. в аргументе команды \do).
Всякий раз, когда параметр шаблона полностью опущен, команды \d отображают все объекты, которые видны в текущем пути поиска схемы — это эквивалентно использованию в качестве шаблона *. Чтобы увидеть все объекты в базе данных, независимо от видимости, используйте в качестве шаблона *.*.
psql предоставляет возможности подстановки переменных подобные тем, что используются в командных оболочках Unix. Переменные представляют собой пары имя/значение, где значением может быть любая строка любой длины. Имя должно состоять из букв (включая нелатинские буквы), цифр и знаков подчёркивания.
Чтобы установить переменную, используйте метакоманду psql \set. Например:
testdb=> \set foo barПрисваивает переменной foo значение bar. Чтобы получить значение переменной, нужно поставить двоеточие перед её именем, например:
testdb=> \echo :foo
barЭто работает как в обычных SQL-командах, так и в метакомандах; подробнее в Интерполяция SQL.
Если вы вызываете \set без второго аргумента, переменная устанавливается с пустой строкой в качестве значения. Чтобы сбросить (т.е. удалить) переменную, используйте команду \unset. Чтобы показать значения всех переменных, вызовите \set без аргументов.
|
Примечание. Аргументы \set подчиняются тем же правилам замены, что и другие команды. Таким образом, вы можете создавать интересные ссылки, такие как \set :foo 'something', и получать 'мягкие ссылки' в Perl или 'переменные переменные' в PHP. К сожалению, с этими конструкциями ничего полезного сделать нельзя. С другой стороны, \set bar :foo — вполне допустимый способ скопировать переменную. |
Некоторые из этих переменных обрабатываются psql особым образом. Они представляют собой определённые настройки параметров, которые можно изменить во время выполнения, изменяя значение переменной, или в некоторых случаях представляют изменяемое состояние psql. Хотя вы можете использовать эти переменные для других целей, это не рекомендуется, поскольку поведение программы может очень быстро стать очень странным. По соглашению, имена всех специально обработанных переменных состоят из заглавных букв ASCII (и, возможно, цифр и знаков подчёркивания). Чтобы обеспечить максимальную совместимость в будущем, избегайте использования таких имён переменных в своих целях. Список всех специальных переменных следует ниже.
Таблица 99— Переменные
|
Переменная |
Описание |
|---|---|
| AUTOCOMMIT |
При значении on (по умолчанию) после каждой успешно выполненной команды выполняется фиксация изменений. Чтобы отложить фиксацию изменений в этом режиме, нужно выполнить SQL-команду BEGIN или START TRANSACTION. При значении off или если переменная не определена, фиксация изменений не происходит до тех пор, пока явно не выполнена команда COMMIT или END. При значении off неявно выполняется BEGIN непосредственно перед любой командой, за исключением случаев когда: команда уже в транзакционном блоке; перед самой командой BEGIN или другой командой управления транзакциями; перед командой, которая не может выполняться внутри транзакционного блока (например, VACUUM). Если режим autocommit отключён, необходимо явно откатывать изменения в неуспешных транзакциях, выполняя команду ABORT или ROLLBACK. Также имейте в виду, что при выходе из сессии без фиксации изменений несохранённые изменения будут потеряны. Включённый режим autocommit является традиционным для PostgreSQL, а выключенный режим ближе к спецификации SQL. Если вы предпочитаете отключить режим autocommit, это можно сделать в общесистемном файле psqlrc или в персональном файле ~/.psqlrc. |
| COMP_KEYWORD_CASE | Определяет, какой регистр букв будет использован при автоматическом завершении ключевых слов SQL. Если установлено lower или upper, будет использоваться нижний или верхний регистр соответственно. Если установлено preserve-lower или preserve-upper (по умолчанию), то завершаемое слово будет в том же регистре, что и уже введённое начало слова, но последующие слова, завершаемые полностью, будут в нижнем или верхнем регистре соответственно. |
| DBNAME | Имя базы данных, к которой вы в данный момент подключены. Он устанавливается каждый раз, когда вы подключаетесь к базе данных (включая запуск программы), но эту переменную можно изменить или сбросить. |
| ECHO | Если установлено значение all, все непустые строки ввода выводятся на стандартный вывод по мере чтения. (Это не относится к строкам, читаемым в интерактивном режиме.) Чтобы выбрать это поведение при запуске программы, используйте ключ -a. Со значением queries psql выдаёт каждый запрос, отправляемый серверу, в стандартный вывод. Этому значению соответствует ключ -e. |
| ECHO_HIDDEN | Когда для этой переменной установлено значение on и метакоманда запрашивает базу данных, сначала выводится текст нижележащего запроса. Эта функция поможет вам изучить внутреннее устройство RT.Warehouse и реализовывать похожую функциональность в своих программах. (Чтобы выбрать это поведение при запуске программы, используйте ключ -E.) Если вы установите для переменной значение noexec, запросы просто отображаются, но фактически не отправляются на сервер и не выполняются. |
| ENCODING | Текущая кодировка набора символов на стороне клиента. |
| FETCH_COUNT |
Если для этой переменной задано целочисленное значение больше нуля, результаты запросов SELECT извлекаются и отображаются группами с заданным количеством строк, в отличие от поведения по умолчанию, когда перед отображением результирующий набор накапливается целиком. Это позволяет использовать ограниченный размер памяти независимо от размера выборки. При включении этой функциональности обычно используются значения от 100 до 1000. Имейте в виду, что запрос может завершиться ошибкой после отображения некоторого количества строк. Хотя можно использовать любой формат вывода, формат по умолчанию aligned как правило выглядит хуже, потому что каждая группа по FETCH_COUNT строк форматируется отдельно, что может привести к разной ширине столбцов в разных группах. Остальные форматы вывода работают лучше. |
| HISTCONTROL | Если переменная имеет значение ignorespace, строки, начинающиеся с пробела, не сохраняются в истории. Если она имеет значение ignoredups, в историю не добавляются строки, которые в ней уже есть. Значение ignoreboth объединяет эти два варианта. Со значением none (по умолчанию) в истории сохраняются все строки, считываемые в интерактивном режиме. |
| HISTFILE |
Имя файла, который будет использоваться для хранения списка истории команд. Значение по умолчанию — ~/psql_history. Например, установив: в ~/.psqlrc, psql будет вести отдельный файл истории для каждой базы данных. |
| HISTSIZE | Максимальное количество команд, сохраняемых в истории команд. Значение по умолчанию — 500. |
| HOST | Хост сервера базы данных, к которому вы в настоящее время подключены. Он устанавливается каждый раз, когда вы подключаетесь к базе данных (включая запуск программы), но эту переменную можно изменить или сбросить. |
| IGNOREEOF | Если значение не установлено, отправка символа конца файла EOF (обычно CTRL + D) в интерактивном сеансе psql завершит работу приложения. Если установлено числовое значение, такое количество символов EOF игнорируется до завершения работы приложения. Если переменная установлена, но не имеет числового значения, значение по умолчанию — 10. |
| LASTOID | Содержит значение последнего OID, полученного командой INSERT или \lo_import. Корректное значение переменной гарантируется до тех пор, пока не будет отображён результат следующей SQL-команды. |
| ON_ERROR_ROLLBACK | При значении on, если команда в блоке транзакции выдаёт ошибку, ошибка игнорируется и транзакция продолжается. Со значением interactive такие ошибки игнорируются только в интерактивных сеансах, но не в скриптах. Со значением off (по умолчанию) команда в блоке транзакции, выдающая ошибку, прерывает всю транзакцию. Для реализации режима отката транзакции за вас неявно выполняется команда SAVEPOINT непосредственно перед каждой командой в блоке транзакции, а в случае ошибки команды происходит откат к этой точке сохранения. |
| ON_ERROR_STOP | По умолчанию, после возникновения ошибки обработка команд продолжается. Если эта переменная установлена в значение on, обработка команд будет немедленно прекращена. В интерактивном режиме psql вернётся в командную строку; иначе psql прекратит работу с кодом возврата 3, чтобы отличить этот случай от фатальных ошибок, для которых используется код возврата 1. В любом случае выполнение всех запущенных скриптов (высокоуровневый скрипт и любые другие, которые он мог запустить) будет немедленно прекращено. Если высокоуровневая командная строка содержит несколько SQL-команд, выполнение завершится на текущей команде. |
| PORT | Порт сервера базы данных, к которому вы в данный момент подключены. Он устанавливается каждый раз, когда вы подключаетесь к базе данных (включая запуск программы), но эту переменную можно изменить или сбросить. |
|
PROMPT1 PROMPT2 PROMPT3 |
Они определяют, как должны выглядеть запросы psql. См. Подсказки. |
| QUIET | Установка значения on эквивалента параметру командной строки -q. Это, вероятно, не слишком полезно в интерактивном режиме. |
| SINGLELINE | Установка значения on эквивалентна параметру командной строки -S. |
| SINGLESTEP | Установка значения on эквивалентна параметру командной строки -s. |
| USER | Пользователь базы данных, с которым вы в настоящее время подключены к базе данных. Он устанавливается каждый раз, когда вы подключаетесь к базе данных (включая запуск программы), но эту переменную можно изменить или сбросить. |
| VERBOSITY | Этой переменной можно присвоить значения default, verbose, terse или sqlstate для изменения уровня детализации в сообщениях об ошибках. |
Ключевой особенностью переменных psql является то, что вы можете заменять («интерполировать») их в обычные операторы SQL, а также в аргументы метакоманд. Кроме того, psql предоставляет средства для корректного использования кавычек для значений переменных, используемых в качестве литералов и идентификаторов SQL. Чтобы подставить значение без кавычек, нужно добавить перед именем переменной двоеточие (:). Например:
testdb=> \set foo 'my_table'
testdb=> SELECT * FROM :foo;запросит таблицу my_table. Обратите внимание, что это может быть небезопасно: значение переменной копируется буквально, поэтому оно может содержать непарные кавычки или даже метакоманды. Вы должны убедиться, что это имеет смысл.
Когда значение должно использоваться в качестве литерала или идентификатора SQL, безопаснее всего сделать так, чтобы оно было заключено в кавычки. Если значение переменной используется как SQL литерал, то после двоеточия нужно написать имя переменной в одинарных кавычках. Если значение переменной используется как SQL идентификатор, то после двоеточия нужно написать имя переменной в двойных кавычках. Эти конструкции корректно работают с кавычками и другими специальными символами, которые могут содержаться в значении переменной. Предыдущий пример безопаснее было бы написать так:
testdb=> \set foo 'my_table'
testdb=> SELECT * FROM :"foo";Интерполяция переменных не будет выполняться, если SQL литералы или идентификаторы заключены в кавычки. Поэтому конструкция ':foo' не превратится во взятое в кавычки значение переменной (и это было бы небезопасно, если бы работало, так как обработка кавычек внутри значения переменной была бы некорректной).
Одним из примеров использования этого механизма является копирование содержимого файла в столбец таблицы. Сначала загрузите файл в переменную, а затем интерполируйте значение переменной как строку в кавычках:
testdb=> \set content `cat my_file.txt`
testdb=> INSERT INTO my_table VALUES (:'content');(Обратите внимание, что это всё равно не будет работать, если my_file.txt содержит байты NUL. psql не поддерживает встроенные байты NUL в значения переменных.)
Так как двоеточие может легально присутствовать в SQL-командах, попытка интерполяции (например для :name, :'name' или :"name") не выполняется, если переменная не установлена. В любом случае можно экранировать двоеточие с помощью обратной косой черты, чтобы предотвратить подстановку.
Использование двоеточия для переменных является стандартом SQL для встраиваемых языков запросов, таких как ECPG. Использование двоеточия для срезов массивов и приведения типов является расширениями PostgreSQL, что иногда может конфликтовать со стандартным использованием. Использование двоеточия и кавычек для экранирования значения переменной при подстановке в качестве SQL литерала или идентификатора — это расширение psql.
Вы можете настроить подсказки psql по своему усмотрению. Три переменные PROMPT1, PROMPT2 и PROMPT3 содержат строки и специальные escape-последовательности, которые задают внешний вид подсказок. PROMPT1 — это обычная подсказка, которое выдаётся, когда psql ожидает ввода новой команды. PROMPT2 выдаётся, когда во время ввода команды ожидается дополнительный ввод, например, потому что команда не была завершена точкой с запятой или не были закрыты кавычки. PROMPT3 выдаётся, когда вы запускаете SQL-команду COPY FROM STDIN и вам нужно ввести значение новой строки в терминале.
Значения этих переменных выводятся буквально, за исключением случаев, когда в них встречается знак процента (%). В зависимости от следующего символа будет подставляться определённый текст. Существуют следующие подстановки:
Таблица 100— Подстановки
|
Подстановка |
Описание |
|---|---|
| %M | Полное имя хоста (с доменным именем) сервера базы данных или [local], если соединение осуществляется через сокет домена UNIX, или [local:/dir/name], если при компиляции был изменён путь Unix-сокета по умолчанию. |
| %m | Имя хоста сервера базы данных, усечённое до первой точки, или [local], если соединение осуществляется через сокет домена UNIX. |
| %> | Номер порта, который прослушивает сервер базы данных. |
| %n | Имя пользователя базы данных для текущей сессии. (Это значение может меняться в течение сессии в результате выполнения команды SET SESSION AUTHORIZATION.) |
| %/ | Имя текущей базы данных. |
| %~ | Похоже на %/, но выводит тильду ~, если текущая база данных совпадает с базой данных по умолчанию. |
| %# | Если пользователь текущей сессии является суперпользователем базы данных, то выводит #, иначе >. (Это значение может меняться в течение сессии в результате выполнения команды SET SESSION AUTHORIZATION.) |
| %R | В подсказке 1 это обычно символ =, но @, если сеанс находится в неактивной ветви блока условия, либо ^ в однострочном режиме, либо !, если сеанс не подключён к базе данных (что возможно при ошибке \connect). В подсказке 2 %R заменяется символом, показывающим, почему psql ожидает дополнительный ввод: -, если команда просто ещё не была завершена, но *, если не завершён комментарий /* ... */; апостроф, если не завершена строка в апострофах; кавычки, если не завершён идентификатор в кавычках; знак доллара, если не завершена строка в долларах; либо (, если после открывающей скобки не хватает закрывающей. В подсказке 3 %R не выдаёт ничего. |
| %x | Статус транзакции: пустая строка, если не в транзакционном блоке; *, когда в транзакционном блоке; !, когда в транзакционном блоке, в котором произошла ошибка и ?, когда состояние транзакции не определено (например, нет подключения к базе данных). |
| %digits | Подставляется символ с указанным восьмеричным кодом. |
| %:name: | Значение имени (name) переменной psql. Подробнее см. Переменные. |
| %`command` | Подставляется вывод команды (command), как и в обычной подстановке с обратными апострофами. |
| %[ ... %] |
Подсказки могут содержать символы управления терминалом, которые, например, изменяют цвет, фон или стиль текста подсказки или меняют заголовок окна терминала. Чтобы редактирование строки работало правильно, эти непечатаемые управляющие символы должны быть обозначены как невидимые, заключив их в %[ and %]. В подсказке может появиться несколько таких пар. Например, приводит к появлению выделенного жирным шрифтом (1;) подсказки жёлтогй на черном (33;40) на терминалах, совместимых с VT100 и поддерживающих цвет. Чтобы вставить знак процента в подсказку, напишите %%. Подсказки по умолчанию: '%/%R%# ' для PROMPT1 и PROMPT2, '>> ' для PROMPT3. |
psql использует библиотеку readline для удобного редактирования командной строки. История команд автоматически сохраняется при выходе из psql и перезагружается при запуске psql. Также поддерживается завершение по табуляции, хотя логика завершения не претендует на роль анализатора SQL. Запросы, генерируемые с помощью клавиши Tab, также могут конфликтовать с другими командами SQL, например, SET TRANSACTION ISOLATION LEVEL. Если по какой-то причине вам не нравится завершение по табуляции, вы можете отключить его в файле .inputrc в своём домашнем каталоге:
$if psql
set disable-completion on
$endifТаблица 101— Переменные окружения
|
Параметр |
Описание |
|---|---|
| COLUMNS | Если \pset columns равно нулю, управляет шириной формата вывода wrapped, а также определяет, нужно ли использовать постраничник и нужно ли переключаться в вертикальный формат в режиме expanded auto. |
| PAGER | Если результат запроса не помещается на экране, он пропускается через эту программу. Обычно это more или less. От использования постраничника можно отказаться, присвоив переменной PSQL_PAGER или PAGER пустую строку, либо изменив соответствующие параметры с помощью команды \pset. |
| PGDATABASE | — |
| PGHOST | — |
| PGPORT | — |
| PGUSER | Параметры подключения по умолчанию. |
| PSQL_EDITOR | — |
| EDITOR | — |
| VISUAL | Редактор, используемый командами \e, \ef. Эти переменные рассматриваются в том же порядке; в силу вступает первое установленное значение. Если ни одна из переменных не установлена, по умолчанию в Unix-системах используется vi, а в Windows — notepad.exe. |
| PSQL_EDITOR_LINENUMBER_ARG |
Если в командах \e, \ef указан номер строки, эта переменная задаёт аргумент командной строки, с которым номер строки может быть передан в редактор. Например, для редакторов Emacs и vi это знак плюс. Добавьте в конец значения пробел, если он требуется для отделения имени аргумента от номера строки. Примеры: Значение по умолчанию + в Unix-подобных системах (соответствует редактору по умолчанию vi и многим другим распространённым редакторам). На платформе Windows нет значения по умолчанию. |
| PSQL_HISTORY | Альтернативное расположение файла истории команд. Допускается использование тильды (~). |
| PSQLRC | Альтернативное расположение файла .psqlrc пользователя. Допускается использование тильды (~). |
| SHELL | Команда операционной системы, выполняемая метакомандой \!. |
| TMPDIR | Каталог для хранения временных файлов. По умолчанию это /tmp. |
Файлы
Таблица 102— Файлы
|
Файл |
Описание |
|---|---|
| psqlrc и ~/.psqlrc |
Если не указан параметр -X или -c, psql пытается считать и выполнить команды из общесистемного файла запуска (psqlrc), а затем из персонального файла запуска пользователя (~/.psqlrc) после подключения к базе данных, но перед подключением обычных команд. Эти файлы можно использовать для настройки клиента и/или сервера, обычно с помощью команд \set и SET. Общесистемный файл запуска называется psqlrc и ищется в каталоге установки "system configuration", который наиболее надежно определяется путем выполнения pg_config --sysconfdir. По умолчанию этот каталог будет расположен ../etc/ относительно каталога, содержащего исполняемые файлы RT.Warehouse. Имя этого каталога можно задать явно с помощью переменной среды PGSYSCONFDIR. Персональный файл запуска пользователя называется .psqlrc и ищется в домашнем каталоге вызывающего пользователя. В Windows, в которой отсутствует такая концепция, персональный файл запуска называется %APPDATA%\postgresql\psqlrc.conf. Расположение персонального файла запуска пользователя можно указать явно с помощью переменной среды PSQLRC. Как общесистемный файл запуска, так и персональный файл запуска пользователя можно привязать к конкретной версии psql, добавив к имени файла дефис и основной или дополнительный номер релиза PostgreSQL, например ~/.psqlrc-9.4. При наличии нескольких файлов, файл с более детальным номером версии будет иметь предпочтение. |
| .psql_history |
История командной строки хранится в файле ~/.psql_history или %APPDATA%\postgresql\psql_history в Windows. Расположение файла истории можно указать явно через переменную среды PSQL_HISTORY. |
psql лучше всего работает с серверами той же или более старой основной версии. Метакоманды особенно часто не срабатывают, если сервер имеет более новую версию, чем сам psql. Однако метакоманды семейства \d должны работать со старыми версиями серверов, но не обязательно с серверами новее, чем сам psql. Общая функциональность запуска SQL-команд и отображения результатов запросов также должна работать на серверах с более новой основной версией, но это не гарантируется во всех случаях.
Если вы хотите использовать psql для подключения к нескольким серверам разных основных версий, рекомендуется использовать последнюю версию psql. Также можно собрать копии psql от каждой основной версии и использовать ту, которая соответствует версии сервера. Но на практике в этих дополнительных сложностях нет необходимости.
psql построен как консольное приложение. Поскольку в Windows консольные окна используют кодировку символов отличную от той, что используется для остальной системы, нужно проявить особую осторожность при использовании 8-битных символов. Если psql обнаружит проблемную кодовую страницу консоли, он предупредит вас при запуске. Чтобы изменить кодовую страницу консоли, необходимы две вещи:
Установите кодовую страницу, введя:
cmd.exe /c chcp 12521252 — это кодировка латинского алфавита, используемая Microsoft Windows для английского и некоторых других западных языков. Если вы используете Cygwin, вы можете поместить эту команду в /etc/profile.
Установите для консольного шрифта значение Lucida Console, поскольку растровый шрифт не работает с кодовой страницей ANSI.
Запустить psql в интерактивном режиме:
psql -p 54321 -U sally mydatabaseВ интерактивном режиме psql распределить команду по нескольким строкам ввода. Обратите внимание на изменение подсказки:
testdb=> CREATE TABLE my_table (
testdb(> first integer not null default 0,
testdb(> second text)
testdb-> ;
CREATE TABLEПосмотрите определение таблицы:
testdb=> \d my_table
Table "my_table"
Attribute | Type | Modifier
-----------+---------+--------------------
first | integer | not null default 0
second | text |Запустить psql в неинтерактивном режиме, передав файл, содержащий SQL-команды:
psql -f /home/gpadmin/test/myscript.sqlУправляет конфигурацией PXF и инстансом службы PXF на локальном хосте RT.Warehouse.
pxf <command> [<option>]Где <command> это:
cluster
help
init
reset
restart
start
status
stop
sync
versionУтилита pxf управляет конфигурацией PXF и инстансом службы PXF на локальном хосте RT.Warehouse.
Вы можете инициализировать или сбросить PXF на мастере, резервном мастере или определённом хосте сегмента. Вы также можете синхронизировать конфигурацию PXF от мастера к этим хостам.
Вы можете запустить, остановить или перезапустить инстанс службы PXF на определённом хосте сегмента или отобразить состояние инстанса службы PXF, запущенного на хосте сегмента.
(Используйте команду pxf cluster для инициализации или сброса PXF на всех хостах, синхронизации конфигурации PXF с кластером RT.Warehouse или для запуска, остановки или отображения состояния инстанса службы PXF на всех хостах сегмента в кластере.)
Таблица 103— Команды pxf
|
Команда |
Описание |
|---|---|
| cluster | Управление конфигурацией PXF и инстансом службы PXF на всех хостах RT.Warehouse. См. pxf cluster. |
| help | Отображение справочного сообщения утилиты управления pxf и дальнейшее завершение. |
| init | Инициализация инстанса службы PXF на хосте. Когда вы инициализируете PXF, вы должны идентифицировать каталог конфигурации пользователя PXF через переменную среды с именем $PXF_CONF. Если вы не установите $PXF_CONF перед инициализацией PXF, PXF предложит вам принять или отклонить каталог конфигурации пользователя по умолчанию, $HOME/pxf, во время процесса инициализации. См. Параметры. |
| reset | Сброс инстанса службы PXF, запущенный на хосте. Сброс удаляет файлы и каталоги среды выполнения PXF и возвращает PXF в неинициализированное состояние. Перед сбросом PXF на хосте необходимо остановить инстанс службы PXF, работающий на хосте сегмента. |
| restart | Перезапуск инстанса службы PXF, запущенного на хосте сегмента. |
| start | Запуск инстанса службы PXF на хосте сегмента. |
| status | Отображение состояния инстанса службы PXF, запущенного на хосте сегмента. |
| stop | Остановка инстанса службы PXF, работающего на хосте сегмента. |
| sync | Синхронизация конфигурации PXF от мастера к определённому резервному мастеру или хосту сегмента RT.Warehouse. Вы должны запустить pxf sync на хосте мастера. См. Параметры. |
| version | Отображение версии PXF и дальнейшее завершение. |
Команда pxf init принимает следующие параметры.
Таблица 104— Параметры pxf int
|
Параметр |
Описание |
|---|---|
| -y | Не запрашивать, использует расположение каталога по умолчанию $PXF_CONF, если переменная среды не установлена. |
Команда pxf reset принимает следующие параметры.
Таблица 105— Параметры pxf reset
|
Параметр |
Описание |
|---|---|
| -f | –force | Не запрашивать перед сбросом инстанса службы PXF; сбросить без вмешательства пользователя. |
Команда pxf sync, выполняемая на хосте мастера RT.Warehouse, принимает следующие параметры.
Таблица 106— Параметры pxf sync
|
Параметр |
Описание |
|---|---|
| <gphost> | Хост RT.Warehouse, с которым нужно синхронизировать конфигурацию PXF. <gphost> должен идентифицировать хост резервного мастера или хост сегмента. |
Запустить инстанс службы PXF на хосте локального сегмента:
$ $GPHOME/pxf/bin/pxf startУправляет конфигурацией PXF и инстансом службы PXF на всех хостах RT.Warehouse.
pxf cluster <command>Где <command> это:
help
init
reset
start
status
stop
syncКоманда утилиты pxf cluster управляет PXF на хостах мастера, резервного мастера и всех сегментов RT.Warehouse. Вы можете использовать эту утилиту для следующих действий:
Для pxf cluster требуется работающий кластер RT.Warehouse. Вы должны запустить эту утилиту на хосте мастера RT.Warehouse.
(Если вы хотите управлять инстансом службы PXF на определённом хосте сегмента, используйте утилиту pxf. См. pxf.)
Таблица 107— Команды pxf cluster
|
Команда |
Описание |
|---|---|
| help | Отображение справочного сообщения pxf cluster и дальнейшее завершение. |
| init | Инициализация инстанса службы PXF на мастере, резервном мастере и на всех хостах сегментов. При инициализации PXF в кластере RT.Warehouse необходимо определить каталог конфигурации пользователя PXF с помощью переменной среды с именем $PXF_CONF. Если вы не установите $PXF_CONF перед инициализацией PXF, PXF вернёт ошибку. |
| reset | Сброс инстанса службы PXF на мастере, резервном мастере и на всех хостах сегментов. Сброс удаляет файлы и каталоги среды выполнения PXF и возвращает PXF в неинициализированное состояние. Перед сбросом PXF в кластере RT.Warehouse необходимо остановить инстанс службы PXF, работающий на каждом хосте сегмента. |
| start | Запуск инстанса службы PXF на всех хостах сегментов. |
| status | Отображение состояния инстанса службы PXF на всех хостах сегментов. |
| stop | Остановка инстанса службы PXF на всех хостах сегментов. |
| sync | Синхронизация конфигурации PXF от мастера к резервному мастеру и ко всем хостам сегментов RT.Warehouse. Если вы обновили конфигурацию пользователя PXF или добавили файлы JAR, вы также должны перезапустить PXF после синхронизации конфигурации PXF. |
Остановить инстанс службы PXF на всех хостах сегментов:
$ $GPHOME/pxf/bin/pxf cluster stopПерестраивает индексы в базе данных.
reindexdb [connection-option ...] [--table | -t table ]
[--index | -i index ] [dbname]
reindexdb [connection-option ...] --all | -a
reindexdb [connection-option ...] --system | -s [dbname]
reindexdb -? | --help
reindexdb -V | --versionreindexdb — это утилита для восстановления индексов в RT.Warehouse.
reindexdb — это оболочка для SQL-команды REINDEX. Эффективной разницы между переиндексированием баз данных с помощью этой утилиты и других методов доступа к серверу нет.
Таблица 108— Параметры reindexdb
|
Параметр |
Описание |
|---|---|
| -a | --all | Переиндексация всех баз данных. |
| [-d] dbname | [--dbname=]dbname | Задаёт имя переиндексируемой базы данных. Если данный параметр не указан и -all не используется, имя базы данных считывается из переменной среды PGDATABASE. Если параметр не установлен, используется имя пользователя, указанное для соединения. |
| -e | --echo | Вызов команд, которые создаёт и отправляет на сервер reindexdb. |
| -i index | --index=index | Пересоздать только индекс. |
| -q | --quiet | Не отображать ответ. |
| -s | --system | Переиндексировать системные каталоги. |
| -t table | --table=table | Переидексировать только таблицу. Несколько таблиц можно переиндексировать, написав несколько ключей -t. |
| -V | --version | Вывод версии reindexdb и выход. |
| -? | --help | Вывод справки об аргументах командной строки reindexdb и выход. |
Таблица 109— Параметры подключения reindexdb
|
Параметр |
Описание |
|---|---|
| -h host | --host=host | Задаёт имя хоста машины, на которой работает мастер-сервер RT.Warehouse. Если параметр не указан, данные считываются из переменной среды PGHOST или по умолчанию используется localhost. |
| -p port | --port=port | Задаёт TCP-порт, на котором мастер-сервер RT.Warehouse прослушивает соединения. Если параметр не указан, данные считываются из переменной среды PGPORT или по умолчанию 5432. |
| -U username | --username=username | Имя роли базы данных для подключения. Если параметр не указан, данные считываются из переменной среды PGUSER или по умолчанию используется текущее имя пользователя системы. |
| -w | --no-password | Никогда не запрашивать пароль. Если сервер требует аутентификации по паролю, а пароль недоступен другими способами, такими как файл .pgpass, попытка подключения не удастся. Этот параметр может быть полезен в batch-заданиях и скриптах, где нет пользователя, который мог бы ввести пароль. |
| -W | --password | Принудительный ввод пароля. |
| --maintenance-db=dbname | Задает имя базы данных для подключения, чтобы определить, какие другие базы данных следует переиндексировать. Если параметр не указан, будет использоваться база данных postgres, а если она не существует, будет использоваться template1. |
reindexdb может потребоваться несколько раз подключиться к мастер-серверу, каждый раз запрашивая пароль. В таких случаях удобно иметь файл ~/.pgpass.
Переиндексировать базу данных mydb:
reindexdb mydbПереиндексировать таблицу foo и индекс bar в базе данных с именем abcd:
reindexdb --table foo --index bar abcdСборщик мусора и анализ базы данных.
vacuumdb [connection-option...] [--full | -f] [--freeze | -F] [--verbose | -v]
[--analyze | -z] [--analyze-only | -Z] [--table | -t table [( column [,...] )] ] [dbname]
vacuumdb [connection-option...] [--all | -a] [--full | -f] [-F]
[--verbose | -v] [--analyze | -z]
[--analyze-only | -Z]
vacuumdb -? | --help
vacuumdb -V | --versionvacuumdb — это утилита для очистки базы данных RT.Warehouse. vacuumdb также будет генерировать внутреннюю статистику, используемую оптимизатором запросов к RT.Warehouse.
vacuumdb — это оболочка для SQL-команды VACUUM. Эффективной разницы между очисткой баз данных с помощью этой утилиты и других методов доступа к серверу нет.
Таблица 110— Параметры vacuumdb
|
Параметр |
Описание |
|---|---|
| -a | --all | Удаление всех баз данных. |
| [-d] dbname | [--dbname=]dbname | Имя базы данных для очистки. Если параметр не указан и -a (или --all) не используется, имя базы данных считывается из переменной среды PGDATABASE. Если он не установлен, используется имя пользователя, указанное для соединения. |
| -e | --echo | Вызов команд, которые создаёт и отправляет на сервер reindexdb. |
| -f | --full |
Выбор полной очистки, которая может освободить больше места, но занимает гораздо больше времени и блокирует таблицу. Предупреждение. VACUUM FULL не рекомендуется в RT.Warehouse. |
| -F | --freeze | Заморозить информацию о транзакции строки. |
| -q | --quiet | Не отображать ответ. |
| -t table [(column)] | --table= table [(column)] | Очистка или анализ только выбранной таблицы. Имена столбцов можно указывать только вместе с параметрами --analyze или --analyze-all. Несколько таблиц можно очистить, написав несколько ключей -t. Если вы указываете столбцы, вам, вероятно, придётся избегать скобок в оболочке. |
| -v | --verbose | Вывод подробной информации во время обработки. |
| -z | --analyze | Сбор статистики для использования планировщиком запросов. |
| -Z | --analyze-only | Вычисление статистики только для использования планировщиком запросов (без вакуума). |
| -V | --version | Вывод версии vacuumdb и выход. |
| -? | --help | Вывод справки об аргументах командной строки vacuumdb и выход. |
Таблица 111— Параметры подключения vacuumdb
|
Параметр |
Описание |
|---|---|
| -h host | --host=host | Задаёт имя хоста машины, на которой работает мастер-сервер RT.Warehouse. Если параметр не указан, данные считываются из переменной среды PGHOST или по умолчанию используется localhost. |
| -p port | --port=port | Задаёт TCP-порт, на котором мастер-сервер RT.Warehouse прослушивает соединения. Если параметр не указан, данные считываются из переменной среды PGPORT или по умолчанию 5432. |
| -U username | --username=username | Имя роли базы данных для подключения. Если параметр не указан, данные считываются из переменной среды PGUSER или по умолчанию используется текущее имя пользователя системы. |
| -w | --no-password | Никогда не запрашивать пароль. Если сервер требует аутентификации по паролю, а пароль недоступен другими способами, такими как файл .pgpass, попытка подключения не удастся. Этот параметр может быть полезен в batch-заданиях и скриптах, где нет пользователя, который мог бы ввести пароль. |
| -W | --password | Принудительный ввод пароля. |
| --maintenance-db=dbname | Задает имя базы данных для подключения, чтобы определить, какие другие базы данных следует переиндексировать. Если параметр не указан, будет использоваться база данных postgres, а если она не существует, будет использоваться template1. |
vacuumdb может потребоваться несколько раз подключиться к мастер-серверу, каждый раз запрашивая пароль. В таких случаях удобно иметь файл ~/.pgpass.
Очистить базу данных test:
vacuumdb testОчистить и проанализировать базу данных с именем bigdb:
vacuumdb --analyze bigdbЧтобы очистить одну таблицу foo в базе данных с именем mydb и проанализировать отдельный столбец bar таблицы. Обратите внимание на кавычки вокруг имён таблиц и столбцов, чтобы избежать скобок в оболочке:
vacuumdb --analyze --verbose --table 'foo(bar)' mydb