Что такое txid: Транзакции Hash ID (TXID) — что это и как найти ID транзакции

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

Обратите внимание, что хэширование — это не то же самое, что шифрование, поскольку у хэша нет ключа, который специально обращал бы его к исходному вводу. Тем не менее, хэш может быть обращен с помощью “грубой силы”, хотя это чрезвычайно сложно и требует много ресурсов. Грубые хэши являются основой майнинга в блокчейне.

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

Сделать это проще с компьютера, чем с мобильного девайса. Некоторые хранилища показывают идентификатор в самом кошельке. Для этого просто нажмите на платеж, который вы сделали, а затем кликните на «ID транзакции» — подобный код (a1565db55d416d3ca149f35b6984e2015b9245e16c5cf312fc80e9d5fbf5d48d) и есть hash ID.

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

• Биткоин (BTC) находится здесь. В «Поиск» введите свой публичный биткоин-адрес, который вы использовали для транзакции. После этого будут отображены все транзакции, которые касаются вашего адреса, от самой новой до самой старой. Первая (новая) транзакция должна быть той, которую вы ищете. Чтобы убедиться — проверьте сумму операции. После нажмите на выделенную синим цветом строку цифр рядом с символом «+» и вы увидите ваш идентификатор транзакции.
• Bitcoin Cash (BCH) — здесь. Повторите все шаги из первого пункта — в этих валютах они идентичны.
• Эфириум (ETH) — здесь. Используйте тот же метод поиска, что и в примерах выше, но в Эфириуме номер хэша транзакции находится не рядом со знаком «+», а в столбце под названием «TxHash».

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

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

• адресат не получил перевод;
• транзакция не была записана в блокчейн в следствии какой-то технической ошибки.

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

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

Источник

FinTimez

Где проверить транзакцию Биткоин: сервисы, как можно отследить транзакцию биткоина

Криптовалюта

10.08.2021

Комментариев: 0

Просмотров: 1121

Читать: 5 мин

Tx Hash — означает хеш транзакции и также известен как идентификатор транзакции (TxID). Он состоит из буквенно-цифровых символов — это идентификационный номер, присвоенный трансакции Биткоин. Каждая трансакция, которая проводится в цепочке блоков биткоинов, имеет этот уникальный идентификатор. И точно так же трансакции в цепочке блоков Ethereum имеют уникальный хэш Tx.

Например, идентификатор transaction Биткоин выглядит так:

a1062db53e416d8fa109f23b7094a21e5b2645e16c5cf532fc90e4d8fbf5d48d

Хеш transaction Ethereum выглядит так:

0xb4bc293478d3ф82a652a8d90a6bfd8ec0ba1a63923bbb4f88147fb8a943da26d

Все трансакции в блокчейне общедоступны. После того, как вы совершите платеж или переведете монеты на другой адрес, transaction будет записана, и также будет сгенерирован Tx Hash ID. 

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

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

Чем полезны Tx Hash? 

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

Как узнать хэш транзакции?

Проверить хэш транзакции биткоин можно несколькими способами. Рассмотрим их.

ID перевода можно узнать в сервисе Blockchain — https://www.blockchain.com/explorer. Зайдите на сайт и перейдите в раздел «Исследовать».

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

Подходящий перевод можно найти с помощью встроенного поиска в браузере, точно указав сумму перевода. Команда: CTRL/Command + F.

TXID операции отобразится в сером поле. Щелкните по нему, и откроется страница с подробной информацией о сделке.

Где смотреть хэш транзакции еще?

Хэш адрес транзакции можно найти в разделе истории transactions сервиса (бумажник, платформа обмена и т.д.), который вы использовали. Если вы не можете найти свой хэш в истории, мы рекомендуем вам связаться с командой поддержки службы и попросить их о помощи. 

Можно хеш транзакции биткоин посмотреть на таких сервисах, как: Core wallet, Electrum Wallet, биржа Coinbase, бирже Binance и других криптовалютных биржах.

Схемы стандартна для обоих кошельков. Перейдите на вкладку “transactions” и найдите нужную трансакцию. Дважды нажмите на ее, и появится окно, в котором вы найдете идентификатор.

На биржах вы сможете найти хэш каждой трансакции в истории вашего счета или в истории платежей.

Войдите в свою учетную запись, перейдите на вкладку «Учетные записи» и выберите кошелек (BTC, ETH, LTC, BCH, BAT, ZRX). Нажмите на интересующую трансакцию. Появится окно. Кликните на просмотр transaction, чтобы узнать идентификатор.

Войдите в свой аккаунт Binance. Действуйте по пути: «Кошелек» — «Обзор кошелька» — «История кошелька». Вам выпадет вся история вводов и выводов средств. Идентификатор transaction находится в графе TxID.

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

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

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

Что значит неподтвержденная транзакция биткоин?

Неподтвержденная транзакция – это транзакция, которая после ее инициирования не была добавлена в блок. Работа сети Bitcoin поддерживается майнерами, которые и «обрабатывают» переводы. У них есть собственный приоритет – чем выше комиссия за байт транзакции, тем быстрее она будет добавлена в новый блок. Так что явление неподтвержденной транзакции – это чаще всего следствие низкой комиссии, которую выбрал отправитель.

Вы всегда можете узнать статус вашего перевода, просто введя в поле поиска сайта blockchain.info свой TXID (id вашей транзакции). Там отображается количество подтверждений и путь самой транзакции. Цифра 2 около и синий статус «кнопки» c надписью Confirmations в Blockchain означает, что транзакция прошла. А если она не была подтверждена, тогда вы увидите характерную надпись Unconfirmed Transaction на красном фоне.

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

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

Почему не подтверждается транзакция?

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

Важно помнить, что размер комиссии не зависит от суммы транзакции. То есть, транзакция на 100 биткоинов может оказаться дешевле, чем на 0,01 BTC. Все зависит от ее размера в байтах. В свою очередь размер зависит от количества связанных транзакций. Например, если вы получили по 1 биткоину от Димы, Саши, Кати, а потом отправляете эти 3 биткоина Вахтангу, то в этой транзакции будет участвовать 4 адреса (включая ваш). А это дополнительные 600 байтов или около того.

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

Можно даже провести приблизительный расчет. Размер 1 блока составляет 1 мегабайт, на скрине выше обычная транзакция «занимает» 370 байт. На генерацию 1 блока уходит порядка 10 минут. Это значит, что за 10 минут может быть подтверждено порядка 2600 транзакций. Но ведь их на самом деле значительно больше.

На все том же сайте blockchain.info можно посмотреть размер mempool (мемпул – очередь) сети. Это объем всех транзакций, который ждут подтверждения.

Суммарно они занимают свыше 100 мегабайт. Это означает, что менее 1% транзакций будет подтверждено в течение 10 минут. В общей сложности на их обработку уйдет 10х100=1000 минут или почти 17 часов. И это при условии, что в сети BTC внезапно перестанут проводиться любые новые транзакции.

Глобальное решение этой ситуации – это увеличение размера блока. Именно для этого и был проведен Segwit . Он предусматривает оптимизацию использования памяти для хранения данных о транзакциях, и должен подготовить сеть к дальнейшим модификациям (увеличение блока) через софтфорк. Segwit2x, который предусматривал хардфорк (жесткое разделение блокчейн) и увеличение размера блока до 2 мегабайт, был отменен.

Что будет с деньгами?

