PostgreSQL वृद्धिशील बैकअप और पॉइंट-इन-टाइम रिकवरी

पोस्टग्रेएसक्यूएल इंक्रीमेंटल बैकअप और पॉइंट-इन-टाइम रिकवरी आउट ऑफ द बॉक्स करने की क्षमता के साथ आता है। इसे प्राप्त करने के लिए सेटिंग्स और प्रक्रियाओं के बारे में अधिक जानने के लिए पढ़ें।

यह WAL फाइलों से शुरू होता है

वाल आगे लिखें लॉग . के लिए खड़ा है . टिकाऊ और परमाणु लेनदेन प्रदान करने के लिए लगभग सभी आधुनिक आरडीबीएमएस प्रणालियों में वाल का उपयोग किया जाता है।

एकल PostgreSQL सर्वर प्रक्रिया द्वारा प्रबंधित PostgreSQL डेटाबेस क्लस्टर में निहित डेटा में परिवर्तन केवल लेनदेन के माध्यम से संभव है। लेन-देन द्वारा डेटा में किए गए संशोधनों को WAL रिकॉर्ड के आदेशित अनुक्रम के रूप में दर्ज किया जाता है . ये रिकॉर्ड निश्चित-लंबाई वाली फाइलों में लिखे जाते हैं जिन्हें WAL सेगमेंट फाइल . कहा जाता है , या बस WAL फ़ाइलें ।

WAL फ़ाइलें $PGDATA/pg_wal में रहती हैं , जहां $PGDATA डेटाबेस क्लस्टर के लिए डेटा निर्देशिका है। उदाहरण के लिए डिफ़ॉल्ट डेबियन इंस्टॉलेशन पर, मुख्य क्लस्टर के लिए WAL फाइलडायरेक्टरी /var/lib/postgresql/10/main/pg_wal है। . यह इस तरह दिखता है:

# pwd
/var/lib/postgresql/10/main/pg_wal
# ls -l
total 278532
-rw------- 1 postgres postgres 16777216 May  7 08:48 00000001000000000000000B
-rw------- 1 postgres postgres 16777216 May  7 10:08 00000001000000000000000C
-rw------- 1 postgres postgres 16777216 May  7 10:08 00000001000000000000000D
-rw------- 1 postgres postgres 16777216 May  7 10:08 00000001000000000000000E
-rw------- 1 postgres postgres 16777216 May  7 10:08 00000001000000000000000F
-rw------- 1 postgres postgres 16777216 May  7 10:08 000000010000000000000010
-rw------- 1 postgres postgres 16777216 May  7 10:08 000000010000000000000011
-rw------- 1 postgres postgres 16777216 May  7 10:08 000000010000000000000012
-rw------- 1 postgres postgres 16777216 May  7 10:08 000000010000000000000013
-rw------- 1 postgres postgres 16777216 May  7 10:08 000000010000000000000014
-rw------- 1 postgres postgres 16777216 May  7 10:08 000000010000000000000015
-rw------- 1 postgres postgres 16777216 May  7 10:08 000000010000000000000016
-rw------- 1 postgres postgres 16777216 May  7 10:08 000000010000000000000017
-rw------- 1 postgres postgres 16777216 May 16 20:52 000000010000000000000018
-rw------- 1 postgres postgres 16777216 May 16 20:56 000000010000000000000019
-rw------- 1 postgres postgres 16777216 May 26 08:52 00000001000000000000001A
-rw------- 1 postgres postgres 16777216 Jun  2 09:59 00000001000000000000001B
drwx------ 2 postgres postgres     4096 Mar 30 10:06 archive_status

क्लस्टर निर्माण से शुरू होने वाले क्रम में WAL फाइलें क्रमिक रूप से उत्पन्न होती हैं। जब तक क्लस्टर में संशोधन होते हैं, तब तक वे उत्पन्न होते रहते हैं। WAL फ़ाइल तंत्र PostgreSQL के कामकाज के लिए आवश्यक है, और इसे बंद नहीं किया जा सकता है।

