Предлагаю ознакомиться с расшифровкой доклада начала 2019 года Андрея Бородина "Резервные копии с WAL-G. Что там в 2019?"
Всем привет! Меня зовут Андрей Бородин. Я разработчик в Яндексе. Я интересуюсь PostgreSQL с 2016-го года, после того, как я поговорил с разработчиками, и они сказали, что тут все просто – ты берешь исходный код и собираешь, и все получится. И с тех пор не могу остановиться – пишу всякие разные штуки.
ਮੈਂ ਜਿਸ ਚੀਜ਼ 'ਤੇ ਕੰਮ ਕਰ ਰਿਹਾ ਹਾਂ ਉਨ੍ਹਾਂ ਵਿੱਚੋਂ ਇੱਕ ਬੈਕਅੱਪ ਸਿਸਟਮ ਹੈ। . Вообще, в Яндексе мы занимаемся системами резервного копирования в PostgreSQL очень давно. И можно найти в интернете серию из шести докладов о том, как мы делаем системы резервного копирования. И с каждым годом они немного эволюционируют, немного развиваются, становятся более надежными.
Но сегодня доклад посвящен не только тому, что мы сделали, но и о том, как все просто и о том, что есть. Кто из вас уже смотрел мои доклады про WAL-G? Это хорошо, что довольно много людей не смотрели, потому что я начну с самой простой вещи.
Если вдруг у вас есть кластер PostgreSQL, а я думаю у каждого он есть по парочке с собой, и вдруг еще нет системы резервного копирования, то нужно получить любое S3 хранилище или Google Cloud совместимое хранилище.
ਉਦਾਹਰਨ ਲਈ, ਤੁਸੀਂ ਸਾਡੇ ਸਟੈਂਡ 'ਤੇ ਆ ਸਕਦੇ ਹੋ ਅਤੇ Yandex ਵਸਤੂ ਸਟੋਰੇਜ਼ ਲਈ ਇੱਕ ਪ੍ਰਚਾਰ ਕੋਡ ਲੈ ਸਕਦੇ ਹੋ, ਜੋ ਕਿ S3 ਅਨੁਕੂਲ ਹੈ।
После чего создать Bucket. Это просто контейнер для информации.
Создать сервисного пользователя.
Cоздать сервисному пользователю ключ доступа aws-s3-key.
Скачать последний стабильный релиз WAL-G.
ਸਾਡੀਆਂ ਪ੍ਰੀ-ਰਿਲੀਜ਼ ਰੀਲੀਜ਼ਾਂ ਤੋਂ ਕਿਵੇਂ ਵੱਖਰੀਆਂ ਹਨ? ਮੈਨੂੰ ਅਕਸਰ ਜਲਦੀ ਰਿਲੀਜ਼ ਕਰਨ ਲਈ ਕਿਹਾ ਜਾਂਦਾ ਹੈ। ਅਤੇ ਜੇ ਸੰਸਕਰਣ ਵਿੱਚ ਕਾਫ਼ੀ ਸਮੇਂ ਲਈ ਕੋਈ ਬੱਗ ਨਹੀਂ ਹੈ, ਉਦਾਹਰਨ ਲਈ, ਇੱਕ ਮਹੀਨਾ, ਤਾਂ ਮੈਂ ਇਸਨੂੰ ਜਾਰੀ ਕਰਦਾ ਹਾਂ. ਇੱਥੇ ਨਵੰਬਰ ਤੋਂ ਇਹ ਰਿਲੀਜ਼ ਹੈ। ਅਤੇ ਇਸਦਾ ਮਤਲਬ ਇਹ ਹੈ ਕਿ ਹਰ ਮਹੀਨੇ ਸਾਨੂੰ ਕੁਝ ਕਿਸਮ ਦਾ ਬੱਗ ਮਿਲਦਾ ਹੈ, ਆਮ ਤੌਰ 'ਤੇ ਗੈਰ-ਨਾਜ਼ੁਕ ਕਾਰਜਸ਼ੀਲਤਾ ਵਿੱਚ, ਪਰ ਅਸੀਂ ਅਜੇ ਤੱਕ ਕੋਈ ਰੀਲੀਜ਼ ਨਹੀਂ ਕੀਤੀ ਹੈ। ਪਿਛਲਾ ਸੰਸਕਰਣ ਸਿਰਫ ਨਵੰਬਰ ਦਾ ਹੈ। ਇਸ ਵਿੱਚ ਸਾਡੇ ਲਈ ਕੋਈ ਵੀ ਬੱਗ ਨਹੀਂ ਹਨ, ਜਿਵੇਂ ਕਿ ਪ੍ਰੋਜੈਕਟ ਅੱਗੇ ਵਧਦੇ ਹੋਏ ਬੱਗ ਸ਼ਾਮਲ ਕੀਤੇ ਗਏ ਸਨ।
ਇੱਕ ਵਾਰ ਜਦੋਂ ਤੁਸੀਂ WAL-G ਨੂੰ ਡਾਉਨਲੋਡ ਕਰ ਲੈਂਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਵਾਤਾਵਰਣ ਵੇਰੀਏਬਲ ਵਿੱਚ ਪਾਸ ਕਰਦੇ ਹੋਏ ਇੱਕ ਸਧਾਰਨ "ਬੈਕਅੱਪ ਸੂਚੀ" ਕਮਾਂਡ ਚਲਾ ਸਕਦੇ ਹੋ। ਅਤੇ ਇਹ ਆਬਜੈਕਟ ਸਟੋਰੇਜ ਨਾਲ ਜੁੜ ਜਾਵੇਗਾ ਅਤੇ ਤੁਹਾਨੂੰ ਦੱਸੇਗਾ ਕਿ ਤੁਹਾਡੇ ਕੋਲ ਕਿਹੜੇ ਬੈਕਅੱਪ ਹਨ। ਪਹਿਲਾਂ, ਬੇਸ਼ੱਕ, ਤੁਹਾਡੇ ਕੋਲ ਬੈਕਅੱਪ ਨਹੀਂ ਹੋਣੇ ਚਾਹੀਦੇ। ਇਸ ਸਲਾਈਡ ਦਾ ਬਿੰਦੂ ਇਹ ਦਰਸਾਉਣਾ ਹੈ ਕਿ ਹਰ ਚੀਜ਼ ਕਾਫ਼ੀ ਸਧਾਰਨ ਹੈ. ਇਹ ਇੱਕ ਕੰਸੋਲ ਕਮਾਂਡ ਹੈ ਜੋ ਵਾਤਾਵਰਣ ਵੇਰੀਏਬਲ ਨੂੰ ਸਵੀਕਾਰ ਕਰਦੀ ਹੈ ਅਤੇ ਉਪ-ਕਮਾਂਡਾਂ ਨੂੰ ਚਲਾਉਂਦੀ ਹੈ।
После этого вы можете сделать свой первый бэкап. Сказать в WAL-G «backup-push» и указать в WAL-G расположение pgdata вашего кластера. И, скорее всего, PostgreSQL вам скажет, если у вас нет еще системы резервного копирования, что вам нужно включить «archive-mode».
Это означает, что нужно пойти в настройки и включить «archive_mode = on» и добавить «archive_command», который точно также является подкомандой в WAL-G. Но в эту тему люди часто почему-то используют бар-скрипты и делают обвязку вокруг WAL-G. Пожалуйста, не делайте так. Используйте функциональность, которая есть в WAL-G. Если вам чего-то не хватает, то пишите в . WAL-G ਮੰਨਦਾ ਹੈ ਕਿ ਇਹ ਇੱਕੋ ਇੱਕ ਪ੍ਰੋਗਰਾਮ ਹੈ ਜੋ archive_command ਵਿੱਚ ਚੱਲਦਾ ਹੈ।
ਅਸੀਂ WAL-G ਦੀ ਵਰਤੋਂ ਮੁੱਖ ਤੌਰ 'ਤੇ Yandex ਡਾਟਾਬੇਸ ਪ੍ਰਬੰਧਨ ਵਿੱਚ ਇੱਕ ਉੱਚ ਉਪਲਬਧਤਾ ਕਲੱਸਟਰ ਬਣਾਉਣ ਲਈ ਕਰਦੇ ਹਾਂ।
ਅਤੇ ਇਹ ਆਮ ਤੌਰ 'ਤੇ ਇੱਕ ਮਾਸਟਰ ਅਤੇ ਕਈ ਪ੍ਰਤੀਕ੍ਰਿਤੀਆਂ ਦੇ ਟੋਪੋਲੋਜੀ ਵਿੱਚ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ। ਉਸੇ ਸਮੇਂ, ਇਹ ਯਾਂਡੇਕਸ ਆਬਜੈਕਟ ਸਟੋਰੇਜ ਵਿੱਚ ਇੱਕ ਬੈਕਅੱਪ ਕਾਪੀ ਬਣਾਉਂਦਾ ਹੈ.
Самые частые сценарии – это создание копий кластера с использованием Point in time recovery. Но в этом случае для нас не так важна производительность системы резервного копирования. Нам просто нужно налить новый кластер из бэкапа.
Обычно производительность системы резервного копирования нам нужна при добавлении нового узла. Почему это важно? Обычно люди добавляют новый узел в кластер, потому что существующий кластер не справляется с читающей нагрузкой. Им нужно добавить новую реплику. Если добавим нагрузку от pg_basebackup на Мастер, то Мастер может сложиться. Поэтому нам очень важно было, чтобы мы могли быстро налить новый узел из архива, создавая минимальную нагрузку на Мастере.
И другая схожая ситуация. Это необходимость переналивки старого Мастера после переключения Мастера кластера из Дата-центра, с которым была потеряна связность.
- ਨਤੀਜੇ ਵਜੋਂ, ਕਾਪੀ ਸਿਸਟਮ ਲਈ ਲੋੜਾਂ ਨੂੰ ਤਿਆਰ ਕਰਦੇ ਸਮੇਂ, ਅਸੀਂ ਮਹਿਸੂਸ ਕੀਤਾ ਕਿ ਕਲਾਉਡ ਵਿੱਚ ਕੰਮ ਕਰਦੇ ਸਮੇਂ pg_basebackup ਸਾਡੇ ਲਈ ਢੁਕਵਾਂ ਨਹੀਂ ਹੈ।
- Мы хотели иметь возможность сжимать наши данные. Но сжатие данных предоставит почти любая система резервного копирования, кроме того, что есть в коробке.
- ਅਸੀਂ ਹਰ ਚੀਜ਼ ਨੂੰ ਸਮਾਨ ਬਣਾਉਣਾ ਚਾਹੁੰਦੇ ਸੀ ਕਿਉਂਕਿ ਕਲਾਉਡ ਵਿੱਚ ਇੱਕ ਉਪਭੋਗਤਾ ਵੱਡੀ ਗਿਣਤੀ ਵਿੱਚ ਪ੍ਰੋਸੈਸਰ ਕੋਰ ਖਰੀਦਦਾ ਹੈ। ਪਰ ਜੇ ਸਾਡੇ ਕੋਲ ਕੁਝ ਸੰਚਾਲਨ ਵਿੱਚ ਸਮਾਨਤਾ ਨਹੀਂ ਹੈ, ਤਾਂ ਵੱਡੀ ਗਿਣਤੀ ਵਿੱਚ ਕੋਰ ਬੇਕਾਰ ਹੋ ਜਾਂਦੇ ਹਨ.
- Нам необходимо шифрование, потому что зачастую это не наши данные и нельзя их хранить в открытом виде. Кстати, именно с шифрования начался наш contribution в WAL-G. Мы дописали шифрование в WAL-G, после чего нас спросили: «Может быть, кто-то из нас займется развитием проекта?». И с тех пор год с лишним я работаю с WAL-G.
- Также нам необходим был троттлинг ресурсов, потому что со временем эксплуатации облака мы выяснили, что иногда у людей бывает важная продуктовая нагрузка ночью и этой нагрузке нельзя мешать. Поэтому мы дописали троттлинг ресурсов.
- А также листинг и управление.
- И верификация.
Мы рассмотрели много различных инструментов. К счастью, у нас огромный выбор в PostgreSQL. И везде нам чего-то не хватало, какой-то одной небольшой функции, какой-то одной небольшой особенности.
И рассмотрев существующие системы мы пришли к том, что будем развивать WAL-G. Он тогда был новым проектом. Довольно легко было повлиять на развитие в сторону именно облачной инфраструктуры системы резервного копирования.
ਮੁੱਖ ਵਿਚਾਰਧਾਰਾ ਜਿਸਦਾ ਅਸੀਂ ਪਾਲਣ ਕਰਦੇ ਹਾਂ ਉਹ ਹੈ ਕਿ WAL-G ਬਾਲਲਾਇਕ ਵਾਂਗ ਸਧਾਰਨ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ।
В WAL-G 4 команды. Это:
ਵਾਲ-ਪੁਸ਼ - ਸ਼ਾਫਟ ਨੂੰ ਆਰਕਾਈਵ ਕਰੋ।
WAL-FETCH – получить вал.
BACKUP-PUSH – сделать бэкап.
BACKUP-FETCH – получить бэкап из системы резервного копирования.
ਵਾਸਤਵ ਵਿੱਚ, WAL-G ਕੋਲ ਇਹਨਾਂ ਬੈਕਅੱਪਾਂ ਦਾ ਪ੍ਰਬੰਧਨ ਵੀ ਹੈ, ਜਿਵੇਂ ਕਿ ਇਤਿਹਾਸ ਵਿੱਚ ਰਿਕਾਰਡਾਂ ਅਤੇ ਬੈਕਅੱਪਾਂ ਨੂੰ ਸੂਚੀਬੱਧ ਕਰਨਾ ਅਤੇ ਮਿਟਾਉਣਾ ਜਿਨ੍ਹਾਂ ਦੀ ਇਸ ਸਮੇਂ ਲੋੜ ਨਹੀਂ ਹੈ।
Одна из важных для нас функция – это функция создания дельта-копий.
ਡੈਲਟਾ ਕਾਪੀਆਂ ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਅਸੀਂ ਪੂਰੇ ਕਲੱਸਟਰ ਦਾ ਪੂਰਾ ਬੈਕਅੱਪ ਨਹੀਂ ਬਣਾਉਂਦੇ, ਸਗੋਂ ਕਲੱਸਟਰ ਵਿੱਚ ਬਦਲੀਆਂ ਹੋਈਆਂ ਫਾਈਲਾਂ ਦੇ ਸਿਰਫ਼ ਬਦਲੇ ਹੋਏ ਪੰਨੇ ਹੀ ਬਣਾਉਂਦੇ ਹਾਂ। ਇਹ ਲਗਦਾ ਹੈ ਕਿ ਕਾਰਜਸ਼ੀਲ ਤੌਰ 'ਤੇ ਇਹ WAL ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਮੁੜ ਪ੍ਰਾਪਤ ਕਰਨ ਦੀ ਯੋਗਤਾ ਦੇ ਸਮਾਨ ਹੈ। ਪਰ ਅਸੀਂ ਸਮਾਨਾਂਤਰ ਵਿੱਚ ਇੱਕ WAL ਸਿੰਗਲ-ਥਰਿੱਡਡ ਡੈਲਟਾ ਬੈਕਅੱਪ ਰੋਲ ਕਰ ਸਕਦੇ ਹਾਂ। ਇਸ ਅਨੁਸਾਰ, ਜਦੋਂ ਸਾਡੇ ਕੋਲ ਸ਼ਨੀਵਾਰ ਨੂੰ ਬੇਸਿਕ ਬੈਕਅੱਪ ਹੁੰਦਾ ਹੈ, ਰੋਜ਼ਾਨਾ ਡੈਲਟਾ ਬੈਕਅੱਪ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਵੀਰਵਾਰ ਨੂੰ ਅਸੀਂ ਅਸਫਲ ਹੋ ਜਾਂਦੇ ਹਾਂ, ਤਾਂ ਸਾਨੂੰ 4 ਡੈਲਟਾ ਬੈਕਅੱਪ ਅਤੇ 10 ਘੰਟੇ ਦੇ WAL ਰੋਲ ਕਰਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਇਹ ਲਗਭਗ ਇੱਕੋ ਸਮਾਂ ਲਵੇਗਾ ਕਿਉਂਕਿ ਡੈਲਟਾ ਬੈਕਅੱਪ ਸਮਾਨਾਂਤਰ ਵਿੱਚ ਰੋਲ ਕਰਦੇ ਹਨ।
LSN-based дельты – это означает, что при создании резервной копии, нам необходимо будет сочетать каждую страницу и сверить ее LSN с LSN предыдущего бэкапа для того, чтобы понять, что она изменилась. Любая страница, которая потенциально может содержать измененные данные, должна присутствовать в дельта-бэкапе.
Как я говорил, довольно много внимания было уделено параллелизму.
ਪਰ PostgreSQL ਵਿੱਚ ਪੁਰਾਲੇਖ API ਇਕਸਾਰ ਹੈ। PostgreSQL ਇੱਕ WAL ਫਾਈਲ ਨੂੰ ਆਰਕਾਈਵ ਕਰਦਾ ਹੈ ਅਤੇ ਇਸਨੂੰ ਰੀਸਟੋਰ ਕਰਨ ਵੇਲੇ ਇੱਕ WAL ਫਾਈਲ ਦੀ ਬੇਨਤੀ ਕਰਦਾ ਹੈ। ਪਰ ਜਦੋਂ ਡੇਟਾਬੇਸ "WAL-FETCH" ਕਮਾਂਡ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਇੱਕ WAL ਫਾਈਲ ਦੀ ਬੇਨਤੀ ਕਰਦਾ ਹੈ, ਤਾਂ ਅਸੀਂ "WAL-PREFETCH" ਕਮਾਂਡ ਨੂੰ ਕਾਲ ਕਰਦੇ ਹਾਂ, ਜੋ ਸਮਾਨਾਂਤਰ ਵਿੱਚ ਆਬਜੈਕਟ ਸਟੋਰ ਤੋਂ ਡੇਟਾ ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ ਅਗਲੀਆਂ 8 ਫਾਈਲਾਂ ਨੂੰ ਤਿਆਰ ਕਰਦਾ ਹੈ।
А когда база данных просит нас заархивировать один вал, мы заглядываем в archive_status и смотрим нет ли других WAL-файлов. И пытаемся закачивать WAL тоже параллельно. Это дает существенный выигрыш по производительности, существенно сокращает расстояние в количестве незаархивированных WAL. Многие разработчики систем резервного копирования считают, что это такая рискованная система, потому что мы опираемся на наши знания внутренностей кода, который не является API PostgreSQL. PostgreSQL не гарантирует наличие нам папки archive_status и не гарантирует семантику, наличие там сигналов готовности у WAL-файлов. Тем не менее мы изучаем исходный код, видим, что это так и стараемся это эксплуатировать. И контролируем в каком направлении развивается PostgreSQL, если вдруг этот механизм будет нарушен, то мы прекратим его использовать.
В чистом виде LSN-based WAL-дельта требует считывать любого файла кластера, у которого mode-time в файловой системе изменился с предыдущего бэкапа. Мы долго с этим жили, почти год. И в итоге пришли к тому, что у нас есть WAL-дельты.
ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਹਰ ਵਾਰ ਜਦੋਂ ਅਸੀਂ ਮਾਸਟਰ 'ਤੇ WAL ਨੂੰ ਆਰਕਾਈਵ ਕਰਦੇ ਹਾਂ, ਅਸੀਂ ਨਾ ਸਿਰਫ਼ ਇਸਨੂੰ ਸੰਕੁਚਿਤ ਕਰਦੇ ਹਾਂ, ਇਸਨੂੰ ਐਨਕ੍ਰਿਪਟ ਕਰਦੇ ਹਾਂ ਅਤੇ ਇਸਨੂੰ ਨੈੱਟਵਰਕ 'ਤੇ ਭੇਜਦੇ ਹਾਂ, ਪਰ ਅਸੀਂ ਇਸਨੂੰ ਉਸੇ ਸਮੇਂ ਪੜ੍ਹਦੇ ਹਾਂ। ਅਸੀਂ ਇਸ ਵਿਚਲੇ ਰਿਕਾਰਡਾਂ ਦਾ ਵਿਸ਼ਲੇਸ਼ਣ ਕਰਦੇ ਹਾਂ ਅਤੇ ਪੜ੍ਹਦੇ ਹਾਂ। ਅਸੀਂ ਸਮਝਦੇ ਹਾਂ ਕਿ ਕਿਹੜੇ ਬਲਾਕ ਬਦਲ ਗਏ ਹਨ ਅਤੇ ਡੈਲਟਾ ਫਾਈਲਾਂ ਨੂੰ ਇਕੱਠਾ ਕਰਦੇ ਹਾਂ।
Delta-файл описывает некоторый диапазон WAL-файлов, описывает информацию о том, какие блоки были изменены в этом диапазоне WAL. И затем эти delta-файлы тоже архивируются.
Тут мы столкнулись с тем, что мы достаточно все быстро распараллелили, но нельзя параллельно читать последовательную историю, потому что в определенном сегменте, нам может встретиться конец предыдущего рекорда WAL, который пока нам не с чем состыковать, потому что параллельное чтение привело к тому, что мы сначала анализируем будущее, у которого нет еще прошлого.
В итоге нам пришлось непонятные куски складывать в _delta_partial файлы. В итоге, когда мы вернемся к прошлому, мы склеим куски WAL рекорда в один, после этого его распарсим и поймем, что в нем менялось.
ਜੇ ਸਾਡੇ ਸ਼ਾਫਟ ਪਾਰਸਿੰਗ ਦੇ ਇਤਿਹਾਸ ਵਿੱਚ ਘੱਟੋ ਘੱਟ ਇੱਕ ਬਿੰਦੂ ਹੈ ਜਿੱਥੇ ਅਸੀਂ ਇਹ ਨਹੀਂ ਸਮਝਦੇ ਕਿ ਕੀ ਹੋ ਰਿਹਾ ਸੀ, ਤਾਂ, ਇਸਦੇ ਅਨੁਸਾਰ, ਅਗਲੇ ਬੈਕਅੱਪ ਦੇ ਦੌਰਾਨ ਸਾਨੂੰ ਪੂਰੇ ਕਲੱਸਟਰ ਨੂੰ ਦੁਬਾਰਾ ਪੜ੍ਹਨ ਲਈ ਮਜ਼ਬੂਰ ਕੀਤਾ ਜਾਵੇਗਾ, ਜਿਵੇਂ ਕਿ ਅਸੀਂ ਇੱਕ ਨਿਯਮਤ LSN ਨਾਲ ਕੀਤਾ ਸੀ. -ਅਧਾਰਿਤ ਡੈਲਟਾ.
ਨਤੀਜੇ ਵਜੋਂ, ਸਾਡੇ ਸਾਰੇ ਦੁੱਖ ਇਸ ਤੱਥ ਵੱਲ ਲੈ ਗਏ ਕਿ ਅਸੀਂ WAL-G ਪਾਰਸਿੰਗ ਲਾਇਬ੍ਰੇਰੀ ਨੂੰ ਖੋਲ੍ਹਿਆ। ਜਿੱਥੋਂ ਤੱਕ ਮੈਨੂੰ ਪਤਾ ਹੈ, ਅਜੇ ਤੱਕ ਕੋਈ ਵੀ ਇਸਦੀ ਵਰਤੋਂ ਨਹੀਂ ਕਰ ਰਿਹਾ ਹੈ, ਪਰ ਜੇ ਕੋਈ ਇਸਨੂੰ ਲਿਖਣਾ ਅਤੇ ਵਰਤਣਾ ਚਾਹੁੰਦਾ ਹੈ, ਤਾਂ ਇਹ ਜਨਤਕ ਖੇਤਰ ਵਿੱਚ ਹੈ. (ਅੱਪਡੇਟ ਕੀਤਾ ਲਿੰਕ )
ਨਤੀਜੇ ਵਜੋਂ, ਸਾਰੀ ਜਾਣਕਾਰੀ ਦਾ ਪ੍ਰਵਾਹ ਕਾਫ਼ੀ ਗੁੰਝਲਦਾਰ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ। ਸਾਡਾ ਮਾਸਟਰ ਸ਼ਾਫਟ ਨੂੰ ਆਰਕਾਈਵ ਕਰਦਾ ਹੈ ਅਤੇ ਡੈਲਟਾ ਫਾਈਲਾਂ ਨੂੰ ਆਰਕਾਈਵ ਕਰਦਾ ਹੈ। ਅਤੇ ਬੈਕਅੱਪ ਕਾਪੀ ਬਣਾਉਣ ਵਾਲੀ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਨੂੰ ਬੈਕਅੱਪ ਦੇ ਵਿਚਕਾਰ ਲੰਘੇ ਸਮੇਂ ਦੌਰਾਨ ਡੈਲਟਾ ਫਾਈਲਾਂ ਪ੍ਰਾਪਤ ਕਰਨੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ। ਇਸ ਸਥਿਤੀ ਵਿੱਚ, ਇਤਿਹਾਸ ਦੇ ਭਾਗਾਂ ਨੂੰ ਬਲਕ ਵਿੱਚ ਜੋੜਨ ਅਤੇ ਪਾਰਸ ਕਰਨ ਦੀ ਲੋੜ ਹੋਵੇਗੀ, ਕਿਉਂਕਿ ਪੂਰਾ ਇਤਿਹਾਸ ਵੱਡੇ ਹਿੱਸਿਆਂ ਵਿੱਚ ਫਿੱਟ ਨਹੀਂ ਹੁੰਦਾ। ਅਤੇ ਇਸ ਤੋਂ ਬਾਅਦ ਹੀ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਪੂਰੇ ਡੈਲਟਾ ਬੈਕਅੱਪ ਨੂੰ ਆਰਕਾਈਵ ਕਰ ਸਕਦੀ ਹੈ।
ਗ੍ਰਾਫ 'ਤੇ ਸਭ ਕੁਝ ਬਹੁਤ ਸਰਲ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ. ਇਹ ਸਾਡੇ ਅਸਲ ਕਲੱਸਟਰਾਂ ਵਿੱਚੋਂ ਇੱਕ ਤੋਂ ਇੱਕ ਡਾਊਨਲੋਡ ਹੈ। ਸਾਡੇ ਕੋਲ LSN-ਅਧਾਰਿਤ, ਇੱਕ ਦਿਨ ਵਿੱਚ ਬਣਾਇਆ ਗਿਆ ਹੈ। ਅਤੇ ਅਸੀਂ ਦੇਖਦੇ ਹਾਂ ਕਿ LSN- ਅਧਾਰਿਤ ਡੈਲਟਾ ਬੈਕਅੱਪ ਸਵੇਰੇ ਤਿੰਨ ਵਜੇ ਤੋਂ ਸਵੇਰੇ ਪੰਜ ਵਜੇ ਤੱਕ ਚੱਲ ਰਿਹਾ ਸੀ. ਇਹ ਪ੍ਰੋਸੈਸਰ ਕੋਰ ਦੀ ਗਿਣਤੀ ਵਿੱਚ ਲੋਡ ਹੈ. WAL-delta ਨੇ ਸਾਨੂੰ ਇੱਥੇ ਲਗਭਗ 20 ਮਿੰਟ ਲਏ। ਭਾਵ, ਇਹ ਕਾਫ਼ੀ ਤੇਜ਼ ਹੋ ਗਿਆ, ਪਰ ਉਸੇ ਸਮੇਂ ਨੈੱਟਵਰਕ ਉੱਤੇ ਇੱਕ ਹੋਰ ਤੀਬਰ ਐਕਸਚੇਂਜ ਸੀ।
ਕਿਉਂਕਿ ਸਾਡੇ ਕੋਲ ਡੇਟਾਬੇਸ ਦੇ ਇਤਿਹਾਸ ਵਿੱਚ ਕਿਹੜੇ ਬਲਾਕਾਂ ਅਤੇ ਕਿਹੜੇ ਸਮੇਂ ਵਿੱਚ ਤਬਦੀਲੀਆਂ ਹੋਈਆਂ ਇਸ ਬਾਰੇ ਜਾਣਕਾਰੀ ਹੈ, ਅਸੀਂ ਹੋਰ ਅੱਗੇ ਜਾ ਕੇ ਕਾਰਜਸ਼ੀਲਤਾ ਨੂੰ ਏਕੀਕ੍ਰਿਤ ਕਰਨ ਦਾ ਫੈਸਲਾ ਕੀਤਾ - ਇੱਕ PostgreSQL ਐਕਸਟੈਂਸ਼ਨ ਜਿਸਨੂੰ "pg_prefaulter" ਕਿਹਾ ਜਾਂਦਾ ਹੈ।
Это означает, что, когда база на Stand-by выполняет restore command, она говорит WAL-G принести следующий WAL-файл. Мы понимаем примерно, к каким блокам данных в ближайшее время процесс восстановления WAL будет обращаться и инициируем операцию чтения на эти блоки. Сделано это для того, чтобы повысить производительность SSD контроллеров. Потому что накат WAL дойдет до страницы, которую нужно поменять. Эта страница находится на диске и отсутствует в page-кэше. И он синхронно будет ждать, когда эта страница приедет. Но рядом стоит WAL-G, который знает о том, что в ближайшее несколько сотен мегабайт WAL нам понадобятся определенные страницы и параллельно начинает их прогревать. Инициирует множество обращений к диску для того, чтобы они выполнялись параллельно. Это хорошо работает на SSD-дисках, но, к сожалению, это абсолютно не применимо для жесткого диска, потому что мы ему только мешаем своими подсказками.
Это то, что есть в коде сейчас.
Есть фичи, которые мы бы хотели дописать.
ਇਹ ਤਸਵੀਰ ਦਰਸਾਉਂਦੀ ਹੈ ਕਿ WAL-delta ਮੁਕਾਬਲਤਨ ਘੱਟ ਸਮਾਂ ਲੈਂਦਾ ਹੈ। ਅਤੇ ਇਹ ਦਿਨ ਦੇ ਦੌਰਾਨ ਡੇਟਾਬੇਸ ਵਿੱਚ ਆਈਆਂ ਤਬਦੀਲੀਆਂ ਨੂੰ ਪੜ੍ਹ ਰਿਹਾ ਹੈ। ਅਸੀਂ ਸਿਰਫ ਰਾਤ ਨੂੰ ਹੀ ਨਹੀਂ WAL-delta ਕਰ ਸਕਦੇ ਹਾਂ, ਕਿਉਂਕਿ ਇਹ ਹੁਣ ਲੋਡ ਦਾ ਮਹੱਤਵਪੂਰਨ ਸਰੋਤ ਨਹੀਂ ਹੈ। ਅਸੀਂ WAL-delta ਨੂੰ ਹਰ ਮਿੰਟ ਪੜ੍ਹ ਸਕਦੇ ਹਾਂ ਕਿਉਂਕਿ ਇਹ ਸਸਤਾ ਹੈ। ਇੱਕ ਮਿੰਟ ਵਿੱਚ ਅਸੀਂ ਕਲੱਸਟਰ ਵਿੱਚ ਆਈਆਂ ਸਾਰੀਆਂ ਤਬਦੀਲੀਆਂ ਨੂੰ ਸਕੈਨ ਕਰ ਸਕਦੇ ਹਾਂ। ਅਤੇ ਇਸ ਨੂੰ "ਤਤਕਾਲ ਵਾਲ-ਡੈਲਟਾ" ਕਿਹਾ ਜਾ ਸਕਦਾ ਹੈ।
Суть в том, чтобы, когда мы восстанавливаем кластер, уменьшить количество историй, которые нам придется накатить последовательно. Т. е. количество WAL, которое накатывается PostgreSQL должно быть сокращено, потому что это занимает существенное время.
Но это не все. Если мы знаем, что какой-то блок будет изменен до точки консистентности бэкапа, мы можем его не менять в прошлом. Т. е. сейчас у нас пофайловая оптимизация наката WAL-delta. Это означает, что если, например, во вторник какая-то таблица была целиком удалена или какие-то файлы были удалены целиком из таблицы, то при накате delta в понедельник и восстановления субботнего pg_basebackup, мы эти данные даже создавать не будем.
Мы хотим эту технологию распространить на страничный уровень. Т. е. если какая-то часть файла меняется в понедельник, но при этом будет перезаписана в среду, то при восстановлении на точку в четверг, нам не нужно первые несколько версий страниц записывать на диск.
Но это пока идея, которая активно обсуждается у нас внутри, но до кода пока еще не дошло.
Еще одну фичу мы хотим сделать в WAL-G. Мы хотим сделать расширяемость, потому что нам нужно поддерживать разные базы данных и хотелось бы иметь возможность одинаково подходить к управлению бэкапами. Но проблема в том, что API MySQL отличаются радикально. У MySQL PITR основан не на физическом WAL-логе, а на binlog. И у нас нет системы архивации в MySQL, которая бы сказала какой-то внешней системе, что вот этот binlog закончен и нужно его заархивировать. Нам нужно где-то в cron стоять с базой и проверять – а нет ли чего-то готового?
ਅਤੇ ਇਸੇ ਤਰ੍ਹਾਂ, ਇੱਕ MySQL ਰੀਸਟੋਰ ਦੇ ਦੌਰਾਨ, ਕੋਈ ਰੀਸਟੋਰ ਕਮਾਂਡ ਨਹੀਂ ਹੈ ਜੋ ਸਿਸਟਮ ਨੂੰ ਦੱਸ ਸਕੇ ਕਿ ਮੈਨੂੰ ਅਜਿਹੀਆਂ ਅਤੇ ਅਜਿਹੀਆਂ ਫਾਈਲਾਂ ਦੀ ਲੋੜ ਹੈ। ਆਪਣੇ ਕਲੱਸਟਰ ਨੂੰ ਦੁਬਾਰਾ ਬਣਾਉਣਾ ਸ਼ੁਰੂ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ, ਤੁਹਾਨੂੰ ਇਹ ਜਾਣਨ ਦੀ ਲੋੜ ਹੈ ਕਿ ਤੁਹਾਨੂੰ ਕਿਹੜੀਆਂ ਫ਼ਾਈਲਾਂ ਦੀ ਲੋੜ ਪਵੇਗੀ। ਤੁਹਾਨੂੰ ਖੁਦ ਅੰਦਾਜ਼ਾ ਲਗਾਉਣ ਦੀ ਜ਼ਰੂਰਤ ਹੈ ਕਿ ਤੁਹਾਨੂੰ ਕਿਹੜੀਆਂ ਫਾਈਲਾਂ ਦੀ ਜ਼ਰੂਰਤ ਹੋਏਗੀ. ਪਰ ਇਨ੍ਹਾਂ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਕਿਸੇ ਤਰ੍ਹਾਂ ਦੂਰ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ। (ਸਪਸ਼ਟੀਕਰਨ: MySQL ਪਹਿਲਾਂ ਹੀ ਸਮਰਥਿਤ ਹੈ)
ਰਿਪੋਰਟ ਵਿੱਚ, ਮੈਂ ਉਹਨਾਂ ਮਾਮਲਿਆਂ ਬਾਰੇ ਵੀ ਗੱਲ ਕਰਨਾ ਚਾਹੁੰਦਾ ਸੀ ਜਦੋਂ WAL-G ਤੁਹਾਡੇ ਲਈ ਅਨੁਕੂਲ ਨਹੀਂ ਹੈ।
Если у вас нет синхронной реплики, WAL-G не гарантирует вам сохранность последнего сегмента. И если архивация отстает от последних нескольких сегментов истории, что является риском. В случае отсутствия синхронной реплики, я бы не рекомендовал пользоваться WAL-G. Все-таки в основном он проектируется для облачной инсталляции, которая подразумевает High Availability решения с синхронной репликой, которая отвечает за сохранность закоммиченных последних байт.
Я часто вижу людей, которые пытаются одновременно эксплуатировать и WAL-G и WAL-E. Мы поддерживаем обратную совместимость в том плане, что WAL-G может восстановить вал из WAL-E и может восстановить бэкап, сделанный в WAL-E. Но поскольку обе эти системы используют параллельный wal-push, они начинают красть друг у друга файлы. Если в WAL-G мы это починим, то в WAL-E это все равно останется. В WAL-E смотрит archive-status, видит готовые файлы и архивирует их, при этом другие системы, просто не узнают о том, что этот WAL-файл существовал, потому что PostgreSQL не будет пытаться заархивировать его во второй раз.
Что мы тут починим со стороны WAL-G? Мы не будем сообщать PostgreSQL о том, что этот файл был унесен параллельно, а когда PostgreSQL нас попросит его заархивировать, мы уже будем знать, что такой файл с таким mode-time и с таким md5 уже был заархивирован и просто скажем PostgreSQL – OK, все готово, по сути, ничего не делая.
Но на стороне WAL-E вряд ли эта проблема будет чиниться, поэтому сделать archive command, который заархивирует файл и в WAL-G, и в WAL-E сейчас невозможно.
Кроме того, есть случаи, когда WAL-G вам не подходит сейчас, но мы обязательно будем это чинить.
Во-первых, у нас сейчас нет встроенной верификации бэкапа. У нас нет верификации ни во время бэкапа, ни при восстановлении. Конечно, в облаке это реализуется. Но это реализуется просто предпроверкой, просто восстановлением кластера. Хотелось бы дать такую функциональность пользователям. Но под верификацией я предполагаю, что в WAL-G будет возможность восстановить кластер и запустить его, и прогнать smoke-тесты: pg_dumpall в /dev/null и amcheck верификацию индексов.
ਵਰਤਮਾਨ ਵਿੱਚ WAL-G ਵਿੱਚ WAL ਤੋਂ ਇੱਕ ਬੈਕਅੱਪ ਨੂੰ ਮੁਲਤਵੀ ਕਰਨ ਦਾ ਕੋਈ ਤਰੀਕਾ ਨਹੀਂ ਹੈ। ਭਾਵ, ਅਸੀਂ ਕੁਝ ਵਿੰਡੋ ਨੂੰ ਸਪੋਰਟ ਕਰਦੇ ਹਾਂ। ਉਦਾਹਰਨ ਲਈ, ਪਿਛਲੇ ਸੱਤ ਦਿਨਾਂ ਨੂੰ ਸਟੋਰ ਕਰਨਾ, ਪਿਛਲੇ ਦਸ ਬੈਕਅੱਪਾਂ ਨੂੰ ਸਟੋਰ ਕਰਨਾ, ਪਿਛਲੇ ਤਿੰਨ ਪੂਰੇ ਬੈਕਅੱਪਾਂ ਨੂੰ ਸਟੋਰ ਕਰਨਾ। ਅਕਸਰ ਲੋਕ ਆਉਂਦੇ ਹਨ ਅਤੇ ਕਹਿੰਦੇ ਹਨ: "ਸਾਨੂੰ ਨਵੇਂ ਸਾਲ 'ਤੇ ਜੋ ਹੋਇਆ ਉਸ ਦਾ ਬੈਕਅੱਪ ਚਾਹੀਦਾ ਹੈ ਅਤੇ ਅਸੀਂ ਇਸਨੂੰ ਹਮੇਸ਼ਾ ਲਈ ਰੱਖਣਾ ਚਾਹੁੰਦੇ ਹਾਂ।" WAL-G ਅਜੇ ਤੱਕ ਅਜਿਹਾ ਨਹੀਂ ਕਰ ਸਕਦਾ ਹੈ। (ਨੋਟ - ਇਹ ਪਹਿਲਾਂ ਹੀ ਠੀਕ ਕੀਤਾ ਜਾ ਚੁੱਕਾ ਹੈ। ਹੋਰ ਪੜ੍ਹੋ - ਬੈਕਅੱਪ-ਮਾਰਕ ਵਿਕਲਪ )
ਅਤੇ ਸਾਡੇ ਕੋਲ PITR ਨੂੰ ਪ੍ਰਮਾਣਿਤ ਕਰਦੇ ਸਮੇਂ ਸਾਰੇ ਸ਼ਾਫਟ ਹਿੱਸਿਆਂ ਲਈ ਪੇਜ ਚੈਕਸਮ ਅਤੇ ਇਕਸਾਰਤਾ ਜਾਂਚਾਂ ਨਹੀਂ ਹਨ।
Из всего этого я составил проект для Google Summer of Code. Если вы знаете толковых студентов, которые хотели бы пописать что-либо на Go и получить несколько тысяч долларов от одной компании на букву «G», то порекомендуйте им наш проект. Я выступлю ментором этого проекта, они смогут это сделать. Если студентов не найдется, то я возьму и сделаю это сам летом.
ਅਤੇ ਸਾਡੇ ਕੋਲ ਹੋਰ ਬਹੁਤ ਸਾਰੀਆਂ ਛੋਟੀਆਂ ਸਮੱਸਿਆਵਾਂ ਹਨ ਜਿਨ੍ਹਾਂ 'ਤੇ ਅਸੀਂ ਹੌਲੀ-ਹੌਲੀ ਕੰਮ ਕਰ ਰਹੇ ਹਾਂ। ਅਤੇ ਕੁਝ ਬਹੁਤ ਅਜੀਬ ਚੀਜ਼ਾਂ ਵਾਪਰਦੀਆਂ ਹਨ.
Например, если в WAL-G дать пустой бэкап, то он просто упадет. Например, если сказать ему, что надо забэкапить пустую папку. Там не будет лежать pg_control файла. И он подумает, что он чего-то не понимает. По идее в данном случае нужно написать нормальное сообщение пользователю, чтобы объяснить ему, как пользоваться инструментом. Но это даже фича не программирования, а фича хорошего доходчивого языка.
ਸਾਨੂੰ ਨਹੀਂ ਪਤਾ ਕਿ ਔਫਲਾਈਨ ਬੈਕਅੱਪ ਕਿਵੇਂ ਕਰਨਾ ਹੈ। ਜੇਕਰ ਡੇਟਾਬੇਸ ਝੂਠ ਬੋਲ ਰਿਹਾ ਹੈ, ਤਾਂ ਅਸੀਂ ਇਸਦਾ ਬੈਕਅੱਪ ਨਹੀਂ ਲੈ ਸਕਦੇ। ਪਰ ਇੱਥੇ ਸਭ ਕੁਝ ਬਹੁਤ ਹੀ ਸਧਾਰਨ ਹੈ. ਅਸੀਂ LSN ਦੁਆਰਾ ਬੈਕਅੱਪ ਨੂੰ ਕਾਲ ਕਰਦੇ ਹਾਂ ਜਦੋਂ ਇਹ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ। ਅੰਡਰਲਾਈੰਗ ਬੇਸ ਦਾ LSN ਕੰਟਰੋਲ ਫਾਈਲ ਤੋਂ ਪੜ੍ਹਿਆ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ। ਅਤੇ ਇਹ ਅਜਿਹੀ ਅਣਹੋਣੀ ਵਿਸ਼ੇਸ਼ਤਾ ਹੈ. ਬਹੁਤ ਸਾਰੇ ਬੈਕਅੱਪ ਸਿਸਟਮ ਇੱਕ ਅੰਡਰਲਾਈੰਗ ਡੇਟਾਬੇਸ ਦਾ ਬੈਕਅੱਪ ਲੈ ਸਕਦੇ ਹਨ। ਅਤੇ ਇਹ ਸੁਵਿਧਾਜਨਕ ਹੈ.
ਅਸੀਂ ਵਰਤਮਾਨ ਵਿੱਚ ਬੈਕਅੱਪ ਸਪੇਸ ਦੀ ਕਮੀ ਨੂੰ ਸਹੀ ਢੰਗ ਨਾਲ ਨਹੀਂ ਸੰਭਾਲ ਸਕਦੇ। ਕਿਉਂਕਿ ਅਸੀਂ ਆਮ ਤੌਰ 'ਤੇ ਘਰ ਵਿੱਚ ਵੱਡੇ ਬੈਕਅੱਪ ਨਾਲ ਕੰਮ ਕਰਦੇ ਹਾਂ। ਅਤੇ ਉਹ ਇਸ ਦੇ ਨੇੜੇ ਨਹੀਂ ਆਏ. ਪਰ ਜੇਕਰ ਕੋਈ ਇਸ ਸਮੇਂ ਗੋ ਵਿੱਚ ਪ੍ਰੋਗਰਾਮ ਕਰਨਾ ਚਾਹੁੰਦਾ ਹੈ, ਤਾਂ ਬਾਲਟੀ ਵਿੱਚ ਸਪੇਸ ਤੋਂ ਬਾਹਰ ਦੀਆਂ ਗਲਤੀਆਂ ਲਈ ਹੈਂਡਲਿੰਗ ਸ਼ਾਮਲ ਕਰੋ। ਮੈਂ ਯਕੀਨੀ ਤੌਰ 'ਤੇ ਪੁੱਲ ਬੇਨਤੀ ਨੂੰ ਦੇਖਾਂਗਾ।
ਅਤੇ ਮੁੱਖ ਗੱਲ ਜੋ ਸਾਨੂੰ ਚਿੰਤਤ ਕਰਦੀ ਹੈ ਉਹ ਇਹ ਹੈ ਕਿ ਅਸੀਂ ਜਿੰਨੇ ਸੰਭਵ ਹੋ ਸਕੇ ਡੌਕਰ ਏਕੀਕਰਣ ਟੈਸਟ ਚਾਹੁੰਦੇ ਹਾਂ ਜੋ ਵੱਖ-ਵੱਖ ਸਥਿਤੀਆਂ ਦੀ ਜਾਂਚ ਕਰਦੇ ਹਨ. ਇਸ ਸਮੇਂ ਅਸੀਂ ਸਿਰਫ ਬੁਨਿਆਦੀ ਦ੍ਰਿਸ਼ਾਂ ਦੀ ਜਾਂਚ ਕਰ ਰਹੇ ਹਾਂ। ਹਰੇਕ ਪ੍ਰਤੀਬੱਧਤਾ 'ਤੇ, ਪਰ ਅਸੀਂ ਉਹਨਾਂ ਸਾਰੀਆਂ ਕਾਰਜਸ਼ੀਲਤਾਵਾਂ ਦੀ ਜਾਂਚ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹਾਂ ਜਿਨ੍ਹਾਂ ਦਾ ਅਸੀਂ ਸਮਰਥਨ ਕਰਦੇ ਹਾਂ। ਖਾਸ ਤੌਰ 'ਤੇ, ਉਦਾਹਰਨ ਲਈ, ਸਾਡੇ ਕੋਲ PostgreSQL 9.4-9.5 ਲਈ ਕਾਫੀ ਸਮਰਥਨ ਹੋਵੇਗਾ। ਅਸੀਂ ਉਹਨਾਂ ਦਾ ਸਮਰਥਨ ਕਰਦੇ ਹਾਂ ਕਿਉਂਕਿ ਕਮਿਊਨਿਟੀ PostgreSQL ਦਾ ਸਮਰਥਨ ਕਰਦੀ ਹੈ, ਪਰ ਅਸੀਂ ਇਹ ਯਕੀਨੀ ਬਣਾਉਣ ਲਈ ਵਚਨਬੱਧਤਾ ਦੀ ਜਾਂਚ ਨਹੀਂ ਕਰਦੇ ਹਾਂ ਕਿ ਸਭ ਕੁਝ ਟੁੱਟਿਆ ਨਹੀਂ ਹੈ। ਅਤੇ ਇਹ ਮੈਨੂੰ ਲੱਗਦਾ ਹੈ ਕਿ ਇਹ ਇੱਕ ਗੰਭੀਰ ਖਤਰਾ ਹੈ.
ਸਾਡੇ ਕੋਲ WAL-G ਯਾਂਡੇਕਸ ਡਾਟਾਬੇਸ ਪ੍ਰਬੰਧਨ ਵਿੱਚ ਇੱਕ ਹਜ਼ਾਰ ਤੋਂ ਵੱਧ ਕਲੱਸਟਰਾਂ 'ਤੇ ਚੱਲ ਰਿਹਾ ਹੈ। ਅਤੇ ਇਹ ਹਰ ਰੋਜ਼ ਕਈ ਸੌ ਟੈਰਾਬਾਈਟ ਡੇਟਾ ਦਾ ਬੈਕਅੱਪ ਲੈਂਦਾ ਹੈ।
ਸਾਡੇ ਕੋਡ ਵਿੱਚ ਸਾਡੇ ਕੋਲ ਬਹੁਤ ਸਾਰੇ TODO ਹਨ। ਜੇ ਤੁਸੀਂ ਪ੍ਰੋਗਰਾਮ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ, ਆਓ, ਅਸੀਂ ਪੁੱਲ ਬੇਨਤੀਆਂ ਦੀ ਉਡੀਕ ਕਰ ਰਹੇ ਹਾਂ, ਅਸੀਂ ਸਵਾਲਾਂ ਦੀ ਉਡੀਕ ਕਰ ਰਹੇ ਹਾਂ.
ਤੁਹਾਡੇ ਸਵਾਲ
Добрый вечер! Спасибо! Я так полагаю, что если вы используете WAL-delta, то, наверное, вы сильно опираетесь на full-page writes. И если да, то проводили ли вы тесты? Вы показывали красивый график. Насколько он не красивее становится, если FPW выключить?
Full-page writes у нас включен, мы не пробовали его выключать. Т. е. я, как разработчик, не пробовал его выключать. Системные администраторы, которые исследовали, наверное, исследовали этот вопрос. Но нам FPW необходим. Его практически никто не отключает, потому что иначе невозможно взять бэкап с реплики.
ਰਿਪੋਰਟ ਲਈ ਧੰਨਵਾਦ! ਮੇਰੇ ਦੋ ਸਵਾਲ ਹਨ। ਪਹਿਲਾ ਸਵਾਲ ਇਹ ਹੈ ਕਿ ਟੇਬਲਸਪੇਸ ਦਾ ਕੀ ਹੋਵੇਗਾ?
Мы ждем pull request. Наши базы живут на SSD и NMVE дисках и нам эта фича не очень нужна. Я прямо сейчас не готов потратить серьезное время на то, чтобы ее сделать хорошо. Я всеми руками за то, чтобы мы это поддержали. Есть люди, которые это поддержали, но поддержали в том виде, как это подходит для них. Сделали форк, но не делают pull request. (Добавлено в версии 0.2.13)
ਅਤੇ ਦੂਜਾ ਸਵਾਲ. ਤੁਸੀਂ ਸ਼ੁਰੂ ਵਿੱਚ ਕਿਹਾ ਸੀ ਕਿ WAL-G ਇਹ ਮੰਨਦਾ ਹੈ ਕਿ ਇਹ ਇਕੱਲੇ ਕੰਮ ਕਰਦਾ ਹੈ ਅਤੇ ਕਿਸੇ ਵੀ ਰੈਪਰ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ। ਮੈਂ ਖੁਦ ਰੈਪਰ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹਾਂ। ਉਹਨਾਂ ਦੀ ਵਰਤੋਂ ਕਿਉਂ ਨਹੀਂ ਕੀਤੀ ਜਾਣੀ ਚਾਹੀਦੀ?
Мы хотим, чтобы он был простым, как балалайка. Это означает, что тебе вообще ничего, кроме балалайки не надо. Мы хотим, чтобы система была простой. Если у тебя есть функциональность, которую тебе необходимо сделать в скрипте, то приходи и рассказывай – сделаем ее на Go.
ਸਤ ਸ੍ਰੀ ਅਕਾਲ! ਰਿਪੋਰਟ ਲਈ ਧੰਨਵਾਦ! ਅਸੀਂ WAL-G ਨੂੰ GPG ਡੀਕ੍ਰਿਪਸ਼ਨ ਨਾਲ ਕੰਮ ਕਰਨ ਲਈ ਪ੍ਰਾਪਤ ਕਰਨ ਵਿੱਚ ਅਸਮਰੱਥ ਸੀ। ਇਹ ਆਮ ਤੌਰ 'ਤੇ ਐਨਕ੍ਰਿਪਟ ਕਰਦਾ ਹੈ, ਪਰ ਡੀਕ੍ਰਿਪਟ ਨਹੀਂ ਕਰਨਾ ਚਾਹੁੰਦਾ ਹੈ। ਕੀ ਇਹ ਉਹ ਚੀਜ਼ ਹੈ ਜੋ ਸਾਡੇ ਲਈ ਕੰਮ ਨਹੀਂ ਕਰਦੀ? ਸਥਿਤੀ ਨਿਰਾਸ਼ਾਜਨਕ ਹੈ।
Создавайте вопрос на GitHub, давайте разбираться.
Т. е. не сталкивались с таким?
Там есть особенность репорта ошибок, что когда WAL-G не понимает, что это за файл, он спрашивает: «Может быть, он зашифрован?». Возможно, проблема совсем не в шифровании. Я хочу поправить логирование на эту тему. Расшифровать он должен. На эту тему мы сейчас работаем в том плане, что не очень нравится, как организована система получения публичных и приватных ключей. Потому что мы вызываем внешний GPG для того, чтобы он нам отдал свои ключи. А потом мы эти ключи берем и передаем внутреннему GPG, который open PGP, который к нам компилирован вовнутрь WAL-G, и там вызываем шифрование. В этом плане мы хотим систему улучшить и хотим поддержать шифрование Libsodium (Добавлено в версии 0.2.15). Конечно, расшифрование должно работать, давайте разбираться – больше симптомом нужно, чем пара слов. Можно как-нибудь собраться в комнате докладчика и посмотреть на систему. (PGP encryption without external GPG — v0.2.9)
ਸਤ ਸ੍ਰੀ ਅਕਾਲ! ਰਿਪੋਰਟ ਲਈ ਧੰਨਵਾਦ! ਮੇਰੇ ਦੋ ਸਵਾਲ ਹਨ। ਮੈਨੂੰ ਦੋ ਪ੍ਰਦਾਤਾਵਾਂ ਵਿੱਚ pg_basebackup ਅਤੇ WAL ਲੌਗ ਇਨ ਕਰਨ ਦੀ ਅਜੀਬ ਇੱਛਾ ਹੈ, ਭਾਵ ਮੈਂ ਇੱਕ ਕਲਾਉਡ ਅਤੇ ਦੂਜਾ ਕਰਨਾ ਚਾਹੁੰਦਾ ਹਾਂ। ਕੀ ਅਜਿਹਾ ਕਰਨ ਦਾ ਕੋਈ ਤਰੀਕਾ ਹੈ?
Сейчас этого нет, но идея интересная.
ਮੈਂ ਸਿਰਫ਼ ਇੱਕ ਪ੍ਰਦਾਤਾ 'ਤੇ ਭਰੋਸਾ ਨਹੀਂ ਕਰਦਾ ਹਾਂ, ਮੈਂ ਦੂਜੇ ਵਿੱਚ ਵੀ ਇਹੀ ਹੋਣਾ ਚਾਹੁੰਦਾ ਹਾਂ, ਸਿਰਫ ਸਥਿਤੀ ਵਿੱਚ।
ਵਿਚਾਰ ਦਿਲਚਸਪ ਹੈ. ਤਕਨੀਕੀ ਤੌਰ 'ਤੇ, ਇਸ ਨੂੰ ਲਾਗੂ ਕਰਨਾ ਔਖਾ ਨਹੀਂ ਹੈ। ਵਿਚਾਰ ਨੂੰ ਗੁਆਚਣ ਤੋਂ ਰੋਕਣ ਲਈ, ਕੀ ਮੈਂ ਤੁਹਾਨੂੰ GitHub 'ਤੇ ਇੱਕ ਮੁੱਦਾ ਬਣਾਉਣ ਲਈ ਕਹਿ ਸਕਦਾ ਹਾਂ?
ਹਾਂ ਜ਼ਰੂਰ.
И тогда, когда придут студенты на Google Summer of Code, мы добавим им в проект, чтобы больше было работы, чтобы больше получить от них.
ਅਤੇ ਦੂਜਾ ਸਵਾਲ. GitHub 'ਤੇ ਇੱਕ ਮੁੱਦਾ ਹੈ। ਮੈਨੂੰ ਲੱਗਦਾ ਹੈ ਕਿ ਇਹ ਪਹਿਲਾਂ ਹੀ ਬੰਦ ਹੈ। ਬਹਾਲੀ ਦੇ ਦੌਰਾਨ ਇੱਕ ਦਹਿਸ਼ਤ ਹੈ. ਅਤੇ ਇਸਨੂੰ ਹਰਾਉਣ ਲਈ, ਤੁਸੀਂ ਇੱਕ ਵੱਖਰੀ ਅਸੈਂਬਲੀ ਬਣਾਈ ਸੀ। ਇਹ ਮੁੱਦਿਆਂ ਵਿੱਚ ਸਹੀ ਹੈ. ਅਤੇ ਇੱਕ ਥਰਿੱਡ ਵਿੱਚ ਇੱਕ ਵੇਰੀਏਬਲ ਵਾਤਾਵਰਨ ਕਰਨ ਦਾ ਵਿਕਲਪ ਹੈ. ਅਤੇ ਇਸ ਲਈ ਇਹ ਬਹੁਤ ਹੌਲੀ ਹੌਲੀ ਕੰਮ ਕਰਦਾ ਹੈ. ਅਤੇ ਸਾਨੂੰ ਇਸ ਸਮੱਸਿਆ ਦਾ ਸਾਹਮਣਾ ਕਰਨਾ ਪਿਆ, ਅਤੇ ਇਹ ਅਜੇ ਤੱਕ ਹੱਲ ਨਹੀਂ ਕੀਤਾ ਗਿਆ ਹੈ।
ਸਮੱਸਿਆ ਇਹ ਹੈ ਕਿ ਕਿਸੇ ਕਾਰਨ ਕਰਕੇ ਸਟੋਰੇਜ਼ (CEPH) ਕੁਨੈਕਸ਼ਨ ਨੂੰ ਰੀਸੈਟ ਕਰਦਾ ਹੈ ਜਦੋਂ ਅਸੀਂ ਇਸ 'ਤੇ ਉੱਚ ਸਮਰੂਪਤਾ ਨਾਲ ਆਉਂਦੇ ਹਾਂ। ਇਸ ਬਾਰੇ ਕੀ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ? ਮੁੜ ਕੋਸ਼ਿਸ਼ ਤਰਕ ਇਸ ਤਰ੍ਹਾਂ ਦਿਖਦਾ ਹੈ। ਅਸੀਂ ਫਾਈਲ ਨੂੰ ਦੁਬਾਰਾ ਡਾਊਨਲੋਡ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਰਹੇ ਹਾਂ। ਇੱਕ ਪਾਸ ਵਿੱਚ, ਸਾਡੇ ਕੋਲ ਬਹੁਤ ਸਾਰੀਆਂ ਫਾਈਲਾਂ ਡਾਉਨਲੋਡ ਨਹੀਂ ਹੋਈਆਂ ਸਨ, ਅਸੀਂ ਉਹਨਾਂ ਸਾਰਿਆਂ ਲਈ ਇੱਕ ਦੂਜੀ ਬਣਾਵਾਂਗੇ ਜਿਨ੍ਹਾਂ ਨੇ ਲੌਗਇਨ ਨਹੀਂ ਕੀਤਾ ਹੈ। ਅਤੇ ਜਿੰਨਾ ਚਿਰ ਪ੍ਰਤੀ ਦੁਹਰਾਓ ਘੱਟੋ-ਘੱਟ ਇੱਕ ਫਾਈਲ ਲੋਡ ਕੀਤੀ ਜਾਂਦੀ ਹੈ, ਅਸੀਂ ਦੁਹਰਾਉਂਦੇ ਹਾਂ ਅਤੇ ਦੁਹਰਾਉਂਦੇ ਹਾਂ ਅਤੇ ਦੁਹਰਾਉਂਦੇ ਹਾਂ. ਅਸੀਂ ਮੁੜ ਕੋਸ਼ਿਸ਼ ਦੇ ਤਰਕ ਵਿੱਚ ਸੁਧਾਰ ਕੀਤਾ ਹੈ - ਘਾਤਕ ਬੈਕਆਫ। ਪਰ ਇਹ ਪੂਰੀ ਤਰ੍ਹਾਂ ਸਪੱਸ਼ਟ ਨਹੀਂ ਹੈ ਕਿ ਇਸ ਤੱਥ ਦਾ ਕੀ ਕਰਨਾ ਹੈ ਕਿ ਕੁਨੈਕਸ਼ਨ ਸਟੋਰੇਜ ਸਿਸਟਮ ਵਾਲੇ ਪਾਸੇ ਟੁੱਟ ਜਾਂਦਾ ਹੈ। ਭਾਵ, ਜਦੋਂ ਅਸੀਂ ਇੱਕ ਸਟ੍ਰੀਮ 'ਤੇ ਅਪਲੋਡ ਕਰਦੇ ਹਾਂ, ਤਾਂ ਇਹ ਇਹਨਾਂ ਕੁਨੈਕਸ਼ਨਾਂ ਨੂੰ ਨਹੀਂ ਤੋੜਦਾ ਹੈ। ਅਸੀਂ ਇੱਥੇ ਕੀ ਸੁਧਾਰ ਕਰ ਸਕਦੇ ਹਾਂ? ਸਾਡੇ ਕੋਲ ਨੈੱਟਵਰਕ ਥ੍ਰੋਟਲਿੰਗ ਹੈ, ਅਸੀਂ ਹਰੇਕ ਕਨੈਕਸ਼ਨ ਨੂੰ ਇਸ ਦੁਆਰਾ ਭੇਜੇ ਬਾਈਟਾਂ ਦੀ ਸੰਖਿਆ ਦੁਆਰਾ ਸੀਮਿਤ ਕਰ ਸਕਦੇ ਹਾਂ। ਨਹੀਂ ਤਾਂ, ਮੈਨੂੰ ਨਹੀਂ ਪਤਾ ਕਿ ਇਸ ਤੱਥ ਨਾਲ ਕਿਵੇਂ ਨਜਿੱਠਣਾ ਹੈ ਕਿ ਆਬਜੈਕਟ ਸਟੋਰੇਜ ਸਾਨੂੰ ਇਸ ਤੋਂ ਸਮਾਨਾਂਤਰ ਵਿੱਚ ਡਾਊਨਲੋਡ ਜਾਂ ਡਾਊਨਲੋਡ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਨਹੀਂ ਦਿੰਦੀ।
Нет никакого SLA? Не написано у них, как они позволяют себя мучить?
Суть в том, что люди, которые приходят с этим вопросом, обычно имеют свое хранилище. Т. е. с Amazon или с Google Cloud, или с Yandex Object Storage никто не приходит.
Может вопрос уже не к вам?
ਇੱਥੇ ਸਵਾਲ ਇਹ ਨਹੀਂ ਹੈ ਕਿ ਇਸ ਮਾਮਲੇ ਵਿੱਚ ਕਿਸ ਨੂੰ. ਜੇਕਰ ਇਸ ਨਾਲ ਨਜਿੱਠਣ ਦੇ ਤਰੀਕੇ ਬਾਰੇ ਕੋਈ ਵਿਚਾਰ ਹਨ, ਤਾਂ ਆਓ ਇਸਨੂੰ WAL-G ਵਿੱਚ ਕਰੀਏ। ਪਰ ਹੁਣ ਤੱਕ ਮੇਰੇ ਕੋਲ ਇਸ ਨਾਲ ਕਿਵੇਂ ਨਜਿੱਠਣਾ ਹੈ ਇਸ ਬਾਰੇ ਕੋਈ ਵਧੀਆ ਵਿਚਾਰ ਨਹੀਂ ਹਨ. ਕੁਝ ਆਬਜੈਕਟ ਸਟੋਰੇਜ ਹਨ ਜੋ ਸੂਚੀਕਰਨ ਬੈਕਅੱਪ ਨੂੰ ਵੱਖਰੇ ਢੰਗ ਨਾਲ ਸਮਰਥਨ ਕਰਦੇ ਹਨ। ਤੁਸੀਂ ਉਹਨਾਂ ਨੂੰ ਵਸਤੂਆਂ ਦੀ ਸੂਚੀ ਬਣਾਉਣ ਲਈ ਕਹਿੰਦੇ ਹੋ, ਅਤੇ ਉਹ ਉੱਥੇ ਫੋਲਡਰ ਜੋੜਦੇ ਹਨ। WAL-G ਇਸ 'ਤੇ ਡਰ ਜਾਂਦਾ ਹੈ - ਇੱਥੇ ਕੁਝ ਅਜਿਹੀ ਚੀਜ਼ ਹੈ ਜੋ ਫਾਈਲ ਨਹੀਂ ਹੈ, ਮੈਂ ਇਸਨੂੰ ਰੀਸਟੋਰ ਨਹੀਂ ਕਰ ਸਕਦਾ, ਜਿਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਬੈਕਅੱਪ ਰੀਸਟੋਰ ਨਹੀਂ ਕੀਤਾ ਗਿਆ ਸੀ। ਭਾਵ, ਅਸਲ ਵਿੱਚ, ਤੁਹਾਡੇ ਕੋਲ ਇੱਕ ਪੂਰੀ ਤਰ੍ਹਾਂ ਰੀਸਟੋਰ ਕੀਤਾ ਗਿਆ ਕਲੱਸਟਰ ਹੈ, ਪਰ ਇਹ ਤੁਹਾਨੂੰ ਇੱਕ ਗਲਤ ਸਥਿਤੀ ਵਾਪਸ ਕਰਦਾ ਹੈ ਕਿਉਂਕਿ ਆਬਜੈਕਟ ਸਟੋਰੇਜ ਨੇ ਕੁਝ ਅਜੀਬ ਜਾਣਕਾਰੀ ਵਾਪਸ ਕੀਤੀ ਹੈ ਜੋ ਇਸਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਸਮਝ ਨਹੀਂ ਸਕੀ।
Это в облаке Mail возникает такая штука.
ਜੇ ਤੁਸੀਂ ਇੱਕ ਪ੍ਰਜਨਨ ਬਣਾ ਸਕਦੇ ਹੋ ...
Оно стабильно вопроизводится…
ਜੇਕਰ ਕੋਈ ਪੁਨਰ-ਨਿਰਮਾਣ ਹੈ, ਤਾਂ ਮੈਂ ਸੋਚਦਾ ਹਾਂ ਕਿ ਅਸੀਂ ਮੁੜ ਕੋਸ਼ਿਸ਼ ਕਰਨ ਦੀਆਂ ਰਣਨੀਤੀਆਂ ਨਾਲ ਪ੍ਰਯੋਗ ਕਰਾਂਗੇ ਅਤੇ ਇਹ ਪਤਾ ਲਗਾਵਾਂਗੇ ਕਿ ਕਿਵੇਂ ਮੁੜ ਕੋਸ਼ਿਸ਼ ਕਰਨੀ ਹੈ ਅਤੇ ਸਮਝਣਾ ਹੈ ਕਿ ਕਲਾਉਡ ਨੂੰ ਸਾਡੇ ਤੋਂ ਕੀ ਚਾਹੀਦਾ ਹੈ। ਹੋ ਸਕਦਾ ਹੈ ਕਿ ਇਹ ਸਾਡੇ ਲਈ ਤਿੰਨ ਕੁਨੈਕਸ਼ਨਾਂ 'ਤੇ ਸਥਿਰ ਹੋਵੇਗਾ ਅਤੇ ਕੁਨੈਕਸ਼ਨ ਨਹੀਂ ਤੋੜੇਗਾ, ਫਿਰ ਅਸੀਂ ਧਿਆਨ ਨਾਲ ਤਿੰਨਾਂ ਤੱਕ ਪਹੁੰਚ ਜਾਵਾਂਗੇ। ਕਿਉਂਕਿ ਹੁਣ ਅਸੀਂ ਕਨੈਕਸ਼ਨ ਨੂੰ ਬਹੁਤ ਜਲਦੀ ਛੱਡ ਦਿੰਦੇ ਹਾਂ, ਭਾਵ ਜੇਕਰ ਅਸੀਂ 16 ਥ੍ਰੈਡਾਂ ਨਾਲ ਰਿਕਵਰੀ ਸ਼ੁਰੂ ਕੀਤੀ ਹੈ, ਤਾਂ ਪਹਿਲੀ ਮੁੜ ਕੋਸ਼ਿਸ਼ ਕਰਨ ਤੋਂ ਬਾਅਦ 8 ਥ੍ਰੈਡ, 4 ਥ੍ਰੈਡ, 2 ਥ੍ਰੈਡ ਅਤੇ ਇੱਕ ਹੋਵੇਗਾ। ਅਤੇ ਫਿਰ ਇਹ ਫਾਈਲ ਨੂੰ ਇੱਕ ਸਟ੍ਰੀਮ ਵਿੱਚ ਖਿੱਚੇਗਾ. ਜੇ ਕੁਝ ਜਾਦੂਈ ਮੁੱਲ ਹਨ ਜਿਵੇਂ ਕਿ 7,5 ਥਰਿੱਡ ਪੰਪਿੰਗ ਲਈ ਸਭ ਤੋਂ ਵਧੀਆ ਹਨ, ਤਾਂ ਅਸੀਂ ਉਨ੍ਹਾਂ 'ਤੇ ਧਿਆਨ ਦੇਵਾਂਗੇ ਅਤੇ ਹੋਰ 7,5 ਥ੍ਰੈਡ ਬਣਾਉਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਾਂਗੇ। ਇੱਥੇ ਇੱਕ ਵਿਚਾਰ ਹੈ.
Спасибо за доклад! Как выглядит полный workflow работы с WAL-G? Например, в дурацком случае, когда дельты по страницам нет. И мы берем и снимаем начальный бэкап, потом архивируем вал до посинения. Здесь, как я понимаю, есть разбивка. В какой-то момент нужно сделать delta-бэкап страниц, т. е. какой-то внешний процесс это драйвит или как это случается?
ਡੈਲਟਾ ਬੈਕਅੱਪ API ਕਾਫ਼ੀ ਸਧਾਰਨ ਹੈ. ਉੱਥੇ ਇੱਕ ਨੰਬਰ ਹੈ - ਅਧਿਕਤਮ ਡੈਲਟਾ ਸਟੈਪਸ, ਇਸ ਨੂੰ ਕਿਹਾ ਜਾਂਦਾ ਹੈ। ਇਹ ਡਿਫੌਲਟ ਜ਼ੀਰੋ ਹੈ। ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਹਰ ਵਾਰ ਜਦੋਂ ਤੁਸੀਂ ਬੈਕਅੱਪ-ਪੁਸ਼ ਕਰਦੇ ਹੋ, ਇਹ ਇੱਕ ਪੂਰਾ ਬੈਕਅੱਪ ਡਾਊਨਲੋਡ ਕਰਦਾ ਹੈ। ਜੇਕਰ ਤੁਸੀਂ ਇਸਨੂੰ ਕਿਸੇ ਵੀ ਸਕਾਰਾਤਮਕ ਸੰਖਿਆ ਵਿੱਚ ਬਦਲਦੇ ਹੋ, ਉਦਾਹਰਨ ਲਈ, 3, ਤਾਂ ਅਗਲੀ ਵਾਰ ਜਦੋਂ ਤੁਸੀਂ ਬੈਕਅੱਪ-ਪੁਸ਼ ਕਰਦੇ ਹੋ, ਤਾਂ ਇਹ ਪਿਛਲੇ ਬੈਕਅੱਪ ਦੇ ਇਤਿਹਾਸ ਨੂੰ ਵੇਖਦਾ ਹੈ। ਉਹ ਦੇਖਦਾ ਹੈ ਕਿ ਤੁਸੀਂ 3 ਡੈਲਟਾ ਦੀ ਲੜੀ ਤੋਂ ਵੱਧ ਨਹੀਂ ਜਾਂਦੇ ਅਤੇ ਇੱਕ ਡੈਲਟਾ ਬਣਾਉਂਦਾ ਹੈ.
ਭਾਵ, ਹਰ ਵਾਰ ਜਦੋਂ ਅਸੀਂ WAL-G ਨੂੰ ਲਾਂਚ ਕਰਦੇ ਹਾਂ, ਇਹ ਪੂਰਾ ਬੈਕਅੱਪ ਬਣਾਉਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦਾ ਹੈ?
ਨਹੀਂ, ਅਸੀਂ WAL-G ਚਲਾਉਂਦੇ ਹਾਂ, ਅਤੇ ਇਹ ਇੱਕ ਡੈਲਟਾ ਬਣਾਉਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦਾ ਹੈ ਜੇਕਰ ਤੁਹਾਡੀਆਂ ਨੀਤੀਆਂ ਇਸਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦੀਆਂ ਹਨ।
Грубо говоря, если каждый раз запускать его с нулем, то он будет себя вести как pg_basebackup?
Нет, он все равно будет работать быстрее, потому что он использует сжатие и параллелизм. Pg_basebackup тебе рядом положит вал. WAL-G рассчитывает на то, что у тебя настроена архивация. И будет выдавать warning, если она не настроена.
Pg_basebackup можно запустить без валов.
Да, тогда они будут вести себя почти одинаково. Pg_basebackup копирует на файловую систему. У нас есть, кстати, нова фича, о которой я забыл сказать. Мы теперь можем из pg_basebackup на файловую систему бэкапиться. Не знаю, зачем это надо, но это есть.
Например, на CephFS. Не все хотят Object Storage конфигурировать.
ਹਾਂ, ਸ਼ਾਇਦ ਇਸੇ ਲਈ ਉਨ੍ਹਾਂ ਨੇ ਇਸ ਵਿਸ਼ੇਸ਼ਤਾ ਬਾਰੇ ਇੱਕ ਸਵਾਲ ਪੁੱਛਿਆ ਤਾਂ ਜੋ ਅਸੀਂ ਇਹ ਕਰ ਸਕੀਏ। ਅਤੇ ਅਸੀਂ ਇਹ ਕੀਤਾ.
Спасибо за доклад! Есть как раз вопрос по поводу копирования на файловую систему. Из коробки вы сейчас поддерживаете копирование на remote storage, например, если какая-то полка в ЦОД или еще что-нибудь?
В такой формулировке – это сложный вопрос. Да, мы поддерживаем, но эта функциональность еще не включена ни в один релиз. Т. е. все предрелизы это поддерживают, но в релизных версиях этого нет. Эта функциональность добавлена в версию 0.2. Она обязательна скоро окажется в релизе, как только мы починим все известные баги. Но прямо сейчас это можно сделать только в предрелизе. В предрелизе есть два бага. Проблема с восстановлением WAL-E, это мы не починили. И в последнем предрелизе добавлен баг про delta-backup. Поэтому мы всем рекомендуем пользоваться релизными версиями. Как только в предрелизе перестанут находиться баги, можно будет сказать, что мы поддерживаем Google Cloud, S3-совместимые вещи и файловый storage.
Привет, спасибо за доклад. Как я понял, WAL-G – это не централизованная какая-то система как barmen? Планируете ли в этом направлении двигаться?
ਸਮੱਸਿਆ ਇਹ ਹੈ ਕਿ ਅਸੀਂ ਇਸ ਦਿਸ਼ਾ ਤੋਂ ਦੂਰ ਚਲੇ ਗਏ ਹਾਂ। WAL-G ਬੇਸ ਹੋਸਟ 'ਤੇ, ਕਲੱਸਟਰ ਹੋਸਟ 'ਤੇ, ਅਤੇ ਕਲੱਸਟਰ ਦੇ ਸਾਰੇ ਮੇਜ਼ਬਾਨਾਂ 'ਤੇ ਰਹਿੰਦਾ ਹੈ। ਜਦੋਂ ਅਸੀਂ ਕਈ ਹਜ਼ਾਰ ਕਲੱਸਟਰਾਂ ਵਿੱਚ ਚਲੇ ਗਏ, ਸਾਡੇ ਕੋਲ ਬਹੁਤ ਸਾਰੀਆਂ ਬਾਰਟੈਂਡਰ ਸਥਾਪਨਾਵਾਂ ਸਨ। ਅਤੇ ਹਰ ਵਾਰ ਜਦੋਂ ਉਹਨਾਂ ਵਿੱਚ ਕੁਝ ਵੱਖਰਾ ਹੋ ਜਾਂਦਾ ਹੈ, ਇਹ ਇੱਕ ਵੱਡੀ ਸਮੱਸਿਆ ਹੈ. ਕਿਉਂਕਿ ਉਹਨਾਂ ਦੀ ਮੁਰੰਮਤ ਕਰਨ ਦੀ ਲੋੜ ਹੈ, ਤੁਹਾਨੂੰ ਇਹ ਸਮਝਣ ਦੀ ਲੋੜ ਹੈ ਕਿ ਹੁਣ ਕਿਹੜੇ ਕਲੱਸਟਰਾਂ ਵਿੱਚ ਬੈਕਅੱਪ ਨਹੀਂ ਹਨ। ਮੈਂ ਬੈਕਅੱਪ ਪ੍ਰਣਾਲੀਆਂ ਲਈ ਭੌਤਿਕ ਹਾਰਡਵੇਅਰ ਦੀ ਦਿਸ਼ਾ ਵਿੱਚ WAL-G ਨੂੰ ਵਿਕਸਤ ਕਰਨ ਦੀ ਯੋਜਨਾ ਨਹੀਂ ਬਣਾਉਂਦਾ. ਜੇਕਰ ਭਾਈਚਾਰਾ ਇੱਥੇ ਕੁਝ ਕਾਰਜਸ਼ੀਲਤਾ ਚਾਹੁੰਦਾ ਹੈ, ਤਾਂ ਮੈਨੂੰ ਕੋਈ ਇਤਰਾਜ਼ ਨਹੀਂ ਹੈ।
ਸਾਡੇ ਕੋਲ ਸਟੋਰੇਜ ਲਈ ਜ਼ਿੰਮੇਵਾਰ ਟੀਮਾਂ ਹਨ। ਅਤੇ ਅਸੀਂ ਇੰਨਾ ਚੰਗਾ ਮਹਿਸੂਸ ਕਰਦੇ ਹਾਂ ਕਿ ਇਹ ਅਸੀਂ ਨਹੀਂ ਹਾਂ, ਕਿ ਇੱਥੇ ਵਿਸ਼ੇਸ਼ ਲੋਕ ਹਨ ਜੋ ਸਾਡੀਆਂ ਫਾਈਲਾਂ ਨੂੰ ਉੱਥੇ ਰੱਖਦੇ ਹਨ ਜਿੱਥੇ ਫਾਈਲਾਂ ਸੁਰੱਖਿਅਤ ਹੁੰਦੀਆਂ ਹਨ। ਉਹ ਫਾਈਲਾਂ ਦੀ ਇੱਕ ਨਿਸ਼ਚਤ ਗਿਣਤੀ ਦੇ ਨੁਕਸਾਨ ਦਾ ਸਾਮ੍ਹਣਾ ਕਰਨ ਲਈ ਉੱਥੇ ਹਰ ਤਰ੍ਹਾਂ ਦੀ ਚਲਾਕ ਕੋਡਿੰਗ ਕਰਦੇ ਹਨ। ਉਹ ਨੈੱਟਵਰਕ ਬੈਂਡਵਿਡਥ ਲਈ ਜ਼ਿੰਮੇਵਾਰ ਹਨ। ਜਦੋਂ ਤੁਹਾਡੇ ਕੋਲ ਬਾਰਟੈਂਡਰ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਤੁਹਾਨੂੰ ਅਚਾਨਕ ਪਤਾ ਲੱਗ ਸਕਦਾ ਹੈ ਕਿ ਬਹੁਤ ਸਾਰੇ ਟ੍ਰੈਫਿਕ ਵਾਲੇ ਛੋਟੇ ਡੇਟਾਬੇਸ ਇੱਕੋ ਸਰਵਰ 'ਤੇ ਇਕੱਠੇ ਹੋਏ ਹਨ। ਜਾਪਦਾ ਹੈ ਕਿ ਤੁਹਾਡੇ ਕੋਲ ਇਸ 'ਤੇ ਬਹੁਤ ਸਾਰੀ ਜਗ੍ਹਾ ਹੈ, ਪਰ ਕਿਸੇ ਕਾਰਨ ਕਰਕੇ ਸਭ ਕੁਝ ਨੈਟਵਰਕ ਦੁਆਰਾ ਫਿੱਟ ਨਹੀਂ ਹੁੰਦਾ ਹੈ। ਇਹ ਆਲੇ-ਦੁਆਲੇ ਦੇ ਹੋਰ ਤਰੀਕੇ ਨਾਲ ਬਾਹਰ ਚਾਲੂ ਹੋ ਸਕਦਾ ਹੈ. ਇੱਥੇ ਬਹੁਤ ਸਾਰੇ ਨੈਟਵਰਕ ਹਨ, ਪ੍ਰੋਸੈਸਰ ਕੋਰ ਹਨ, ਪਰ ਇੱਥੇ ਕੋਈ ਡਿਸਕ ਨਹੀਂ ਹਨ. ਅਤੇ ਅਸੀਂ ਕੁਝ ਜੁਗਲ ਕਰਨ ਦੀ ਇਸ ਜ਼ਰੂਰਤ ਤੋਂ ਥੱਕ ਗਏ, ਅਤੇ ਅਸੀਂ ਇਸ ਤੱਥ ਵੱਲ ਚਲੇ ਗਏ ਕਿ ਡੇਟਾ ਸਟੋਰੇਜ ਇੱਕ ਵੱਖਰੀ ਸੇਵਾ ਹੈ, ਜਿਸ ਲਈ ਵੱਖਰੇ ਵਿਸ਼ੇਸ਼ ਲੋਕ ਜ਼ਿੰਮੇਵਾਰ ਹਨ।
P.S Вышла новая версия , ਜਿਸ ਵਿੱਚ ਤੁਸੀਂ .walg.json ਸੰਰਚਨਾ ਫਾਈਲ ਦੀ ਵਰਤੋਂ ਕਰ ਸਕਦੇ ਹੋ, ਜੋ ਕਿ ਮੂਲ ਰੂਪ ਵਿੱਚ ਪੋਸਟਗ੍ਰੇਸ ਹੋਮ ਡਾਇਰੈਕਟਰੀ ਵਿੱਚ ਸਥਿਤ ਹੈ। ਤੁਸੀਂ bash ਸਕ੍ਰਿਪਟਾਂ ਨੂੰ ਛੱਡ ਸਕਦੇ ਹੋ। ਉਦਾਹਰਨ .walg.json ਇਸ ਅੰਕ ਵਿੱਚ ਹੈ
ਵੀਡੀਓ:
ਸਰੋਤ: www.habr.com