Одно можно сказать точно – ваши деньги никуда от вас не пропадут. Тут есть два сценария:

• Ждать, пока ваша транзакция таки получит необходимых 2 подтверждения;
• Принимать какие-то меры, чтобы ее протолкнуть.

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

И даже если вы не спешите с переводом, на каком-то этапе придется принимать меры. О об основных способах ускорения мы поговорим ниже.

Сколько ждать подтверждения транзакции биткоин

На некоторых сервисах указывается как долго ожидать подтверждения. Но эти цифры редко-когда имеют что-то общее с реальностью. Вы можете самостоятельно рассчитать время подтверждения транзакции. Для этого вам необходимо обратить внимание на строку Fee per byte.

Как обезопаситься от зависания транзакций

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

Если вы получили 10 биткоинов через 10 транзакций по 1 биткоину, то перевод этих 10 биткоинов по своему объему в байтах будет намного больше, чем перевод 100 биткоинов, которые вы получили с 1 адреса. Это и есть пример «Пути» отправляемых биткоинов. Аналогично и при отправлении – чем больше адресов, тем больше комиссия. Если вам нужно отправить BTC нескольким получателям, тогда объединяйте транзакции в одну и «разветвляйте» ее через Input.

Ключевое значение – это размер комиссии на 1 байт. Перед тем как отправлять битки, посмотрите показатели мемпула и проверьте среднее значение комиссий в сети. Посмотреть показатели комиссий можно на BitcoinFees.

Если мемпул пуст, тогда даже перевод с небольшой «пеней» пройдет – здесь работает простой закон спроса и предложения. Майнеры обрабатывают транзакции, так как лучшие предложения поступают редко. Идеальное время проведения – это когда Китай и Азия спят. То есть в европейской первой и второй временной зоне в этот период вечер (6-10 часов).

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

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

Итак, резюме:

1. Неподтвержденная транзакция – это транзакция, которая после отправки по какой-то причине не была добавлена в блок.
2. Чтобы ускорить транзакцию, можно использовать метод двойной траты (Double Spend), CPFP, Replace-by-fee либо специальные ускорители.
3. Чтобы обезопаситься от зависаний, нужно выставлять правильную комиссию и учитывать время проведения транзакции.

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

Блокчейн — революционная технология хранения и обработки данных, обладающая одновременно несколькими свойствами:

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

Чтобы хешировать данные, получаемые в процессе генерации биткоинов (bitcoin), используют алгоритм шифрования SHA-256, применяемый также в криптографии. Он состоит в том, что информация любого размера и вида кодируется в 256-битный ключ, состоящий из цифр и букв латинского алфавита.

Хеш функция уникальна тем, что с ее помощью кодируется как многотомная книга, так и одно слово, а размер полученного ключа будет одинаковым. При попытке внести изменения хотя бы в 1 символ исходного блока, полученный в результате hash ключ будет кардинально отличаться. Эта ситуация называется «эффект лавины» и служит для защиты от изменений. Также алгоритм SHA-256 гарантирует защиту от коллизий, т. е. вероятность генерации совпадающих хешей при неодинаковых исходных данных стремится к нулю.

Хеширование в майнинге

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

Пользователи во время майнинга создают новые контейнеры с информацией, но подтверждение получают только те, которые отвечают заданным условиям блокчейна. Хеш блока, создаваемого пользователем, должен быть меньше максимально возможного за вычетом переменной, которую обозначают как «сложность». В зависимости от того, с какой скоростью находились предыдущие блоки, сложность задачи увеличивается или уменьшается, чтобы скорость майнинга в будущем оставалась на относительно одинаковом уровне. Если одновременно отслеживается не один блок, удовлетворяющий указанному условию, то пройдет проверку и в список транзакций добавится только тот, чья цепочка длиннее.

ВАЖНО! Чтобы узнать хеш конкретной транзакции, нужно воспользоваться специальными программными средствами или сайтами. Например, если вводить на сайте www.blockchain.info информацию о биткоин-транзакции, то на экране отобразятся все сведения о ней, в том числе и искомый хеш. Управление транзакциями осуществляют в личном кабинете, там же отслеживают отправителей и получателей биткоинов, заводят биткоин-кошелек, обменивают криптовалюту.

Использование хеширования в области блокчейна и при создании биткоинов помогает проверять истинность и неизменность полученных блоков, защищает их от вмешательства извне. Кроме шифрования SHA-256, в блокчейне применяются другие хорошие криптографические методы: X11, DaggerHashimoto, Scrypt.

Видео: криптографические хеш-функции

Видео: что называется хешированием?

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

Перегрузка сети пошла на спад

Количество неподтвержденных транзакций стало значительно меньше, чем на пике в конце мая – mempool (пул неподтвержденных транзакций) составляет в среднем от 7 000 до 15 000 транзакций в день. Это серьезный контраст с недавним положением, когда очередь достигала 200 000 транзакций всего несколько недель назад. Количество неподтвержденных транзакций начало уменьшаться в первую неделю июня, и положительная тенденция продолжилась и до сегодняшнего дня.

Так как количество неподтвержденных транзакций снизилось, создав благоприятную почву для операций с биткоином, комиссии также пошли на спад. Менее чем два года назад кто угодно мог отправить биткоины за комиссию, которая тогда составляла примерно 0.02 доллара в BTC. Однако в мае этого года размер комиссий достиг в среднем 5 долларов за транзакцию. Тем не менее теперь комиссии вновь стали уменьшаться и стали меньше доллара, а согласно сообщениям некоторых сторонников биткоина – достаточные для быстрого подтверждения комиссии составляют около 0.25 доллара.

Трудности в проверке теорий

Безусловно, существует несколько теорий, объясняющих уменьшение количества неподтвержденных транзакций и размера комиссионных сборов. Некоторые считают, что ситуация с высокими комисиями – результат «спам-атаки», которая заключалась в том, что один человек или группа отправляли большое количество транзакций с низкими комиссионными. Однако большинство участников сообщества считает эту теорию несостоятельной – для поддержки такой атаки потребовалось бы слишком много средств.

Еще одно объяснение обуславливает уменьшение количества транзакций и сокращение комиссий снижением активности в сети. Например, цена на биткоин падала несколько раз после достижения исторического максимума, что привело к снижению количества транзакций. Наряду с этим объем торговли снизился до 1 миллиарда по сравнению с 2 миллиардами долларов в BTC в день. Еще одна теория заключается в том, что такие компании как Genesis mining и другие крупные предприятия, осуществляют больше транзакций «вне сети». Большинство из этих теорий с трудом подвергаются проверке и пока остаются лишь домыслами участников сообщества.

Кошельки подстраиваются под ситуацию

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

Например, вчера кошелек Breadwallet рекомендовал размер комиссии в 1.76 доллара для типичной транзакции размером в 226 байт. Если перейти на страницу конвертера комиссий на сайте 21 Inc , можно увидеть, что «самая оптимальная транзакционная комиссия в настоящее время составляет 300 сатоши/байт» для 226-байтовой транзакции, что вчера равнялось 1.73 доллара. Многие кошельки сейчас запрашивают более высокие комиссии, чем необходимо.

Существуют и другие кошельки, которые позволяют менять размер комиссий – пользователи могут сами выставить размер комиссий значительно меньше 300 сатоши/байт. Такие транзакции, скорее всего, будут подтверждаться так же быстро, как и с более высокими рекомендуемыми комиссиями. Большинство кошельков используют динамические настройки комиссий, которые предлагают только три варианта комиссий, размер которых основывается на таких же инструментах, как и графики 21 Inc. Однако есть несколько кошельков, которые позволяют устанавливать размер комиссии самостоятельно — Bitcoin Core, Electrum, Blockchain.info, Trezor, Armory, Green Address, Airbitz и другие.

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

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