परिवर्तनों को पहली बार WAL रिकॉर्ड के रूप में लिखे जाने के बाद, उन्हें डेटा के ऑन-डिस्क प्रतिनिधित्व पर ही लागू करना होगा। इस प्रक्रिया कोचेकपॉइंटिंग . कहा जाता है , और स्वचालित रूप से पृष्ठभूमि में होता है (इसे मैन्युअल रूप से भी मजबूर किया जा सकता है)। जिस बिंदु तक चेकपॉइंटिंग की जाती थी, उसेREDO बिंदु . कहा जाता है . चेकपॉइंटिंग भी पोस्टग्रेज आर्किटेक्चर का एक अनिवार्य हिस्सा है और इसे बंद नहीं किया जा सकता है।

WAL फ़ाइल प्रतिधारण

PostgreSQL सर्वर संचालन के सामान्य क्रम में, WAL फ़ाइलें pg_wal . में लिखी जाती रहेंगी निर्देशिका। लेकिन वे आसपास क्यों हैं?

एक कारण क्रैश रिकवरी है। यदि PostgreSQL सर्वर क्रैश और पुनरारंभ होता है, तो यह अंतिम REDO बिंदु से WAL रिकॉर्ड से डेटा फ़ाइलों (चेकपॉइंटिंग) में परिवर्तन लागू करना शुरू कर देता है। यह गारंटी देता है कि डेटा फ़ाइलें अंतिम पूर्ण लेनदेन के अनुरूप हैं।

एक अन्य कारण स्ट्रीमिंग प्रतिकृति से संबंधित है। स्ट्रीमिंग प्रतिकृति WAL रिकॉर्ड्स को स्टैंडबाय . पर भेजकर काम करती है सर्वर, जो इन्हें स्थानीय रूप से संग्रहीत करते हैं और चौकियों का प्रदर्शन करते हैं। स्टैंडबाय उस सर्वर से पीछे रह सकते हैं जिससे वे प्रतिलिपि बना रहे हैं (जिसे प्राथमिक . कहा जाता है) ) उदाहरण के लिए, यदि प्राथमिक ने 100 WAL रिकॉर्ड बनाए हैं और स्टैंडबाय ने पहले 80 प्राप्त किए हैं और लागू किए हैं, तो सबसे हाल के 20 उपलब्ध होने चाहिए ताकि स्टैंडबाय रिकॉर्ड 81 के बाद से प्राप्त और लागू हो सके।

लेकिन निश्चित रूप से बहुत पुरानी वाल फाइलों को हटाया जा सकता है? हां। PostgreSQL को नवीनतम WAL फ़ाइलों को बनाए रखने और पुराने को हटाने का निर्देश दिया जा सकता है। तीन प्रासंगिक कॉन्फ़िगरेशन विकल्प हैं:

wal_keep_segments - WAL फ़ाइल निर्देशिका में बनाए रखने के लिए नवीनतम WAL फ़ाइलों की न्यूनतम संख्या सेट करता है
max_wal_size - WAL फ़ाइल निर्देशिका में WAL फ़ाइलों का अधिकतम कुल आकार निर्दिष्ट करता है। यदि यह अधिक हो जाता है, तो पुराने हटा दिए जाते हैं। हालांकि, इसके कुछ कारण हो सकते हैं (wal_keep_segments . के लिए उच्च मान सहित) ) जो इस सेटिंग को सम्मानित होने से रोक सकता है।
min_wal_size - वाल फाइलों के लिए न्यूनतम कुल आकार निर्दिष्ट करता है। जब तक वास्तविक आकार इस मान से नीचे रहता है, तब तक कोई भी फाइल नहीं हटाई जाएगी।

वास्तविक जीवन में, पिछली सभी WAL फ़ाइलों को pg_wal के अंतर्गत संग्रहीत करना संभव या आवश्यक नहीं है। निर्देशिका।

WAL फ़ाइल संग्रह

वाल फाइलों का वास्तविक मूल्य यह है कि वे परिवर्तनों की एक धारा हैं जिन्हें पोस्टग्रेएसक्यूएल क्लस्टर की एक सुसंगत प्रतिकृति प्राप्त करने के लिए रिकॉर्ड किया जा सकता है और फिर से चलाया जा सकता है। पोस्टग्रेएसक्यूएल एक ऐसा तरीका प्रदान करता है जिसके द्वारा हम प्रत्येक वाल फाइल को प्राप्त करने के बाद कॉपी (या "संग्रह") कर सकते हैं। बनाया गया - archive_command कॉन्फ़िगरेशन विकल्प।