Почему транзакция не подтверждается

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

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

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

Современные кошельки, такие как Bitcoin Core или blockchain.info, автоматически предлагают оптимальный размер комиссии. Проблема в том, что алгоритм расчета не идеален, и может не учитывать мощные всплески активности в сети. Даже если пользователь указал рекомендуемую комиссию для своей транзакции, существует риск ее зависания в блокчейне.

Зависла транзакция в блокчейн: что делать

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

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

Первое, что необходимо сделать — получить информацию о статусе транзакции. Для этого зайдите на сайт blockchain.info и введите id транзакции (обычно обозначается как tx или txid) в текстовое поле, расположенное в правом верхнем углу. Запрос выполняется нажатием клавиши на клавиатуре (нажимать кнопку не нужно!).

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

В графе «Плата за байт» указан размер комиссии. Это число пригодится для дальнейшей оценки ситуации.

Далее нужно сравнить эту комиссию с текущей статистикой сети Bitcoin. Сделать это можно, просмотрев рекомендуемые комиссии на сайте bitaps.com . Если плата за байт примерно равна или превышает последнее число в поле «Recommended fee», можно надеяться на подтверждение транзакции в течение 1 – 2 часов.

Для подтверждения информации можно воспользоваться сервисом Bitcoinfees , который показывает количество неподтвержденных переводов, разделяя их по размеру комиссии.

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

Способы ускорения транзакций

Если у вас возникла неподтвержденная транзакция в блокчейн, что делать дальше и как ее побыстрее «протолкнуть»? Существует несколько способов ускорения транзакций, которые могут помочь в различных ситуациях. Перечислим основные методы в порядке увеличения сложности.

Использование ускорителей майнинговых пулов

Майнинговые пулы, контролирующие большую долю мощности в системе Bitcoin, могут способствовать пользователям в ускорении транзакций. На данный момент интерес представляют сервисы двух крупных пулов:

В первую очередь стоит использовать ускоритель ViaBTC: он не требует регистрации, и все, что нужно сделать пользователю — ввести id транзакции и капчу.

Если после нескольких попыток транзакция так и не подтвердилась, следует переходить к использованию ускорителя Antpool. Для регистрации на сайте нужно указать E-mail и пароль.

Бот-ускоритель в Telegram

Telegram бот @FastTXbot создан для автоматического ускорения переводов в сети Bitcoin. Для его использования необходимо отправить номер зависшей транзакции и ждать результата. На самом деле бот использует один из предыдущих способов — ускорение через Antpool. При этом робот автоматически делает всю работу за пользователя: достаточно просто дождаться уведомления о результате процедуры, которое обычно приходит в течение 10 минут.

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

replace-by-fee

Данная возможность позволяет создать копию зависшей транзакции с повышенной комиссией. На сегодня replace-by-fee поддерживается популярными десктопными кошельками Bitcoin Core и Electrum, а также онлайн-кошельком GreenAddress. Для использования функции нужно создать перевод, содержащий точно такую же сумму, при этом увеличив комиссию до приемлемого уровня. Кроме того, при отправке транзакции нужно обязательно выбрать пункт replace-by-fee: в противном случае средства отправятся дважды. В Bitcoin Core нужная галочка спрятана в нижней части окна отправки.

CPFP (Child pays for parent)

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

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

Для использования CPFP в Bitcoin Core нужно перейти в меню «Настройки» — «Опции», выбрать вкладку «Кошелек» и отметить галочки, как показано на скриншоте.

После этого останется создать новую транзакцию на вкладке «Отправить». Щелчком по кнопке «Входы» нужно выбрать сумму, которая изначально была отправлена на счет получателя. Если ускорение производит отправитель, в качестве входа нужно выбирать «сдачу», которая осталась после отправки транзакции. Увидеть размер сдачи можно при просмотре транзакции на сайте blockchain.info.

При использовании CPFP следует устанавливать комиссию, достаточную для проведения сразу двух транзакций. Например, при рекомендуемой плате 150 sat/B следует устанавливать комиссию 300 sat/B или выше.

Двойное расходование

Наиболее сложный способ, доступный только для пользователей Bitcoin Core. Рекомендуется для опытных пользователей, так как требует навыков использования командной строки и очень аккуратного обращения с входами транзакций.

Для начала необходимо запустить кошелек из командной строки с параметром -zapwallettxes. Кроме того, для современных версий Bitcoin Core требуется удаление файла mempool.dat из папки с программой. После этого можно создавать новую транзакцию, которая в точности повторит старую, за исключением увеличенной комиссии.

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

Заключение: как защититься от неподтвержденных транзакций

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

• Подборки новостей один раз в день к вам на Email:
• Подборки криптоновостей 1 раз в день в Телеграме: BitExpert
• Инсайды, прогнозы обсуждения важных тем у нас в Телеграм чате: BitExpert Chat
• Вся лента криптоновостей журнала BitExpert у вас в Телеграме: BitExpert LIVE

Нашли ошибку в тексте? Выделите ее и нажмите CTRL+ENTER

Хотите ли вы стать разработчиком блокчейн-приложений или просто интересуетесь, что происходит во время отправки биткоинов другу – вам нужно разбираться в процессе создания и осуществления транзакций. Почему?

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

Разработчики узнают, как их Биткоин клиент осуществляет транзакции в сети (и что происходит, когда они получены).

Простые пользователи найдут ответ на вопрос: “Какие запускаются процессы, когда вы отправляете биткоины другу?”.

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

Биткоин транзакции и их роль в общей картине

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

Это простое, но точное описание может озадачить: так что же на самом деле представляет из себя транзакция?

⦁ Как понимание процесса переводов поможет стать хорошим разработчиком блокчейнов?

⦁ Каким образом транзакции позволяют переводить биткоины другому человеку?

Ответы на эти вопросы различаются в зависимости от вида транзакции. Даже работая только с биткоином, мы можем воспользоваться несколькими системами переводов.

Но начнём с азов и разберёмся с главным видом транзакции под названием pay-to-PK-hash. Сейчас этим типом переводов пользуются 99% владельцев биткоинов.

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

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

Каждая Биткоин транзакция состоит из “входов” (inputs) и “выходов” (outputs). Мы отобразили её структуру на изображении:

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

Когда вы отправляете подруге деньги, то в качестве адреса используется её “выход”. А ваши “входы” будут доказательством, что у отправителя есть достаточная сумма для осуществления операции. У вас может быть несколько “входов”, сумма которых и является балансом аккаунта. В этом простом случае в транзакции участвует только один вход и один вывод.

Подробно о биткоин транзакциях

Давайте разберёмся в механизме реальной Биткоин транзакции. Для наглядности взгляните ещё раз на изображение.

Если мы изучим типичную транзакцию в “разрезе”, то увидим, что она состоит из 3-х больших частей: заголовка, вход(ов) и выход(ов). Давайте кратко рассмотрим компоненты, входящие в эти секции, так как они будут важны для понимания процесса. Отметим, что все эти поля присущи так называемым row-транзакциям. Они осуществляются между одноранговыми узлами при создании перевода.

Заголовок

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

⦁ ver : номер версии, которая используется для верификации блока.

⦁ vin_sz : число входов транзакции. Vout_sz отображает число выходов.

⦁ lock_time : определяет самое раннее время, когда блок может быть добавлен в цепь. Это либо высота блока, либо метка unix-времени.

Вход

⦁ хэш предыдущего выхода: указывает на предыдущий неосуществленный выход транзакции (UTXO). По сути, это ваши деньги, которые вы собираетесь потратить на эту транзакцию.

⦁ n : индекс в списке выходов предыдущей транзакции. Показывает актуальный номер текущего выхода.

⦁ scriptSig : скрипт отправки, который подтверждает, что у создателя транзакции есть права пересылать деньги.

Выход

⦁ значение (value) : количество потраченных сатоши (1 BTC = 100,000,000 Satoshi).

⦁ scriptPubKey : второй из двух скриптов, осуществляющих транзакцию. Нужен для определения хэша публичного ключа получателя.

Верификация транзакции

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

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

⦁ Подписи на каждом входе действительны. Это определяется выполнением последовательности скриптов. Подробности вы найдёте в следующей главе.

⦁ Нет UTXO, отправленных чаще, чем один раз за транзакцию. Обратите внимание на различия с первым пунктом.

⦁ Все значения выхода транзакции неотрицательны.

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

Базовая pay-to-PK-hash транзакция

Биткоин имеет свой собственный скриптовый язык. Он достаточно мощный, чтобы позволить разработчикам создавать сложные и настраиваемые виды транзакций. Существует около пяти стандартных видов переводов, которые поддерживаются классическими биткоин клиентами. Но есть и другие клиенты, которые работают с иными видами транзакций за определенную плату. Здесь мы просто рассмотрим механизм pay-to-PK-hash.

Для любой транзакции, чтобы она считалась действительной, пара скриптов scriptSig/scriptPubKey должна показать значение “true”. При отправлении транзакции включается scriptSig. Он собирает информацию от scriptPubKey и при его выполнении подтверждает выход транзакции. Оба скрипта находятся в одной и той же ячейке.

Так как адреса биткоинов на самом деле являются хешами, то отправитель не сможет узнать, какой ключ проверяется: открытый или закрытый. Поэтому получатель указывает оба ключа, а scriptPubKey будет дублировать и хешировать открытый ключ. Этот процесс позволяет скрипту убедиться, что ключ принадлежит предполагаемому получателю.

Во время выполнения операции вы увидите, что константы при встрече помещаются в стек. Система добавляет или удаляет элементы из стека по мере их обработки. Например, OP_HASh260 возьмёт верхний элемент из стека, и сделает это дважды, сначала с SHA-256, а затем с RIPEMD-160. Когда все элементы в нашем скрипте будут оценены, появится значение true при удачной операции или false в случае нахождения ошибок.

В целом, pay-to-PK-hash – довольно простой тип транзакции. Он гарантирует, что только пользователь с соответствующей парой открытого/закрытого ключей может получить и потратить биткоины. Когда все критерии из предыдущего абзаца выполнены, транзакция считается успешной и помещается в блок.

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

Что такое TXID или как найти транзакцию в океане блокчейнов

1. Что такое транзакция с криптовалютой и как она осуществляется?
2. Что такое TXID и зачем он нужен?
3. Как использовать TXID?
4. Как найти TXID?
5. Заключение

1.Что такое транзакция с криптовалютой и как она осуществляется?

2. Что такое TXID и зачем он нужен?

3. Как использовать TXID?

4. Как найти TXID?

5. Заключение

TXID (Transaction Identifier) ​​Explained — Mycryptopedia

Транзакции в таких сетях, как Биткойн, работают с использованием модели UTXO (неизрасходованный вывод транзакций).В этой модели узлы в сети отслеживают все доступные расходуемые выходы транзакций, также известные как неизрасходованные выходы транзакций или UTXO. Эти неизрасходованные выходы транзакций затем используются в качестве входных данных при формировании новых транзакций в сети. TXID, также известный как идентификатор транзакции или хэш транзакции, представляет собой уникальный фрагмент данных, который используется для идентификации транзакции.

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

Транзакции транслируются в сериализованном байтовом формате, известном как формат необработанных транзакций. В информатике сериализация — это процесс перевода внутреннего представления структуры данных в формат, который может передаваться по одному байту за раз.Затем этот необработанный формат транзакции дважды хешируется с использованием алгоритма криптографического хеширования, которым в случае Биткойна является SHA-256, для получения TXID транзакции.

TXID не гарантируется, пока транзакция не будет подтверждена сетью. Однако на отслеживание платежей с использованием TXID может повлиять гибкость транзакции. Это происходит, когда TXID транзакции изменяется до того, как ее можно будет подтвердить в блоке.Это проблематично, поскольку создает возможности для атаки на плохо закодированное программное обеспечение кошелька, предполагающее неизменность неподтвержденных TXID. В Биткойне внедрение Segregated Witness или SegWit было разработано как решение проблемы гибкости транзакций.

SegWit — это обновление правил консенсуса Биткойн и сетевого протокола, который был предложен и реализован как софт-форк BIP-141. В области криптографии термин свидетель используется для описания решения криптографической головоломки.В случае с биткойном свидетель служит решением головоломки, связанной с UTXO. Эта криптографическая головоломка также известна как сценарий блокировки, сценарий-свидетель или scriptPubKey, и он определяет условия, которые должны быть сначала выполнены, прежде чем можно будет потратить UTXO. В контексте протокола Биткойн цифровая подпись — это один из типов свидетелей, которые могут быть представлены для решения криптографической головоломки с целью расходования средств. Однако в более широком смысле термин свидетель можно рассматривать как любое решение, которое может удовлетворять условиям, налагаемым на UTXO.В случае Биткойна термин свидетель можно рассматривать как более общий термин для сценария разблокировки, который также известен как сценарий подписи или scriptSig. Сценарий разблокировки — это набор параметров данных, которые генерируются спонсором для удовлетворения условий, установленных сценарием блокировки.

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

С внедрением SegWit транзакции в сети Биткойн теперь имеют два идентификатора: TXID и WTXID.TXID — это традиционный идентификатор транзакции, который представляет собой двойной хэш SHA-256 сериализованной транзакции без данных свидетеля. В то время как новая транзакция WTXID представляет собой двойной хэш SHA-256 нового формата сериализации транзакции с данными свидетеля. Таким образом, поскольку транзакции SegWit не содержат данных свидетелей на каждом входе, нет части транзакции, которая может быть изменена третьей стороной.

Что такое хэш транзакции?

Торговля криптовалютами может быть действительно быстрым и легким процессом, если вы освоите его.Когда ваш криптокошелек и торговый счет настроены на платформе обмена криптовалютой, такой как Coinbase, вы можете начать торговать любым из самых популярных цифровых активов, таких как биткойны (BTC), Ether (ETH), токены ERC20 и т. Д.

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

Какова роль хеширования транзакции?

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

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

Как искать в блокчейне ваш TXID

Все хэши транзакций общедоступны и доступны для просмотра в блокчейне конкретной цифровой валюты. В момент создания и отправки перевода он получает свой уникальный TXID в цепочке блоков. Хэш создается с использованием технологии 256-битного алгоритма безопасного хеширования (SHA-256), которая в основном гарантирует, что никакие идентификаторы транзакций не могут иметь одинаковый хэш, поэтому нет возможности смешивать или компрометировать передачи.

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

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