यह विकल्प एक शेल कमांड स्ट्रिंग को निर्दिष्ट करता है जिसे प्रत्येक WAL फ़ाइल बनाने के बाद लागू किया जाता है। यहां कुछ उदाहरण दिए गए हैं:

# Copy the file to a safe location (like a mounted NFS volume)
archive_command = 'cp %p /mnt/nfs/%f'

# Not overwriting files is a good practice
archive_command = 'test ! -f /mnt/nfs/%f && cp %p /mnt/nfs/%f'

# Copy to S3 bucket
archive_command = 's3cmd put %p s3://BUCKET/path/%f'

# Copy to Google Cloud bucket
archive_command = 'gsutil cp %p gs://BUCKET/path/%f'

# An external script
archive_command = '/opt/scripts/archive_wal %p'

2 अन्य विकल्प भी हैं, जिन्हें सेट किया जाना चाहिए:

# this must be "on" to enable WAL archiving
archive_mode = on

# has to be "replica" (default) or "logical" for WAL archiving
wal_level = replica

WAL संपीड़न

आप WAL फ़ाइलों को किसी दीर्घकालिक/सुरक्षित संग्रहण स्थान में कॉपी करने से पहले उन्हें संपीड़ित कर सकते हैं। हालांकि, wal_compression . नामक एक विकल्प है . इसे चालू करने से PostgreSQL WALfiles के भीतर अलग-अलग WAL रिकॉर्ड को संपीड़ित कर देगा। WAL फ़ाइलें स्वयं एक ही आकार की होंगी (आमतौर पर 16 एमबी), लेकिन इसमें सादे रिकॉर्ड के बजाय संपीड़ित रिकॉर्ड का एक क्रम होगा।

सतत संग्रह करना

WAL संग्रह को सतत संग्रह भी कहा जाता है और प्रभावी है,वृद्धिशील बैकअप ।

वृद्धिशील बैकअप की इस प्रक्रिया को शुरू करने से पहले, एक पूर्ण बैकअप की आवश्यकता होती है। यह एक आधार रेखा स्थापित करता है जिस पर WAL फ़ाइलों को वृद्धिशील रूप से पुनर्स्थापित किया जा सकता है। एक पूर्ण बैकअप या तो लिया जा सकता है:

पोस्टग्रेज सर्वर प्रक्रिया को बंद करना और क्लस्टर डेटाडायरेक्टरी की प्रतिलिपि बनाना (अनुमतियों को संरक्षित करते हुए), या
pg_basebackup का उपयोग करके चल रहे Postgres सर्वर पर।

प्वाइंट-इन-टाइम-रिकवरी (PITR)

PITR एक पूर्ण बैकअप की बहाली से शुरू करने के लिए PostgreSQL की क्षमता को संदर्भित करता है, फिर उत्तरोत्तर संग्रहीत WAL फ़ाइलों को एक निर्दिष्ट टाइमस्टैम्प तक लाता है और लागू करता है।

ऐसा करने के लिए, हमें पुनर्स्थापित क्लस्टर डेटा निर्देशिका में "recovery.conf" नामक एक फ़ाइल बनानी होगी और उस डेटा निर्देशिका के लिए एक पोस्टग्रेस सर्वर शुरू करना होगा। पुनर्प्राप्ति.कॉन्फ़ फ़ाइल में लक्ष्य टाइमस्टैम्प होता है, और यह इस तरह दिखता है:

restore_command = 'cp /tmp/demo/archive/%f "%p"'
recovery_target_time = '2019-06-04 14:10:00'

restore_command निर्दिष्ट करता है कि PostgreSQL द्वारा आवश्यक WAL फ़ाइल कैसे प्राप्त करें। यह आर्काइव_कमांड का विलोम है। recovery_target_time उस समय को निर्दिष्ट करता है जब तक हमें परिवर्तनों की आवश्यकता होती है।