То же самое и с другими криптовалютами, вам просто нужно использовать веб-сайт с обозревателем блоков для соответствующей цепочки блоков. Например, если вы обмениваетесь активами на основе Ethereum, вы не можете использовать обозреватель блоков биткойнов, чтобы найти свою конкретную транзакцию. Вместо этого вы должны использовать Etherscan.io, чтобы найти данные о вашем переводе.

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

Как найти хэш транзакции биткойнов на Coinbase

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

1. Войдите в свою учетную запись Coinbase.

2. Используйте вкладку Accounts , чтобы перейти в свой кошелек и выбрать BTC.

3. Здесь вы найдете историю транзакций BTC.Щелкните одну из этих отправленных транзакций.

4. Появится всплывающее окно. Выберите Просмотреть транзакцию , и вы увидите хэш транзакции.

Несколько слов перед тем…

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

Что такое хэш (Tx Hash, Transaction id) транзакции?

Использование TxHash и TxID

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

Любой, у кого есть TxID, узнает все детали перевода, такие как: адрес отправителя, адрес получателя, общая сумма отправки, дата перевода, высота блока, комиссия и количество подтверждений. Хэш транзакции и идентификаторы не содержат личной информации, поэтому ее можно безопасно передавать.

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

Как найти хэш-идентификатор транзакции?

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

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

Чтобы узнать TxID или TxHash, найдите свой BTC или адрес получателя в blockexplorer. Если вы видите в списке много транзакций, просто найдите сумму отправленных BTC.Таким образом, можно найти конкретный перевод. Как только вам удалось его найти, вы также можете легко найти хеш-идентификатор транзакции. Теперь вы можете просто поделиться идентификатором транзакции или, найдя его, указать URL страницы.

TXID клиентов превышают 4000000000, вызывая сообщения NOTICE, или превышают 4294467296, что приводит к тому, что запросы не принимаются и завершаются с ошибкой FATAL

Проблема

Для системы, работающей в течение длительного времени, TXID, используемый системой, в конечном итоге превысит поддерживаемый системой лимит 2 ^ 32 i. 32 i.е. 4294967296, после чего система перестанет обрабатывать запросы. И единственный выход — сбросить TXID на более низкое значение и восстановить систему, что приведет к потере этих транзакций, то есть к возможной потере данных.

Эта проблема была частично решена в более поздних выпусках NPS.
В более поздних версиях система корректно оборачивается вокруг TXID и продолжит обрабатывать запросы без каких-либо перерывов.

Остается проблема в том, что по-прежнему отображается фальшивое ПРЕДУПРЕЖДЕНИЕ.

ПОЗДНИЕ ВЕРСИИ NPS будут демонстрировать следующее поведение (это было проверено с помощью 7.2.1.9)
Многие команды (такие как nzhw, nzsession, nzsql) теперь начинают отображать сообщения, когда вы их вызываете!
Значит, УВЕДОМЛЕНИЕ (довольно часто) будет у вас на лице!
Почти невозможно игнорировать!

ВНИМАНИЕ: текущий идентификатор транзакции 4200001470 превышает порог предупреждения 4000000000. Немедленно обратитесь в службу поддержки!
Если вы не предпримете никаких действий, в конечном итоге вы начнете получать сообщения ERROR, такие как это
Ошибка: сбой подключения к БД: FATAL 1: текущий идентификатор транзакции 4294467315 превышает системный порог 4294467296.Блокировка дальнейших транзакций во избежание потери данных. Немедленно обратитесь в службу поддержки, чтобы продолжить использование системы !.

В этом случае ПРЕДУПРЕЖДЕНИЕ можно просто проигнорировать, поскольку сообщение ПРЕДУПРЕЖДЕНИЕ является ложным и в конечном итоге исчезнет без каких-либо действий. Но поскольку это предупреждение трудно игнорировать, стоит потратить 2 часа на отключение базы данных и обновить каталог, чтобы это ПРЕДУПРЕЖДЕНИЕ исчезло.

Также некоторые клиенты (например, IDAA) никогда не увидят ни одного из этих предупреждающих сообщений.

Диагностика проблемы

Клиент начнет видеть следующее УВЕДОМЛЕНИЕ, которое является предупреждением о том, что TXID достигает порога остановки:

«УВЕДОМЛЕНИЕ: текущий идентификатор транзакции 4000000001 превышает порог предупреждения 4000000000. Немедленно обратитесь в службу поддержки!»

Как только порог будет достигнут, все запросы начнут завершаться ошибкой со следующей ошибкой:

«FATAL: текущий идентификатор транзакции 4294467297 превышает системный порог 4294467296.Блокировка дальнейших транзакций во избежание потери данных. Немедленно обратитесь в службу поддержки, чтобы продолжить использование системы! »

-ИЛИ-

Клиент может столкнуться с проблемой при запуске нового сеанса nzsql (текущие подключенные сеансы должны быть в порядке). Ошибка:

` nzsql: PQconnectPoll () — ошибка пакета подтверждения (1001): получен ответ`.

Проблема вызвана тем, что nzsql не может обработать сообщения elog: NOTICE после достижения порогового значения.

Решение проблемы

Решением может быть либо обновление каталога, как описано в шаге II) ниже, либо решение должно состоять в том, чтобы сначала сбросить идентификатор транзакции postgres, как описано в шаге I) ниже, а затем шаг II).

Если nzstart не запускает базу данных, вы должны выполнить шаг I), а затем шаг II).
Если вы можете успешно вернуть базу данных, выполните nzstop и перейдите непосредственно к шагу II), пропуская шаг I)

Шаг I) Инструкции по сбросу идентификатора транзакции postgres на 4294940000.
==================================== =================================

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

Вот еще несколько общих шагов (хоть и немного больше, но более общие … и они должны работать)

на терминале №1
——————————————— —————
сенсорный / tmp / spin_postgres
/ nz / kit / sbin / postgres -D /nz/data.1.0 system

на терминале №2
——————————————— —————
(спящий режим 10; rm / tmp / spin_postgres) & nzgdb -pid
b StartupXLOG
c
b ReadCheckpointRecord
c
s # Шагайте, пока не вернетесь в процедуру ReadRecord.Наверное 2 раза.
s # Шагайте, пока не вернетесь в процедуру ReadCheckpointRecord. Наверное, в 3 раза.
s # Шагайте, пока не вернетесь в процедуру StartupXLOG. D

Шаг II) Инструкции по обновлению каталога (обновление каталога занимает около 1 часа)
================================== ================================================

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

Приведенная ниже команда, выполняемая от имени пользователя root, позволяет запустить обновление каталога, даже если NPS в данный момент не подключен к сети, когда вы начали.
/ nz / kit / sbin / nzupgrade -r -T catupgrade upgrade DOCATUPGRADE = TRUE FORCESTATE = 1
—————————- ————
# После этого вы можете подтвердить изменение … и проверить значение pg txid
# через этот SQL
выберите pgxid из _v_pg_transaction, где sessionid = current_sid;
—————————————-

[{«Продукт»: {«код»: «SSULQD», «ярлык»: «IBM PureData System»}, «Бизнес-подразделение»: {«код»: «BU053», «ярлык»: «Облачная платформа и платформа данных») }, «Компонент»: «База данных», «Платформа»: [{«код»: «PF025», «метка»: «Независимая от платформы»}], «Версия»: «1.0.0 «,» Edition «:» «,» Line of Business «: {» code «:» LOB10 «,» label «:» Data and AI «}}]