जब एक PostgreSQL सर्वर प्रक्रिया शुरू होती है और एक recovery.conf . का पता लगाती है डेटा निर्देशिका में फ़ाइल, यह "रिकवरी मोड" नामक एक विशेष मोड में शुरू होता है। पुनर्प्राप्ति मोड में, क्लाइंट कनेक्शन अस्वीकार कर दिए जाते हैं। पोस्टग्रेज़ WALफ़ाइलें प्राप्त करता है और उन्हें तब तक लागू करता है जब तक कि पुनर्प्राप्ति लक्ष्य (इस मामले में, निर्दिष्ट टाइमस्टैम्प तक परिवर्तन) प्राप्त नहीं हो जाता। जब लक्ष्य प्राप्त हो जाता है, तो सर्वर डिफ़ॉल्ट रूप से WAL रीप्ले को रोक देता है (अन्य क्रियाएं संभव हैं)। इस बिंदु पर, आपको पुनर्स्थापना की स्थिति की जांच करनी चाहिए और यदि सब कुछ ठीक दिखता है, तो पुनर्प्राप्ति मोड से बाहर निकलने के लिए रुकें और सामान्य ऑपरेशन जारी रखें।

सब को एक साथ रखना

यह सब सिद्धांत और पाठ का एक पूरा समूह था, आइए इसे देखें कि यह व्यवहार में कैसे काम करता है।

सबसे पहले एक नया क्लस्टर इनिशियलाइज़ करें:

/tmp/demo$ pg_ctl -D clus1 initdb
The files belonging to this database system will be owned by user "postgres".
This user must also own the server process.

The database cluster will be initialized with locale "C.UTF-8".
The default database encoding has accordingly been set to "UTF8".
The default text search configuration will be set to "english".

Data page checksums are disabled.

creating directory clus1 ... ok
creating subdirectories ... ok
selecting default max_connections ... 100
selecting default shared_buffers ... 128MB
selecting dynamic shared memory implementation ... posix
creating configuration files ... ok
running bootstrap script ... ok
performing post-bootstrap initialization ... ok
syncing data to disk ... ok

WARNING: enabling "trust" authentication for local connections
You can change this by editing pg_hba.conf or using the option -A, or
--auth-local and --auth-host, the next time you run initdb.

Success. You can now start the database server using:

    /usr/lib/postgresql/10/bin/pg_ctl -D clus1 -l logfile start

हम एक निर्देशिका भी बनाएंगे जो हमारे सुरक्षित भंडारण स्थान के रूप में काम करेगी। आइए इसे "संग्रह" कहते हैं।

/tmp/demo$ mkdir archive
/tmp/demo$ ls -l
total 8
drwxr-xr-x  2 postgres postgres 4096 Jun  4 14:02 archive
drwx------ 19 postgres postgres 4096 Jun  4 14:02 clus1

इससे पहले कि हम सर्वर शुरू कर सकें, हमें पहले चर्चा की गई संग्रह सेटिंग्स को कॉन्फ़िगर करने की आवश्यकता है। तो चलिए निम्नलिखित कोclus1/postgres.conf . के अंत में जोड़ते हैं :

port = 6000
wal_level = logical
archive_mode = on
archive_command = 'cp %p /tmp/demo/archive/%f'
archive_timeout = 60

हमारा आर्काइव कमांड केवल WAL फाइल को हमारे द्वारा पहले बनाई गई आर्काइव डायरेक्टरी में कॉपी करता है।

हमने archive_timeout . भी जोड़ा है सेटिंग। आमतौर पर, WAL फ़ाइल केवल तभी बनाई जाती है जब 16 MB WAL फ़ाइल को भरने के लिए पर्याप्त WAL रिकॉर्ड हों। इसका मतलब है कि कुछ लिखने वाले सर्वरों के लिए, आपको WAL फ़ाइल बनाने के लिए लंबा इंतजार करना पड़ सकता है। सेटिंग आर्काइव_टाइमआउट पोस्टग्रेज़ को बताती है कि उसे जरूरी हर सेकंड में aWAL फ़ाइल बनाएँ, भले ही वह भरी हुई हो या नहीं।

यहां हमने इसे 60 (सेकंड) पर सेट किया है, लेकिन यह केवल डेमो के लिए है! आप आमतौर पर इसे कभी भी इतना कम नहीं रखना चाहेंगे।

आइए "clus1" की एक प्रति भी बनाएं। यह एक पूर्ण बैकअप के बराबर है।

/tmp/demo$ cp -Rp clus1 clus2
/tmp/demo$ ls -l
total 12
drwxr-xr-x  2 postgres postgres 4096 Jun  4 14:02 archive
drwx------ 19 postgres postgres 4096 Jun  4 14:03 clus1
drwx------ 19 postgres postgres 4096 Jun  4 14:03 clus2