Управление транзакциями (Руководство разработчика приложений REST) ​​- Документация по продукту MarkLogic 10

API клиента REST обеспечивает управление транзакциями с помощью службы / transaction и параметра txid , доступного для операций с документами и поисковых запросов. В этом разделе рассматриваются следующие темы:

Сводка служб

Многие службы, доступные через REST Client API, позволяют выполнять операцию в контексте конкретной транзакции, передавая идентификатор транзакции в параметре txid .Служба / транзакции поддерживает создание и администрирование этих транзакций.

Служба / транзакции поддерживает следующие операции:

Служба / транзакции / {txid} поддерживает следующие операции:

Обзор транзакций RESTful

В этом разделе дается краткое введение в модель транзакций сервера MarkLogic. поскольку это применимо к REST Client API. Полное обсуждение модели транзакций см. В разделе Understanding Transactions in MarkLogic Server в Руководстве разработчика приложений ..

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

Например, когда вы обновляете документ в базе данных, выполняя запрос PUT к службе / documents , служба эффективно создает новую транзакцию, обновляет документ, фиксирует транзакцию, а затем отправляет ответ. Обновление сразу же отображается в базе данных и доступно для других запросов.

Клиентский API REST также позволяет вашему приложению напрямую управлять границами транзакции, чтобы несколько запросов оценивались в одном контексте транзакции. Это эквивалентно транзакциям с несколькими операторами, описанным в Сводке концепции транзакций с несколькими операторами в Руководстве разработчика приложений .

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

Чтобы использовать транзакции с несколькими операторами:

1. Создайте транзакцию с несколькими операторами, отправив запрос POST в службу / transaction . Сервис возвращает идентификатор транзакции. См. Создание транзакции.
2. Оценить один или несколько запросов в контексте транзакции, включив идентификатор транзакции в параметр запроса txid .См. «Связывание транзакции с запросом».
3. Зафиксируйте или откатите транзакцию, отправив запрос POST в службу / transaction . См. «Фиксация или откат транзакции».

Если ваше приложение взаимодействует с MarkLogic Server через балансировщик нагрузки, вам может потребоваться включить cookie сеанса балансировщика нагрузки в ваши запросы, чтобы сохранить сродство сеанса. Дополнительные сведения см. В разделе «Управление транзакциями при использовании балансировщика нагрузки».

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

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

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

Создание транзакции

Чтобы создать транзакцию, отправьте запрос POST в службу / transaction с URL-адресом в форме:

 http: //  host :  port / version  / transaction 

Служба отвечает идентификатором транзакции в заголовке ответа Location .Используйте идентификатор транзакции для управления транзакцией, в которой MarkLogic Server оценивает будущие запросы; см. «Связывание транзакции с запросом».

Идентификатор транзакции, возвращаемый в заголовке Location, имеет форму. Вы можете использовать этот путь к ресурсу для последующей фиксации или отката транзакции, как описано в разделе «Фиксация или откат транзакции».

/ версия  / transaction /  txnid  

Например:

 # Пользователи Windows, см. Изменение примеров команд для Windows
$ curl -X POST -d "" --anyauth --user user: password \
-H "Content-type: text / plain" \
http: // localhost: 8000 / LATEST / транзакции
...
HTTP / 1.1 303 См. Созданную транзакцию
Расположение: / v1 / transaction / 3148548124558550433 

При предоставлении идентификатора транзакции для будущих запросов используйте только часть txnid . Например:

 $ curl -X PUT -T ./example.xml --anyauth --user user: password \
'http: // localhost: 8000 / LATEST / documents? uri = / xml / example.xml &  txid = 3148548124558550433 ' 

Транзакции, созданные с помощью службы / transaction , должны быть явно подтверждены или отменены.Невозможность зафиксировать или откатить транзакцию до истечения тайм-аута запроса вызывает автоматический откат. Вы можете назначить более короткий временной лимит для транзакции с помощью параметра URL-адреса timeLimit:

 http: //  host :  port / version  / transaction? TimeLimit =  секунд  

Для удобства идентификации транзакции в отчетах о состоянии серверов вы можете присвоить транзакции имя. Имя транзакции по умолчанию — client-txn. Чтобы назначить транзакцию, добавьте в запрос параметр URL-адреса name :

 http: //  host :  port / version  / transaction? Name =  txn_name  

Связывание транзакции с запросом

После создания транзакции, как описано в разделе «Создание транзакции», вы можете оценить манипуляции с документами и поисковые запросы в этой транзакции, указав идентификатор транзакции везде, где поддерживается параметр URL-адреса txid .

Например, чтобы выполнить обновление документа в контексте определенной транзакции, включите идентификатор транзакции в запрос PUT к службе / documents :

 # Пользователи Windows, см. Изменение примеров команд для Windows
$ curl -X PUT -T ./example.xml --anyauth --user user: password \
'http: // localhost: 8000 / LATEST / documents? uri = / xml / example.xml &  txid = 3148548124558550433 ' 

Обновления, связанные с явной транзакцией, видны другим запросам, выполняемым в той же транзакции, но не виден вне транзакции, пока транзакция не будет зафиксирована.См. «Фиксация или откат транзакции».

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

Подтверждение или откат транзакции

Чтобы зафиксировать транзакцию, созданную путем выполнения запроса POST к службе / transaction , отправьте запрос POST в службу / transaction / {txid} с URL-адресом в форме:

 http: //  host :  порт / версия  / transaction /  txid ? Result =  результат  

Где txid — это идентификатор транзакции, возвращенный в заголовке Location при создании транзакции запрос ответ, а результат — это либо фиксация , либо откат .

MarkLogic Server отвечает кодом 204, когда транзакция успешно зафиксирована или откатывается, или если транзакция больше не существует.

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

Проверка статуса транзакции

Чтобы запросить статус транзакции, отправьте запрос GET в службу / transaction с URL-адресом в форме:

 http: //  host :  порт / версия  / transaction /  txid  

Где txid — это идентификатор транзакции, возвращенный в заголовке Location ответа на запрос создания транзакции.

Сервер MarkLogic отвечает информацией о статусе транзакции в XML или JSON, в зависимости от формата, запрошенного через заголовок HTTP Accept или формат , параметр URL-адреса . Формат по умолчанию — XML. Если заданы как заголовок Accept , так и параметр формата , параметр формата имеет приоритет.

Чтобы запросить определенный формат, установите для заголовка Accept значение application / json или application / xml , или установите для параметра URL format значение xml или json .В следующем примере запрашивается вывод JSON с использованием заголовка Accept :

 # Пользователи Windows, см. Изменение примеров команд для Windows
$ curl -X GET --anyauth --user user: password \
-H " Принять: application / json " \
http://marklogic.com/rest -api ">
  
     1506593501555860493 
     somehost 
  
  
     17994162681305741146 
     Службы приложений 
  
  
     8896678293064963766 
     Документы 
  
   216104635458437451 
   клиент-txn 
   обновить 
   0 
   idle 
   false 
   2012-08-18T17: 23: 00-07: 00 
   600 
   3600 
   7071164303237443533 
   правда 
 

Информация о статусе JSON, возвращаемая в ответе, принимает следующую форму:

 {
  "rapi: transaction-status": {
    "rapi: host": {
      "rapi: host-id": "1506593501555860493",
      "rapi: host-name": "somehost"
    },
    "rapi: server": {
      "rapi: server-id": "17994162681305741146",
      "rapi: имя-сервера": "Службы приложений"
    },
    "rapi: database": {
      "rapi: database-id": "8896678293064963766",
      "rapi: имя-базы данных": "Документы"
    },
    "rapi: идентификатор-транзакции": "216104635458437451",
    "rapi: имя-транзакции": "клиент-txn",
    "rapi: режим-транзакции": "обновление",
    "rapi: отметка времени транзакции": "0",
    "rapi: состояние-транзакции": "простаивает",
    "rapi: cancelled": "false",
    "rapi: start-time": "2012-08-18T17: 23: 00-07: 00",
    "rapi: time-limit": "600",
    "rapi: max-time-limit": "3600",
    "rapi: user": "7071164303237443533",
    "rapi: admin": "правда"
  }
} 

Вы также можете проверить статус транзакции с помощью интерфейса администратора или xdmp: host-status.

Управление транзакциями при использовании балансировщика нагрузки

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

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

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

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

1. Создайте транзакцию с несколькими выписками.
   1. Отправьте запрос POST в службу / transaction . Балансировщик нагрузки направляет запрос на какой-либо хост в вашем кластере MarkLogic.
   2. Ответ от MarkLogic включает идентификатор транзакции в заголовок Location, а подсистема балансировки нагрузки добавляет файл cookie сеанса. Клиентское приложение кэширует идентификатор транзакции и файл cookie сеанса для использования в последующих запросах в той же транзакции.
2. Выполнение операций в контексте транзакции с несколькими операторами.
   1. Отправьте запрос на оценку как часть транзакции, например, вставку документа. Включите в запрос идентификатор транзакции (как параметр запроса) и файл cookie сеанса. Балансировщик нагрузки использует cookie, чтобы направить запрос на тот же хост, который изначально создал транзакцию.
   2. MarkLogic отвечает без включения файлов cookie, но балансировщик нагрузки добавляет файл cookie сеанса.
3. Когда все будет готово, закройте транзакцию путем фиксации или отката.
   1. Отправьте запрос POST службе / transaction / {txid} , который включает идентификатор транзакции (в URL-адресе) и файл cookie сеанса.
   2. MarkLogic закрывает транзакцию и отвечает без файлов cookie. Балансировщик нагрузки добавляет файл cookie сеанса. Клиентское приложение отбрасывает кэшированный идентификатор транзакции и, как правило, файл cookie сеанса, поскольку транзакция больше не действительна.

На следующей схеме показаны шаги, описанные выше.Шаги на схеме соответствуют шагам процедуры. Идентификатор транзакции представлен на диаграмме цифрой tid .

Балансировщик нагрузки прикрепляет файл cookie сеанса к ответам на все запросы API клиента REST, но от вашего приложения требуется только передать его обратно как часть операции транзакции с несколькими операторами.

Приложение REST Client API может использовать файл cookie сеанса за пределами одной транзакции с несколькими операторами, прикрепляя файл cookie сеанса к другим запросам.Однако для большинства операций не требуется привязка сеанса. Исключение файла cookie сеанса из запросов, которые не являются частью транзакции с несколькими операторами, позволяет подсистеме балансировки нагрузки более эффективно распределять работу по вашему кластеру MarkLogic.

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

Вы не должны отправлять запрос, который включает идентификатор транзакции для одной транзакции с файлом cookie сеанса, связанным с другим. Некоторые реализации пула HTTP-соединений могут неправильно обрабатывать файлы cookie сеанса. Например, объединенное соединение может возвращать файл cookie, который не является правильным для транзакции, которую вы пытаетесь использовать.

Управление исчерпанием идентификатора транзакции (циклический переход) в PostgreSQL

Одной из наиболее важных тем, которую необходимо понять при администрировании базы данных PostgresSQL, является концепция идентификаторов транзакций (TXID), которые могут быть исчерпаны, если не отслеживаются должным образом.Однако в этом сообщении блога не будут подробно рассказываться о том, что такое исчерпание TXID на самом деле. Раздел документации Routine Vacuuming , вероятно, один из самых важных для чтения и понимания, поэтому я направлю вас туда. В этом сообщении в блоге будет рассказано о простом способе его отслеживания и о том, что можно сделать, чтобы предотвратить возникновение проблемы.

Мониторинг

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

Следующий запрос — это тот, который мы используем в Crunchy Data в нашем инструменте PGmonitor, чтобы предоставить очень простые точки данных для трендов / предупреждений.

  С max_age AS (
    ВЫБЕРИТЕ 2000000000 как max_old_xid
        , установка AS autovacuum_freeze_max_age
        ИЗ pg_catalog.pg_settings
        ГДЕ name = 'autovacuum_freeze_max_age')
, per_database_stats AS (
    ВЫБЕРИТЕ имя данных
        , m.max_old_xid :: int
        , m.autovacuum_freeze_max_age :: int
        , возраст (d.datfrozenxid) AS old_current_xid
    ИЗ pg_catalog.pg_database d
    JOIN max_age m ON (истина)
    ГДЕ d.datallowconn)
ВЫБЕРИТЕ max (old_current_xid) AS old_current_xid
    , max (ROUND (100 * (old_current_xid / max_old_xid :: float))) AS percent_towards_wraparound
    , max (ROUND (100 * (old_current_xid / autovacuum_freeze_max_age :: float))) AS percent_towards_emergency_autovac
ИЗ per_database_stats  

Метрика percent_towards_wraparound — это действительно критическая метрика, для которой нужно настроить оповещение.Поскольку он использует функцию age () для определения значения TXID, он принимает во внимание, действительно ли они находятся в точке исчерпания, чтобы увидеть, действительно ли циклический переход вызывает реальную проблему. Если когда-либо будет достигнуто исчерпание, база данных будет принудительно завершена, что может привести к неопределенному времени простоя, чтобы его можно было исправить. В этом запросе есть небольшой буфер, поскольку верхняя граница, которую он проверяет (ровно 2 миллиарда), меньше фактического максимального целочисленного значения, которое вызывает исчерпание.Но это достаточно близко, чтобы это предупреждение, достигающее 100%, нужно было немедленно отреагировать.

Метрика percent_towards_emergency_autovac — это дополнительное значение, которое мы рекомендуем отслеживать, особенно для систем, в которых этот мониторинг раньше никогда не проводился (см. Примечания к Недавние преимущества замораживания ниже о том, когда можно снизить или удалить этот приоритет предупреждений). Это отслеживает, чтобы максимальное значение TXID в базе данных достигло autovacuum_freeze_max_age .Это настраиваемое пользователем значение, которое имеет значение по умолчанию 200 миллионов, и когда максимальное значение TXID любой таблицы достигает его, в этой таблице срабатывает автоматическая очистка с более высоким приоритетом. Вы узнаете этот специальный вакуумный сеанс, потому что в pg_stat_activity он будет помечен как (для предотвращения циклического перехода) . Это более высокий приоритет в том смысле, что он будет работать, даже если автоочистка отключена, и если этот вакуум будет отменен вручную, он почти сразу же перезапустится снова. Он также требует некоторых различных внутренних низкоуровневых блокировок, поэтому это может вызвать немного более высокую конкуренцию за эти таблицы в зависимости от того, как они используются во время аварийного вакуума.Если у вас возникнут проблемы с конкуренцией / блокировкой, и они могут быть сужены до аварийного вакуума, являющегося причиной, его совершенно безопасно отменить, чтобы позволить другим вашим транзакциям завершиться. Просто имейте в виду, что он будет перезапускаться до тех пор, пока не будет успешно завершен циклический вакуум или пока не будет запущен ручной вакуум