अब हम क्लस्टर शुरू कर सकते हैं:

/tmp/demo$ pg_ctl -D clus1 -l log1 start
waiting for server to start.... done
server started

आइए कुछ डेटा जोड़ें।

/tmp/demo$ psql -h /var/run/postgresql -p 6000 postgres
psql (10.8 (Ubuntu 10.8-0ubuntu0.18.04.1))
Type "help" for help.

postgres=# create database demo;
CREATE DATABASE
postgres=# \c demo
You are now connected to database "demo" as user "postgres".
demo=# create table tbl1 (col1 int);
CREATE TABLE
demo=# insert into tbl1 (col1) select generate_series(1, 10000);
INSERT 0 10000
demo=# select count(*) from tbl1;
 count
-------
 10000
(1 row)

demo=# select now();
              now
-------------------------------
 2019-06-04 14:05:05.657871+00
(1 row)

demo=# \q

ध्यान दें कि अब समय 14:05 है। आइए देखें कि हमारा आर्काइव कमांड काम कर रहा है या नहीं:

/tmp/demo$ ls -l archive/
total 16384
-rw------- 1 postgres postgres 16777216 Jun  4 14:04 000000010000000000000001

हाँ, हमारे पास एक एकल संग्रह फ़ाइल है। हमारा आखिरी बदलाव 14:05 बजे था, आइए अब कुछ मिनट प्रतीक्षा करें और फिर कुछ और बदलाव करें।

/tmp/demo$ psql -h /var/run/postgresql -p 6000 demo
psql (10.8 (Ubuntu 10.8-0ubuntu0.18.04.1))
Type "help" for help.

demo=# select now();
              now
-------------------------------
 2019-06-04 14:16:06.093859+00
(1 row)

demo=# select count(*) from tbl1;
 count
-------
 10000
(1 row)

demo=# insert into tbl1 (col1) select generate_series(1, 100);
INSERT 0 100
demo=# select count(*) from tbl1;
 count
-------
 10100
(1 row)

demo=# \q

तो अब हमने 14:16 पर 100 और पंक्तियाँ जोड़ दी हैं। आइए सर्वर को रोकें:

/tmp/demo$ pg_ctl -D clus1 stop
waiting for server to shut down.... done
server stopped
/tmp/demo$

और हमारे संग्रह को दोबारा जांचें:

/tmp/demo$ ls -l archive/
total 65536
-rw------- 1 postgres postgres 16777216 Jun  4 14:04 000000010000000000000001
-rw------- 1 postgres postgres 16777216 Jun  4 14:05 000000010000000000000002
-rw------- 1 postgres postgres 16777216 Jun  4 14:09 000000010000000000000003
-rw------- 1 postgres postgres 16777216 Jun  4 14:16 000000010000000000000004

अछा लगता है। अब हम 14:10 समय तक clus2 की PITR पुनर्प्राप्ति करने का प्रयास करेंगे।

आइए पहले clus2 के postgres.conf को संपादित करें और इन पंक्तियों को अंत में जोड़ें:

port = 6001
archive_mode = off

WAL फ़ाइलों को फिर से चलाने के लिए, हमें PostgreSQL सर्वर को clus2 (जिसे हमने अभी तक शुरू नहीं किया है) को पुनर्प्राप्ति मोड में रखना होगा। ऐसा करने के लिए, clus2 में "recovery.conf" नामक फ़ाइल बनाएं:

/tmp/demo$ cat clus2/recovery.conf
restore_command = 'cp /tmp/demo/archive/%f "%p"'
recovery_target_time = '2019-06-04 14:10:00'

इसमें restore_command . शामिल है जो पहलेarchive_command . के विपरीत है , अर्थात् अनुरोधित फ़ाइल को संग्रह निर्देशिका से pg_wal निर्देशिका में कॉपी करना।

हमने recovery_target_time . भी सेट किया है 14:10 तक।

अब हम clus2 शुरू करते हैं:

/tmp/demo$ pg_ctl -D clus2 -l log2 start
waiting for server to start.... done
server started

क्या हुआ यह देखने के लिए, आइए लॉग फ़ाइल की जाँच करें:

/tmp/demo$ cat log2
2019-06-04 14:19:10.862 UTC [10513] LOG:  listening on IPv4 address "127.0.0.1", port 6001
2019-06-04 14:19:10.864 UTC [10513] LOG:  listening on Unix socket "/var/run/postgresql/.s.PGSQL.6001"
2019-06-04 14:19:10.883 UTC [10514] LOG:  database system was shut down at 2019-06-04 14:02:31 UTC
2019-06-04 14:19:10.883 UTC [10514] LOG:  starting point-in-time recovery to 2019-06-04 14:10:00+00
2019-06-04 14:19:10.903 UTC [10514] LOG:  restored log file "000000010000000000000001" from archive
2019-06-04 14:19:10.930 UTC [10514] LOG:  consistent recovery state reached at 0/16383E8
2019-06-04 14:19:10.930 UTC [10514] LOG:  redo starts at 0/16383E8
2019-06-04 14:19:10.931 UTC [10513] LOG:  database system is ready to accept read only connections
2019-06-04 14:19:11.037 UTC [10514] LOG:  restored log file "000000010000000000000002" from archive
2019-06-04 14:19:11.079 UTC [10514] LOG:  restored log file "000000010000000000000003" from archive
2019-06-04 14:19:11.122 UTC [10514] LOG:  restored log file "000000010000000000000004" from archive
2019-06-04 14:19:11.141 UTC [10514] LOG:  recovery stopping before commit of transaction 559, time 2019-06-04 14:16:24.875517+00
2019-06-04 14:19:11.141 UTC [10514] LOG:  recovery has paused
2019-06-04 14:19:11.141 UTC [10514] HINT:  Execute pg_wal_replay_resume() to continue.

पुनर्प्राप्ति त्वरित थी (वास्तविक जीवन में, इसमें घंटे या दिन लग सकते हैं) और लॉगस्टेट्स कि यह किसी विशेष लेनदेन से पहले बंद हो गया है (जिसमें टाइमस्टैम्प> 14:10 है)। इसमें यह भी कहा गया है कि पुनर्प्राप्ति रोक दी गई है और इसे मैन्युअल रूप से जारी रखा जाना चाहिए।

आइए डेटा की जांच करें:

/tmp/demo$ psql -h /var/run/postgresql -p 6001 demo
psql (10.8 (Ubuntu 10.8-0ubuntu0.18.04.1))
Type "help" for help.

demo=# select count(*) from tbl1;
 count
-------
 10000
(1 row)

हम देखते हैं कि केवल 10000 पंक्तियाँ हैं। 14:16 बजे, हमने 100 और जोड़ दिए, जो तालिका में दिखाई नहीं दिए।

यह अच्छा लग रहा है, तो चलिए फिर से शुरू करते हैं:

demo=# select pg_wal_replay_resume();
 pg_wal_replay_resume
----------------------

(1 row)

लॉग फ़ाइल अब रिपोर्ट करती है कि पुनर्प्राप्ति पूर्ण हो गई है और सामान्य संचालन बहाल हो गए हैं:

2019-06-04 14:20:26.219 UTC [10514] LOG:  redo done at 0/4002160
2019-06-04 14:20:26.219 UTC [10514] LOG:  last completed transaction was at log time 2019-06-04 14:05:28.813325+00
cp: cannot stat '/tmp/demo/archive/00000002.history': No such file or directory
2019-06-04 14:20:26.228 UTC [10514] LOG:  selected new timeline ID: 2
2019-06-04 14:20:26.272 UTC [10514] LOG:  archive recovery complete
cp: cannot stat '/tmp/demo/archive/00000001.history': No such file or directory
2019-06-04 14:20:26.388 UTC [10513] LOG:  database system is ready to accept connections

और हमने एक निर्दिष्ट समय तक क्लस्टर को सफलतापूर्वक पुनर्प्राप्त कर लिया है!

आगे पढ़ना

WAL संग्रह, पुनर्प्राप्ति मोड और PITR के बारे में अधिक जानने के लिए यहां कुछ शुरुआती बिंदु दिए गए हैं:

दस्तावेज़:पुनर्प्राप्ति कॉन्फ़िगरेशन
दस्तावेज़:सतत संग्रह और PITR
अध्याय 9 "द इंटर्नल्स ऑफ़ पोस्टग्रेएसक्यूएल" पुस्तक से
टूल्स:वाल-ई, वाल-जी, बर्मन