Для баз данных с высокой скоростью транзакций было бы полезно увеличить autovacuum_freeze_max_age , чтобы избежать частого возникновения аварийного вакуума.Основная проблема, связанная с увеличением этого параметра, заключается в том, что это может увеличить требования к хранилищу в папках pg_xact и pg_commit_ts в каталоге данных. Опять же, прочтите документацию Routine Vacuuming по ссылке выше, чтобы узнать, каковы эти требования к хранилищу при настройке этого параметра. Я часто без особых проблем устанавливал это значение в 1 миллиард, но только когда я уверен, что циклический переход отслеживается и дисковое пространство доступно.

Итак, когда срабатывает одно из этих предупреждений, как это исправить?

Простое исправление

Самый простой (но не обязательно самый быстрый) способ восстановить максимальное значение возраста TXID — это принудительно очистить весь кластер базы данных.И лучший способ сделать этот вакуум в масштабах всего кластера — это двоичная утилита Vacuumdb, поставляемая с PostgreSQL.

  Vacuumdb --all --freeze --jobs = 2 --echo --analyze  

Параметр —all обеспечивает очистку всех баз данных, поскольку TXID является глобальным значением. Параметр —freeze обеспечивает более агрессивный запуск вакуума, чтобы гарантировать, что в этой таблице заморожено как можно больше кортежей (подробности о том, что такое замораживание, см. В Routine Vacuuming ). —jobs = 2 позволяет запускать несколько пылесосов параллельно. Это должно быть установлено настолько высоким, насколько ваша система может обрабатывать, чтобы ускорить процесс, но будьте осторожны, устанавливая его слишком высоким, поскольку это приводит к дополнительному вводу-выводу и более быстрой генерации WAL (увеличению использования диска). —echo просто обеспечивает минимальную обратную связь, так что вы можете увидеть некоторый прогресс. —analyze обеспечивает обновление статистики. Если требуется время, чтобы завершить этот вакуумный запуск, его можно отключить и выполнить как отдельный шаг позже, используя параметр —analyze-only .

Последние преимущества замораживания

Еще одно преимущество варианта —freeze , о котором я упомяну здесь, может заключаться в значительном сокращении генерации IO и WAL во время будущих операций с вакуумом. PostgreSQL 9.6 представил функцию, которая позволяет вакууму пропускать страницу, если все кортежи внутри нее помечены как замороженные. И PG11 еще больше улучшил это для индексов. Так что, если у вас есть много старых таблиц, которые больше не записываются, это делает так, что, когда они действительно нуждаются в очистке по какой-либо причине, это гораздо менее затратная операция.Это также делает предупреждение percent_towards_emergency_autovac меньшим беспокойством, поскольку это не будет такой большой неожиданный всплеск активности. Итак, как только вы настроите все правильно, вы можете считать это предупреждение предупреждением с низким приоритетом или, возможно, даже удалить его и просто беспокоиться о мониторинге самого цикла.

Исправление для таблицы

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

  ВЫБРАТЬ имя данных
    , возраст (datfrozenxid)
    , current_setting ('autovacuum_freeze_max_age')
ИЗ pg_database
ЗАКАЗАТЬ ПО 2 DESC;

  имя_данных | возраст | текущая настройка
----------- + ----------- + -----------------
 postgres | 170604895 | 200000000
 mydb | 169088197 | 200000000
 template0 | 142915024 | 200000000
 template1 | 142914999 | 200000000  

Здесь вы можете увидеть, что как база данных postgres по умолчанию, так и база данных пользователя являются наиболее непосредственной проблемой при приближении к аварийному вакуумированию.К счастью, они далеки от истощения, но вы бы также увидели это здесь, если бы возраст составлял около 2,1 миллиарда. Далее нам нужно подключиться к соответствующей базе данных и посмотреть состояние самих таблиц.

  postgres = # ВЫБРАТЬ c.oid :: regclass
    , возраст (c.relfrozenxid)
    , pg_size_pretty (pg_total_relation_size (c.oid))
ИЗ pg_class c
ПРИСОЕДИНЯЙТЕСЬ к пространству имен pg n на c.relnamespace = n.oid
ГДЕ relkind IN ('r', 't', 'm')
И n.nspname НЕ В ('pg_toast')
ORDER BY 2 DESC LIMIT 100;

                    oid | возраст | pg_size_pretty
-------------------------------------------- + ----- ------ + ----------------
 pg_proc | 170606208 | 936 КБ
 pg_description | 170606208 | 480 кБ
 pg_depend | 109192353 | 1336 КБ
 pg_attribute | 109192353 | 728 кБ
 pg_shdepend | 89774141 | 2976 МБ
 pg_db_role_setting | 77594841 | 16 кБ
 pg_tablespace | 77594841 | 72 кБ
 pg_pltemplate | 77594841 | 56 кБ
 pg_auth_members | 77594841 | 16 кБ
 pg_authid | 77594841 | 72 кБ
[...]  

Здесь вы можете видеть, что есть только несколько таблиц с большим возрастом, но в более реалистичном примере таблицы вы, вероятно, увидите результаты, близкие к пределу в 100 строк с более высоким возрастом. Далее мы хотим очистить только эти конкретные таблицы. Если это всего лишь несколько таблиц, вводить команды VACUUM вручную не составляет большого труда. Но если у вас их более 100, это может быть утомительно и подвержено опечаткам. Таким образом, мы можем использовать некоторую конкатенацию строк вместе с некоторыми командами psql для генерации некоторых операторов и помещения их в файл для автоматического запуска для нас.

  \ t \ o /tmp/vacuum.sql select 'вакуум заморозить подробный анализ' || oid :: regclass || ';' из pg_class, где relkind in ('r', 't', 'm'), упорядоченный по возрасту (relfrozenxid) desc limit 100; \ o \ t \ установить ECHO все \ i /tmp/vacuum.sql 

Я настоятельно рекомендую проверить документацию psql, чтобы узнать, что делают все эти команды с косой чертой, но в основном то, что они делают:

• Отключить заголовки столбцов
• Отправлять весь вывод после этого в файл /tmp/vacuum.sql
• Сгенерировать не более 100 операторов VACUUM для каждой таблицы, возвращаемой из запроса
• Отключить вывод файлов и снова включить заголовки столбцов
• Выводить каждую команду, запущенную после этого
• Поочередно запускайте операторы вакуума, содержащиеся в вакууме.sql файл

Даже если нужно очистить более 100 таблиц, я обычно делаю это партиями по 100, чтобы дать генерации IO и WAL время успокоиться. Обычно я пытаюсь получить максимальный XID для любой таблицы, по крайней мере, до 50% от autovacuum_freeze_max_age , обычно даже до 30-40%, если это не будет слишком большой проблемой. Также обратите внимание, что вам нужно будет войти в каждую базу данных, чтобы выполнить эти команды VACUUM. Вы можете войти в template1 , чтобы исправить это, если хотите, но вы не сможете войти в template0 . template0 можно спокойно проигнорировать и дать запустить autovacuum_freeze_max_age , так как он очень мал и завершится почти мгновенно. Если вам интересно, что это за базы данных шаблонов, проверьте документацию.

Заключение

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