Migrate postgres to newer hardware

Re: Migrate postgres to newer hardware

--0016e6d99fa1e346ea048302ed87
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

2010/3/30 Renato Oliveira

> Dear All,
>
> What would be the easiest and fastest way to migrate Postgres 8.2.24 32 B=
IT
> to a new server 64 Bit.
>
> The existing server runs on 32 bit architecture and has a database as big
> as 160GB.
>
> We initially thought of using PITR, but as one of the PITR requirements i=
s
> both machines need to be similar.
>
> This similarity needs to be even in architecture? I think I read somethin=
g
> which says â€=9CYesâ€=9D.
>
> If we cannot use PITR what would be the best approach, we canâ€=99t h=
ave down
> time I am afraid.
>
> Any ideas or suggestions would be very welcome.
>
>
>
I'd use Slony as a replication tool so the data would be copied to the new
serwer while the old still works. After initial copy Slony will copy change=
s
made during making the copy. Later (when the replication lag is small) it
should be enough to stop application, reconfigure it for the new database,
get rid of replication so the new slave database will restore all triggers
and then start the application for using the new database.
Slony uses pure SQL for copying the data so there is no problem with the
differences in the hardware.

regards
Szymon Guz

--0016e6d99fa1e346ea048302ed87
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Re: Migrate postgres to newer hardware

--_000_7965A9DCF12CC14984420BCC37B1608F25AB1AED5DElzargrantc ou_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

U3p5bW9uLA0KDQpXZSBoYWQgU2xvbnkgcnVubmluZyBwcmV2aW91c2x5LCBi dXQgaXQgbGFnZ2Vk
IGJlaGluZCBzbyBiYWRseSB0aGF0IG5ldmVyIG1hbmFnZWQgdG8gY2F0Y2gg dXAuDQoNCkhhcmR3
YXJlDQpBTUQgMS44R0h6IDMyIEJpdHMNCjhHQiBSQU0gRERSMQ0KMzAwR0Ig RGlzayBzaW5nbGUg
dm9sdW1lDQoNCkRhdGFiYXNlOg0KUG9zdGdyZXMgOC4yLjI0DQoxNjBHQiBp biBzaXplDQpUaGVy
ZSBhcmUgdGhvdXNhbmRzIG9mIHRhYmxlcywgYXBwYXJlbnRseSBmb3IgZWFj aCBuZXcgZGV2aWNl
IGEgbmV3IHRhYmxlIGlzIGNyZWF0ZWQuDQoNClRoZSBEQiAgZ3Jvd3MgYXJv dW5kIDFHQiBldmVy
eSAyIGRheXMuDQoNCkRvIHlvdSBzdGlsbCB0aGluayBzbG9ueSB3b3VsZCB3 b3JrPw0KDQpUaGFu
ayB5b3UgdmVyeSBtdWNoDQoNClJlbmF0bw0KDQoNCg0KUmVuYXRvIE9saXZl aXJhDQpTeXN0ZW1z
IEFkbWluaXN0cmF0b3INCmUtbWFpbDogcmVuYXRvLm9saXZlaXJhQGdyYW50 LmNvLnVrDQoNClRl
bDogKzQ0ICgwKTE3NjMgMjYwODExDQpGYXg6ICs0NCAoMCkxNzYzIDI2MjQx MA0Kd3d3LmdyYW50
LmNvLnVrPGh0dHA6Ly93d3cuZ3JhbnQuY28udWsvPg0KDQpHcmFudCBJbnN0 cnVtZW50cyAoQ2Ft
YnJpZGdlKSBMdGQNCg0KQ29tcGFueSByZWdpc3RlcmVkIGluIEVuZ2xhbmQs IHJlZ2lzdHJhdGlv
biBudW1iZXIgNjU4MTMzDQoNClJlZ2lzdGVyZWQgb2ZmaWNlIGFkZHJlc3M6 DQoyOSBTdGF0aW9u
IFJvYWQsDQpTaGVwcmV0aCwNCkNBTUJTIFNHOCA2R0INClVLDQoNCg0KRnJv bTogU3p5bW9uIEd1
eiBbbWFpbHRvOm1hYmV3bHVuQGdtYWlsLmNvbV0NClNlbnQ6IDMwIE1hcmNo IDIwMTAgMTI6MjkN
ClRvOiBSZW5hdG8gT2xpdmVpcmENCkNjOiBwZ3NxbC1hZG1pbkBwb3N0Z3Jl c3FsLm9yZw0KU3Vi
amVjdDogUmU6IFtBRE1JTl0gTWlncmF0ZSBwb3N0Z3JlcyB0byBuZXdlciBo YXJkd2FyZQ0KDQoN
CjIwMTAvMy8zMCBSZW5hdG8gT2xpdmVpcmEgPHJlbmF0by5vbGl2ZWlyYUBn cmFudC5jby51azxt
YWlsdG86cmVuYXRvLm9saXZlaXJhQGdyYW50LmNvLnVrPj4NCkRlYXIgQWxs LA0KV2hhdCB3b3Vs
ZCBiZSB0aGUgZWFzaWVzdCBhbmQgZmFzdGVzdCB3YXkgdG8gbWlncmF0ZSBQ b3N0Z3JlcyA4LjIu
MjQgMzIgQklUIHRvIGEgbmV3IHNlcnZlciA2NCBCaXQuDQpUaGUgZXhpc3Rp bmcgc2VydmVyIHJ1
bnMgb24gMzIgYml0IGFyY2hpdGVjdHVyZSBhbmQgaGFzIGEgZGF0YWJhc2Ug YXMgYmlnIGFzIDE2
MEdCLg0KV2UgaW5pdGlhbGx5IHRob3VnaHQgb2YgdXNpbmcgUElUUiwgYnV0 IGFzIG9uZSBvZiB0
aGUgUElUUiByZXF1aXJlbWVudHMgaXMgYm90aCBtYWNoaW5lcyBuZWVkIHRv IGJlIHNpbWlsYXIu
DQpUaGlzIHNpbWlsYXJpdHkgbmVlZHMgdG8gYmUgZXZlbiBpbiBhcmNoaXRl Y3R1cmU/IEkgdGhp
bmsgSSByZWFkIHNvbWV0aGluZyB3aGljaCBzYXlzIOKAnFllc+KAnS4NCklm IHdlIGNhbm5vdCB1
c2UgUElUUiB3aGF0IHdvdWxkIGJlIHRoZSBiZXN0IGFwcHJvYWNoLCB3ZSBj YW7igJl0IGhhdmUg
ZG93biB0aW1lIEkgYW0gYWZyYWlkLg0KQW55IGlkZWFzIG9yIHN1Z2dlc3Rp b25zIHdvdWxkIGJl
IHZlcnkgd2VsY29tZS4NCg0KDQpJJ2QgdXNlIFNsb255IGFzIGEgcmVwbGlj YXRpb24gdG9vbCBz
byB0aGUgZGF0YSB3b3VsZCBiZSBjb3BpZWQgdG8gdGhlIG5ldyBzZXJ3ZXIg d2hpbGUgdGhlIG9s
ZCBzdGlsbCB3b3Jrcy4gQWZ0ZXIgaW5pdGlhbCBjb3B5IFNsb255IHdpbGwg Y29weSBjaGFuZ2Vz
IG1hZGUgZHVyaW5nIG1ha2luZyB0aGUgY29weS4gTGF0ZXIgKHdoZW4gdGhl IHJlcGxpY2F0aW9u
IGxhZyBpcyBzbWFsbCkgaXQgc2hvdWxkIGJlIGVub3VnaCB0byBzdG9wIGFw cGxpY2F0aW9uLCBy
ZWNvbmZpZ3VyZSBpdCBmb3IgdGhlIG5ldyBkYXRhYmFzZSwgZ2V0IHJpZCBv ZiByZXBsaWNhdGlv
biBzbyB0aGUgbmV3IHNsYXZlIGRhdGFiYXNlIHdpbGwgcmVzdG9yZSBhbGwg dHJpZ2dlcnMgYW5k
IHRoZW4gc3RhcnQgdGhlIGFwcGxpY2F0aW9uIGZvciB1c2luZyB0aGUgbmV3 IGRhdGFiYXNlLg0K
U2xvbnkgdXNlcyBwdXJlIFNRTCBmb3IgY29weWluZyB0aGUgZGF0YSBzbyB0 aGVyZSBpcyBubyBw
cm9ibGVtIHdpdGggdGhlIGRpZmZlcmVuY2VzIGluIHRoZSBoYXJkd2FyZS4N Cg0KcmVnYXJkcw0K
U3p5bW9uIEd1eg0KDQoNCg0KUCBQbGVhc2UgY29uc2lkZXIgdGhlIGVudmly b25tZW50IGJlZm9y
ZSBwcmludGluZyB0aGlzIGVtYWlsDQpDT05GSURFTlRJQUxJVFk6IFRoZSBp bmZvcm1hdGlvbiBp
biB0aGlzIGUtbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGlzIGNvbmZpZGVu dGlhbC4gSXQgaXMg
aW50ZW5kZWQgb25seSBmb3IgdGhlIG5hbWVkIHJlY2lwaWVudHMocykuIElm IHlvdSBhcmUgbm90
IHRoZSBuYW1lZCByZWNpcGllbnQgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVy IGltbWVkaWF0ZWx5
IGFuZCBkbyBub3QgZGlzY2xvc2UgdGhlIGNvbnRlbnRzIHRvIGFub3RoZXIg cGVyc29uIG9yIHRh
a2UgY29waWVzLg0KDQpWSVJVU0VTOiBUaGUgY29udGVudHMgb2YgdGhpcyBl LW1haWwgb3IgYXR0
YWNobWVudChzKSBtYXkgY29udGFpbiB2aXJ1c2VzIHdoaWNoIGNvdWxkIGRh bWFnZSB5b3VyIG93
biBjb21wdXRlciBzeXN0ZW0uIFdoaWxzdCBHcmFudCBJbnN0cnVtZW50cyAo Q2FtYnJpZGdlKSBM
dGQgaGFzIHRha2VuIGV2ZXJ5IHJlYXNvbmFibGUgcHJlY2F1dGlvbiB0byBt aW5pbWlzZSB0aGlz
IHJpc2ssIHdlIGNhbm5vdCBhY2NlcHQgbGlhYmlsaXR5IGZvciBhbnkgZGFt YWdlIHdoaWNoIHlv
dSBzdXN0YWluIGFzIGEgcmVzdWx0IG9mIHNvZnR3YXJlIHZpcnVzZXMuIFlv dSBzaG91bGQgdGhl
cmVmb3JlIGNhcnJ5IG91dCB5b3VyIG93biB2aXJ1cyBjaGVja3MgYmVmb3Jl IG9wZW5pbmcgdGhl
IGF0dGFjaG1lbnQocykuDQoNCk9wZW5YTUw6IEZvciBpbmZvcm1hdGlvbiBh Ym91dCB0aGUgT3Bl
blhNTCBmaWxlIGZvcm1hdCBpbiB1c2Ugd2l0aGluIEdyYW50IEluc3RydW1l bnRzIHBsZWFzZSB2
aXNpdCBvdXIgd2Vic2l0ZTxodHRwOi8vd3d3LmdyYW50LmNvLnVrL1N1cHBv cnQvb3BlbnhtbC5o
dG1sPg0K

--_000_7965A9DCF12CC14984420BCC37B1608F25AB1AED5DElzargrantc ou_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

77u/PEhUTUwgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1odG1s NDAiIHhtbG5zOm09
Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vb2ZmaWNlLzIwMDQvMTIv b21tbCIgeG1sbnM6
bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp2PSJ1cm46
c2NoZW1hcy1taWNyb3NvZnQtY29tOnZtbCIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0
LWNvbTpvZmZpY2U6d29yZCI+PGhlYWQ+PE1FVEEgY29udGVudD0idGV4dC9o dG1sOyBjaGFyc2V0
PXV0Zi04IiBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiPg0KPE1FVEEgY29u dGVudD0idGV4dC9o
dG1sOyBjaGFyc2V0PXV0Zi04IiBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUi Pg0KDQo8bWV0YSBj
b250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiIGh0dHAtZXF1aXY9 Q29udGVudC1UeXBl
Pg0KPG1ldGEgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVk IG1lZGl1bSkiIG5h
bWU9R2VuZXJhdG9yPg0KPHN0eWxlPg0KPCEtLQ0KIC8qIEZvbnQgRGVmaW5p dGlvbnMgKi8NCiBA
Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6 MiAxNSA1IDIgMiAy
IDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7 DQoJcGFub3NlLTE6
MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KIC8qIFN0eWxlIERlZmluaXRpb25z ICovDQogcC5Nc29O
b3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46 MGNtOw0KCW1hcmdp
bi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJUaW1l
cyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVy bGluaw0KCXttc28t
c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29y YXRpb246dW5kZXJs
aW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0K CXttc28tc3R5bGUt
cHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlv bjp1bmRlcmxpbmU7
fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29u YWwtcmVwbHk7DQoJ
Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjoj MUY0OTdEO30NCi5N
c29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5O30N CkBwYWdlIFNlY3Rp
b24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQg NzIuMHB0IDcyLjBw
dCA3Mi4wcHQ7fQ0KZGl2LlNlY3Rpb24xDQoJe3BhZ2U6U2VjdGlvbjE7fQ0K LS0+DQo8L3N0eWxl
Pg0KPCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQogPG86c2hhcGVkZWZhdWx0 cyB2OmV4dD0iZWRp
dCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1b aWYgZ3RlIG1zbyA5
XT48eG1sPg0KIDxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCiAgPG86 aWRtYXAgdjpleHQ9
ImVkaXQiIGRhdGE9IjEiIC8+DQogPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwh W2VuZGlmXS0tPg0K
PC9oZWFkPjxCT0RZPg0KPERJViBTVFlMRT0iRk9OVC1TSVpFOiA5cHQ7IEZP TlQtRkFNSUxZOiBD
b3VyaWVyIE5ldyI+DQo8RElWPg0KPERJVj48Rk9OVCBGQUNFPSJBcmlhbCIg U0laRT0iMiI+DQoN
CjxkaXYgY2xhc3M9U2VjdGlvbjE+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48 c3BhbiBzdHlsZT0n
Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMt c2VyaWYiOw0KY29s
b3I6IzFGNDk3RCc+U3p5bW9uLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0K PHAgY2xhc3M9TXNv
Tm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiJDYWxpYnJp
Iiwic2Fucy1zZXJpZiI7DQpjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48
L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1z aXplOjExLjBwdDtm
b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KY29sb3I6IzFG NDk3RCc+V2UgaGFk
IFNsb255IHJ1bm5pbmcgcHJldmlvdXNseSwgYnV0IGl0IGxhZ2dlZCBiZWhp bmQgc28gYmFkbHkN
CnRoYXQgbmV2ZXIgbWFuYWdlZCB0byBjYXRjaCB1cC48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQoN
CjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEx LjBwdDtmb250LWZh
bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KY29sb3I6IzFGNDk3RCc+ PG86cD4mbmJzcDs8
L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4g c3R5bGU9J2ZvbnQt
c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlm IjsNCmNvbG9yOiMx
RjQ5N0QnPkhhcmR3YXJlPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBj bGFzcz1Nc29Ob3Jt
YWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 IkNhbGlicmkiLCJz
YW5zLXNlcmlmIjsNCmNvbG9yOiMxRjQ5N0QnPkFNRCAxLjhHSHogMzIgQml0 czxvOnA+PC9vOnA+
PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxl PSdmb250LXNpemU6
MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQpj b2xvcjojMUY0OTdE
Jz44R0IgUkFNIEREUjE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNs YXNzPU1zb05vcm1h
bD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToi Q2FsaWJyaSIsInNh
bnMtc2VyaWYiOw0KY29sb3I6IzFGNDk3RCc+MzAwR0IgRGlzayBzaW5nbGUg dm9sdW1lPG86cD48
L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4g c3R5bGU9J2ZvbnQt
c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlm IjsNCmNvbG9yOiMx
RjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xh c3M9TXNvTm9ybWFs
PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fu
cy1zZXJpZiI7DQpjb2xvcjojMUY0OTdEJz5EYXRhYmFzZTo8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+
DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjExLjBwdDtmb250
LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KY29sb3I6IzFGNDk3 RCc+UG9zdGdyZXMg
OC4yLjI0IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNv Tm9ybWFsPjxzcGFu
IHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJp
ZiI7DQpjb2xvcjojMUY0OTdEJz4xNjBHQiBpbiBzaXplPG86cD48L286cD48 L3NwYW4+PC9wPg0K
DQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1m
YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCmNvbG9yOiMxRjQ5N0Qn PlRoZXJlIGFyZSB0
aG91c2FuZHMgb2YgdGFibGVzLCBhcHBhcmVudGx5IGZvciBlYWNoIG5ldyBk ZXZpY2UgYQ0KbmV3
IHRhYmxlIGlzIGNyZWF0ZWQuPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8 cCBjbGFzcz1Nc29O
b3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6IkNhbGlicmki
LCJzYW5zLXNlcmlmIjsNCmNvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwv
cD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNp emU6MTEuMHB0O2Zv
bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQpjb2xvcjojMUY0 OTdEJz5UaGUgREIg
Jm5ic3A7Z3Jvd3MgYXJvdW5kIDFHQiBldmVyeSAyIGRheXMuPG86cD48L286 cD48L3NwYW4+PC9w
Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMS4wcHQ7Zm9u
dC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCmNvbG9yOiMxRjQ5 N0QnPjxvOnA+Jm5i
c3A7PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxz cGFuIHN0eWxlPSdm
b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1z ZXJpZiI7DQpjb2xv
cjojMUY0OTdEJz5EbyB5b3Ugc3RpbGwgdGhpbmsgc2xvbnkgd291bGQgd29y az88bzpwPjwvbzpw
Pjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHls ZT0nZm9udC1zaXpl
OjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0K Y29sb3I6IzFGNDk3
RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1N c29Ob3JtYWw+PHNw
YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNl
cmlmIjsNCmNvbG9yOiMxRjQ5N0QnPlRoYW5rIHlvdSB2ZXJ5IG11Y2g8bzpw PjwvbzpwPjwvc3Bh
bj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjExLjBw
dDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KY29sb3I6 IzFGNDk3RCc+PG86
cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3Jt YWw+PHNwYW4gc3R5
bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJz YW5zLXNlcmlmIjsN
CmNvbG9yOiMxRjQ5N0QnPlJlbmF0bzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N Cg0KPHAgY2xhc3M9
TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiJDYWxp
YnJpIiwic2Fucy1zZXJpZiI7DQpjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNw OzwvbzpwPjwvc3Bh
bj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjExLjBw
dDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KY29sb3I6 IzFGNDk3RCc+PG86
cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KDQo8L0ZPTlQ+PC9ESVY+DQo8 RElWPjxGT05UIEZB
Q0U9IkFyaWFsIiBTSVpFPSIyIj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElW PjxGT05UIEZBQ0U9
IkFyaWFsIiBTSVpFPSIyIj48Rk9OVCBGQUNFPSJBcmlhbCIgU0laRT0iMiI+ UmVuYXRvIE9saXZl
aXJhPEJSPlN5c3RlbXMgQWRtaW5pc3RyYXRvcjxCUj5lLW1haWw6IHJlbmF0 by5vbGl2ZWlyYUBn
cmFudC5jby51azwvRk9OVD48L0ZPTlQ+PEZPTlQgRkFDRT0iQXJpYWwiIFNJ WkU9IjIiPjxGT05U
IEZBQ0U9IkFyaWFsIiBTSVpFPSIyIj48L0ZPTlQ+PC9GT05UPjwvRElWPg0K PERJVj48Rk9OVCBG
QUNFPSJBcmlhbCIgU0laRT0iMiI+PEZPTlQgRkFDRT0iQXJpYWwiIFNJWkU9 IjIiPjwvRk9OVD48
L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIEZBQ0U9IkFyaWFsIiBT SVpFPSIyIj48Rk9O
VCBGQUNFPSJBcmlhbCIgU0laRT0iMiI+VGVsOiArNDQgKDApMTc2MyAyNjA4 MTE8QlI+RmF4OiAr
NDQgKDApMTc2MyAyNjI0MTA8QlI+PEEgSFJFRj0iaHR0cDovL3d3dy5ncmFu dC5jby51ay8iPnd3
dy5ncmFudC5jby51azwvQT48L0ZPTlQ+PC9GT05UPjwvRElWPg0KPERJVj48 Rk9OVCBGQUNFPSJB
cmlhbCIgU0laRT0iMiI+PEZPTlQgRkFDRT0iQXJpYWwiIFNJWkU9IjIiPjwv Rk9OVD48L0ZPTlQ+
Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIEZBQ0U9IkFyaWFsIiBTSVpFPSIy Ij48Rk9OVCBGQUNF
PSJBcmlhbCIgU0laRT0iMiI+R3JhbnQgSW5zdHJ1bWVudHMgKENhbWJyaWRn ZSkgTHRkIDxCUj4m
bmJzcDs8QlI+Q29tcGFueSByZWdpc3RlcmVkIGluIEVuZ2xhbmQsIHJlZ2lz dHJhdGlvbiBudW1i
ZXIgNjU4MTMzPEJSPiZuYnNwOzxCUj5SZWdpc3RlcmVkIG9mZmljZSBhZGRy ZXNzOjxCUj4yOSBT
dGF0aW9uIFJvYWQsIDxCUj5TaGVwcmV0aCwgPEJSPkNBTUJTIFNHOCA2R0Ig PEJSPlVLPC9GT05U
PjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgRkFDRT0iQXJpYWwiIFNJWkU9 IjIiPjxGT05UIEZB
Q0U9IkFyaWFsIiBTSVpFPSIyIj48L0ZPTlQ+PC9GT05UPjxGT05UIEZBQ0U9 IkFyaWFsIiBTSVpF
PSIyIj48Rk9OVCBGQUNFPSJBcmlhbCIgU0laRT0iMiI+PC9GT05UPjwvRk9O VD4mbmJzcDs8L0RJ
Vj4NCjxESVY+PEZPTlQgRkFDRT0iQXJpYWwiIFNJWkU9IjIiPjxGT05UIEZB Q0U9IkFyaWFsIiBT
SVpFPSIyIj48L0ZPTlQ+PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBGQUNF PSJBcmlhbCIgU0la
RT0iMiI+PEZPTlQgRkFDRT0iQXJpYWwiIFNJWkU9IjIiPjwvRk9OVD48L0ZP TlQ+Jm5ic3A7PC9E
SVY+DQo8RElWPjxGT05UIEZBQ0U9IkFyaWFsIiBTSVpFPSIyIj48Rk9OVCBG QUNFPSJBcmlhbCIg
U0laRT0iMiI+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Yj48c3BhbiBsYW5n PUVOLVVTIHN0eWxl
PSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5Og0KIlRhaG9tYSIsInNh bnMtc2VyaWYiJz5G
cm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1z aXplOjEwLjBwdDsN
CmZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+IFN6eW1vbiBH dXogW21haWx0bzpt
YWJld2x1bkBnbWFpbC5jb21dIDxicj4NCjxiPlNlbnQ6PC9iPiAzMCBNYXJj aCAyMDEwIDEyOjI5
PGJyPg0KPGI+VG86PC9iPiBSZW5hdG8gT2xpdmVpcmE8YnI+DQo8Yj5DYzo8 L2I+IHBnc3FsLWFk
bWluQHBvc3RncmVzcWwub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBb QURNSU5dIE1pZ3Jh
dGUgcG9zdGdyZXMgdG8gbmV3ZXIgaGFyZHdhcmU8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQoNCjwv
ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48 L3A+DQoNCjxwIGNs
YXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCg0KPGRpdj4N Cg0KPHAgY2xhc3M9
TXNvTm9ybWFsPjIwMTAvMy8zMCBSZW5hdG8gT2xpdmVpcmEgJmx0OzxhIGhy ZWY9Im1haWx0bzpy
ZW5hdG8ub2xpdmVpcmFAZ3JhbnQuY28udWsiPnJlbmF0by5vbGl2ZWlyYUBn cmFudC5jby51azwv
YT4mZ3Q7PG86cD48L286cD48L3A+DQoNCjxkaXY+DQoNCjxkaXY+DQoNCjxk aXY+DQoNCjxkaXY+
DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1h cmdpbi10b3AtYWx0
OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPkRlYXINCkFsbCw8 bzpwPjwvbzpwPjwv
cD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bztt
c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+V2hhdA0Kd291bGQgYmUgdGhl IGVhc2llc3QgYW5k
IGZhc3Rlc3Qgd2F5IHRvIG1pZ3JhdGUgUG9zdGdyZXMgOC4yLjI0IDMyIEJJ VCB0byBhIG5ldw0K
c2VydmVyIDY0IEJpdC48bzpwPjwvbzpwPjwvcD4NCg0KPHAgY2xhc3M9TXNv Tm9ybWFsIHN0eWxl
PSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byc+VGhl
DQpleGlzdGluZyBzZXJ2ZXIgcnVucyBvbiAzMiBiaXQgYXJjaGl0ZWN0dXJl IGFuZCBoYXMgYSBk
YXRhYmFzZSBhcyBiaWcgYXMgMTYwR0IuPG86cD48L286cD48L3A+DQoNCjxw IGNsYXNzPU1zb05v
cm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0
OmF1dG8nPldlDQppbml0aWFsbHkgdGhvdWdodCBvZiB1c2luZyBQSVRSLCBi dXQgYXMgb25lIG9m
IHRoZSBQSVRSIHJlcXVpcmVtZW50cyBpcyBib3RoDQptYWNoaW5lcyBuZWVk IHRvIGJlIHNpbWls
YXIuPG86cD48L286cD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbCBzdHls ZT0nbXNvLW1hcmdp
bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPlRo aXMNCnNpbWlsYXJp
dHkgbmVlZHMgdG8gYmUgZXZlbiBpbiBhcmNoaXRlY3R1cmU/IEkgdGhpbmsg SSByZWFkIHNvbWV0
aGluZyB3aGljaA0Kc2F5cyDigJxZZXPigJ0uPG86cD48L286cD48L3A+DQoN CjxwIGNsYXNzPU1z
b05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20t
YWx0OmF1dG8nPklmDQp3ZSBjYW5ub3QgdXNlIFBJVFIgd2hhdCB3b3VsZCBi ZSB0aGUgYmVzdCBh
cHByb2FjaCwgd2UgY2Fu4oCZdCBoYXZlIGRvd24gdGltZSBJDQphbSBhZnJh aWQuPG86cD48L286
cD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdp bi10b3AtYWx0OmF1
dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPkFueQ0KaWRlYXMgb3Ig c3VnZ2VzdGlvbnMg
d291bGQgYmUgdmVyeSB3ZWxjb21lLjxvOnA+PC9vOnA+PC9wPg0KDQo8cCBj bGFzcz1Nc29Ob3Jt
YWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDph
dXRvJz48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCg0KPC9kaXY+DQoNCjwvZGl2 Pg0KDQo8L2Rpdj4N
Cg0KPC9kaXY+DQoNCjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29O b3JtYWw+Jm5ic3A7
PG86cD48L286cD48L3A+DQoNCjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFz cz1Nc29Ob3JtYWw+
SSdkIHVzZSBTbG9ueSBhcyBhIHJlcGxpY2F0aW9uIHRvb2wgc28gdGhlIGRh dGEgd291bGQgYmUN
CmNvcGllZCB0byB0aGUgbmV3IHNlcndlciB3aGlsZSB0aGUgb2xkIHN0aWxs IHdvcmtzLiBBZnRl
ciBpbml0aWFsIGNvcHkgU2xvbnkNCndpbGwgY29weSBjaGFuZ2VzIG1hZGUg ZHVyaW5nIG1ha2lu
ZyB0aGUgY29weS4gTGF0ZXIgKHdoZW4gdGhlIHJlcGxpY2F0aW9uIGxhZw0K aXMgc21hbGwpIGl0
IHNob3VsZCBiZSBlbm91Z2ggdG8gc3RvcCBhcHBsaWNhdGlvbiwgcmVjb25m aWd1cmUgaXQgZm9y
IHRoZSBuZXcNCmRhdGFiYXNlLCBnZXQgcmlkIG9mIHJlcGxpY2F0aW9uIHNv IHRoZSBuZXcgc2xh
dmUgZGF0YWJhc2Ugd2lsbCByZXN0b3JlIGFsbA0KdHJpZ2dlcnMgYW5kIHRo ZW4gc3RhcnQgdGhl
IGFwcGxpY2F0aW9uIGZvciB1c2luZyB0aGUgbmV3IGRhdGFiYXNlLjxvOnA+ PC9vOnA+PC9wPg0K
DQo8L2Rpdj4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPlNsb255 IHVzZXMgcHVyZSBT
UUwgZm9yIGNvcHlpbmcgdGhlIGRhdGEgc28gdGhlcmUgaXMgbm8NCnByb2Js ZW0gd2l0aCB0aGUg
ZGlmZmVyZW5jZXMgaW4gdGhlIGhhcmR3YXJlLjxvOnA+PC9vOnA+PC9wPg0K DQo8L2Rpdj4NCg0K
PGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KDQo8L2Rp
dj4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPnJlZ2FyZHM8bzpw PjwvbzpwPjwvcD4N
Cg0KPC9kaXY+DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD5Tenlt b24gR3V6PG86cD48
L286cD48L3A+DQoNCjwvZGl2Pg0KDQo8L2Rpdj4NCg0KPC9kaXY+DQoNCjwv Rk9OVD48L0ZPTlQ+
PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBGQUNFPSJB cmlhbCIgU0laRT0i
MiI+PEZPTlQgRkFDRT0iQXJpYWwiIFNJWkU9IjIiPjwvRk9OVD48L0ZPTlQ+ PC9ESVY+DQo8RElW
PiZuYnNwOzwvRElWPiA8L0RJVj4NCjxESVY+DQo8UCBDTEFTUz0iTXNvTm9y bWFsIj48RU0+PEI+
PFNQQU4gTEFORz0iRU4tVVMiIFNUWUxFPSJGT05ULVNJWkU6IDE4cHQ7IENP TE9SOiBncmVlbjsg
Rk9OVC1GQU1JTFk6IFdlYmRpbmdzIj48L1NQQU4+PC9CPjwvRU0+Jm5ic3A7 PC9QPg0KPFAgQ0xB
U1M9Ik1zb05vcm1hbCI+PEVNPjxCPjxTUEFOIExBTkc9IkVOLVVTIiBTVFlM RT0iRk9OVC1TSVpF
OiAxOHB0OyBDT0xPUjogZ3JlZW47IEZPTlQtRkFNSUxZOiBXZWJkaW5ncyI+ UDwvU1BBTj48L0I+
PC9FTT48RU0+PEI+PFNQQU4gTEFORz0iRU4tVVMiIFNUWUxFPSJGT05ULVNJ WkU6IDEwcHQ7IENP
TE9SOiBibGFjazsgRk9OVC1GQU1JTFk6ICdWZXJkYW5hJywnc2Fucy1zZXJp ZiciPiA8L1NQQU4+
PC9CPjwvRU0+PFNUUk9ORz48ST48U1BBTiBTVFlMRT0iRk9OVC1TSVpFOiA3 LjVwdDsgQ09MT1I6
IGdyZWVuOyBGT05ULUZBTUlMWTogJ0FyaWFsJywnc2Fucy1zZXJpZiciPlBs ZWFzZSBjb25zaWRl
ciB0aGUgZW52aXJvbm1lbnQgYmVmb3JlIHByaW50aW5nIHRoaXMgZW1haWw8 L1NQQU4+PC9JPjwv
U1RST05HPjwvUD48L0RJVj4NCjxESVY+PEZPTlQgRkFDRT0iQXJpYWwiIFNJ WkU9IjIiPjxTVFJP
Tkc+Q09ORklERU5USUFMSVRZPC9TVFJPTkc+OiBUaGUgaW5mb3JtYXRpb24g aW4gdGhpcyBlLW1h
aWwgYW5kIGFueSBhdHRhY2htZW50cyBpcyBjb25maWRlbnRpYWwuIEl0IGlz IGludGVuZGVkIG9u
bHkgZm9yIHRoZSBuYW1lZCByZWNpcGllbnRzKHMpLiBJZiB5b3UgYXJlIG5v dCB0aGUgbmFtZWQg
cmVjaXBpZW50IHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVs eSBhbmQgZG8gbm90
IGRpc2Nsb3NlIHRoZSBjb250ZW50cyB0byBhbm90aGVyIHBlcnNvbiBvciB0 YWtlIGNvcGllcy4g
PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBGQUNFPSJBcmlhbCIgU0laRT0i MiI+PC9GT05UPiZu
YnNwOzwvRElWPg0KPERJVj48Rk9OVCBGQUNFPSJBcmlhbCIgU0laRT0iMiI+ PFNUUk9ORz48L1NU
Uk9ORz48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIEZBQ0U9IkFyaWFsIiBT SVpFPSIyIj48U1RS
T05HPlZJUlVTRVM6PC9TVFJPTkc+IFRoZSBjb250ZW50cyBvZiB0aGlzIGUt bWFpbCBvciBhdHRh
Y2htZW50KHMpIG1heSBjb250YWluIHZpcnVzZXMgd2hpY2ggY291bGQgZGFt YWdlIHlvdXIgb3du
IGNvbXB1dGVyIHN5c3RlbS4gV2hpbHN0IEdyYW50IEluc3RydW1lbnRzIChD YW1icmlkZ2UpIEx0
ZCBoYXMgdGFrZW4gZXZlcnkgcmVhc29uYWJsZSBwcmVjYXV0aW9uIHRvIG1p bmltaXNlIHRoaXMg
cmlzaywgd2UgY2Fubm90IGFjY2VwdCBsaWFiaWxpdHkgZm9yIGFueSBkYW1h Z2Ugd2hpY2ggeW91
IHN1c3RhaW4gYXMgYSByZXN1bHQgb2Ygc29mdHdhcmUgdmlydXNlcy4gWW91 IHNob3VsZCB0aGVy
ZWZvcmUgY2Fycnkgb3V0IHlvdXIgb3duIHZpcnVzIGNoZWNrcyBiZWZvcmUg b3BlbmluZyB0aGUg
YXR0YWNobWVudChzKS48L0ZPTlQ+PC9ESVY+DQo8RElWPiZuYnNwOzwvRElW Pg0KPERJVj48Rk9O
VCBGQUNFPSJBcmlhbCIgU0laRT0iMiI+PC9GT05UPjwvRElWPg0KPERJVj48 Rk9OVCBGQUNFPSJB
cmlhbCIgU0laRT0iMiI+PFNUUk9ORz5PcGVuWE1MPC9TVFJPTkc+OiBGb3Ig aW5mb3JtYXRpb24g
YWJvdXQgdGhlIE9wZW5YTUwgZmlsZSBmb3JtYXQgaW4gdXNlIHdpdGhpbiBH cmFudCBJbnN0cnVt
ZW50cyBwbGVhc2UgdmlzaXQgb3VyIDxBIEhSRUY9Imh0dHA6Ly93d3cuZ3Jh bnQuY28udWsvU3Vw
cG9ydC9vcGVueG1sLmh0bWwiPndlYnNpdGU8L0E+PC9GT05UPjwvRElWPjwv RElWPjwvQk9EWT48
L0hUTUw+DQo=

--_000_7965A9DCF12CC14984420BCC37B1608F25AB1AED5DElzargrantc ou_--

Re: Migrate postgres to newer hardware

On Tue, 2010-03-30 at 12:36 +0100, Renato Oliveira wrote:
> 
> Szymon,
>=20
>
>=20
> We had Slony running previously, but it lagged behind so badly that
> never managed to catch up.
>=20
>
>=20
> Hardware
>=20
> AMD 1.8GHz 32 Bits
>=20
> 8GB RAM DDR1
>=20
> 300GB Disk single volume
>=20
>
>=20
> Database:
>=20
> Postgres 8.2.24=20
>=20
> 160GB in size
>=20
> There are thousands of tables, apparently for each new device a new
> table is created.

I *think* I remember reading a while back case on the Slony list that
some of the internal queries where not very efficient for databases with
large numbers of tables.
>=20
> The DB grows around 1GB every 2 days.

That's not material. We use slony replicate much larger databases with
a higher growth rate than that.
>=20
> Do you still think slony would work?

It might, it might not. I'd ask for assistance on the Slony list.

Also, Londiste is another replication engine that can be used for DB
upgrades.

>
> Renato Oliveira
> Systems Administrator
> e-mail: renato.oliveira@grant.co.uk
>
> Tel: +44 (0)1763 260811
> Fax: +44 (0)1763 262410
> www.grant.co.uk
>
> Grant Instruments (Cambridge) Ltd=20
>
> Company registered in England, registration number 658133
>
> Registered office address:
> 29 Station Road,=20
> Shepreth,=20
> CAMBS SG8 6GB=20
> UK
>
>=20
>
> From: Szymon Guz [mailto:mabewlun@gmail.com]=20
> Sent: 30 March 2010 12:29
> To: Renato Oliveira
> Cc: pgsql-admin@postgresql.org
> Subject: Re: [ADMIN] Migrate postgres to newer hardware
>=20
>=20
>
>=20
>
>=20
> 2010/3/30 Renato Oliveira
>=20
> Dear All,
>=20
> What would be the easiest and fastest way to migrate Postgres 8.2.24
> 32 BIT to a new server 64 Bit.
>=20
> The existing server runs on 32 bit architecture and has a database as
> big as 160GB.
>=20
> We initially thought of using PITR, but as one of the PITR
> requirements is both machines need to be similar.
>=20
> This similarity needs to be even in architecture? I think I read
> something which says â€=9CYesâ€=9D.
>=20
> If we cannot use PITR what would be the best approach, we canâ€=99t h=
ave
> down time I am afraid.
>=20
> Any ideas or suggestions would be very welcome.
>=20
>
>=20
>=20
>
>=20
>=20
> I'd use Slony as a replication tool so the data would be copied to the
> new serwer while the old still works. After initial copy Slony will
> copy changes made during making the copy. Later (when the replication
> lag is small) it should be enough to stop application, reconfigure it
> for the new database, get rid of replication so the new slave database
> will restore all triggers and then start the application for using the
> new database.
>=20
>=20
> Slony uses pure SQL for copying the data so there is no problem with
> the differences in the hardware.
>=20
>=20
>
>=20
>=20
> regards
>=20
>=20
> Szymon Guz
>=20
>=20
>
>=20
>
>
>=20
> P Please consider the environment before printing this email
>=20
>=20
> CONFIDENTIALITY: The information in this e-mail and any attachments is
> confidential. It is intended only for the named recipients(s). If you
> are not the named recipient please notify the sender immediately and
> do not disclose the contents to another person or take copies.=20
>
>=20
> VIRUSES: The contents of this e-mail or attachment(s) may contain
> viruses which could damage your own computer system. Whilst Grant
> Instruments (Cambridge) Ltd has taken every reasonable precaution to
> minimise this risk, we cannot accept liability for any damage which
> you sustain as a result of software viruses. You should therefore
> carry out your own virus checks before opening the attachment(s).
>
>=20
> OpenXML: For information about the OpenXML file format in use within
> Grant Instruments please visit our website
--=20
Brad Nicholson 416-673-4106
Database Administrator, Afilias Canada Corp.



--=20
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin

Re: Migrate postgres to newer hardware

Hi Brad,

Thank you for your reply, really appreciated.

Do you know how much load slony gives to your servers?

Thank you again


Renato




Renato Oliveira
Systems Administrator
e-mail: renato.oliveira@grant.co.uk

Tel: +44 (0)1763 260811
Fax: +44 (0)1763 262410
http://www.grant.co.uk/

Grant Instruments (Cambridge) Ltd

Company registered in England, registration number 658133

Registered office address:
29 Station Road,
Shepreth,
CAMBS SG8 6GB
UK

-----Original Message-----


From: Brad Nicholson [mailto:bnichols@ca.afilias.info]
Sent: 30 March 2010 13:20
To: Renato Oliveira
Cc: Szymon Guz; pgsql-admin@postgresql.org
Subject: Re: [ADMIN] Migrate postgres to newer hardware

On Tue, 2010-03-30 at 12:36 +0100, Renato Oliveira wrote:
> ?
> Szymon,
>
>
>
> We had Slony running previously, but it lagged behind so badly that
> never managed to catch up.
>
>
>
> Hardware
>
> AMD 1.8GHz 32 Bits
>
> 8GB RAM DDR1
>
> 300GB Disk single volume
>
>
>
> Database:
>
> Postgres 8.2.24
>
> 160GB in size
>
> There are thousands of tables, apparently for each new device a new
> table is created.

I *think* I remember reading a while back case on the Slony list that
some of the internal queries where not very efficient for databases with
large numbers of tables.
>
> The DB grows around 1GB every 2 days.

That's not material. We use slony replicate much larger databases with
a higher growth rate than that.
>
> Do you still think slony would work?

It might, it might not. I'd ask for assistance on the Slony list.

Also, Londiste is another replication engine that can be used for DB
upgrades.

>
> Renato Oliveira
> Systems Administrator
> e-mail: renato.oliveira@grant.co.uk
>
> Tel: +44 (0)1763 260811
> Fax: +44 (0)1763 262410
> www.grant.co.uk
>
> Grant Instruments (Cambridge) Ltd
>
> Company registered in England, registration number 658133
>
> Registered office address:
> 29 Station Road,
> Shepreth,
> CAMBS SG8 6GB
> UK
>
>
>
> From: Szymon Guz [mailto:mabewlun@gmail.com]
> Sent: 30 March 2010 12:29
> To: Renato Oliveira
> Cc: pgsql-admin@postgresql.org
> Subject: Re: [ADMIN] Migrate postgres to newer hardware
>
>
>
>
>
>
> 2010/3/30 Renato Oliveira
>
> Dear All,
>
> What would be the easiest and fastest way to migrate Postgres 8.2.24
> 32 BIT to a new server 64 Bit.
>
> The existing server runs on 32 bit architecture and has a database as
> big as 160GB.
>
> We initially thought of using PITR, but as one of the PITR
> requirements is both machines need to be similar.
>
> This similarity needs to be even in architecture? I think I read
> something which says =93Yes=94.
>
> If we cannot use PITR what would be the best approach, we can=92t have
> down time I am afraid.
>
> Any ideas or suggestions would be very welcome.
>
>
>
>
>
>
>
> I'd use Slony as a replication tool so the data would be copied to the
> new serwer while the old still works. After initial copy Slony will
> copy changes made during making the copy. Later (when the replication
> lag is small) it should be enough to stop application, reconfigure it
> for the new database, get rid of replication so the new slave database
> will restore all triggers and then start the application for using the
> new database.
>
>
> Slony uses pure SQL for copying the data so there is no problem with
> the differences in the hardware.
>
>
>
>
>
> regards
>
>
> Szymon Guz
>
>
>
>
>
>
>
> P Please consider the environment before printing this email
>
>
> CONFIDENTIALITY: The information in this e-mail and any attachments is
> confidential. It is intended only for the named recipients(s). If you
> are not the named recipient please notify the sender immediately and
> do not disclose the contents to another person or take copies.
>
>
> VIRUSES: The contents of this e-mail or attachment(s) may contain
> viruses which could damage your own computer system. Whilst Grant
> Instruments (Cambridge) Ltd has taken every reasonable precaution to
> minimise this risk, we cannot accept liability for any damage which
> you sustain as a result of software viruses. You should therefore
> carry out your own virus checks before opening the attachment(s).
>
>
> OpenXML: For information about the OpenXML file format in use within
> Grant Instruments please visit our website
--
Brad Nicholson 416-673-4106
Database Administrator, Afilias Canada Corp.





-----Original Message-----


P Please consider the environment before printing this email
CONFIDENTIALITY: The information in this e-mail and any attachments is conf=
idential. It is intended only for the named recipients(s). If you are not t=
he named recipient please notify the sender immediately and do not disclose=
the contents to another person or take copies.

VIRUSES: The contents of this e-mail or attachment(s) may contain viruses w=
hich could damage your own computer system. Whilst Grant Instruments (Cambr=
idge) Ltd has taken every reasonable precaution to minimise this risk, we c=
annot accept liability for any damage which you sustain as a result of soft=
ware viruses. You should therefore carry out your own virus checks before o=
pening the attachment(s).

OpenXML: For information about the OpenXML file format in use within Grant =
Instruments please visit our http://www.grant.co.uk/Support/openxml.html


--=20
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin

Re: Migrate postgres to newer hardware

--=-G/mW6bAfRWpRtgmXPCR4
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Renato.

I would follow the ancient method: perform a pg_dump / pg_restore

Yes, you will have to take offline database for a long period.

And yes, it would be a great moment to perform a 8.4 upgrade.
Performance is far superior, restore is far faster...=20
.... and yes, it could give you many problems if you don't perform many
test in order to address all queries without explicit type conversions
before real migration, but I think it's the best moment to deal with a
very convenient upgrade. =20

We have performed this upgrade last week with a gforge (with only 25GB
database) and having also to upgrade to new tsearch2 and everything is
running smooth.

-----Original Message-----
From: Renato Oliveira
To: pgsql-admin@postgresql.org
Subject: [ADMIN] Migrate postgres to newer hardware
Date: Tue, 30 Mar 2010 12:18:36 +0100

Dear All,

=20

What would be the easiest and fastest way to migrate Postgres 8.2.24 32
BIT to a new server 64 Bit.

=20

The existing server runs on 32 bit architecture and has a database as
big as 160GB.

=20

We initially thought of using PITR, but as one of the PITR requirements
is both machines need to be similar.=20

This similarity needs to be even in architecture? I think I read
something which says â€=9CYesâ€=9D.

=20

If we cannot use PITR what would be the best approach, we canâ€=99t h=
ave
down time I am afraid.

=20

Any ideas or suggestions would be very welcome.

=20

Thank you very much

=20

Best regards

=20

Renato

=20

=20


=20
Renato Oliveira
Systems Administrator
e-mail: renato.oliveira@grant.co.uk
=20
Tel: +44 (0)1763 260811
Fax: +44 (0)1763 262410
www.grant.co.uk
=20
Grant Instruments (Cambridge) Ltd=20
=20
Company registered in England, registration number 658133
=20
Registered office address:
29 Station Road,=20
Shepreth,=20
CAMBS SG8 6GB=20
UK
=20

=20

=20

=20
=20

P Please consider the environment before printing this email


CONFIDENTIALITY: The information in this e-mail and any attachments is
confidential. It is intended only for the named recipients(s). If you
are not the named recipient please notify the sender immediately and do
not disclose the contents to another person or take copies.=20
=20

VIRUSES: The contents of this e-mail or attachment(s) may contain
viruses which could damage your own computer system. Whilst Grant
Instruments (Cambridge) Ltd has taken every reasonable precaution to
minimise this risk, we cannot accept liability for any damage which you
sustain as a result of software viruses. You should therefore carry out
your own virus checks before opening the attachment(s).
=20

OpenXML: For information about the OpenXML file format in use within
Grant Instruments please visit our website


--=-G/mW6bAfRWpRtgmXPCR4
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: 7bit








Hi Renato.



I would follow the ancient method: perform a pg_dump / pg_restore



Yes, you will have to take offline database for a long period.



And yes, it would be a great moment to perform a 8.4 upgrade. Performance is far superior, restore is far faster...

.... and yes, it could give you many problems if you don't perform many test in order to address all queries without explicit type conversions before real migration, but I think it's the best moment to deal with a very convenient upgrade. 



We have performed this upgrade last week with a gforge (with only 25GB database) and having also to upgrade to new tsearch2 and everything is running smooth.



-----Original Message-----

From: Renato Oliveira <>

To: pgsql-admin@postgresql.org <>

Subject: [ADMIN] Migrate postgres to newer hardware

Date: Tue, 30 Mar 2010 12:18:36 +0100



Dear All,



 



What would be the easiest and fastest way to migrate Postgres 8.2.24 32 BIT to a new server 64 Bit.



 



The existing server runs on 32 bit architecture and has a database as big as 160GB.



 



We initially thought of using PITR, but as one of the PITR requirements is both machines need to be similar.



This similarity needs to be even in architecture? I think I read something which says “Yes”.



 



If we cannot use PITR what would be the best approach, we can’t have down time I am afraid.



 



Any ideas or suggestions would be very welcome.



 



Thank you very much



 



Best regards



 



Renato



 



 





 
Renato Oliveira

Systems Administrator

e-mail: renato.oliveira@grant.co.uk
 
Tel: +44 (0)1763 260811

Fax: +44 (0)1763 262410


 
Grant Instruments (Cambridge) Ltd

 

Company registered in England, registration number 658133

 

Registered office address:

29 Station Road,

Shepreth,

CAMBS SG8 6GB

UK
 


 


 


 
 



P Please consider the environment before printing this email





CONFIDENTIALITY: The information in this e-mail and any attachments is confidential. It is intended only for the named recipients(s). If you are not the named recipient please notify the sender immediately and do not disclose the contents to another person or take copies.
 


VIRUSES: The contents of this e-mail or attachment(s) may contain viruses which could damage your own computer system. Whilst Grant Instruments (Cambridge) Ltd has taken every reasonable precaution to minimise this risk, we cannot accept liability for any damage which you sustain as a result of software viruses. You should therefore carry out your own virus checks before opening the attachment(s).
 


OpenXML: For information about the OpenXML file format in use within Grant Instruments please visit our





--=-G/mW6bAfRWpRtgmXPCR4--

Re: Migrate postgres to newer hardware

On Tue, 2010-03-30 at 16:29 +0200, Iñigo Martinez Lasala wrote:
> Hi Renato.
>=20
> I would follow the ancient method: perform a pg_dump / pg_restore

This is the easiest approach. The problem is that a lot of people have
contractual SLA's that do not allow them to take their systems down long
enough to do a dump and restore upgrade.

--=20
Brad Nicholson 416-673-4106
Database Administrator, Afilias Canada Corp.



--=20
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin

Re: Migrate postgres to newer hardware

Hi Renato,

dump/restore is the way to go. I suppose, you don't want to compile
Postgres for 32 bit on the new machine which might work and might allow
you to do the PITR migration.

And "downtime is not an option" is always a sign of insufficient
planning beforehand. There is no system which doesn't need an upgrade or
reboot or whatever, so there will be downtime and it needs to be
considered during system analysis.

In my experience, it is often just a matter of communicating: "Because
of hardware upgrades, the system XYZ will not be available on ..."

After all the switch won't be without interruption - you need to switch
to the new server anyway.

Tino, having migrated a 300+ GB database.

On Tue, Mar 30, 2010 at 04:29:29PM +0200, Iñigo Martinez Lasala wrot=
e:

> I would follow the ancient method: perform a pg_dump / pg_restore
>=20
> Yes, you will have to take offline database for a long period.
>=20
> And yes, it would be a great moment to perform a 8.4 upgrade.
> Performance is far superior, restore is far faster...=20
> ... and yes, it could give you many problems if you don't perform many
> test in order to address all queries without explicit type conversions
> before real migration, but I think it's the best moment to deal with a
> very convenient upgrade. =20
>=20
> We have performed this upgrade last week with a gforge (with only 25GB
> database) and having also to upgrade to new tsearch2 and everything is
> running smooth.
>=20
> -----Original Message-----
> From: Renato Oliveira
> To: pgsql-admin@postgresql.org
> Subject: [ADMIN] Migrate postgres to newer hardware
> Date: Tue, 30 Mar 2010 12:18:36 +0100
>=20
> Dear All,
>=20
> =20
>=20
> What would be the easiest and fastest way to migrate Postgres 8.2.24 32
> BIT to a new server 64 Bit.
>=20
> =20
>=20
> The existing server runs on 32 bit architecture and has a database as
> big as 160GB.
>=20
> =20
>=20
> We initially thought of using PITR, but as one of the PITR requirements
> is both machines need to be similar.=20
>=20
> This similarity needs to be even in architecture? I think I read
> something which says â€=9CYesâ€=9D.
>=20
> =20
>=20
> If we cannot use PITR what would be the best approach, we canâ€=99t=
have
> down time I am afraid.
>=20
> =20
>=20
> Any ideas or suggestions would be very welcome.
>=20
> =20
>=20
> Thank you very much
>=20
> =20
>=20
> Best regards
>=20
> =20
>=20
> Renato
>=20
> =20
>=20
> =20
>=20
>=20
> =20
> Renato Oliveira
> Systems Administrator
> e-mail: renato.oliveira@grant.co.uk
> =20
> Tel: +44 (0)1763 260811
> Fax: +44 (0)1763 262410
> www.grant.co.uk
> =20
> Grant Instruments (Cambridge) Ltd=20
> =20
> Company registered in England, registration number 658133
> =20
> Registered office address:
> 29 Station Road,=20
> Shepreth,=20
> CAMBS SG8 6GB=20
> UK
> =20
>=20
> =20
>=20
> =20
>=20
> =20
> =20
>=20
> P Please consider the environment before printing this email
>=20
>=20
> CONFIDENTIALITY: The information in this e-mail and any attachments is
> confidential. It is intended only for the named recipients(s). If you
> are not the named recipient please notify the sender immediately and do
> not disclose the contents to another person or take copies.=20
> =20
>=20
> VIRUSES: The contents of this e-mail or attachment(s) may contain
> viruses which could damage your own computer system. Whilst Grant
> Instruments (Cambridge) Ltd has taken every reasonable precaution to
> minimise this risk, we cannot accept liability for any damage which you
> sustain as a result of software viruses. You should therefore carry out
> your own virus checks before opening the attachment(s).
> =20
>=20
> OpenXML: For information about the OpenXML file format in use within
> Grant Instruments please visit our website
>=20

--=20
"What we nourish flourishes." - "Was wir nähren erblüht."

www.lichtkreis-chemnitz.de
www.tisc.de

--=20
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin

Re: Migrate postgres to newer hardware

That is very true and well pointed out.





Renato Oliveira
Systems Administrator
e-mail: renato.oliveira@grant.co.uk

Tel: +44 (0)1763 260811
Fax: +44 (0)1763 262410
http://www.grant.co.uk/

Grant Instruments (Cambridge) Ltd

Company registered in England, registration number 658133

Registered office address:
29 Station Road,
Shepreth,
CAMBS SG8 6GB
UK

-----Original Message-----


From: Brad Nicholson [mailto:bnichols@ca.afilias.info]
Sent: 30 March 2010 15:38
To: I=F1igo Martinez Lasala
Cc: Renato Oliveira; pgsql-admin
Subject: Re: [ADMIN] Migrate postgres to newer hardware

On Tue, 2010-03-30 at 16:29 +0200, I=F1igo Martinez Lasala wrote:
> Hi Renato.
>
> I would follow the ancient method: perform a pg_dump / pg_restore

This is the easiest approach. The problem is that a lot of people have
contractual SLA's that do not allow them to take their systems down long
enough to do a dump and restore upgrade.

--
Brad Nicholson 416-673-4106
Database Administrator, Afilias Canada Corp.





-----Original Message-----


P Please consider the environment before printing this email
CONFIDENTIALITY: The information in this e-mail and any attachments is conf=
idential. It is intended only for the named recipients(s). If you are not t=
he named recipient please notify the sender immediately and do not disclose=
the contents to another person or take copies.

VIRUSES: The contents of this e-mail or attachment(s) may contain viruses w=
hich could damage your own computer system. Whilst Grant Instruments (Cambr=
idge) Ltd has taken every reasonable precaution to minimise this risk, we c=
annot accept liability for any damage which you sustain as a result of soft=
ware viruses. You should therefore carry out your own virus checks before o=
pening the attachment(s).

OpenXML: For information about the OpenXML file format in use within Grant =
Instruments please visit our http://www.grant.co.uk/Support/openxml.html


--=20
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin

Re: Migrate postgres to newer hardware

If I use postgres 32 bit will it benefit from the extra memory on the syste=
m?

I don't think it will.

Thank you very much

Renato



Renato Oliveira
Systems Administrator
e-mail: renato.oliveira@grant.co.uk

Tel: +44 (0)1763 260811
Fax: +44 (0)1763 262410
http://www.grant.co.uk/

Grant Instruments (Cambridge) Ltd

Company registered in England, registration number 658133

Registered office address:
29 Station Road,
Shepreth,
CAMBS SG8 6GB
UK

-----Original Message-----


From: pgsql-admin-owner@postgresql.org [mailto:pgsql-admin-owner@postgresql=
..org] On Behalf Of Tino Schwarze
Sent: 30 March 2010 15:39
To: pgsql-admin@postgresql.org
Subject: Re: [ADMIN] Migrate postgres to newer hardware

Hi Renato,

dump/restore is the way to go. I suppose, you don't want to compile
Postgres for 32 bit on the new machine which might work and might allow
you to do the PITR migration.

And "downtime is not an option" is always a sign of insufficient
planning beforehand. There is no system which doesn't need an upgrade or
reboot or whatever, so there will be downtime and it needs to be
considered during system analysis.

In my experience, it is often just a matter of communicating: "Because
of hardware upgrades, the system XYZ will not be available on ..."

After all the switch won't be without interruption - you need to switch
to the new server anyway.

Tino, having migrated a 300+ GB database.

On Tue, Mar 30, 2010 at 04:29:29PM +0200, I=F1igo Martinez Lasala wrote:

> I would follow the ancient method: perform a pg_dump / pg_restore
>
> Yes, you will have to take offline database for a long period.
>
> And yes, it would be a great moment to perform a 8.4 upgrade.
> Performance is far superior, restore is far faster...
> ... and yes, it could give you many problems if you don't perform many
> test in order to address all queries without explicit type conversions
> before real migration, but I think it's the best moment to deal with a
> very convenient upgrade.
>
> We have performed this upgrade last week with a gforge (with only 25GB
> database) and having also to upgrade to new tsearch2 and everything is
> running smooth.
>
> -----Original Message-----
> From: Renato Oliveira
> To: pgsql-admin@postgresql.org
> Subject: [ADMIN] Migrate postgres to newer hardware
> Date: Tue, 30 Mar 2010 12:18:36 +0100
>
> Dear All,
>
>
>
> What would be the easiest and fastest way to migrate Postgres 8.2.24 32
> BIT to a new server 64 Bit.
>
>
>
> The existing server runs on 32 bit architecture and has a database as
> big as 160GB.
>
>
>
> We initially thought of using PITR, but as one of the PITR requirements
> is both machines need to be similar.
>
> This similarity needs to be even in architecture? I think I read
> something which says =93Yes=94.
>
>
>
> If we cannot use PITR what would be the best approach, we can=92t have
> down time I am afraid.
>
>
>
> Any ideas or suggestions would be very welcome.
>
>
>
> Thank you very much
>
>
>
> Best regards
>
>
>
> Renato
>
>
>
>
>
>
>
> Renato Oliveira
> Systems Administrator
> e-mail: renato.oliveira@grant.co.uk
>
> Tel: +44 (0)1763 260811
> Fax: +44 (0)1763 262410
> www.grant.co.uk
>
> Grant Instruments (Cambridge) Ltd
>
> Company registered in England, registration number 658133
>
> Registered office address:
> 29 Station Road,
> Shepreth,
> CAMBS SG8 6GB
> UK
>
>
>
>
>
>
>
>
>
> P Please consider the environment before printing this email
>
>
> CONFIDENTIALITY: The information in this e-mail and any attachments is
> confidential. It is intended only for the named recipients(s). If you
> are not the named recipient please notify the sender immediately and do
> not disclose the contents to another person or take copies.
>
>
> VIRUSES: The contents of this e-mail or attachment(s) may contain
> viruses which could damage your own computer system. Whilst Grant
> Instruments (Cambridge) Ltd has taken every reasonable precaution to
> minimise this risk, we cannot accept liability for any damage which you
> sustain as a result of software viruses. You should therefore carry out
> your own virus checks before opening the attachment(s).
>
>
> OpenXML: For information about the OpenXML file format in use within
> Grant Instruments please visit our website
>

--
"What we nourish flourishes." - "Was wir nähren erblüht."

www.lichtkreis-chemnitz.de
www.tisc.de

--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin



-----Original Message-----


P Please consider the environment before printing this email
CONFIDENTIALITY: The information in this e-mail and any attachments is conf=
idential. It is intended only for the named recipients(s). If you are not t=
he named recipient please notify the sender immediately and do not disclose=
the contents to another person or take copies.

VIRUSES: The contents of this e-mail or attachment(s) may contain viruses w=
hich could damage your own computer system. Whilst Grant Instruments (Cambr=
idge) Ltd has taken every reasonable precaution to minimise this risk, we c=
annot accept liability for any damage which you sustain as a result of soft=
ware viruses. You should therefore carry out your own virus checks before o=
pening the attachment(s).

OpenXML: For information about the OpenXML file format in use within Grant =
Instruments please visit our http://www.grant.co.uk/Support/openxml.html


--=20
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin

Re: Migrate postgres to newer hardware

Are there any commercial solutions out there for migrating large DBs?

Renato



Renato Oliveira
Systems Administrator
e-mail: renato.oliveira@grant.co.uk

Tel: +44 (0)1763 260811
Fax: +44 (0)1763 262410
http://www.grant.co.uk/

Grant Instruments (Cambridge) Ltd

Company registered in England, registration number 658133

Registered office address:
29 Station Road,
Shepreth,
CAMBS SG8 6GB
UK

-----Original Message-----


From: pgsql-admin-owner@postgresql.org [mailto:pgsql-admin-owner@postgresql=
..org] On Behalf Of Tino Schwarze
Sent: 30 March 2010 15:39
To: pgsql-admin@postgresql.org
Subject: Re: [ADMIN] Migrate postgres to newer hardware

Hi Renato,

dump/restore is the way to go. I suppose, you don't want to compile
Postgres for 32 bit on the new machine which might work and might allow
you to do the PITR migration.

And "downtime is not an option" is always a sign of insufficient
planning beforehand. There is no system which doesn't need an upgrade or
reboot or whatever, so there will be downtime and it needs to be
considered during system analysis.

In my experience, it is often just a matter of communicating: "Because
of hardware upgrades, the system XYZ will not be available on ..."

After all the switch won't be without interruption - you need to switch
to the new server anyway.

Tino, having migrated a 300+ GB database.

On Tue, Mar 30, 2010 at 04:29:29PM +0200, I=F1igo Martinez Lasala wrote:

> I would follow the ancient method: perform a pg_dump / pg_restore
>
> Yes, you will have to take offline database for a long period.
>
> And yes, it would be a great moment to perform a 8.4 upgrade.
> Performance is far superior, restore is far faster...
> ... and yes, it could give you many problems if you don't perform many
> test in order to address all queries without explicit type conversions
> before real migration, but I think it's the best moment to deal with a
> very convenient upgrade.
>
> We have performed this upgrade last week with a gforge (with only 25GB
> database) and having also to upgrade to new tsearch2 and everything is
> running smooth.
>
> -----Original Message-----
> From: Renato Oliveira
> To: pgsql-admin@postgresql.org
> Subject: [ADMIN] Migrate postgres to newer hardware
> Date: Tue, 30 Mar 2010 12:18:36 +0100
>
> Dear All,
>
>
>
> What would be the easiest and fastest way to migrate Postgres 8.2.24 32
> BIT to a new server 64 Bit.
>
>
>
> The existing server runs on 32 bit architecture and has a database as
> big as 160GB.
>
>
>
> We initially thought of using PITR, but as one of the PITR requirements
> is both machines need to be similar.
>
> This similarity needs to be even in architecture? I think I read
> something which says =93Yes=94.
>
>
>
> If we cannot use PITR what would be the best approach, we can=92t have
> down time I am afraid.
>
>
>
> Any ideas or suggestions would be very welcome.
>
>
>
> Thank you very much
>
>
>
> Best regards
>
>
>
> Renato
>
>
>
>
>
>
>
> Renato Oliveira
> Systems Administrator
> e-mail: renato.oliveira@grant.co.uk
>
> Tel: +44 (0)1763 260811
> Fax: +44 (0)1763 262410
> www.grant.co.uk
>
> Grant Instruments (Cambridge) Ltd
>
> Company registered in England, registration number 658133
>
> Registered office address:
> 29 Station Road,
> Shepreth,
> CAMBS SG8 6GB
> UK
>
>
>
>
>
>
>
>
>
> P Please consider the environment before printing this email
>
>
> CONFIDENTIALITY: The information in this e-mail and any attachments is
> confidential. It is intended only for the named recipients(s). If you
> are not the named recipient please notify the sender immediately and do
> not disclose the contents to another person or take copies.
>
>
> VIRUSES: The contents of this e-mail or attachment(s) may contain
> viruses which could damage your own computer system. Whilst Grant
> Instruments (Cambridge) Ltd has taken every reasonable precaution to
> minimise this risk, we cannot accept liability for any damage which you
> sustain as a result of software viruses. You should therefore carry out
> your own virus checks before opening the attachment(s).
>
>
> OpenXML: For information about the OpenXML file format in use within
> Grant Instruments please visit our website
>

--
"What we nourish flourishes." - "Was wir nähren erblüht."

www.lichtkreis-chemnitz.de
www.tisc.de

--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin



-----Original Message-----


P Please consider the environment before printing this email
CONFIDENTIALITY: The information in this e-mail and any attachments is conf=
idential. It is intended only for the named recipients(s). If you are not t=
he named recipient please notify the sender immediately and do not disclose=
the contents to another person or take copies.

VIRUSES: The contents of this e-mail or attachment(s) may contain viruses w=
hich could damage your own computer system. Whilst Grant Instruments (Cambr=
idge) Ltd has taken every reasonable precaution to minimise this risk, we c=
annot accept liability for any damage which you sustain as a result of soft=
ware viruses. You should therefore carry out your own virus checks before o=
pening the attachment(s).

OpenXML: For information about the OpenXML file format in use within Grant =
Instruments please visit our http://www.grant.co.uk/Support/openxml.html


--=20
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin

Re: Migrate postgres to newer hardware

We had a similar situation last week, 32-bit to 64-bit OS. We decided to ke=
ep our PostgreSQL 32-bit (our backup/replication servers are still running =
32-bit). We are running it on a 64-bit xen image. We used the package manag=
er to install the 32-bit binaries. Building cross-platform is tricky, so we=
avoided it.

We then did the easy rsync method. With the old DB running, new DB stopped:
1) rsync the /data/ directory
1b) rsync it again (for large DBs, this will get any changes since the long=
initial rsync)
2) shutdown the old DB
3) final rsync (took us 20 minutes on 5GB)
4) starup new DB

Matt

-----Original Message-----
From: pgsql-admin-owner@postgresql.org [mailto:pgsql-admin-owner@postgresql=
..org] On Behalf Of Tino Schwarze
Sent: Tuesday, March 30, 2010 9:39 AM
To: pgsql-admin@postgresql.org
Subject: Re: [ADMIN] Migrate postgres to newer hardware

Hi Renato,

dump/restore is the way to go. I suppose, you don't want to compile
Postgres for 32 bit on the new machine which might work and might allow
you to do the PITR migration.

And "downtime is not an option" is always a sign of insufficient
planning beforehand. There is no system which doesn't need an upgrade or
reboot or whatever, so there will be downtime and it needs to be
considered during system analysis.

In my experience, it is often just a matter of communicating: "Because
of hardware upgrades, the system XYZ will not be available on ..."

After all the switch won't be without interruption - you need to switch
to the new server anyway.

Tino, having migrated a 300+ GB database.

On Tue, Mar 30, 2010 at 04:29:29PM +0200, Iñigo Martinez Lasala wrote:

> I would follow the ancient method: perform a pg_dump / pg_restore
>=20
> Yes, you will have to take offline database for a long period.
>=20
> And yes, it would be a great moment to perform a 8.4 upgrade.
> Performance is far superior, restore is far faster...=20
> ... and yes, it could give you many problems if you don't perform many
> test in order to address all queries without explicit type conversions
> before real migration, but I think it's the best moment to deal with a
> very convenient upgrade.
>=20
> We have performed this upgrade last week with a gforge (with only 25GB
> database) and having also to upgrade to new tsearch2 and everything is
> running smooth.
>=20
> -----Original Message-----
> From: Renato Oliveira
> To: pgsql-admin@postgresql.org
> Subject: [ADMIN] Migrate postgres to newer hardware
> Date: Tue, 30 Mar 2010 12:18:36 +0100
>=20
> Dear All,
>=20
>
>=20
> What would be the easiest and fastest way to migrate Postgres 8.2.24 32
> BIT to a new server 64 Bit.
>=20
>
>=20
> The existing server runs on 32 bit architecture and has a database as
> big as 160GB.
>=20
>
>=20
> We initially thought of using PITR, but as one of the PITR requirements
> is both machines need to be similar.=20
>=20
> This similarity needs to be even in architecture? I think I read
> something which says â€=9CYesâ€=9D.
>=20
>
>=20
> If we cannot use PITR what would be the best approach, we canâ€=99t h=
ave
> down time I am afraid.
>=20
>
>=20
> Any ideas or suggestions would be very welcome.
>=20
>
>=20
> Thank you very much
>=20
>
>=20
> Best regards
>=20
>
>=20
> Renato
>=20
>
>=20
>
>=20
>=20
>
> Renato Oliveira
> Systems Administrator
> e-mail: renato.oliveira@grant.co.uk
>
> Tel: +44 (0)1763 260811
> Fax: +44 (0)1763 262410
> www.grant.co.uk
>
> Grant Instruments (Cambridge) Ltd=20
>
> Company registered in England, registration number 658133
>
> Registered office address:
> 29 Station Road,=20
> Shepreth,=20
> CAMBS SG8 6GB=20
> UK
>
>=20
>
>=20
>
>=20
>
>
>=20
> P Please consider the environment before printing this email
>=20
>=20
> CONFIDENTIALITY: The information in this e-mail and any attachments is
> confidential. It is intended only for the named recipients(s). If you
> are not the named recipient please notify the sender immediately and do
> not disclose the contents to another person or take copies.=20
>
>=20
> VIRUSES: The contents of this e-mail or attachment(s) may contain
> viruses which could damage your own computer system. Whilst Grant
> Instruments (Cambridge) Ltd has taken every reasonable precaution to
> minimise this risk, we cannot accept liability for any damage which you
> sustain as a result of software viruses. You should therefore carry out
> your own virus checks before opening the attachment(s).
>
>=20
> OpenXML: For information about the OpenXML file format in use within
> Grant Instruments please visit our website
>=20

--=20
"What we nourish flourishes." - "Was wir nähren erblüht."

www.lichtkreis-chemnitz.de
www.tisc.de

--=20
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin


--=20
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin

Re: Migrate postgres to newer hardware

2010/3/30 Renato Oliveira :
> If I use postgres 32 bit will it benefit from the extra memory on the system?
>
> I don't think it will.
>
> Thank you very much
>
> Renato
>

Depending on the system, with a 32Bit OS you can only address 2 or 3
GB of continuous memory. 64Bit OS's have not this limitation.

--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin

Re: Migrate postgres to newer hardware

Renato Oliveira writes:
> If I use postgres 32 bit will it benefit from the extra memory on the system?

Yes, although perhaps not as much as you'd get with a 64-bit build.
You still get the ability to have more than 4GB worth of kernel-managed
disk cache, and in many situations that's all the value of a 64-bit
machine anyway. You can find lots and lots about that in the
pgsql-performance archives.

regards, tom lane

--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin

Re: Migrate postgres to newer hardware

On Tue, Mar 30, 2010 at 8:51 AM, Renato Oliveira
wrote:
> If I use postgres 32 bit will it benefit from the extra memory on the system?

Indirectly, yes. No individual PG process will be able to address
more than 4 gbytes of memory. Assuming you have a 64-bit OS living
underneath, however, that may not matter much. You'll potentially be
somewhat constrained in the sane values you can use for shared_buffers
(which, on a 16 gbyte box for example, I'd probably start in the 4
gbyte range and tune from there -- not an option in a 32-bit install).

But leaving aside effective_cache_size (and, as mentioned, potentially
shared_buffers), none of your config values are likely to approach the
4 gbyte boundary -- and in the case of effective_cache_size, that
isn't actually directly addressed by postgres, anyway. It's just used
by the planner to calculate the likelihood of a given page it needs
being in the OS buffer cache, instead of on disk.

I've had production systems with a 32-bit postgres running quite
happily on a 64-bit OS.

rls

--
:wq

--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin

Re: Migrate postgres to newer hardware

--=-77Ej586WkG6NxkQMUI6t
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Yes, you only have that two possibilities, I think.

PITR is not an option. I tested the same, from 7.4 32bit to 7.4 64bit
and didn't work. Later, when I asked here, I was told why not.

The problem with slony is that you have to manually create tables in
destination database and all database model (procedures, triggers,
sequences, views, etc). If your application creates new tables, you will
have to deal with this prior starting migration, or at least disable the
creation of new tables.

Slony is asynchronous, so you will have to ensure that all changes have
been committed to new database before changing your applications or
exchanging IP addresses.
Slony also add many triggers and special tables to both databases
(master and slave). So, after migration, you will have to delete them.
It's not difficult but don't forget to do it.

By the way, are you sure your database is 160GB? Including indexes?
There are strategies in order to perform a faster pg_restore...=20
For example, if you migrate your database schema but don't create
indexes, then migrate data and finally create pending indexes restore
will be faster. With pg 8.4 restore is very fast, so it will take less
time that export.

Anyway, if you cannot leave database down for a day, I think slony will
be your best bet, although it's not exempt of problems. :)

-----Original Message-----
From: Renato Oliveira
To: Iñigo Martinez Lasala
Subject: RE: [ADMIN] Migrate postgres to newer hardware
Date: Tue, 30 Mar 2010 15:47:27 +0100


Hey Iñigo,

=20

Thank you very much for your reply.

=20

I would love to do just that, but unfortunately I canâ€=99t it is not=
as
simple as that.

=20

I would love if the application had been built in with this in mindâ€=
=A6

=20

To give you an idea; the pg_dump takes 15 hours and I attempted a
restore yesterday and it took 14 hours and 21 min.

It would not be viable for us and specially I cannot have the system
down more than maximum 30 min without the risk of losing data and
customers not having alerts.

=20

I donâ€=99t think I will be able to use PITR to migrate to new server=
s
specially if it is 64 bit and to migrate to another 32 bit is no gain,
as we need more memory.

=20

As far as can gather there are only two ways:

a) Slony type

b) Pg_dump

=20

Is that correct ? Do you guys have any other ways?

=20

Renato

=20

=20


=20
Renato Oliveira
Systems Administrator
e-mail: renato.oliveira@grant.co.uk
=20
Tel: +44 (0)1763 260811
Fax: +44 (0)1763 262410
www.grant.co.uk
=20
Grant Instruments (Cambridge) Ltd=20
=20
Company registered in England, registration number 658133
=20
Registered office address:
29 Station Road,=20
Shepreth,=20
CAMBS SG8 6GB=20
UK
=20

=20
From: Iñigo Martinez Lasala [mailto:imartinez@vectorsf.com]=20
Sent: 30 March 2010 15:29
To: Renato Oliveira
Cc: pgsql-admin
Subject: Re: [ADMIN] Migrate postgres to newer hardware


=20

Hi Renato.

I would follow the ancient method: perform a pg_dump / pg_restore

Yes, you will have to take offline database for a long period.

And yes, it would be a great moment to perform a 8.4 upgrade.
Performance is far superior, restore is far faster...=20
.... and yes, it could give you many problems if you don't perform many
test in order to address all queries without explicit type conversions
before real migration, but I think it's the best moment to deal with a
very convenient upgrade. =20

We have performed this upgrade last week with a gforge (with only 25GB
database) and having also to upgrade to new tsearch2 and everything is
running smooth.

-----Original Message-----
From: Renato Oliveira
To: pgsql-admin@postgresql.org
Subject: [ADMIN] Migrate postgres to newer hardware
Date: Tue, 30 Mar 2010 12:18:36 +0100

Dear All,

=20

What would be the easiest and fastest way to migrate Postgres 8.2.24 32
BIT to a new server 64 Bit.

=20

The existing server runs on 32 bit architecture and has a database as
big as 160GB.

=20

We initially thought of using PITR, but as one of the PITR requirements
is both machines need to be similar.=20

This similarity needs to be even in architecture? I think I read
something which says â€=9CYesâ€=9D.

=20

If we cannot use PITR what would be the best approach, we canâ€=99t h=
ave
down time I am afraid.

=20

Any ideas or suggestions would be very welcome.

=20

Thank you very much

=20

Best regards

=20

Renato

=20

=20


Renato Oliveira
Systems Administrator
e-mail: renato.oliveira@grant.co.uk Tel: +44 (0)1763 260811
Fax: +44 (0)1763 262410
www.grant.co.uk Grant Instruments (Cambridge) Ltd=20
=20
Company registered in England, registration number 658133
=20
Registered office address:
29 Station Road,=20
Shepreth,=20
CAMBS SG8 6GB=20
UK =20
=20
=20
=20

P Please consider the environment before printing this email


CONFIDENTIALITY: The information in this e-mail and any attachments is
confidential. It is intended only for the named recipients(s). If you
are not the named recipient please notify the sender immediately and do
not disclose the contents to another person or take copies. =20
VIRUSES: The contents of this e-mail or attachment(s) may contain
viruses which could damage your own computer system. Whilst Grant
Instruments (Cambridge) Ltd has taken every reasonable precaution to
minimise this risk, we cannot accept liability for any damage which you
sustain as a result of software viruses. You should therefore carry out
your own virus checks before opening the attachment(s). =20
OpenXML: For information about the OpenXML file format in use within
Grant Instruments please visit our website=20


=20

=20
=20

P Please consider the environment before printing this email


CONFIDENTIALITY: The information in this e-mail and any attachments is
confidential. It is intended only for the named recipients(s). If you
are not the named recipient please notify the sender immediately and do
not disclose the contents to another person or take copies.=20
=20

VIRUSES: The contents of this e-mail or attachment(s) may contain
viruses which could damage your own computer system. Whilst Grant
Instruments (Cambridge) Ltd has taken every reasonable precaution to
minimise this risk, we cannot accept liability for any damage which you
sustain as a result of software viruses. You should therefore carry out
your own virus checks before opening the attachment(s).
=20

OpenXML: For information about the OpenXML file format in use within
Grant Instruments please visit our website


--=-77Ej586WkG6NxkQMUI6t
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: 7bit








Yes, you only have that two possibilities, I think.



PITR is not an option. I tested the same, from 7.4 32bit to 7.4 64bit and didn't work. Later, when I asked here, I was told why not.



The problem with slony is that you have to manually create tables in destination database and all database model (procedures, triggers, sequences, views, etc). If your application creates new tables, you will have to deal with this prior starting migration, or at least disable the creation of new tables.



Slony is asynchronous, so you will have to ensure that all changes have been committed to new database before changing your applications or exchanging IP addresses.

Slony also add many triggers and special tables to both databases (master and slave). So, after migration, you will have to delete them. It's not difficult but don't forget to do it.



By the way, are you sure your database is 160GB? Including indexes? There are strategies in order to perform a faster pg_restore...

For example, if you migrate your database schema but don't create indexes, then migrate data and finally create pending indexes restore will be faster. With pg 8.4 restore is very fast, so it will take less time that export.



Anyway, if you cannot leave database down for a day, I think slony will be your best bet, although it's not exempt of problems. :)



-----Original Message-----

From: Renato Oliveira <>

To: Iñigo Martinez Lasala <>

Subject: RE: [ADMIN] Migrate postgres to newer hardware

Date: Tue, 30 Mar 2010 15:47:27 +0100




Hey Iñigo,



 



Thank you very much for your reply.



 



I would love to do just that, but unfortunately I can’t it is not as simple as that.



 



I would love if the application had been built in with this in mind…



 



To give you an idea; the pg_dump takes 15 hours and I attempted a restore yesterday and it took 14 hours and 21 min.



It would not be viable for us and specially I cannot have the system down more than maximum 30 min without the risk of losing data and customers not having alerts.



 



I don’t think I will be able to use PITR to migrate to new servers specially if it is 64 bit and to migrate to another 32 bit is no gain, as we need more memory.



 



As far as can gather there are only two ways:



a)   Slony type



b)   Pg_dump



 



Is that correct ? Do you guys have any other ways?



 



Renato



 



 





 
Renato Oliveira

Systems Administrator

e-mail: renato.oliveira@grant.co.uk
 
Tel: +44 (0)1763 260811

Fax: +44 (0)1763 262410


 
Grant Instruments (Cambridge) Ltd

 

Company registered in England, registration number 658133

 

Registered office address:

29 Station Road,

Shepreth,

CAMBS SG8 6GB

UK
 


 
From: Iñigo Martinez Lasala [mailto:imartinez@vectorsf.com]

Sent: 30 March 2010 15:29

To: Renato Oliveira

Cc: pgsql-admin

Subject: Re: [ADMIN] Migrate postgres to newer hardware





 



Hi Renato.



I would follow the ancient method: perform a pg_dump / pg_restore



Yes, you will have to take offline database for a long period.



And yes, it would be a great moment to perform a 8.4 upgrade. Performance is far superior, restore is far faster...

... and yes, it could give you many problems if you don't perform many test in order to address all queries without explicit type conversions before real migration, but I think it's the best moment to deal with a very convenient upgrade. 



We have performed this upgrade last week with a gforge (with only 25GB database) and having also to upgrade to new tsearch2 and everything is running smooth.



-----Original Message-----

From: Renato Oliveira <>

To: pgsql-admin@postgresql.org <>

Subject: [ADMIN] Migrate postgres to newer hardware

Date: Tue, 30 Mar 2010 12:18:36 +0100



Dear All,



 



What would be the easiest and fastest way to migrate Postgres 8.2.24 32 BIT to a new server 64 Bit.



 



The existing server runs on 32 bit architecture and has a database as big as 160GB.



 



We initially thought of using PITR, but as one of the PITR requirements is both machines need to be similar.



This similarity needs to be even in architecture? I think I read something which says “Yes”.



 



If we cannot use PITR what would be the best approach, we can’t have down time I am afraid.



 



Any ideas or suggestions would be very welcome.



 



Thank you very much



 



Best regards



 



Renato



 



 





  Renato Oliveira

Systems Administrator

e-mail: renato.oliveira@grant.co.uk   Tel: +44 (0)1763 260811

Fax: +44 (0)1763 262410

  Grant Instruments (Cambridge) Ltd

 

Company registered in England, registration number 658133

 

Registered office address:

29 Station Road,

Shepreth,

CAMBS SG8 6GB

UK  

 

 

   



P Please consider the environment before printing this email





CONFIDENTIALITY: The information in this e-mail and any attachments is confidential. It is intended only for the named recipients(s). If you are not the named recipient please notify the sender immediately and do not disclose the contents to another person or take copies.  

VIRUSES: The contents of this e-mail or attachment(s) may contain viruses which could damage your own computer system. Whilst Grant Instruments (Cambridge) Ltd has taken every reasonable precaution to minimise this risk, we cannot accept liability for any damage which you sustain as a result of software viruses. You should therefore carry out your own virus checks before opening the attachment(s).  

OpenXML: For information about the OpenXML file format in use within Grant Instruments please visit our





 


 
 



P Please consider the environment before printing this email





CONFIDENTIALITY: The information in this e-mail and any attachments is confidential. It is intended only for the named recipients(s). If you are not the named recipient please notify the sender immediately and do not disclose the contents to another person or take copies.
 


VIRUSES: The contents of this e-mail or attachment(s) may contain viruses which could damage your own computer system. Whilst Grant Instruments (Cambridge) Ltd has taken every reasonable precaution to minimise this risk, we cannot accept liability for any damage which you sustain as a result of software viruses. You should therefore carry out your own virus checks before opening the attachment(s).
 


OpenXML: For information about the OpenXML file format in use within Grant Instruments please visit our





--=-77Ej586WkG6NxkQMUI6t--

Re: Migrate postgres to newer hardware

> -----Original Message-----
> From: Renato Oliveira
> To: pgsql-admin@postgresql.org
> Subject: [ADMIN] Migrate postgres to newer hardware
> Date: Tue, 30 Mar 2010 12:18:36 +0100
>
> Dear All,
>
>
>
> What would be the easiest and fastest way to migrate Postgres 8.2.24 32 B=
IT
> to a new server 64 Bit.
>
>
>
> The existing server runs on 32 bit architecture and has a database as big=
as
> 160GB.
>
>
>
> We initially thought of using PITR, but as one of the PITR requirements is
> both machines need to be similar.
>
> This similarity needs to be even in architecture? I think I read something
> which says =93Yes=94.
>
>
>
> If we cannot use PITR what would be the best approach, we can=92t have do=
wn
> time I am afraid.
>
>
>
> Any ideas or suggestions would be very welcome.
>
>
>
> Thank you very much
>
>
>
> Best regards
>
>
>
> Renato
>
>
>
>
>
>
> =A0 Renato Oliveira
> Systems Administrator
> e-mail: renato.oliveira@grant.co.uk =A0 Tel: +44 (0)1763 260811
> Fax: +44 (0)1763 262410
> www.grant.co.uk =A0 Grant Instruments (Cambridge) Ltd
>
> Company registered in England, registration number 658133
>
> Registered office address:
> 29 Station Road,
> Shepreth,
> CAMBS SG8 6GB
> UK
>
>
>
>
> P Please consider the environment before printing this email
>
>
> CONFIDENTIALITY: The information in this e-mail and any attachments is
> confidential. It is intended only for the named recipients(s). If you are
> not the named recipient please notify the sender immediately and do not
> disclose the contents to another person or take copies.
> VIRUSES: The contents of this e-mail or attachment(s) may contain viruses
> which could damage your own computer system. Whilst Grant Instruments
> (Cambridge) Ltd has taken every reasonable precaution to minimise this ri=
sk,
> we cannot accept liability for any damage which you sustain as a result of
> software viruses. You should therefore carry out your own virus checks
> before opening the attachment(s).
> OpenXML: For information about the OpenXML file format in use within Grant
> Instruments please visit our website
>
>
>
>
>
> P Please consider the environment before printing this email
>
>
> CONFIDENTIALITY: The information in this e-mail and any attachments is
> confidential. It is intended only for the named recipients(s). If you are
> not the named recipient please notify the sender immediately and do not
> disclose the contents to another person or take copies.
> VIRUSES: The contents of this e-mail or attachment(s) may contain viruses
> which could damage your own computer system. Whilst Grant Instruments
> (Cambridge) Ltd has taken every reasonable precaution to minimise this ri=
sk,
> we cannot accept liability for any damage which you sustain as a result of
> software viruses. You should therefore carry out your own virus checks
> before opening the attachment(s).
> OpenXML: For information about the OpenXML file format in use within Grant
> Instruments please visit our website
>

You can use the pg_dump method and use pgpool to replicate the new
data, then when sinchronized, switch off the old node.

--=20
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin

Re: Migrate postgres to newer hardware

On Tue, 2010-03-30 at 16:38 +0200, Tino Schwarze wrote:
> Hi Renato,
>
> dump/restore is the way to go. I suppose, you don't want to compile
> Postgres for 32 bit on the new machine which might work and might allow
> you to do the PITR migration.
>
> And "downtime is not an option" is always a sign of insufficient
> planning beforehand.

First, there is a big difference between saying "downtime is not an
option" and "several hours of downtime is not an option".

Lack of planning is launching a system without having the procedures and
tooling in place to cope with the technical issues while functioning
within your contractual constraints.

Many of people have tight contracts about system availability with end
customers, often with financial penalties associated for failure to
comply. Dump and restore of a large system is something that can take a
very long time, and can't always fit inside those maintenance windows.

> There is no system which doesn't need an upgrade or
> reboot or whatever, so there will be downtime and it needs to be
> considered during system analysis.

Correct. One of the reasons we (Afilias) wrote Slony was so that we
could quickly move the services from one database to another with a
short application outage. That gives us the freedom to do many
maintenances without having the application down for extended periods.
PG upgrades fit nicely into this. The only outage is a brief one to
move master and re-point the target. You can measure the time in
minutes (or even seconds if your procedures are automated enough).

> In my experience, it is often just a matter of communicating: "Because
> of hardware upgrades, the system XYZ will not be available on ..."

Again, this will depend on business drivers.

> After all the switch won't be without interruption - you need to switch
> to the new server anyway.

There is a very big difference between saying the system will be down
for a short duration during a Slony switchover and the system will be
down for several hours while doing a dump and restore.

--
Brad Nicholson 416-673-4106
Database Administrator, Afilias Canada Corp.



--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin

Re: Migrate postgres to newer hardware

Renato Oliveira wrote:
> Are there any commercial solutions out there for migrating large DBs?
>

I'm not aware of any. The main way to address this problem by throwing
money at it is to hire someone extremely familiar with PostgreSQL
replication technology and figure out how to customize one of the
available approaches (Slony, Londiste, PITR, dump/restore) to match your
application. For example, in some cases it's possible to record
database changes on the application side, replicate the database via one
of the fast online approaches like PITR, and then synchronize just the
changes made in the master while that was happening for a fast
switch-over to a new version. It's not unheard for that to require
small application changes to support, to provide an easier way to log
the difference between the two.

If you can't take the additional load of Slony and have minimal
tolerance for downtime, you really need to come up with a long-term
approach to coping with that from an application architecture
perspective. Unfortunately you're not going to find any quick fix for
that combination of requirements.

--
Greg Smith 2ndQuadrant US Baltimore, MD
PostgreSQL Training, Services and Support
greg@2ndQuadrant.com www.2ndQuadrant.us


--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin

Re: Migrate postgres to newer hardware

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160


> What would be the easiest and fastest way to
> migrate Postgres 8.2.24 32 BIT to a new server 64 Bit.
....
> If we cannot use PITR what would be the best approach,
> we can't have down time I am afraid.
>
> Any ideas or suggestions would be very welcome.

You could also consider Bucardo. Its advantage is that it
does not TRUNCATE and COPY over the entire data on startup
(unless you ask it to), so you can use "pre-warmed" slaves
and avoid the load and time of a full copy. So the procedure
would be something like:

1. Install Bucardo and add all tables you want replicated.
2. Perform your usual pg_dump and restore to the new box.
(or use a snapshot, bring up a PITR slave, etc.)
3. Drop the bucardo schema on the new box.
Run ANALYZE on the new box.
4. Tell Bucardo about the new box, then start it up.
This will copy over all changes made since the pg_dump.
5. Stop your app, or put the DB in readonly mode.
6. Do a final Bucardo sync of any changes since step 4.
7. Copy over any other tables that do not have primary keys.
8. Point your app at the new box.

For speed, you can do things like turn off fsync and some
other settings on the new box until just before step 8.

And of course no matter which solution you choose, you'll
want to test this out first using a complete copy of the db
going from a 32-bit test box to a 64-bit test box. Heck, it
might even be a good time to jump to version 8.4 :)

- --
Greg Sabino Mullane greg@turnstep.com
End Point Corporation http://www.endpoint.com/
PGP Key: 0x14964AC8 201003301345
http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B90 6714964AC8
-----BEGIN PGP SIGNATURE-----

iEYEAREDAAYFAkuyOYIACgkQvJuQZxSWSsgPqwCg3DGv8O0klxkCdukecwuN yxir
TvAAni+5rbVbmwbAz3zsgahMuBHfuAUM
=ybeB
-----END PGP SIGNATURE-----



--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin

Re: Migrate postgres to newer hardware

Hi Everybody,

I'm not a dba. I'm a sysadmin by training. Is there some way to mirro=
r the disks at the OS level? And then move it to the new machine. Just a th=
ough, I don't know the exact steps. But if you are interested, I can see wh=
at I can find.

-Tino

________________________________________
From: pgsql-admin-owner@postgresql.org [pgsql-admin-owner@postgresql.org] O=
n Behalf Of Greg Smith [greg@2ndquadrant.com]
Sent: Tuesday, March 30, 2010 1:05 PM
To: Dai, Tino; Renato Oliveira
Cc: pgsql-admin@postgresql.org; Tino Schwarze
Subject: Re: [ADMIN] Migrate postgres to newer hardware

Renato Oliveira wrote:
> Are there any commercial solutions out there for migrating large DBs?
>

I'm not aware of any. The main way to address this problem by throwing
money at it is to hire someone extremely familiar with PostgreSQL
replication technology and figure out how to customize one of the
available approaches (Slony, Londiste, PITR, dump/restore) to match your
application. For example, in some cases it's possible to record
database changes on the application side, replicate the database via one
of the fast online approaches like PITR, and then synchronize just the
changes made in the master while that was happening for a fast
switch-over to a new version. It's not unheard for that to require
small application changes to support, to provide an easier way to log
the difference between the two.

If you can't take the additional load of Slony and have minimal
tolerance for downtime, you really need to come up with a long-term
approach to coping with that from an application architecture
perspective. Unfortunately you're not going to find any quick fix for
that combination of requirements.

--
Greg Smith 2ndQuadrant US Baltimore, MD
PostgreSQL Training, Services and Support
greg@2ndQuadrant.com www.2ndQuadrant.us


--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin

--=20
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin

Re: Migrate postgres to newer hardware

Tino,

I did try mirroring the disk using 'dd' command and it took me a long time.
At the end postgres did not start up.

I am sure I could probably get postgres working, but the db integrity not s=
ure about that.

Thank you very much for the input and offer

Renato



Renato Oliveira
Systems Administrator
e-mail: renato.oliveira@grant.co.uk

Tel: +44 (0)1763 260811
Fax: +44 (0)1763 262410
http://www.grant.co.uk/

Grant Instruments (Cambridge) Ltd

Company registered in England, registration number 658133

Registered office address:
29 Station Road,
Shepreth,
CAMBS SG8 6GB
UK

-----Original Message-----


From: Dai, Tino [mailto:tdai@loc.gov]
Sent: 31 March 2010 03:08
To: Greg Smith; Renato Oliveira
Cc: pgsql-admin@postgresql.org; Tino Schwarze
Subject: RE: [ADMIN] Migrate postgres to newer hardware

Hi Everybody,

I'm not a dba. I'm a sysadmin by training. Is there some way to mirro=
r the disks at the OS level? And then move it to the new machine. Just a th=
ough, I don't know the exact steps. But if you are interested, I can see wh=
at I can find.

-Tino

________________________________________
From: pgsql-admin-owner@postgresql.org [pgsql-admin-owner@postgresql.org] O=
n Behalf Of Greg Smith [greg@2ndquadrant.com]
Sent: Tuesday, March 30, 2010 1:05 PM
To: Dai, Tino; Renato Oliveira
Cc: pgsql-admin@postgresql.org; Tino Schwarze
Subject: Re: [ADMIN] Migrate postgres to newer hardware

Renato Oliveira wrote:
> Are there any commercial solutions out there for migrating large DBs?
>

I'm not aware of any. The main way to address this problem by throwing
money at it is to hire someone extremely familiar with PostgreSQL
replication technology and figure out how to customize one of the
available approaches (Slony, Londiste, PITR, dump/restore) to match your
application. For example, in some cases it's possible to record
database changes on the application side, replicate the database via one
of the fast online approaches like PITR, and then synchronize just the
changes made in the master while that was happening for a fast
switch-over to a new version. It's not unheard for that to require
small application changes to support, to provide an easier way to log
the difference between the two.

If you can't take the additional load of Slony and have minimal
tolerance for downtime, you really need to come up with a long-term
approach to coping with that from an application architecture
perspective. Unfortunately you're not going to find any quick fix for
that combination of requirements.

--
Greg Smith 2ndQuadrant US Baltimore, MD
PostgreSQL Training, Services and Support
greg@2ndQuadrant.com www.2ndQuadrant.us


--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin



-----Original Message-----


P Please consider the environment before printing this email
CONFIDENTIALITY: The information in this e-mail and any attachments is conf=
idential. It is intended only for the named recipients(s). If you are not t=
he named recipient please notify the sender immediately and do not disclose=
the contents to another person or take copies.

VIRUSES: The contents of this e-mail or attachment(s) may contain viruses w=
hich could damage your own computer system. Whilst Grant Instruments (Cambr=
idge) Ltd has taken every reasonable precaution to minimise this risk, we c=
annot accept liability for any damage which you sustain as a result of soft=
ware viruses. You should therefore carry out your own virus checks before o=
pening the attachment(s).

OpenXML: For information about the OpenXML file format in use within Grant =
Instruments please visit our http://www.grant.co.uk/Support/openxml.html


--=20
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin

Re: Migrate postgres to newer hardware

Greg,

Thank you very much for your input.
I agree with you and I do understand where you are coming from.

I do agree that in order to transition without a noticeable downtime the ap=
plication would need to be built for that.

Which one works best: bucardo, slony or Londiste?

I have researched Slony and Bucardo but have not heard of Londiste before.

How many people are using all three of them and their review have you hear=
d anything about that?

Thank you again

Really Appreciate it

Renato



Renato Oliveira
Systems Administrator
e-mail: renato.oliveira@grant.co.uk

Tel: +44 (0)1763 260811
Fax: +44 (0)1763 262410
http://www.grant.co.uk/

Grant Instruments (Cambridge) Ltd

Company registered in England, registration number 658133

Registered office address:
29 Station Road,
Shepreth,
CAMBS SG8 6GB
UK

-----Original Message-----


From: Greg Smith [mailto:greg@2ndquadrant.com]
Sent: 30 March 2010 18:06
To: Renato Oliveira
Cc: Tino Schwarze; pgsql-admin@postgresql.org
Subject: Re: [ADMIN] Migrate postgres to newer hardware

Renato Oliveira wrote:
> Are there any commercial solutions out there for migrating large DBs?
>

I'm not aware of any. The main way to address this problem by throwing
money at it is to hire someone extremely familiar with PostgreSQL
replication technology and figure out how to customize one of the
available approaches (Slony, Londiste, PITR, dump/restore) to match your
application. For example, in some cases it's possible to record
database changes on the application side, replicate the database via one
of the fast online approaches like PITR, and then synchronize just the
changes made in the master while that was happening for a fast
switch-over to a new version. It's not unheard for that to require
small application changes to support, to provide an easier way to log
the difference between the two.

If you can't take the additional load of Slony and have minimal
tolerance for downtime, you really need to come up with a long-term
approach to coping with that from an application architecture
perspective. Unfortunately you're not going to find any quick fix for
that combination of requirements.

--
Greg Smith 2ndQuadrant US Baltimore, MD
PostgreSQL Training, Services and Support
greg@2ndQuadrant.com www.2ndQuadrant.us




-----Original Message-----


P Please consider the environment before printing this email
CONFIDENTIALITY: The information in this e-mail and any attachments is conf=
idential. It is intended only for the named recipients(s). If you are not t=
he named recipient please notify the sender immediately and do not disclose=
the contents to another person or take copies.

VIRUSES: The contents of this e-mail or attachment(s) may contain viruses w=
hich could damage your own computer system. Whilst Grant Instruments (Cambr=
idge) Ltd has taken every reasonable precaution to minimise this risk, we c=
annot accept liability for any damage which you sustain as a result of soft=
ware viruses. You should therefore carry out your own virus checks before o=
pening the attachment(s).

OpenXML: For information about the OpenXML file format in use within Grant =
Instruments please visit our http://www.grant.co.uk/Support/openxml.html


--=20
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin

Re: Migrate postgres to newer hardware

On Wed, Mar 31, 2010 at 1:43 AM, Renato Oliveira
wrote:
> Greg,
>
> Thank you very much for your input.
> I agree with you and I do understand where you are coming from.
>
> I do agree that in order to transition without a noticeable downtime the =
application would need to be built for that.
>
> Which one works best: bucardo, slony or Londiste?
>
> I have researched Slony and Bucardo but have not heard of =A0Londiste bef=
ore.
>
> How many people are using all three of them and their review =A0have you =
heard anything about that?

I run slony. On our regular db there are about 2000 relations, about
1200 of those are indexes, so slony has to worry about 800 or so
relations. It has no problem with that. On another machine that has
some 45k relations in addition to the 2000 base relations. That slony
instance takes 3.5 hours to run the same create set that takes 2
minutes on the machine with just 2000 relations.

Slony should be able to work for you. See if you can schedule it so
you start your subscription right when you're entering your lowest
throughput window. Your real bottleneck here is that source database
with a single hard drive. That's going to limit your speed of
subscription by quite a bit.

--=20
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin

Re: Migrate postgres to newer hardware

--_000_7965A9DCF12CC14984420BCC37B1608F25AB1AEF22Elzargrantc ou_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SGkgScOxaWdvLA0KDQpUaGFuayB5b3UgZm9yIHlvdXIgaW5wdXQsIHJlYWxs eSBhcHByZWNpYXRl
ZC4NCg0KSSBqdXN0IGhhZCBhIHRob3VnaHQ7IGlmIEkgYmFja3VwIOKAmHBn X2R1bXDigJkgZnVs
bCBkYXRhYmFzZSwgdGhlbiByZXN0b3JlIHRvIG15IG5ldyBtYWNoaW5lIG5l dyBwb3N0Z3JlcyA4
LjQsIHdoaWNoIG9uZSBvZiB0aGVzZSBwcm9ncmFtcyB3b3VsZCB3b3JrIGJl c3QgdG8gZG8gdGhl
IG1pZ3JhdGlvbiwNClNsb255LCBCdWNhcmRvIG9yIExvbmRpc3RlPw0KDQpJ IHdvdWxkIGxpa2Ug
dG8gc2F5IHRoYXQgd2UgZGlkIGhhdmUgc2xvbnkgYW5kIEkgd2FzIG5vdCBp bXByZXNzZWQsIGl0
IGZlbGwgYmVoaW5kIGFuZCBjb3VsZCBub3QgY2F0Y2ggdXAgYW5kIGNhdXNl ZCBhIHZlcnkgaGln
aCBsb2FkIG9uIHRoZSBzeXN0ZW0uDQpBbHNvIHRoZXkgd2F5IGl0cyBwaGls b3NvcGh5IHdvcmtz
LCBpdCBpcyB2ZXJ5IGhpZ2ggbWFpbnRlbmFuY2UsIGFuZCB0aGUgaWRlYSBv ZiBjcmVhdGluZyB0
YWJsZXMsIGFuZCB0cmlnZ2VycyBvbiBib3RoIGRicy4uLg0KSXQgbWlnaHQg YmUsIGl0IHdhcyBu
b3Qgc2V0dXAgcHJvcGVybHkgb3Igd2VsbCwgd2UgcmVtb3ZlZCBpdCBhcyB0 aGUgZGIgd2FzIHNj
cmVhbWluZyBmb3Igc29tZSBmcmVzaCBhaXIuDQoNClBzIEkgd291bGQgbGlr ZSB0byBwb2ludCBv
dXQgdGhhdCBJIGFtIHN5c3RlbXMgYWRtaW5pc3RyYXRvciBhbmQgbm90IGEg ZGJhLCBzbyB5b3Ug
Y2FuIHVuZGVyc3RhbmQgc29tZXRpbWVzIG15IHF1ZXN0aW9ucy4uLg0KDQpJ IHRoaW5rIEJ1Y2Fy
ZG8gc2VlbXMgYmVzdCBmb3IgdGhlIHRhc2ssIGZvciB3aGF0IEkgaGF2ZSBy ZWFkIHNvIGZhciwg
IGJ1dCBJIGRvIG5vdCBrbm93Lg0KDQpUaGFuayB5b3UgdmVyeSBtdWNoIGFu ZCBJIGFtIHNvcnJ5
IGZvciB0aGlzDQoNClJlbmF0bw0KDQoNCg0KDQpSZW5hdG8gT2xpdmVpcmEN ClN5c3RlbXMgQWRt
aW5pc3RyYXRvcg0KZS1tYWlsOiByZW5hdG8ub2xpdmVpcmFAZ3JhbnQuY28u dWsNCg0KVGVsOiAr
NDQgKDApMTc2MyAyNjA4MTENCkZheDogKzQ0ICgwKTE3NjMgMjYyNDEwDQp3 d3cuZ3JhbnQuY28u
dWs8aHR0cDovL3d3dy5ncmFudC5jby51ay8+DQoNCkdyYW50IEluc3RydW1l bnRzIChDYW1icmlk
Z2UpIEx0ZA0KDQpDb21wYW55IHJlZ2lzdGVyZWQgaW4gRW5nbGFuZCwgcmVn aXN0cmF0aW9uIG51
bWJlciA2NTgxMzMNCg0KUmVnaXN0ZXJlZCBvZmZpY2UgYWRkcmVzczoNCjI5 IFN0YXRpb24gUm9h
ZCwNClNoZXByZXRoLA0KQ0FNQlMgU0c4IDZHQg0KVUsNCg0KDQpGcm9tOiBJ w7FpZ28gTWFydGlu
ZXogTGFzYWxhIFttYWlsdG86aW1hcnRpbmV6QHZlY3RvcnNmLmNvbV0NClNl bnQ6IDMwIE1hcmNo
IDIwMTAgMTY6MjcNClRvOiBSZW5hdG8gT2xpdmVpcmENCkNjOiBwZ3NxbC1h ZG1pbg0KU3ViamVj
dDogUkU6IFtBRE1JTl0gTWlncmF0ZSBwb3N0Z3JlcyB0byBuZXdlciBoYXJk d2FyZQ0KDQpZZXMs
IHlvdSBvbmx5IGhhdmUgdGhhdCB0d28gcG9zc2liaWxpdGllcywgSSB0aGlu ay4NCg0KUElUUiBp
cyBub3QgYW4gb3B0aW9uLiBJIHRlc3RlZCB0aGUgc2FtZSwgZnJvbSA3LjQg MzJiaXQgdG8gNy40
IDY0Yml0IGFuZCBkaWRuJ3Qgd29yay4gTGF0ZXIsIHdoZW4gSSBhc2tlZCBo ZXJlLCBJIHdhcyB0
b2xkIHdoeSBub3QuDQoNClRoZSBwcm9ibGVtIHdpdGggc2xvbnkgaXMgdGhh dCB5b3UgaGF2ZSB0
byBtYW51YWxseSBjcmVhdGUgdGFibGVzIGluIGRlc3RpbmF0aW9uIGRhdGFi YXNlIGFuZCBhbGwg
ZGF0YWJhc2UgbW9kZWwgKHByb2NlZHVyZXMsIHRyaWdnZXJzLCBzZXF1ZW5j ZXMsIHZpZXdzLCBl
dGMpLiBJZiB5b3VyIGFwcGxpY2F0aW9uIGNyZWF0ZXMgbmV3IHRhYmxlcywg eW91IHdpbGwgaGF2
ZSB0byBkZWFsIHdpdGggdGhpcyBwcmlvciBzdGFydGluZyBtaWdyYXRpb24s IG9yIGF0IGxlYXN0
IGRpc2FibGUgdGhlIGNyZWF0aW9uIG9mIG5ldyB0YWJsZXMuDQoNClNsb255 IGlzIGFzeW5jaHJv
bm91cywgc28geW91IHdpbGwgaGF2ZSB0byBlbnN1cmUgdGhhdCBhbGwgY2hh bmdlcyBoYXZlIGJl
ZW4gY29tbWl0dGVkIHRvIG5ldyBkYXRhYmFzZSBiZWZvcmUgY2hhbmdpbmcg eW91ciBhcHBsaWNh
dGlvbnMgb3IgZXhjaGFuZ2luZyBJUCBhZGRyZXNzZXMuDQpTbG9ueSBhbHNv IGFkZCBtYW55IHRy
aWdnZXJzIGFuZCBzcGVjaWFsIHRhYmxlcyB0byBib3RoIGRhdGFiYXNlcyAo bWFzdGVyIGFuZCBz
bGF2ZSkuIFNvLCBhZnRlciBtaWdyYXRpb24sIHlvdSB3aWxsIGhhdmUgdG8g ZGVsZXRlIHRoZW0u
IEl0J3Mgbm90IGRpZmZpY3VsdCBidXQgZG9uJ3QgZm9yZ2V0IHRvIGRvIGl0 Lg0KDQpCeSB0aGUg
d2F5LCBhcmUgeW91IHN1cmUgeW91ciBkYXRhYmFzZSBpcyAxNjBHQj8gSW5j bHVkaW5nIGluZGV4
ZXM/IFRoZXJlIGFyZSBzdHJhdGVnaWVzIGluIG9yZGVyIHRvIHBlcmZvcm0g YSBmYXN0ZXIgcGdf
cmVzdG9yZS4uLg0KRm9yIGV4YW1wbGUsIGlmIHlvdSBtaWdyYXRlIHlvdXIg ZGF0YWJhc2Ugc2No
ZW1hIGJ1dCBkb24ndCBjcmVhdGUgaW5kZXhlcywgdGhlbiBtaWdyYXRlIGRh dGEgYW5kIGZpbmFs
bHkgY3JlYXRlIHBlbmRpbmcgaW5kZXhlcyByZXN0b3JlIHdpbGwgYmUgZmFz dGVyLiBXaXRoIHBn
IDguNCByZXN0b3JlIGlzIHZlcnkgZmFzdCwgc28gaXQgd2lsbCB0YWtlIGxl c3MgdGltZSB0aGF0
IGV4cG9ydC4NCg0KQW55d2F5LCBpZiB5b3UgY2Fubm90IGxlYXZlIGRhdGFi YXNlIGRvd24gZm9y
IGEgZGF5LCBJIHRoaW5rIHNsb255IHdpbGwgYmUgeW91ciBiZXN0IGJldCwg YWx0aG91Z2ggaXQn
cyBub3QgZXhlbXB0IG9mIHByb2JsZW1zLiA6KQ0KDQotLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0t
LQ0KRnJvbTogUmVuYXRvIE9saXZlaXJhIDxyZW5hdG8ub2xpdmVpcmFAZ3Jh bnQuY28udWs8bWFp
bHRvOlJlbmF0byUyME9saXZlaXJhJTIwJTNjcmVuYXRvLm9saXZlaXJhQGdy YW50LmNvLnVrJTNl
Pj4NClRvOiBJw7FpZ28gTWFydGluZXogTGFzYWxhIDxpbWFydGluZXpAdmVj dG9yc2YuY29tPG1h
aWx0bzolM2QlM2ZJU08tODg1OS0xJTNmUSUzZkklM2RGMWlnbyUzZiUzZCUy ME1hcnRpbmV6JTIw
TGFzYWxhJTIwJTNjaW1hcnRpbmV6QHZlY3RvcnNmLmNvbSUzZT4+DQpTdWJq ZWN0OiBSRTogW0FE
TUlOXSBNaWdyYXRlIHBvc3RncmVzIHRvIG5ld2VyIGhhcmR3YXJlDQpEYXRl OiBUdWUsIDMwIE1h
ciAyMDEwIDE1OjQ3OjI3ICswMTAwDQoNCu+7vyBIZXkgScOxaWdvLA0KDQoN Cg0KVGhhbmsgeW91
IHZlcnkgbXVjaCBmb3IgeW91ciByZXBseS4NCg0KDQoNCkkgd291bGQgbG92 ZSB0byBkbyBqdXN0
IHRoYXQsIGJ1dCB1bmZvcnR1bmF0ZWx5IEkgY2Fu4oCZdCBpdCBpcyBub3Qg YXMgc2ltcGxlIGFz
IHRoYXQuDQoNCg0KDQpJIHdvdWxkIGxvdmUgaWYgdGhlIGFwcGxpY2F0aW9u IGhhZCBiZWVuIGJ1
aWx0IGluIHdpdGggdGhpcyBpbiBtaW5k4oCmDQoNCg0KDQpUbyBnaXZlIHlv dSBhbiBpZGVhOyB0
aGUgcGdfZHVtcCB0YWtlcyAxNSBob3VycyBhbmQgSSBhdHRlbXB0ZWQgYSBy ZXN0b3JlIHllc3Rl
cmRheSBhbmQgaXQgdG9vayAxNCBob3VycyBhbmQgMjEgbWluLg0KDQpJdCB3 b3VsZCBub3QgYmUg
dmlhYmxlIGZvciB1cyBhbmQgc3BlY2lhbGx5IEkgY2Fubm90IGhhdmUgdGhl IHN5c3RlbSBkb3du
IG1vcmUgdGhhbiBtYXhpbXVtIDMwIG1pbiB3aXRob3V0IHRoZSByaXNrIG9m IGxvc2luZyBkYXRh
IGFuZCBjdXN0b21lcnMgbm90IGhhdmluZyBhbGVydHMuDQoNCg0KDQpJIGRv buKAmXQgdGhpbmsg
SSB3aWxsIGJlIGFibGUgdG8gdXNlIFBJVFIgdG8gbWlncmF0ZSB0byBuZXcg c2VydmVycyBzcGVj
aWFsbHkgaWYgaXQgaXMgNjQgYml0IGFuZCB0byBtaWdyYXRlIHRvIGFub3Ro ZXIgMzIgYml0IGlz
IG5vIGdhaW4sIGFzIHdlIG5lZWQgbW9yZSBtZW1vcnkuDQoNCg0KDQpBcyBm YXIgYXMgY2FuIGdh
dGhlciB0aGVyZSBhcmUgb25seSB0d28gd2F5czoNCg0KYSkgICBTbG9ueSB0 eXBlDQoNCmIpICAg
UGdfZHVtcA0KDQoNCg0KSXMgdGhhdCBjb3JyZWN0ID8gRG8geW91IGd1eXMg aGF2ZSBhbnkgb3Ro
ZXIgd2F5cz8NCg0KDQoNClJlbmF0bw0KDQoNCg0KDQoNCg0KICBSZW5hdG8g T2xpdmVpcmENClN5
c3RlbXMgQWRtaW5pc3RyYXRvcg0KZS1tYWlsOiByZW5hdG8ub2xpdmVpcmFA Z3JhbnQuY28udWsg
ICBUZWw6ICs0NCAoMCkxNzYzIDI2MDgxMQ0KRmF4OiArNDQgKDApMTc2MyAy NjI0MTANCnd3dy5n
cmFudC5jby51azxodHRwOi8vd3d3LmdyYW50LmNvLnVrLz4gICBHcmFudCBJ bnN0cnVtZW50cyAo
Q2FtYnJpZGdlKSBMdGQNCg0KQ29tcGFueSByZWdpc3RlcmVkIGluIEVuZ2xh bmQsIHJlZ2lzdHJh
dGlvbiBudW1iZXIgNjU4MTMzDQoNClJlZ2lzdGVyZWQgb2ZmaWNlIGFkZHJl c3M6DQoyOSBTdGF0
aW9uIFJvYWQsDQpTaGVwcmV0aCwNCkNBTUJTIFNHOCA2R0INClVLDQogIEZy b206IEnDsWlnbyBN
YXJ0aW5leiBMYXNhbGEgW21haWx0bzppbWFydGluZXpAdmVjdG9yc2YuY29t XQ0KU2VudDogMzAg
TWFyY2ggMjAxMCAxNToyOQ0KVG86IFJlbmF0byBPbGl2ZWlyYQ0KQ2M6IHBn c3FsLWFkbWluDQpT
dWJqZWN0OiBSZTogW0FETUlOXSBNaWdyYXRlIHBvc3RncmVzIHRvIG5ld2Vy IGhhcmR3YXJlDQoN
Cg0KDQoNCkhpIFJlbmF0by4NCg0KSSB3b3VsZCBmb2xsb3cgdGhlIGFuY2ll bnQgbWV0aG9kOiBw
ZXJmb3JtIGEgcGdfZHVtcCAvIHBnX3Jlc3RvcmUNCg0KWWVzLCB5b3Ugd2ls bCBoYXZlIHRvIHRh
a2Ugb2ZmbGluZSBkYXRhYmFzZSBmb3IgYSBsb25nIHBlcmlvZC4NCg0KQW5k IHllcywgaXQgd291
bGQgYmUgYSBncmVhdCBtb21lbnQgdG8gcGVyZm9ybSBhIDguNCB1cGdyYWRl LiBQZXJmb3JtYW5j
ZSBpcyBmYXIgc3VwZXJpb3IsIHJlc3RvcmUgaXMgZmFyIGZhc3Rlci4uLg0K Li4uIGFuZCB5ZXMs
IGl0IGNvdWxkIGdpdmUgeW91IG1hbnkgcHJvYmxlbXMgaWYgeW91IGRvbid0 IHBlcmZvcm0gbWFu
eSB0ZXN0IGluIG9yZGVyIHRvIGFkZHJlc3MgYWxsIHF1ZXJpZXMgd2l0aG91 dCBleHBsaWNpdCB0
eXBlIGNvbnZlcnNpb25zIGJlZm9yZSByZWFsIG1pZ3JhdGlvbiwgYnV0IEkg dGhpbmsgaXQncyB0
aGUgYmVzdCBtb21lbnQgdG8gZGVhbCB3aXRoIGEgdmVyeSBjb252ZW5pZW50 IHVwZ3JhZGUuDQoN
CldlIGhhdmUgcGVyZm9ybWVkIHRoaXMgdXBncmFkZSBsYXN0IHdlZWsgd2l0 aCBhIGdmb3JnZSAo
d2l0aCBvbmx5IDI1R0IgZGF0YWJhc2UpIGFuZCBoYXZpbmcgYWxzbyB0byB1 cGdyYWRlIHRvIG5l
dyB0c2VhcmNoMiBhbmQgZXZlcnl0aGluZyBpcyBydW5uaW5nIHNtb290aC4N Cg0KLS0tLS1Pcmln
aW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFJlbmF0byBPbGl2ZWlyYSA8cmVu YXRvLm9saXZlaXJh
QGdyYW50LmNvLnVrPG1haWx0bzpSZW5hdG8lMjBPbGl2ZWlyYSUyMCUzY3Jl bmF0by5vbGl2ZWly
YUBncmFudC5jby51ayUzZT4+DQpUbzogcGdzcWwtYWRtaW5AcG9zdGdyZXNx bC5vcmcgPHBnc3Fs
LWFkbWluQHBvc3RncmVzcWwub3JnPG1haWx0bzolMjJwZ3NxbC1hZG1pbkBw b3N0Z3Jlc3FsLm9y
ZyUyMiUyMCUzY3Bnc3FsLWFkbWluQHBvc3RncmVzcWwub3JnJTNlPj4NClN1 YmplY3Q6IFtBRE1J
Tl0gTWlncmF0ZSBwb3N0Z3JlcyB0byBuZXdlciBoYXJkd2FyZQ0KRGF0ZTog VHVlLCAzMCBNYXIg
MjAxMCAxMjoxODozNiArMDEwMA0KDQpEZWFyIEFsbCwNCg0KDQoNCldoYXQg d291bGQgYmUgdGhl
IGVhc2llc3QgYW5kIGZhc3Rlc3Qgd2F5IHRvIG1pZ3JhdGUgUG9zdGdyZXMg OC4yLjI0IDMyIEJJ
VCB0byBhIG5ldyBzZXJ2ZXIgNjQgQml0Lg0KDQoNCg0KVGhlIGV4aXN0aW5n IHNlcnZlciBydW5z
IG9uIDMyIGJpdCBhcmNoaXRlY3R1cmUgYW5kIGhhcyBhIGRhdGFiYXNlIGFz IGJpZyBhcyAxNjBH
Qi4NCg0KDQoNCldlIGluaXRpYWxseSB0aG91Z2h0IG9mIHVzaW5nIFBJVFIs IGJ1dCBhcyBvbmUg
b2YgdGhlIFBJVFIgcmVxdWlyZW1lbnRzIGlzIGJvdGggbWFjaGluZXMgbmVl ZCB0byBiZSBzaW1p
bGFyLg0KDQpUaGlzIHNpbWlsYXJpdHkgbmVlZHMgdG8gYmUgZXZlbiBpbiBh cmNoaXRlY3R1cmU/
IEkgdGhpbmsgSSByZWFkIHNvbWV0aGluZyB3aGljaCBzYXlzIOKAnFllc+KA nS4NCg0KDQoNCklm
IHdlIGNhbm5vdCB1c2UgUElUUiB3aGF0IHdvdWxkIGJlIHRoZSBiZXN0IGFw cHJvYWNoLCB3ZSBj
YW7igJl0IGhhdmUgZG93biB0aW1lIEkgYW0gYWZyYWlkLg0KDQoNCg0KQW55 IGlkZWFzIG9yIHN1
Z2dlc3Rpb25zIHdvdWxkIGJlIHZlcnkgd2VsY29tZS4NCg0KDQoNClRoYW5r IHlvdSB2ZXJ5IG11
Y2gNCg0KDQoNCkJlc3QgcmVnYXJkcw0KDQoNCg0KUmVuYXRvDQoNCg0KDQoN Cg0KDQogIFJlbmF0
byBPbGl2ZWlyYQ0KU3lzdGVtcyBBZG1pbmlzdHJhdG9yDQplLW1haWw6IHJl bmF0by5vbGl2ZWly
YUBncmFudC5jby51ayAgIFRlbDogKzQ0ICgwKTE3NjMgMjYwODExDQpGYXg6 ICs0NCAoMCkxNzYz
IDI2MjQxMA0Kd3d3LmdyYW50LmNvLnVrPGh0dHA6Ly93d3cuZ3JhbnQuY28u dWsvPiAgIEdyYW50
IEluc3RydW1lbnRzIChDYW1icmlkZ2UpIEx0ZA0KDQpDb21wYW55IHJlZ2lz dGVyZWQgaW4gRW5n
bGFuZCwgcmVnaXN0cmF0aW9uIG51bWJlciA2NTgxMzMNCg0KUmVnaXN0ZXJl ZCBvZmZpY2UgYWRk
cmVzczoNCjI5IFN0YXRpb24gUm9hZCwNClNoZXByZXRoLA0KQ0FNQlMgU0c4 IDZHQg0KVUsNCg0K
DQoNCg0KUCBQbGVhc2UgY29uc2lkZXIgdGhlIGVudmlyb25tZW50IGJlZm9y ZSBwcmludGluZyB0
aGlzIGVtYWlsDQoNCg0KQ09ORklERU5USUFMSVRZOiBUaGUgaW5mb3JtYXRp b24gaW4gdGhpcyBl
LW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBpcyBjb25maWRlbnRpYWwuIEl0 IGlzIGludGVuZGVk
IG9ubHkgZm9yIHRoZSBuYW1lZCByZWNpcGllbnRzKHMpLiBJZiB5b3UgYXJl IG5vdCB0aGUgbmFt
ZWQgcmVjaXBpZW50IHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlh dGVseSBhbmQgZG8g
bm90IGRpc2Nsb3NlIHRoZSBjb250ZW50cyB0byBhbm90aGVyIHBlcnNvbiBv ciB0YWtlIGNvcGll
cy4NClZJUlVTRVM6IFRoZSBjb250ZW50cyBvZiB0aGlzIGUtbWFpbCBvciBh dHRhY2htZW50KHMp
IG1heSBjb250YWluIHZpcnVzZXMgd2hpY2ggY291bGQgZGFtYWdlIHlvdXIg b3duIGNvbXB1dGVy
IHN5c3RlbS4gV2hpbHN0IEdyYW50IEluc3RydW1lbnRzIChDYW1icmlkZ2Up IEx0ZCBoYXMgdGFr
ZW4gZXZlcnkgcmVhc29uYWJsZSBwcmVjYXV0aW9uIHRvIG1pbmltaXNlIHRo aXMgcmlzaywgd2Ug
Y2Fubm90IGFjY2VwdCBsaWFiaWxpdHkgZm9yIGFueSBkYW1hZ2Ugd2hpY2gg eW91IHN1c3RhaW4g
YXMgYSByZXN1bHQgb2Ygc29mdHdhcmUgdmlydXNlcy4gWW91IHNob3VsZCB0 aGVyZWZvcmUgY2Fy
cnkgb3V0IHlvdXIgb3duIHZpcnVzIGNoZWNrcyBiZWZvcmUgb3BlbmluZyB0 aGUgYXR0YWNobWVu
dChzKS4NCk9wZW5YTUw6IEZvciBpbmZvcm1hdGlvbiBhYm91dCB0aGUgT3Bl blhNTCBmaWxlIGZv
cm1hdCBpbiB1c2Ugd2l0aGluIEdyYW50IEluc3RydW1lbnRzIHBsZWFzZSB2 aXNpdCBvdXIgd2Vi
c2l0ZTxodHRwOi8vd3d3LmdyYW50LmNvLnVrL1N1cHBvcnQvb3BlbnhtbC5o dG1sPg0KDQoNCg0K
DQoNClAgUGxlYXNlIGNvbnNpZGVyIHRoZSBlbnZpcm9ubWVudCBiZWZvcmUg cHJpbnRpbmcgdGhp
cyBlbWFpbA0KDQoNCkNPTkZJREVOVElBTElUWTogVGhlIGluZm9ybWF0aW9u IGluIHRoaXMgZS1t
YWlsIGFuZCBhbnkgYXR0YWNobWVudHMgaXMgY29uZmlkZW50aWFsLiBJdCBp cyBpbnRlbmRlZCBv
bmx5IGZvciB0aGUgbmFtZWQgcmVjaXBpZW50cyhzKS4gSWYgeW91IGFyZSBu b3QgdGhlIG5hbWVk
IHJlY2lwaWVudCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRl bHkgYW5kIGRvIG5v
dCBkaXNjbG9zZSB0aGUgY29udGVudHMgdG8gYW5vdGhlciBwZXJzb24gb3Ig dGFrZSBjb3BpZXMu
DQpWSVJVU0VTOiBUaGUgY29udGVudHMgb2YgdGhpcyBlLW1haWwgb3IgYXR0 YWNobWVudChzKSBt
YXkgY29udGFpbiB2aXJ1c2VzIHdoaWNoIGNvdWxkIGRhbWFnZSB5b3VyIG93 biBjb21wdXRlciBz
eXN0ZW0uIFdoaWxzdCBHcmFudCBJbnN0cnVtZW50cyAoQ2FtYnJpZGdlKSBM dGQgaGFzIHRha2Vu
IGV2ZXJ5IHJlYXNvbmFibGUgcHJlY2F1dGlvbiB0byBtaW5pbWlzZSB0aGlz IHJpc2ssIHdlIGNh
bm5vdCBhY2NlcHQgbGlhYmlsaXR5IGZvciBhbnkgZGFtYWdlIHdoaWNoIHlv dSBzdXN0YWluIGFz
IGEgcmVzdWx0IG9mIHNvZnR3YXJlIHZpcnVzZXMuIFlvdSBzaG91bGQgdGhl cmVmb3JlIGNhcnJ5
IG91dCB5b3VyIG93biB2aXJ1cyBjaGVja3MgYmVmb3JlIG9wZW5pbmcgdGhl IGF0dGFjaG1lbnQo
cykuDQpPcGVuWE1MOiBGb3IgaW5mb3JtYXRpb24gYWJvdXQgdGhlIE9wZW5Y TUwgZmlsZSBmb3Jt
YXQgaW4gdXNlIHdpdGhpbiBHcmFudCBJbnN0cnVtZW50cyBwbGVhc2Ugdmlz aXQgb3VyIHdlYnNp
dGU8aHR0cDovL3d3dy5ncmFudC5jby51ay9TdXBwb3J0L29wZW54bWwuaHRt bD4NCg0KDQoNClAg
UGxlYXNlIGNvbnNpZGVyIHRoZSBlbnZpcm9ubWVudCBiZWZvcmUgcHJpbnRp bmcgdGhpcyBlbWFp
bA0KQ09ORklERU5USUFMSVRZOiBUaGUgaW5mb3JtYXRpb24gaW4gdGhpcyBl LW1haWwgYW5kIGFu
eSBhdHRhY2htZW50cyBpcyBjb25maWRlbnRpYWwuIEl0IGlzIGludGVuZGVk IG9ubHkgZm9yIHRo
ZSBuYW1lZCByZWNpcGllbnRzKHMpLiBJZiB5b3UgYXJlIG5vdCB0aGUgbmFt ZWQgcmVjaXBpZW50
IHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBhbmQgZG8g bm90IGRpc2Nsb3Nl
IHRoZSBjb250ZW50cyB0byBhbm90aGVyIHBlcnNvbiBvciB0YWtlIGNvcGll cy4NCg0KVklSVVNF
UzogVGhlIGNvbnRlbnRzIG9mIHRoaXMgZS1tYWlsIG9yIGF0dGFjaG1lbnQo cykgbWF5IGNvbnRh
aW4gdmlydXNlcyB3aGljaCBjb3VsZCBkYW1hZ2UgeW91ciBvd24gY29tcHV0 ZXIgc3lzdGVtLiBX
aGlsc3QgR3JhbnQgSW5zdHJ1bWVudHMgKENhbWJyaWRnZSkgTHRkIGhhcyB0 YWtlbiBldmVyeSBy
ZWFzb25hYmxlIHByZWNhdXRpb24gdG8gbWluaW1pc2UgdGhpcyByaXNrLCB3 ZSBjYW5ub3QgYWNj
ZXB0IGxpYWJpbGl0eSBmb3IgYW55IGRhbWFnZSB3aGljaCB5b3Ugc3VzdGFp biBhcyBhIHJlc3Vs
dCBvZiBzb2Z0d2FyZSB2aXJ1c2VzLiBZb3Ugc2hvdWxkIHRoZXJlZm9yZSBj YXJyeSBvdXQgeW91
ciBvd24gdmlydXMgY2hlY2tzIGJlZm9yZSBvcGVuaW5nIHRoZSBhdHRhY2ht ZW50KHMpLg0KDQpP
cGVuWE1MOiBGb3IgaW5mb3JtYXRpb24gYWJvdXQgdGhlIE9wZW5YTUwgZmls ZSBmb3JtYXQgaW4g
dXNlIHdpdGhpbiBHcmFudCBJbnN0cnVtZW50cyBwbGVhc2UgdmlzaXQgb3Vy IHdlYnNpdGU8aHR0
cDovL3d3dy5ncmFudC5jby51ay9TdXBwb3J0L29wZW54bWwuaHRtbD4NCg==

--_000_7965A9DCF12CC14984420BCC37B1608F25AB1AEF22Elzargrantc ou_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

77u/PEhUTUwgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1odG1s NDAiIHhtbG5zOm09
Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vb2ZmaWNlLzIwMDQvMTIv b21tbCIgeG1sbnM6
bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp2PSJ1cm46
c2NoZW1hcy1taWNyb3NvZnQtY29tOnZtbCIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0
LWNvbTpvZmZpY2U6d29yZCI+PGhlYWQ+PE1FVEEgY29udGVudD0idGV4dC9o dG1sOyBjaGFyc2V0
PXV0Zi04IiBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiPg0KPE1FVEEgY29u dGVudD0idGV4dC9o
dG1sOyBjaGFyc2V0PXV0Zi04IiBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUi Pg0KDQo8bWV0YSBj
b250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiIGh0dHAtZXF1aXY9 Q29udGVudC1UeXBl
Pg0KPG1ldGEgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVk IG1lZGl1bSkiIG5h
bWU9R2VuZXJhdG9yPg0KPHN0eWxlPg0KPCEtLQ0KIC8qIEZvbnQgRGVmaW5p dGlvbnMgKi8NCiBA
Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6 MiAxNSA1IDIgMiAy
IDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7 DQoJcGFub3NlLTE6
MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KIC8qIFN0eWxlIERlZmluaXRpb25z ICovDQogcC5Nc29O
b3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46 MGNtOw0KCW1hcmdp
bi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJUaW1l
cyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVy bGluaw0KCXttc28t
c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29y YXRpb246dW5kZXJs
aW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0K CXttc28tc3R5bGUt
cHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlv bjp1bmRlcmxpbmU7
fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29u YWwtcmVwbHk7DQoJ
Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjoj MUY0OTdEO30NCi5N
c29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0K CWZvbnQtc2l6ZTox
MC4wcHQ7fQ0KQHBhZ2UgU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4w cHQ7DQoJbWFyZ2lu
OjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuU2VjdGlvbjEN Cgl7cGFnZTpTZWN0
aW9uMTt9DQotLT4NCjwvc3R5bGU+DQo8IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4NCiA8bzpzaGFw
ZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94 bWw+PCFbZW5kaWZd
LS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQogPG86c2hhcGVsYXlvdXQg djpleHQ9ImVkaXQi
Pg0KICA8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCiA8L286 c2hhcGVsYXlvdXQ+
PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+PEJPRFk+DQo8RElWIFNUWUxF PSJGT05ULVNJWkU6
IDlwdDsgRk9OVC1GQU1JTFk6IENvdXJpZXIgTmV3Ij4NCjxESVY+DQo8RElW PjxGT05UIEZBQ0U9
IkFyaWFsIiBTSVpFPSIyIj4NCg0KPGRpdiBjbGFzcz1TZWN0aW9uMT4NCg0K PHAgY2xhc3M9TXNv
Tm9ybWFsPkhpIEnDsWlnbyw8bzpwPjwvbzpwPjwvcD4NCg0KPHAgY2xhc3M9 TXNvTm9ybWFsPjxv
OnA+Jm5ic3A7PC9vOnA+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+VGhh bmsgeW91IGZvciB5
b3VyIGlucHV0LCByZWFsbHkgYXBwcmVjaWF0ZWQuPG86cD48L286cD48L3A+ DQoNCjxwIGNsYXNz
PU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCg0KPHAgY2xhc3M9 TXNvTm9ybWFsPkkg
anVzdCBoYWQgYSB0aG91Z2h0OyBpZiBJIGJhY2t1cCDigJhwZ19kdW1w4oCZ IGZ1bGwgZGF0YWJh
c2UsDQp0aGVuIHJlc3RvcmUgdG8gbXkgbmV3IG1hY2hpbmUgbmV3IHBvc3Rn cmVzIDguNCwgd2hp
Y2ggb25lIG9mIHRoZXNlIHByb2dyYW1zDQp3b3VsZCB3b3JrIGJlc3QgdG8g ZG8gdGhlIG1pZ3Jh
dGlvbiw8bzpwPjwvbzpwPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPlNs b255LCBCdWNhcmRv
IG9yIExvbmRpc3RlPzxvOnA+PC9vOnA+PC9wPg0KDQo8cCBjbGFzcz1Nc29O b3JtYWw+PG86cD4m
bmJzcDs8L286cD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD5JIHdvdWxk IGxpa2UgdG8gc2F5
IHRoYXQgd2UgZGlkIGhhdmUgc2xvbnkgYW5kIEkgd2FzIG5vdA0KaW1wcmVz c2VkLCBpdCBmZWxs
IGJlaGluZCBhbmQgY291bGQgbm90IGNhdGNoIHVwIGFuZCBjYXVzZWQgYSB2 ZXJ5IGhpZ2ggbG9h
ZCBvbg0KdGhlIHN5c3RlbS48bzpwPjwvbzpwPjwvcD4NCg0KPHAgY2xhc3M9 TXNvTm9ybWFsPkFs
c28gdGhleSB3YXkgaXRzIHBoaWxvc29waHkgd29ya3MsIGl0IGlzIHZlcnkg aGlnaA0KbWFpbnRl
bmFuY2UsIGFuZCB0aGUgaWRlYSBvZiBjcmVhdGluZyB0YWJsZXMsIGFuZCB0 cmlnZ2VycyBvbiBi
b3RoIGRicy4uLjxvOnA+PC9vOnA+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3Jt YWw+SXQgbWlnaHQg
YmUsIGl0IHdhcyBub3Qgc2V0dXAgcHJvcGVybHkgb3Igd2VsbCwgd2UgcmVt b3ZlZA0KaXQgYXMg
dGhlIGRiIHdhcyBzY3JlYW1pbmcgZm9yIHNvbWUgZnJlc2ggYWlyLjxvOnA+ PC9vOnA+PC9wPg0K
DQo8cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+DQoN CjxwIGNsYXNzPU1z
b05vcm1hbD5QcyBJIHdvdWxkIGxpa2UgdG8gcG9pbnQgb3V0IHRoYXQgSSBh bSBzeXN0ZW1zIGFk
bWluaXN0cmF0b3INCmFuZCBub3QgYSBkYmEsIHNvIHlvdSBjYW4gdW5kZXJz dGFuZCBzb21ldGlt
ZXMgbXkgcXVlc3Rpb25zLi4uPG86cD48L286cD48L3A+DQoNCjxwIGNsYXNz PU1zb05vcm1hbD48
bzpwPiZuYnNwOzwvbzpwPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPkkg dGhpbmsgQnVjYXJk
byBzZWVtcyBiZXN0IGZvciB0aGUgdGFzaywgZm9yIHdoYXQgSSBoYXZlDQpy ZWFkIHNvIGZhciwg
Jm5ic3A7YnV0IEkgZG8gbm90IGtub3cuPG86cD48L286cD48L3A+DQoNCjxw IGNsYXNzPU1zb05v
cm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9y bWFsPlRoYW5rIHlv
dSB2ZXJ5IG11Y2ggYW5kIEkgYW0gc29ycnkgZm9yIHRoaXM8bzpwPjwvbzpw PjwvcD4NCg0KPHAg
Y2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KDQo8cCBj bGFzcz1Nc29Ob3Jt
YWw+UmVuYXRvPG86cD48L286cD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1h bD48bzpwPiZuYnNw
OzwvbzpwPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxl PSdmb250LXNpemU6
MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQpj b2xvcjojMUY0OTdE
Jz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1z b05vcm1hbD48c3Bh
biBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJy aSIsInNhbnMtc2Vy
aWYiOw0KY29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KDQo8ZGl2
Pg0KDQo8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIEZBQ0U9IkFyaWFsIiBT SVpFPSIyIj48L0ZP
TlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIEZBQ0U9IkFyaWFsIiBTSVpF PSIyIj48Rk9OVCBG
QUNFPSJBcmlhbCIgU0laRT0iMiI+UmVuYXRvIE9saXZlaXJhPEJSPlN5c3Rl bXMgQWRtaW5pc3Ry
YXRvcjxCUj5lLW1haWw6IHJlbmF0by5vbGl2ZWlyYUBncmFudC5jby51azwv Rk9OVD48L0ZPTlQ+
PEZPTlQgRkFDRT0iQXJpYWwiIFNJWkU9IjIiPjxGT05UIEZBQ0U9IkFyaWFs IiBTSVpFPSIyIj48
L0ZPTlQ+PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBGQUNFPSJBcmlhbCIg U0laRT0iMiI+PEZP
TlQgRkFDRT0iQXJpYWwiIFNJWkU9IjIiPjwvRk9OVD48L0ZPTlQ+Jm5ic3A7 PC9ESVY+DQo8RElW
PjxGT05UIEZBQ0U9IkFyaWFsIiBTSVpFPSIyIj48Rk9OVCBGQUNFPSJBcmlh bCIgU0laRT0iMiI+
VGVsOiArNDQgKDApMTc2MyAyNjA4MTE8QlI+RmF4OiArNDQgKDApMTc2MyAy NjI0MTA8QlI+PEEg
SFJFRj0iaHR0cDovL3d3dy5ncmFudC5jby51ay8iPnd3dy5ncmFudC5jby51 azwvQT48L0ZPTlQ+
PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBGQUNFPSJBcmlhbCIgU0laRT0i MiI+PEZPTlQgRkFD
RT0iQXJpYWwiIFNJWkU9IjIiPjwvRk9OVD48L0ZPTlQ+Jm5ic3A7PC9ESVY+ DQo8RElWPjxGT05U
IEZBQ0U9IkFyaWFsIiBTSVpFPSIyIj48Rk9OVCBGQUNFPSJBcmlhbCIgU0la RT0iMiI+R3JhbnQg
SW5zdHJ1bWVudHMgKENhbWJyaWRnZSkgTHRkIDxCUj4mbmJzcDs8QlI+Q29t cGFueSByZWdpc3Rl
cmVkIGluIEVuZ2xhbmQsIHJlZ2lzdHJhdGlvbiBudW1iZXIgNjU4MTMzPEJS PiZuYnNwOzxCUj5S
ZWdpc3RlcmVkIG9mZmljZSBhZGRyZXNzOjxCUj4yOSBTdGF0aW9uIFJvYWQs IDxCUj5TaGVwcmV0
aCwgPEJSPkNBTUJTIFNHOCA2R0IgPEJSPlVLPC9GT05UPjwvRk9OVD48L0RJ Vj4NCjxESVY+PEZP
TlQgRkFDRT0iQXJpYWwiIFNJWkU9IjIiPjxGT05UIEZBQ0U9IkFyaWFsIiBT SVpFPSIyIj48L0ZP
TlQ+PC9GT05UPjxGT05UIEZBQ0U9IkFyaWFsIiBTSVpFPSIyIj48Rk9OVCBG QUNFPSJBcmlhbCIg
U0laRT0iMiI+PC9GT05UPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZP TlQgRkFDRT0iQXJp
YWwiIFNJWkU9IjIiPjxGT05UIEZBQ0U9IkFyaWFsIiBTSVpFPSIyIj48L0ZP TlQ+PC9GT05UPjwv
RElWPg0KPERJVj48Rk9OVCBGQUNFPSJBcmlhbCIgU0laRT0iMiI+PEZPTlQg RkFDRT0iQXJpYWwi
IFNJWkU9IjIiPjwvRk9OVD48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxG T05UIEZBQ0U9IkFy
aWFsIiBTSVpFPSIyIj48Rk9OVCBGQUNFPSJBcmlhbCIgU0laRT0iMiI+DQoN CjxwIGNsYXNzPU1z
b05vcm1hbD48Yj48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6 MTAuMHB0O2ZvbnQt
ZmFtaWx5Og0KIlRhaG9tYSIsInNhbnMtc2VyaWYiJz5Gcm9tOjwvc3Bhbj48 L2I+PHNwYW4gbGFu
Zz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsNCmZvbnQtZmFtaWx5 OiJUYWhvbWEiLCJz
YW5zLXNlcmlmIic+IEnDsWlnbyBNYXJ0aW5leiBMYXNhbGENClttYWlsdG86 aW1hcnRpbmV6QHZl
Y3RvcnNmLmNvbV0gPGJyPg0KPGI+U2VudDo8L2I+IDMwIE1hcmNoIDIwMTAg MTY6Mjc8YnI+DQo8
Yj5Ubzo8L2I+IFJlbmF0byBPbGl2ZWlyYTxicj4NCjxiPkNjOjwvYj4gcGdz cWwtYWRtaW48YnI+
DQo8Yj5TdWJqZWN0OjwvYj4gUkU6IFtBRE1JTl0gTWlncmF0ZSBwb3N0Z3Jl cyB0byBuZXdlciBo
YXJkd2FyZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPC9kaXY+DQoNCjwv ZGl2Pg0KDQo8cCBj
bGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+DQoNCjxwIGNs YXNzPU1zb05vcm1h
bD5ZZXMsIHlvdSBvbmx5IGhhdmUgdGhhdCB0d28gcG9zc2liaWxpdGllcywg SSB0aGluay48YnI+
DQo8YnI+DQpQSVRSIGlzIG5vdCBhbiBvcHRpb24uIEkgdGVzdGVkIHRoZSBz YW1lLCBmcm9tIDcu
NCAzMmJpdCB0byA3LjQgNjRiaXQgYW5kDQpkaWRuJ3Qgd29yay4gTGF0ZXIs IHdoZW4gSSBhc2tl
ZCBoZXJlLCBJIHdhcyB0b2xkIHdoeSBub3QuPGJyPg0KPGJyPg0KVGhlIHBy b2JsZW0gd2l0aCBz
bG9ueSBpcyB0aGF0IHlvdSBoYXZlIHRvIG1hbnVhbGx5IGNyZWF0ZSB0YWJs ZXMgaW4NCmRlc3Rp
bmF0aW9uIGRhdGFiYXNlIGFuZCBhbGwgZGF0YWJhc2UgbW9kZWwgKHByb2Nl ZHVyZXMsIHRyaWdn
ZXJzLCBzZXF1ZW5jZXMsDQp2aWV3cywgZXRjKS4gSWYgeW91ciBhcHBsaWNh dGlvbiBjcmVhdGVz
IG5ldyB0YWJsZXMsIHlvdSB3aWxsIGhhdmUgdG8gZGVhbCB3aXRoDQp0aGlz IHByaW9yIHN0YXJ0
aW5nIG1pZ3JhdGlvbiwgb3IgYXQgbGVhc3QgZGlzYWJsZSB0aGUgY3JlYXRp b24gb2YgbmV3IHRh
Ymxlcy48YnI+DQo8YnI+DQpTbG9ueSBpcyBhc3luY2hyb25vdXMsIHNvIHlv dSB3aWxsIGhhdmUg
dG8gZW5zdXJlIHRoYXQgYWxsIGNoYW5nZXMgaGF2ZSBiZWVuDQpjb21taXR0 ZWQgdG8gbmV3IGRh
dGFiYXNlIGJlZm9yZSBjaGFuZ2luZyB5b3VyIGFwcGxpY2F0aW9ucyBvciBl eGNoYW5naW5nIElQ
DQphZGRyZXNzZXMuPGJyPg0KU2xvbnkgYWxzbyBhZGQgbWFueSB0cmlnZ2Vy cyBhbmQgc3BlY2lh
bCB0YWJsZXMgdG8gYm90aCBkYXRhYmFzZXMgKG1hc3RlciBhbmQNCnNsYXZl KS4gU28sIGFmdGVy
IG1pZ3JhdGlvbiwgeW91IHdpbGwgaGF2ZSB0byBkZWxldGUgdGhlbS4gSXQn cyBub3QgZGlmZmlj
dWx0DQpidXQgZG9uJ3QgZm9yZ2V0IHRvIGRvIGl0Ljxicj4NCjxicj4NCkJ5 IHRoZSB3YXksIGFy
ZSB5b3Ugc3VyZSB5b3VyIGRhdGFiYXNlIGlzIDE2MEdCPyBJbmNsdWRpbmcg aW5kZXhlcz8gVGhl
cmUgYXJlDQpzdHJhdGVnaWVzIGluIG9yZGVyIHRvIHBlcmZvcm0gYSBmYXN0 ZXIgcGdfcmVzdG9y
ZS4uLiA8YnI+DQpGb3IgZXhhbXBsZSwgaWYgeW91IG1pZ3JhdGUgeW91ciBk YXRhYmFzZSBzY2hl
bWEgYnV0IGRvbid0IGNyZWF0ZSBpbmRleGVzLCB0aGVuDQptaWdyYXRlIGRh dGEgYW5kIGZpbmFs
bHkgY3JlYXRlIHBlbmRpbmcgaW5kZXhlcyByZXN0b3JlIHdpbGwgYmUgZmFz dGVyLiBXaXRoIHBn
DQo4LjQgcmVzdG9yZSBpcyB2ZXJ5IGZhc3QsIHNvIGl0IHdpbGwgdGFrZSBs ZXNzIHRpbWUgdGhh
dCBleHBvcnQuPGJyPg0KPGJyPg0KQW55d2F5LCBpZiB5b3UgY2Fubm90IGxl YXZlIGRhdGFiYXNl
IGRvd24gZm9yIGEgZGF5LCBJIHRoaW5rIHNsb255IHdpbGwgYmUgeW91cg0K YmVzdCBiZXQsIGFs
dGhvdWdoIGl0J3Mgbm90IGV4ZW1wdCBvZiBwcm9ibGVtcy4gOik8YnI+DQo8 YnI+DQotLS0tLU9y
aWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCjxiPkZyb208L2I+OiBSZW5hdG8g T2xpdmVpcmEgJmx0
OzxhIGhyZWY9Im1haWx0bzpSZW5hdG8lMjBPbGl2ZWlyYSUyMCUzY3JlbmF0 by5vbGl2ZWlyYUBn
cmFudC5jby51ayUzZSI+cmVuYXRvLm9saXZlaXJhQGdyYW50LmNvLnVrPC9h PiZndDs8YnI+DQo8
Yj5UbzwvYj46IEnDsWlnbyBNYXJ0aW5leiBMYXNhbGEgJmx0OzxhIGhyZWY9 Im1haWx0bzolM2Ql
M2ZJU08tODg1OS0xJTNmUSUzZkklM2RGMWlnbyUzZiUzZCUyME1hcnRpbmV6 JTIwTGFzYWxhJTIw
JTNjaW1hcnRpbmV6QHZlY3RvcnNmLmNvbSUzZSI+aW1hcnRpbmV6QHZlY3Rv cnNmLmNvbTwvYT4m
Z3Q7PGJyPg0KPGI+U3ViamVjdDwvYj46IFJFOiBbQURNSU5dIE1pZ3JhdGUg cG9zdGdyZXMgdG8g
bmV3ZXIgaGFyZHdhcmU8YnI+DQo8Yj5EYXRlPC9iPjogVHVlLCAzMCBNYXIg MjAxMCAxNTo0Nzoy
NyArMDEwMDxicj4NCjxicj4NCu+7vyA8c3BhbiBzdHlsZT0nZm9udC1zaXpl OjEwLjBwdCc+SGV5
IEnDsWlnbyw8L3NwYW4+PGJyPg0KPGJyPg0KPHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToxMC4wcHQn
PiZuYnNwOzwvc3Bhbj48YnI+DQo8YnI+DQo8c3BhbiBzdHlsZT0nZm9udC1z aXplOjEwLjBwdCc+
VGhhbmsgeW91IHZlcnkgbXVjaCBmb3IgeW91ciByZXBseS48L3NwYW4+PGJy Pg0KPGJyPg0KPHNw
YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPiZuYnNwOzwvc3Bhbj48YnI+ DQo8YnI+DQo8c3Bh
biBzdHlsZT0nZm9udC1zaXplOjEwLjBwdCc+SSB3b3VsZCBsb3ZlIHRvIGRv IGp1c3QgdGhhdCwg
YnV0IHVuZm9ydHVuYXRlbHkNCkkgY2Fu4oCZdCBpdCBpcyBub3QgYXMgc2lt cGxlIGFzIHRoYXQu
PC9zcGFuPjxicj4NCjxicj4NCjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAu MHB0Jz4mbmJzcDs8
L3NwYW4+PGJyPg0KPGJyPg0KPHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4w cHQnPkkgd291bGQg
bG92ZSBpZiB0aGUgYXBwbGljYXRpb24gaGFkIGJlZW4gYnVpbHQNCmluIHdp dGggdGhpcyBpbiBt
aW5k4oCmPC9zcGFuPjxicj4NCjxicj4NCjxzcGFuIHN0eWxlPSdmb250LXNp emU6MTAuMHB0Jz4m
bmJzcDs8L3NwYW4+PGJyPg0KPGJyPg0KPHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMC4wcHQnPlRv
IGdpdmUgeW91IGFuIGlkZWE7IHRoZSBwZ19kdW1wIHRha2VzIDE1IGhvdXJz DQphbmQgSSBhdHRl
bXB0ZWQgYSByZXN0b3JlIHllc3RlcmRheSBhbmQgaXQgdG9vayAxNCBob3Vy cyBhbmQgMjEgbWlu
Ljwvc3Bhbj48YnI+DQo8YnI+DQo8c3BhbiBzdHlsZT0nZm9udC1zaXplOjEw LjBwdCc+SXQgd291
bGQgbm90IGJlIHZpYWJsZSBmb3IgdXMgYW5kIHNwZWNpYWxseSBJDQpjYW5u b3QgaGF2ZSB0aGUg
c3lzdGVtIGRvd24gbW9yZSB0aGFuIG1heGltdW0gMzAgbWluIHdpdGhvdXQg dGhlIHJpc2sgb2Yg
bG9zaW5nDQpkYXRhIGFuZCBjdXN0b21lcnMgbm90IGhhdmluZyBhbGVydHMu PC9zcGFuPjxicj4N
Cjxicj4NCjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz4mbmJzcDs8 L3NwYW4+PGJyPg0K
PGJyPg0KPHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPkkgZG9u4oCZ dCB0aGluayBJIHdp
bGwgYmUgYWJsZSB0byB1c2UgUElUUiB0bw0KbWlncmF0ZSB0byBuZXcgc2Vy dmVycyBzcGVjaWFs
bHkgaWYgaXQgaXMgNjQgYml0IGFuZCB0byBtaWdyYXRlIHRvIGFub3RoZXIg MzINCmJpdCBpcyBu
byBnYWluLCBhcyB3ZSBuZWVkIG1vcmUgbWVtb3J5Ljwvc3Bhbj48YnI+DQo8 YnI+DQo8c3BhbiBz
dHlsZT0nZm9udC1zaXplOjEwLjBwdCc+Jm5ic3A7PC9zcGFuPjxicj4NCjxi cj4NCjxzcGFuIHN0
eWxlPSdmb250LXNpemU6MTAuMHB0Jz5BcyBmYXIgYXMgY2FuIGdhdGhlciB0 aGVyZSBhcmUgb25s
eSB0d28gd2F5czo8L3NwYW4+PGJyPg0KPGJyPg0KPHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZToxMC4w
cHQnPmEpJm5ic3A7Jm5ic3A7Jm5ic3A7U2xvbnkgdHlwZTwvc3Bhbj48YnI+ DQo8YnI+DQo8c3Bh
biBzdHlsZT0nZm9udC1zaXplOjEwLjBwdCc+YikmbmJzcDsmbmJzcDsmbmJz cDtQZ19kdW1wPC9z
cGFuPjxicj4NCjxicj4NCjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0 Jz4mbmJzcDs8L3Nw
YW4+PGJyPg0KPGJyPg0KPHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQn PklzIHRoYXQgY29y
cmVjdCA/IERvIHlvdSBndXlzIGhhdmUgYW55IG90aGVyDQp3YXlzPzwvc3Bh bj48YnI+DQo8YnI+
DQo8c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdCc+Jm5ic3A7PC9zcGFu Pjxicj4NCjxicj4N
CjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz5SZW5hdG88L3NwYW4+ PGJyPg0KPGJyPg0K
PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPiZuYnNwOzwvc3Bhbj48 YnI+DQo8YnI+DQo8
c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdCc+Jm5ic3A7PC9zcGFuPjxi cj4NCjxicj4NCjxi
cj4NCiZuYnNwOyA8c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdCc+UmVu YXRvIE9saXZlaXJh
PC9zcGFuPjxicj4NCjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz5T eXN0ZW1zIEFkbWlu
aXN0cmF0b3I8L3NwYW4+PGJyPg0KPHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox MC4wcHQnPmUtbWFp
bDogcmVuYXRvLm9saXZlaXJhQGdyYW50LmNvLnVrPC9zcGFuPg0KJm5ic3A7 IDxzcGFuIHN0eWxl
PSdmb250LXNpemU6MTAuMHB0Jz5UZWw6ICs0NCAoMCkxNzYzIDI2MDgxMTwv c3Bhbj48YnI+DQo8
c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdCc+RmF4OiArNDQgKDApMTc2 MyAyNjI0MTA8L3Nw
YW4+PGJyPg0KPHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPjxhIGhy ZWY9Imh0dHA6Ly93
d3cuZ3JhbnQuY28udWsvIj53d3cuZ3JhbnQuY28udWs8L2E+PC9zcGFuPg0K Jm5ic3A7IDxzcGFu
IHN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz5HcmFudCBJbnN0cnVtZW50cyAo Q2FtYnJpZGdlKSBM
dGQgPC9zcGFuPjxicj4NCjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0 Jz4mbmJzcDs8L3Nw
YW4+PGJyPg0KPHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPkNvbXBh bnkgcmVnaXN0ZXJl
ZCBpbiBFbmdsYW5kLCByZWdpc3RyYXRpb24NCm51bWJlciA2NTgxMzM8L3Nw YW4+PGJyPg0KPHNw
YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPiZuYnNwOzwvc3Bhbj48YnI+ DQo8c3BhbiBzdHls
ZT0nZm9udC1zaXplOjEwLjBwdCc+UmVnaXN0ZXJlZCBvZmZpY2UgYWRkcmVz czo8L3NwYW4+PGJy
Pg0KPHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPjI5IFN0YXRpb24g Um9hZCwgPC9zcGFu
Pjxicj4NCjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz5TaGVwcmV0 aCwgPC9zcGFuPjxi
cj4NCjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz5DQU1CUyBTRzgg NkdCIDwvc3Bhbj48
YnI+DQo8c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdCc+VUs8L3NwYW4+ ICZuYnNwOyA8YnI+
DQombmJzcDsgPGI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPkZy b206PC9zcGFuPjwv
Yj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdCc+IEnDsWlnbyBNYXJ0 aW5leiBMYXNhbGEg
W21haWx0bzppbWFydGluZXpAdmVjdG9yc2YuY29tXQ0KPC9zcGFuPjxicj4N CjxiPjxzcGFuIHN0
eWxlPSdmb250LXNpemU6MTAuMHB0Jz5TZW50Ojwvc3Bhbj48L2I+PHNwYW4g c3R5bGU9J2ZvbnQt
c2l6ZToxMC4wcHQnPg0KMzAgTWFyY2ggMjAxMCAxNToyOTwvc3Bhbj48YnI+ DQo8Yj48c3BhbiBz
dHlsZT0nZm9udC1zaXplOjEwLjBwdCc+VG86PC9zcGFuPjwvYj48c3BhbiBz dHlsZT0nZm9udC1z
aXplOjEwLjBwdCc+DQpSZW5hdG8gT2xpdmVpcmE8L3NwYW4+PGJyPg0KPGI+ PHNwYW4gc3R5bGU9
J2ZvbnQtc2l6ZToxMC4wcHQnPkNjOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZTox
MC4wcHQnPg0KcGdzcWwtYWRtaW48L3NwYW4+PGJyPg0KPGI+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6
ZToxMC4wcHQnPlN1YmplY3Q6PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0nZm9u dC1zaXplOg0KMTAu
MHB0Jz4gUmU6IFtBRE1JTl0gTWlncmF0ZSBwb3N0Z3JlcyB0byBuZXdlciBo YXJkd2FyZTwvc3Bh
bj48YnI+DQo8YnI+DQo8YnI+DQo8c3BhbiBzdHlsZT0nZm9udC1zaXplOjEw LjBwdCc+Jm5ic3A7
PC9zcGFuPjxicj4NCjxicj4NCjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAu MHB0Jz5IaSBSZW5h
dG8uPC9zcGFuPjxicj4NCjxicj4NCjxzcGFuIHN0eWxlPSdmb250LXNpemU6 MTAuMHB0Jz5JIHdv
dWxkIGZvbGxvdyB0aGUgYW5jaWVudCBtZXRob2Q6IHBlcmZvcm0gYQ0KcGdf ZHVtcCAvIHBnX3Jl
c3RvcmU8L3NwYW4+PGJyPg0KPGJyPg0KPHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMC4wcHQnPlll
cywgeW91IHdpbGwgaGF2ZSB0byB0YWtlIG9mZmxpbmUgZGF0YWJhc2UgZm9y DQphIGxvbmcgcGVy
aW9kLjwvc3Bhbj48YnI+DQo8YnI+DQo8c3BhbiBzdHlsZT0nZm9udC1zaXpl OjEwLjBwdCc+QW5k
IHllcywgaXQgd291bGQgYmUgYSBncmVhdCBtb21lbnQgdG8gcGVyZm9ybSBh DQo4LjQgdXBncmFk
ZS4gUGVyZm9ybWFuY2UgaXMgZmFyIHN1cGVyaW9yLCByZXN0b3JlIGlzIGZh ciBmYXN0ZXIuLi4g
PC9zcGFuPjxicj4NCjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz4u Li4gYW5kIHllcywg
aXQgY291bGQgZ2l2ZSB5b3UgbWFueSBwcm9ibGVtcyBpZg0KeW91IGRvbid0 IHBlcmZvcm0gbWFu
eSB0ZXN0IGluIG9yZGVyIHRvIGFkZHJlc3MgYWxsIHF1ZXJpZXMgd2l0aG91 dCBleHBsaWNpdA0K
dHlwZSBjb252ZXJzaW9ucyBiZWZvcmUgcmVhbCBtaWdyYXRpb24sIGJ1dCBJ IHRoaW5rIGl0J3Mg
dGhlIGJlc3QgbW9tZW50IHRvDQpkZWFsIHdpdGggYSB2ZXJ5IGNvbnZlbmll bnQgdXBncmFkZS4m
bmJzcDsgPC9zcGFuPjxicj4NCjxicj4NCjxzcGFuIHN0eWxlPSdmb250LXNp emU6MTAuMHB0Jz5X
ZSBoYXZlIHBlcmZvcm1lZCB0aGlzIHVwZ3JhZGUgbGFzdCB3ZWVrIHdpdGgg YQ0KZ2ZvcmdlICh3
aXRoIG9ubHkgMjVHQiBkYXRhYmFzZSkgYW5kIGhhdmluZyBhbHNvIHRvIHVw Z3JhZGUgdG8gbmV3
IHRzZWFyY2gyIGFuZA0KZXZlcnl0aGluZyBpcyBydW5uaW5nIHNtb290aC48 L3NwYW4+PGJyPg0K
PGJyPg0KPHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPi0tLS0tT3Jp Z2luYWwgTWVzc2Fn
ZS0tLS0tPC9zcGFuPjxicj4NCjxiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 MTAuMHB0Jz5Gcm9t
PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdCc+Og0K UmVuYXRvIE9saXZl
aXJhICZsdDs8YSBocmVmPSJtYWlsdG86UmVuYXRvJTIwT2xpdmVpcmElMjAl M2NyZW5hdG8ub2xp
dmVpcmFAZ3JhbnQuY28udWslM2UiPnJlbmF0by5vbGl2ZWlyYUBncmFudC5j by51azwvYT4mZ3Q7
PC9zcGFuPjxicj4NCjxiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0 Jz5Ubzwvc3Bhbj48
L2I+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPjoNCnBnc3FsLWFk bWluQHBvc3RncmVz
cWwub3JnICZsdDs8YSBocmVmPSJtYWlsdG86JTIycGdzcWwtYWRtaW5AcG9z dGdyZXNxbC5vcmcl
MjIlMjAlM2NwZ3NxbC1hZG1pbkBwb3N0Z3Jlc3FsLm9yZyUzZSI+cGdzcWwt YWRtaW5AcG9zdGdy
ZXNxbC5vcmc8L2E+Jmd0Ozwvc3Bhbj48YnI+DQo8Yj48c3BhbiBzdHlsZT0n Zm9udC1zaXplOjEw
LjBwdCc+U3ViamVjdDwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToNCjEwLjBwdCc+
OiBbQURNSU5dIE1pZ3JhdGUgcG9zdGdyZXMgdG8gbmV3ZXIgaGFyZHdhcmU8 L3NwYW4+PGJyPg0K
PGI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPkRhdGU8L3NwYW4+ PC9iPjxzcGFuIHN0
eWxlPSdmb250LXNpemU6MTAuMHB0Jz46DQpUdWUsIDMwIE1hciAyMDEwIDEy OjE4OjM2ICswMTAw
PC9zcGFuPjxicj4NCjxicj4NCjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAu MHB0Jz5EZWFyIEFs
bCw8L3NwYW4+PGJyPg0KPGJyPg0KPHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox MC4wcHQnPiZuYnNw
Ozwvc3Bhbj48YnI+DQo8YnI+DQo8c3BhbiBzdHlsZT0nZm9udC1zaXplOjEw LjBwdCc+V2hhdCB3
b3VsZCBiZSB0aGUgZWFzaWVzdCBhbmQgZmFzdGVzdCB3YXkgdG8NCm1pZ3Jh dGUgUG9zdGdyZXMg
OC4yLjI0IDMyIEJJVCB0byBhIG5ldyBzZXJ2ZXIgNjQgQml0Ljwvc3Bhbj48 YnI+DQo8YnI+DQo8
c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdCc+Jm5ic3A7PC9zcGFuPjxi cj4NCjxicj4NCjxz
cGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz5UaGUgZXhpc3Rpbmcgc2Vy dmVyIHJ1bnMgb24g
MzIgYml0IGFyY2hpdGVjdHVyZQ0KYW5kIGhhcyBhIGRhdGFiYXNlIGFzIGJp ZyBhcyAxNjBHQi48
L3NwYW4+PGJyPg0KPGJyPg0KPHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4w cHQnPiZuYnNwOzwv
c3Bhbj48YnI+DQo8YnI+DQo8c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBw dCc+V2UgaW5pdGlh
bGx5IHRob3VnaHQgb2YgdXNpbmcgUElUUiwgYnV0IGFzIG9uZQ0Kb2YgdGhl IFBJVFIgcmVxdWly
ZW1lbnRzIGlzIGJvdGggbWFjaGluZXMgbmVlZCB0byBiZSBzaW1pbGFyLiA8 L3NwYW4+PGJyPg0K
PGJyPg0KPHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPlRoaXMgc2lt aWxhcml0eSBuZWVk
cyB0byBiZSBldmVuIGluDQphcmNoaXRlY3R1cmU/IEkgdGhpbmsgSSByZWFk IHNvbWV0aGluZyB3
aGljaCBzYXlzIOKAnFllc+KAnS48L3NwYW4+PGJyPg0KPGJyPg0KPHNwYW4g c3R5bGU9J2ZvbnQt
c2l6ZToxMC4wcHQnPiZuYnNwOzwvc3Bhbj48YnI+DQo8YnI+DQo8c3BhbiBz dHlsZT0nZm9udC1z
aXplOjEwLjBwdCc+SWYgd2UgY2Fubm90IHVzZSBQSVRSIHdoYXQgd291bGQg YmUgdGhlIGJlc3QN
CmFwcHJvYWNoLCB3ZSBjYW7igJl0IGhhdmUgZG93biB0aW1lIEkgYW0gYWZy YWlkLjwvc3Bhbj48
YnI+DQo8YnI+DQo8c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdCc+Jm5i c3A7PC9zcGFuPjxi
cj4NCjxicj4NCjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz5Bbnkg aWRlYXMgb3Igc3Vn
Z2VzdGlvbnMgd291bGQgYmUgdmVyeSB3ZWxjb21lLjwvc3Bhbj48YnI+DQo8 YnI+DQo8c3BhbiBz
dHlsZT0nZm9udC1zaXplOjEwLjBwdCc+Jm5ic3A7PC9zcGFuPjxicj4NCjxi cj4NCjxzcGFuIHN0
eWxlPSdmb250LXNpemU6MTAuMHB0Jz5UaGFuayB5b3UgdmVyeSBtdWNoPC9z cGFuPjxicj4NCjxi
cj4NCjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz4mbmJzcDs8L3Nw YW4+PGJyPg0KPGJy
Pg0KPHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPkJlc3QgcmVnYXJk czwvc3Bhbj48YnI+
DQo8YnI+DQo8c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdCc+Jm5ic3A7 PC9zcGFuPjxicj4N
Cjxicj4NCjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz5SZW5hdG88 L3NwYW4+PGJyPg0K
PGJyPg0KPHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPiZuYnNwOzwv c3Bhbj48YnI+DQo8
YnI+DQo8c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdCc+Jm5ic3A7PC9z cGFuPjxicj4NCjxi
cj4NCjxicj4NCjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz4mbmJz cDsgUmVuYXRvIE9s
aXZlaXJhPC9zcGFuPjxicj4NCjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAu MHB0Jz5TeXN0ZW1z
IEFkbWluaXN0cmF0b3I8L3NwYW4+PGJyPg0KPHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToxMC4wcHQn
PmUtbWFpbDogcmVuYXRvLm9saXZlaXJhQGdyYW50LmNvLnVrICZuYnNwOyBU ZWw6DQorNDQgKDAp
MTc2MyAyNjA4MTE8L3NwYW4+PGJyPg0KPHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMC4wcHQnPkZh
eDogKzQ0ICgwKTE3NjMgMjYyNDEwPC9zcGFuPjxicj4NCjxzcGFuIHN0eWxl PSdmb250LXNpemU6
MTAuMHB0Jz48YSBocmVmPSJodHRwOi8vd3d3LmdyYW50LmNvLnVrLyI+d3d3 LmdyYW50LmNvLnVr
PC9hPg0KJm5ic3A7IEdyYW50IEluc3RydW1lbnRzIChDYW1icmlkZ2UpIEx0 ZCA8L3NwYW4+PGJy
Pg0KPHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPiZuYnNwOzwvc3Bh bj48YnI+DQo8c3Bh
biBzdHlsZT0nZm9udC1zaXplOjEwLjBwdCc+Q29tcGFueSByZWdpc3RlcmVk IGluIEVuZ2xhbmQs
IHJlZ2lzdHJhdGlvbg0KbnVtYmVyIDY1ODEzMzwvc3Bhbj48YnI+DQo8c3Bh biBzdHlsZT0nZm9u
dC1zaXplOjEwLjBwdCc+Jm5ic3A7PC9zcGFuPjxicj4NCjxzcGFuIHN0eWxl PSdmb250LXNpemU6
MTAuMHB0Jz5SZWdpc3RlcmVkIG9mZmljZSBhZGRyZXNzOjwvc3Bhbj48YnI+ DQo8c3BhbiBzdHls
ZT0nZm9udC1zaXplOjEwLjBwdCc+MjkgU3RhdGlvbiBSb2FkLCA8L3NwYW4+ PGJyPg0KPHNwYW4g
c3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPlNoZXByZXRoLCA8L3NwYW4+PGJy Pg0KPHNwYW4gc3R5
bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPkNBTUJTIFNHOCA2R0IgPC9zcGFuPjxi cj4NCjxzcGFuIHN0
eWxlPSdmb250LXNpemU6MTAuMHB0Jz5VSyAmbmJzcDsgPC9zcGFuPjxicj4N CjxzcGFuIHN0eWxl
PSdmb250LXNpemU6MTAuMHB0Jz4mbmJzcDsgPC9zcGFuPjxicj4NCjxzcGFu IHN0eWxlPSdmb250
LXNpemU6MTAuMHB0Jz4mbmJzcDsgPC9zcGFuPjxicj4NCjxzcGFuIHN0eWxl PSdmb250LXNpemU6
MTAuMHB0Jz4mbmJzcDsgJm5ic3A7PC9zcGFuPjxicj4NCjxicj4NCjxiPjxp PjxzcGFuIHN0eWxl
PSdmb250LXNpemU6MTAuMHB0Jz5QIFBsZWFzZSBjb25zaWRlciB0aGUgZW52 aXJvbm1lbnQgYmVm
b3JlDQpwcmludGluZyB0aGlzIGVtYWlsPC9zcGFuPjwvaT48L2I+PGJyPg0K PGJyPg0KPGJyPg0K
PGI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPkNPTkZJREVOVElB TElUWTwvc3Bhbj48
L2I+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPjogVGhlIGluZm9y bWF0aW9uIGluIHRo
aXMgZS1tYWlsIGFuZCBhbnkgYXR0YWNobWVudHMNCmlzIGNvbmZpZGVudGlh bC4gSXQgaXMgaW50
ZW5kZWQgb25seSBmb3IgdGhlIG5hbWVkIHJlY2lwaWVudHMocykuIElmIHlv dSBhcmUNCm5vdCB0
aGUgbmFtZWQgcmVjaXBpZW50IHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBp bW1lZGlhdGVseSBh
bmQgZG8gbm90DQpkaXNjbG9zZSB0aGUgY29udGVudHMgdG8gYW5vdGhlciBw ZXJzb24gb3IgdGFr
ZSBjb3BpZXMuICZuYnNwOyA8L3NwYW4+PGJyPg0KPGI+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZTox
MC4wcHQnPlZJUlVTRVM6PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0nZm9udC1z aXplOg0KMTAuMHB0
Jz4gVGhlIGNvbnRlbnRzIG9mIHRoaXMgZS1tYWlsIG9yIGF0dGFjaG1lbnQo cykgbWF5IGNvbnRh
aW4gdmlydXNlcyB3aGljaA0KY291bGQgZGFtYWdlIHlvdXIgb3duIGNvbXB1 dGVyIHN5c3RlbS4g
V2hpbHN0IEdyYW50IEluc3RydW1lbnRzIChDYW1icmlkZ2UpIEx0ZA0KaGFz IHRha2VuIGV2ZXJ5
IHJlYXNvbmFibGUgcHJlY2F1dGlvbiB0byBtaW5pbWlzZSB0aGlzIHJpc2ss IHdlIGNhbm5vdCBh
Y2NlcHQNCmxpYWJpbGl0eSBmb3IgYW55IGRhbWFnZSB3aGljaCB5b3Ugc3Vz dGFpbiBhcyBhIHJl
c3VsdCBvZiBzb2Z0d2FyZSB2aXJ1c2VzLiBZb3UNCnNob3VsZCB0aGVyZWZv cmUgY2Fycnkgb3V0
IHlvdXIgb3duIHZpcnVzIGNoZWNrcyBiZWZvcmUgb3BlbmluZyB0aGUNCmF0 dGFjaG1lbnQocyku
ICZuYnNwOyA8L3NwYW4+PGJyPg0KPGI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMC4wcHQnPk9w
ZW5YTUw8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6DQoxMC4w cHQnPjogRm9yIGlu
Zm9ybWF0aW9uIGFib3V0IHRoZSBPcGVuWE1MIGZpbGUgZm9ybWF0IGluIHVz ZSB3aXRoaW4gR3Jh
bnQNCkluc3RydW1lbnRzIHBsZWFzZSB2aXNpdCBvdXIgPGEgaHJlZj0iaHR0 cDovL3d3dy5ncmFu
dC5jby51ay9TdXBwb3J0L29wZW54bWwuaHRtbCI+d2Vic2l0ZTwvYT4gPC9z cGFuPjxicj4NCjxi
cj4NCjxicj4NCiZuYnNwOyA8YnI+DQombmJzcDsgJm5ic3A7PGJyPg0KPGJy Pg0KPGI+PGk+PHNw
YW4gc3R5bGU9J2NvbG9yOmxpbWUnPlA8L3NwYW4+PHNwYW4gc3R5bGU9J2Nv bG9yOmJsYWNrJz4g
PC9zcGFuPjxzcGFuIHN0eWxlPSdjb2xvcjpsaW1lJz5QbGVhc2UgY29uc2lk ZXIgdGhlIGVudmly
b25tZW50IGJlZm9yZSBwcmludGluZyB0aGlzIGVtYWlsPC9zcGFuPjwvaT48 L2I+PGJyPg0KPGJy
Pg0KPGJyPg0KPGI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPkNP TkZJREVOVElBTElU
WTwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPjog VGhlIGluZm9ybWF0
aW9uIGluIHRoaXMgZS1tYWlsIGFuZCBhbnkgYXR0YWNobWVudHMNCmlzIGNv bmZpZGVudGlhbC4g
SXQgaXMgaW50ZW5kZWQgb25seSBmb3IgdGhlIG5hbWVkIHJlY2lwaWVudHMo cykuIElmIHlvdSBh
cmUNCm5vdCB0aGUgbmFtZWQgcmVjaXBpZW50IHBsZWFzZSBub3RpZnkgdGhl IHNlbmRlciBpbW1l
ZGlhdGVseSBhbmQgZG8gbm90DQpkaXNjbG9zZSB0aGUgY29udGVudHMgdG8g YW5vdGhlciBwZXJz
b24gb3IgdGFrZSBjb3BpZXMuIDwvc3Bhbj4mbmJzcDsgPGJyPg0KPGI+PHNw YW4gc3R5bGU9J2Zv
bnQtc2l6ZToxMC4wcHQnPlZJUlVTRVM6PC9zcGFuPjwvYj48c3BhbiBzdHls ZT0nZm9udC1zaXpl
Og0KMTAuMHB0Jz4gVGhlIGNvbnRlbnRzIG9mIHRoaXMgZS1tYWlsIG9yIGF0 dGFjaG1lbnQocykg
bWF5IGNvbnRhaW4gdmlydXNlcyB3aGljaA0KY291bGQgZGFtYWdlIHlvdXIg b3duIGNvbXB1dGVy
IHN5c3RlbS4gV2hpbHN0IEdyYW50IEluc3RydW1lbnRzIChDYW1icmlkZ2Up IEx0ZA0KaGFzIHRh
a2VuIGV2ZXJ5IHJlYXNvbmFibGUgcHJlY2F1dGlvbiB0byBtaW5pbWlzZSB0 aGlzIHJpc2ssIHdl
IGNhbm5vdCBhY2NlcHQNCmxpYWJpbGl0eSBmb3IgYW55IGRhbWFnZSB3aGlj aCB5b3Ugc3VzdGFp
biBhcyBhIHJlc3VsdCBvZiBzb2Z0d2FyZSB2aXJ1c2VzLiBZb3UNCnNob3Vs ZCB0aGVyZWZvcmUg
Y2Fycnkgb3V0IHlvdXIgb3duIHZpcnVzIGNoZWNrcyBiZWZvcmUgb3Blbmlu ZyB0aGUNCmF0dGFj
aG1lbnQocykuPC9zcGFuPiAmbmJzcDsgPGJyPg0KPGI+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZTox
MC4wcHQnPk9wZW5YTUw8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSdmb250LXNp emU6DQoxMC4wcHQn
PjogRm9yIGluZm9ybWF0aW9uIGFib3V0IHRoZSBPcGVuWE1MIGZpbGUgZm9y bWF0IGluIHVzZSB3
aXRoaW4gR3JhbnQNCkluc3RydW1lbnRzIHBsZWFzZSB2aXNpdCBvdXIgPGEg aHJlZj0iaHR0cDov
L3d3dy5ncmFudC5jby51ay9TdXBwb3J0L29wZW54bWwuaHRtbCI+d2Vic2l0 ZTwvYT48L3NwYW4+
IDxvOnA+PC9vOnA+PC9wPg0KDQo8L2Rpdj4NCg0KPC9GT05UPjwvRk9OVD48 L0RJVj4NCjxESVY+
Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIEZBQ0U9IkFyaWFsIiBTSVpFPSIy Ij48Rk9OVCBGQUNF
PSJBcmlhbCIgU0laRT0iMiI+PC9GT05UPjwvRk9OVD48L0RJVj4NCjxESVY+ Jm5ic3A7PC9ESVY+
IDwvRElWPg0KPERJVj4NCjxQIENMQVNTPSJNc29Ob3JtYWwiPjxFTT48Qj48 U1BBTiBMQU5HPSJF
Ti1VUyIgU1RZTEU9IkZPTlQtU0laRTogMThwdDsgQ09MT1I6IGdyZWVuOyBG T05ULUZBTUlMWTog
V2ViZGluZ3MiPjwvU1BBTj48L0I+PC9FTT4mbmJzcDs8L1A+DQo8UCBDTEFT Uz0iTXNvTm9ybWFs
Ij48RU0+PEI+PFNQQU4gTEFORz0iRU4tVVMiIFNUWUxFPSJGT05ULVNJWkU6 IDE4cHQ7IENPTE9S
OiBncmVlbjsgRk9OVC1GQU1JTFk6IFdlYmRpbmdzIj5QPC9TUEFOPjwvQj48 L0VNPjxFTT48Qj48
U1BBTiBMQU5HPSJFTi1VUyIgU1RZTEU9IkZPTlQtU0laRTogMTBwdDsgQ09M T1I6IGJsYWNrOyBG
T05ULUZBTUlMWTogJ1ZlcmRhbmEnLCdzYW5zLXNlcmlmJyI+IDwvU1BBTj48 L0I+PC9FTT48U1RS
T05HPjxJPjxTUEFOIFNUWUxFPSJGT05ULVNJWkU6IDcuNXB0OyBDT0xPUjog Z3JlZW47IEZPTlQt
RkFNSUxZOiAnQXJpYWwnLCdzYW5zLXNlcmlmJyI+UGxlYXNlIGNvbnNpZGVy IHRoZSBlbnZpcm9u
bWVudCBiZWZvcmUgcHJpbnRpbmcgdGhpcyBlbWFpbDwvU1BBTj48L0k+PC9T VFJPTkc+PC9QPjwv
RElWPg0KPERJVj48Rk9OVCBGQUNFPSJBcmlhbCIgU0laRT0iMiI+PFNUUk9O Rz5DT05GSURFTlRJ
QUxJVFk8L1NUUk9ORz46IFRoZSBpbmZvcm1hdGlvbiBpbiB0aGlzIGUtbWFp bCBhbmQgYW55IGF0
dGFjaG1lbnRzIGlzIGNvbmZpZGVudGlhbC4gSXQgaXMgaW50ZW5kZWQgb25s eSBmb3IgdGhlIG5h
bWVkIHJlY2lwaWVudHMocykuIElmIHlvdSBhcmUgbm90IHRoZSBuYW1lZCBy ZWNpcGllbnQgcGxl
YXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFuZCBkbyBub3Qg ZGlzY2xvc2UgdGhl
IGNvbnRlbnRzIHRvIGFub3RoZXIgcGVyc29uIG9yIHRha2UgY29waWVzLiA8 L0ZPTlQ+PC9ESVY+
DQo8RElWPjxGT05UIEZBQ0U9IkFyaWFsIiBTSVpFPSIyIj48L0ZPTlQ+Jm5i c3A7PC9ESVY+DQo8
RElWPjxGT05UIEZBQ0U9IkFyaWFsIiBTSVpFPSIyIj48U1RST05HPjwvU1RS T05HPjwvRk9OVD48
L0RJVj4NCjxESVY+PEZPTlQgRkFDRT0iQXJpYWwiIFNJWkU9IjIiPjxTVFJP Tkc+VklSVVNFUzo8
L1NUUk9ORz4gVGhlIGNvbnRlbnRzIG9mIHRoaXMgZS1tYWlsIG9yIGF0dGFj aG1lbnQocykgbWF5
IGNvbnRhaW4gdmlydXNlcyB3aGljaCBjb3VsZCBkYW1hZ2UgeW91ciBvd24g Y29tcHV0ZXIgc3lz
dGVtLiBXaGlsc3QgR3JhbnQgSW5zdHJ1bWVudHMgKENhbWJyaWRnZSkgTHRk IGhhcyB0YWtlbiBl
dmVyeSByZWFzb25hYmxlIHByZWNhdXRpb24gdG8gbWluaW1pc2UgdGhpcyBy aXNrLCB3ZSBjYW5u
b3QgYWNjZXB0IGxpYWJpbGl0eSBmb3IgYW55IGRhbWFnZSB3aGljaCB5b3Ug c3VzdGFpbiBhcyBh
IHJlc3VsdCBvZiBzb2Z0d2FyZSB2aXJ1c2VzLiBZb3Ugc2hvdWxkIHRoZXJl Zm9yZSBjYXJyeSBv
dXQgeW91ciBvd24gdmlydXMgY2hlY2tzIGJlZm9yZSBvcGVuaW5nIHRoZSBh dHRhY2htZW50KHMp
LjwvRk9OVD48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05U IEZBQ0U9IkFyaWFs
IiBTSVpFPSIyIj48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIEZBQ0U9IkFy aWFsIiBTSVpFPSIy
Ij48U1RST05HPk9wZW5YTUw8L1NUUk9ORz46IEZvciBpbmZvcm1hdGlvbiBh Ym91dCB0aGUgT3Bl
blhNTCBmaWxlIGZvcm1hdCBpbiB1c2Ugd2l0aGluIEdyYW50IEluc3RydW1l bnRzIHBsZWFzZSB2
aXNpdCBvdXIgPEEgSFJFRj0iaHR0cDovL3d3dy5ncmFudC5jby51ay9TdXBw b3J0L29wZW54bWwu
aHRtbCI+d2Vic2l0ZTwvQT48L0ZPTlQ+PC9ESVY+PC9ESVY+PC9CT0RZPjwv SFRNTD4NCg==

--_000_7965A9DCF12CC14984420BCC37B1608F25AB1AEF22Elzargrantc ou_--

Re: Migrate postgres to newer hardware

Greg,

I am going to gather the figures about our database and I will email to the=
list, if I am allowed to.
Number of tables, number of transactions per day etc.

Nothing on our db servers are optimized, hardware wise, the db is on the sa=
me volume as logs as the os.
I know we have an IO problem because I have been checking it and it has bee=
n growing steadily.
We must migrate to newer and better optimized hardware.

Thank you again

Much appreciated.

Renato



Renato Oliveira
Systems Administrator
e-mail: renato.oliveira@grant.co.uk

Tel: +44 (0)1763 260811
Fax: +44 (0)1763 262410
http://www.grant.co.uk/

Grant Instruments (Cambridge) Ltd

Company registered in England, registration number 658133

Registered office address:
29 Station Road,
Shepreth,
CAMBS SG8 6GB
UK

-----Original Message-----


From: Scott Marlowe [mailto:scott.marlowe@gmail.com]
Sent: 31 March 2010 09:11
To: Renato Oliveira
Cc: Greg Smith; Tino Schwarze; pgsql-admin@postgresql.org
Subject: Re: [ADMIN] Migrate postgres to newer hardware

On Wed, Mar 31, 2010 at 1:43 AM, Renato Oliveira
wrote:
> Greg,
>
> Thank you very much for your input.
> I agree with you and I do understand where you are coming from.
>
> I do agree that in order to transition without a noticeable downtime the =
application would need to be built for that.
>
> Which one works best: bucardo, slony or Londiste?
>
> I have researched Slony and Bucardo but have not heard of Londiste befor=
e.
>
> How many people are using all three of them and their review have you he=
ard anything about that?

I run slony. On our regular db there are about 2000 relations, about
1200 of those are indexes, so slony has to worry about 800 or so
relations. It has no problem with that. On another machine that has
some 45k relations in addition to the 2000 base relations. That slony
instance takes 3.5 hours to run the same create set that takes 2
minutes on the machine with just 2000 relations.

Slony should be able to work for you. See if you can schedule it so
you start your subscription right when you're entering your lowest
throughput window. Your real bottleneck here is that source database
with a single hard drive. That's going to limit your speed of
subscription by quite a bit.



-----Original Message-----


P Please consider the environment before printing this email
CONFIDENTIALITY: The information in this e-mail and any attachments is conf=
idential. It is intended only for the named recipients(s). If you are not t=
he named recipient please notify the sender immediately and do not disclose=
the contents to another person or take copies.

VIRUSES: The contents of this e-mail or attachment(s) may contain viruses w=
hich could damage your own computer system. Whilst Grant Instruments (Cambr=
idge) Ltd has taken every reasonable precaution to minimise this risk, we c=
annot accept liability for any damage which you sustain as a result of soft=
ware viruses. You should therefore carry out your own virus checks before o=
pening the attachment(s).

OpenXML: For information about the OpenXML file format in use within Grant =
Instruments please visit our http://www.grant.co.uk/Support/openxml.html


--=20
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin

Re: Migrate postgres to newer hardware

On Tue, Mar 30, 2010 at 10:07:54PM -0400, Dai, Tino wrote:

> I'm not a dba. I'm a sysadmin by training. Is there some way to
> mirror the disks at the OS level? And then move it to the new
> machine. Just a though, I don't know the exact steps. But if you
> are interested, I can see what I can find.

It would work if both architectures were the same. But Renato is
migrating from 32 bit to 64 bit, so the on-disk format changes.

Tino, too. :-)

--=20
"What we nourish flourishes." - "Was wir nähren erblüht."

www.lichtkreis-chemnitz.de
www.tisc.de

--=20
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin

Re: Migrate postgres to newer hardware

On Wed, 2010-03-31 at 09:22 +0100, Renato Oliveira wrote:
> Greg,
>
> I am going to gather the figures about our database and I will email to the list, if I am allowed to.
> Number of tables, number of transactions per day etc.

Absolutely allowed, and encouraged.

Also, do you have long running transactions against the database? Are
you committing large numbers of writes in a single transaction?

> Nothing on our db servers are optimized, hardware wise, the db is on the same volume as logs as the os.
> I know we have an IO problem because I have been checking it and it has been growing steadily.
> We must migrate to newer and better optimized hardware.

That will be your sticking point with Slony. If your IO system is
already taxed, Slony will just add to the burden.

--
Brad Nicholson 416-673-4106
Database Administrator, Afilias Canada Corp.



--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin

Re: Migrate postgres to newer hardware

Renato Oliveira wrote:
> I am going to gather the figures about our database and I will email to the list, if I am allowed to.
> Number of tables, number of transactions per day etc.
>

A quick snapshot from "vmstat 1" during a busy time is also very helpful.

--
Greg Smith 2ndQuadrant US Baltimore, MD
PostgreSQL Training, Services and Support
greg@2ndQuadrant.com www.2ndQuadrant.us


--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin

Re: Migrate postgres to newer hardware

--=-/CqdAX5qBwmo0KX7Wudq
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I would never sing a SLA for HA if I don't have system, at least, fully
redundant in order to deal with these issues.
Single server, single point of failure.

-----Original Message-----
From: Brad Nicholson
To: Iñigo Martinez Lasala
Cc: Renato Oliveira , pgsql-admin

Subject: Re: [ADMIN] Migrate postgres to newer hardware
Date: Tue, 30 Mar 2010 10:38:02 -0400


On Tue, 2010-03-30 at 16:29 +0200, Iñigo Martinez Lasala wrote:
> Hi Renato.
>=20
> I would follow the ancient method: perform a pg_dump / pg_restore

This is the easiest approach. The problem is that a lot of people have
contractual SLA's that do not allow them to take their systems down long
enough to do a dump and restore upgrade.




--=-/CqdAX5qBwmo0KX7Wudq
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: 7bit








I would never sing a SLA for HA if I don't have system, at least, fully redundant in order to deal with these issues.

Single server, single point of failure.



-----Original Message-----

From: Brad Nicholson <>

To: Iñigo Martinez Lasala <>

Cc: Renato Oliveira <>

Subject: Re: [ADMIN] Migrate postgres to newer hardware

Date: Tue, 30 Mar 2010 10:38:02 -0400

On Tue, 2010-03-30 at 16:29 +0200, Iñigo Martinez Lasala wrote:

> Hi Renato.

> 

> I would follow the ancient method: perform a pg_dump / pg_restore



This is the easiest approach.  The problem is that a lot of people have

contractual SLA's that do not allow them to take their systems down long

enough to do a dump and restore upgrade.

Re: Migrate postgres to newer hardware

--=-tFvshSwyfpy8FmtBKIqY
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I've never worked with Bucardo and Londiste, so I cannot give you any
hint about it.
With slony it's not necessary to restore all database prior staring sync
process. You only have to restore your schema but not data. Slony will
keep them synced with source server.

Anyway, if you plan to migrate to 8.4 there are some issues with slony.
For 8.3 and higher, you will go with slony 2.X. For 8.2 with slony 1.X
I'm not sure if Slony 1.x is compatible with Postgres >=3D 8.3, but I'm
sure slony 2.x is not backwards compatible.

So, prior thinking about migrating to 8.4 you will have to check this.
And more important, it's possible you have to slightly change your
database schema to work in postgres 8.4, specially if you use tsearch2.

If using slony, I wouldn't upgrade to 8.4 before a deep analysis of
changes in your existing database.=20

-----Original Message-----
From: Renato Oliveira
To: Iñigo Martinez Lasala
Cc: pgsql-admin
Subject: RE: [ADMIN] Migrate postgres to newer hardware
Date: Wed, 31 Mar 2010 09:11:37 +0100


Hi Iñigo,

=20

Thank you for your input, really appreciated.

=20

I just had a thought; if I backup â€=98pg_dumpâ€=99 full database=
, then restore
to my new machine new postgres 8.4, which one of these programs would
work best to do the migration,

Slony, Bucardo or Londiste?

=20

I would like to say that we did have slony and I was not impressed, it
fell behind and could not catch up and caused a very high load on the
system.

Also they way its philosophy works, it is very high maintenance, and the
idea of creating tables, and triggers on both dbs...

It might be, it was not setup properly or well, we removed it as the db
was screaming for some fresh air.

=20

Ps I would like to point out that I am systems administrator and not a
dba, so you can understand sometimes my questions...

=20

I think Bucardo seems best for the task, for what I have read so far,
but I do not know.

=20

Thank you very much and I am sorry for this

=20

Renato

=20

=20

=20


=20
Renato Oliveira
Systems Administrator
e-mail: renato.oliveira@grant.co.uk
=20
Tel: +44 (0)1763 260811
Fax: +44 (0)1763 262410
www.grant.co.uk
=20
Grant Instruments (Cambridge) Ltd=20
=20
Company registered in England, registration number 658133
=20
Registered office address:
29 Station Road,=20
Shepreth,=20
CAMBS SG8 6GB=20
UK
=20

=20
From: Iñigo Martinez Lasala [mailto:imartinez@vectorsf.com]=20
Sent: 30 March 2010 16:27
To: Renato Oliveira
Cc: pgsql-admin
Subject: RE: [ADMIN] Migrate postgres to newer hardware


=20

Yes, you only have that two possibilities, I think.

PITR is not an option. I tested the same, from 7.4 32bit to 7.4 64bit
and didn't work. Later, when I asked here, I was told why not.

The problem with slony is that you have to manually create tables in
destination database and all database model (procedures, triggers,
sequences, views, etc). If your application creates new tables, you will
have to deal with this prior starting migration, or at least disable the
creation of new tables.

Slony is asynchronous, so you will have to ensure that all changes have
been committed to new database before changing your applications or
exchanging IP addresses.
Slony also add many triggers and special tables to both databases
(master and slave). So, after migration, you will have to delete them.
It's not difficult but don't forget to do it.

By the way, are you sure your database is 160GB? Including indexes?
There are strategies in order to perform a faster pg_restore...=20
For example, if you migrate your database schema but don't create
indexes, then migrate data and finally create pending indexes restore
will be faster. With pg 8.4 restore is very fast, so it will take less
time that export.

Anyway, if you cannot leave database down for a day, I think slony will
be your best bet, although it's not exempt of problems. :)

-----Original Message-----
From: Renato Oliveira
To: Iñigo Martinez Lasala
Subject: RE: [ADMIN] Migrate postgres to newer hardware
Date: Tue, 30 Mar 2010 15:47:27 +0100

ï»=BF Hey Iñigo,

=20

Thank you very much for your reply.

=20

I would love to do just that, but unfortunately I canâ€=99t it is not=
as
simple as that.

=20

I would love if the application had been built in with this in mindâ€=
=A6

=20

To give you an idea; the pg_dump takes 15 hours and I attempted a
restore yesterday and it took 14 hours and 21 min.

It would not be viable for us and specially I cannot have the system
down more than maximum 30 min without the risk of losing data and
customers not having alerts.

=20

I donâ€=99t think I will be able to use PITR to migrate to new server=
s
specially if it is 64 bit and to migrate to another 32 bit is no gain,
as we need more memory.

=20

As far as can gather there are only two ways:

a) Slony type

b) Pg_dump

=20

Is that correct ? Do you guys have any other ways?

=20

Renato

=20

=20


Renato Oliveira
Systems Administrator
e-mail: renato.oliveira@grant.co.uk Tel: +44 (0)1763 260811
Fax: +44 (0)1763 262410
www.grant.co.uk Grant Instruments (Cambridge) Ltd=20
=20
Company registered in England, registration number 658133
=20
Registered office address:
29 Station Road,=20
Shepreth,=20
CAMBS SG8 6GB=20
UK =20
From: Iñigo Martinez Lasala [mailto:imartinez@vectorsf.com]
Sent:30 March 2010 15:29
To:Renato Oliveira
Cc:pgsql-admin
Subject: Re: [ADMIN] Migrate postgres to newer hardware


=20

Hi Renato.

I would follow the ancient method: perform a pg_dump / pg_restore

Yes, you will have to take offline database for a long period.

And yes, it would be a great moment to perform a 8.4 upgrade.
Performance is far superior, restore is far faster...=20
.... and yes, it could give you many problems if you don't perform many
test in order to address all queries without explicit type conversions
before real migration, but I think it's the best moment to deal with a
very convenient upgrade. =20

We have performed this upgrade last week with a gforge (with only 25GB
database) and having also to upgrade to new tsearch2 and everything is
running smooth.

-----Original Message-----
From: Renato Oliveira
To: pgsql-admin@postgresql.org
Subject: [ADMIN] Migrate postgres to newer hardware
Date: Tue, 30 Mar 2010 12:18:36 +0100

Dear All,

=20

What would be the easiest and fastest way to migrate Postgres 8.2.24 32
BIT to a new server 64 Bit.

=20

The existing server runs on 32 bit architecture and has a database as
big as 160GB.

=20

We initially thought of using PITR, but as one of the PITR requirements
is both machines need to be similar.=20

This similarity needs to be even in architecture? I think I read
something which says â€=9CYesâ€=9D.

=20

If we cannot use PITR what would be the best approach, we canâ€=99t h=
ave
down time I am afraid.

=20

Any ideas or suggestions would be very welcome.

=20

Thank you very much

=20

Best regards

=20

Renato

=20

=20


Renato Oliveira
Systems Administrator
e-mail: renato.oliveira@grant.co.uk Tel: +44 (0)1763 260811
Fax: +44 (0)1763 262410
www.grant.co.uk Grant Instruments (Cambridge) Ltd=20
=20
Company registered in England, registration number 658133
=20
Registered office address:
29 Station Road,=20
Shepreth,=20
CAMBS SG8 6GB=20
UK =20
=20
=20
=20

P Please consider the environment before printing this email


CONFIDENTIALITY: The information in this e-mail and any attachments is
confidential. It is intended only for the named recipients(s). If you
are not the named recipient please notify the sender immediately and do
not disclose the contents to another person or take copies. =20
VIRUSES: The contents of this e-mail or attachment(s) may contain
viruses which could damage your own computer system. Whilst Grant
Instruments (Cambridge) Ltd has taken every reasonable precaution to
minimise this risk, we cannot accept liability for any damage which you
sustain as a result of software viruses. You should therefore carry out
your own virus checks before opening the attachment(s). =20
OpenXML: For information about the OpenXML file format in use within
Grant Instruments please visit our website=20


=20
=20

P Please consider the environment before printing this email


CONFIDENTIALITY: The information in this e-mail and any attachments is
confidential. It is intended only for the named recipients(s). If you
are not the named recipient please notify the sender immediately and do
not disclose the contents to another person or take copies. =20
VIRUSES: The contents of this e-mail or attachment(s) may contain
viruses which could damage your own computer system. Whilst Grant
Instruments (Cambridge) Ltd has taken every reasonable precaution to
minimise this risk, we cannot accept liability for any damage which you
sustain as a result of software viruses. You should therefore carry out
your own virus checks before opening the attachment(s). =20
OpenXML: For information about the OpenXML file format in use within
Grant Instruments please visit our website=20


=20

=20
=20

P Please consider the environment before printing this email


CONFIDENTIALITY: The information in this e-mail and any attachments is
confidential. It is intended only for the named recipients(s). If you
are not the named recipient please notify the sender immediately and do
not disclose the contents to another person or take copies.=20
=20

VIRUSES: The contents of this e-mail or attachment(s) may contain
viruses which could damage your own computer system. Whilst Grant
Instruments (Cambridge) Ltd has taken every reasonable precaution to
minimise this risk, we cannot accept liability for any damage which you
sustain as a result of software viruses. You should therefore carry out
your own virus checks before opening the attachment(s).
=20

OpenXML: For information about the OpenXML file format in use within
Grant Instruments please visit our website


--=-tFvshSwyfpy8FmtBKIqY
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: 7bit








I've never worked with Bucardo and Londiste, so I cannot give you any hint about it.

With slony it's not necessary to restore all database prior staring sync process. You only have to restore your schema but not data. Slony will keep them synced with source server.



Anyway, if you plan to migrate to 8.4 there are some issues with slony. For 8.3 and higher, you will go with slony 2.X. For 8.2 with slony 1.X

I'm not sure if Slony 1.x is compatible with Postgres >= 8.3, but I'm sure slony 2.x is not backwards compatible.



So, prior thinking about migrating to 8.4 you will have to check this. And more important, it's possible you have to slightly change your database schema to work in postgres 8.4, specially if you use tsearch2.



If using slony, I wouldn't upgrade to 8.4 before a deep analysis of changes in your existing database.



-----Original Message-----

From: Renato Oliveira <>

To: Iñigo Martinez Lasala <>

Cc: pgsql-admin <>

Subject: RE: [ADMIN] Migrate postgres to newer hardware

Date: Wed, 31 Mar 2010 09:11:37 +0100




Hi Iñigo,



 



Thank you for your input, really appreciated.



 



I just had a thought; if I backup ‘pg_dump’ full database, then restore to my new machine new postgres 8.4, which one of these programs would work best to do the migration,



Slony, Bucardo or Londiste?



 



I would like to say that we did have slony and I was not impressed, it fell behind and could not catch up and caused a very high load on the system.



Also they way its philosophy works, it is very high maintenance, and the idea of creating tables, and triggers on both dbs...



It might be, it was not setup properly or well, we removed it as the db was screaming for some fresh air.



 



Ps I would like to point out that I am systems administrator and not a dba, so you can understand sometimes my questions...



 



I think Bucardo seems best for the task, for what I have read so far,  but I do not know.



 



Thank you very much and I am sorry for this



 



Renato



 



 



 





 
Renato Oliveira

Systems Administrator

e-mail: renato.oliveira@grant.co.uk
 
Tel: +44 (0)1763 260811

Fax: +44 (0)1763 262410


 
Grant Instruments (Cambridge) Ltd

 

Company registered in England, registration number 658133

 

Registered office address:

29 Station Road,

Shepreth,

CAMBS SG8 6GB

UK
 


 
From: Iñigo Martinez Lasala [mailto:imartinez@vectorsf.com]

Sent: 30 March 2010 16:27

To: Renato Oliveira

Cc: pgsql-admin

Subject: RE: [ADMIN] Migrate postgres to newer hardware





 



Yes, you only have that two possibilities, I think.



PITR is not an option. I tested the same, from 7.4 32bit to 7.4 64bit and didn't work. Later, when I asked here, I was told why not.



The problem with slony is that you have to manually create tables in destination database and all database model (procedures, triggers, sequences, views, etc). If your application creates new tables, you will have to deal with this prior starting migration, or at least disable the creation of new tables.



Slony is asynchronous, so you will have to ensure that all changes have been committed to new database before changing your applications or exchanging IP addresses.

Slony also add many triggers and special tables to both databases (master and slave). So, after migration, you will have to delete them. It's not difficult but don't forget to do it.



By the way, are you sure your database is 160GB? Including indexes? There are strategies in order to perform a faster pg_restore...

For example, if you migrate your database schema but don't create indexes, then migrate data and finally create pending indexes restore will be faster. With pg 8.4 restore is very fast, so it will take less time that export.



Anyway, if you cannot leave database down for a day, I think slony will be your best bet, although it's not exempt of problems. :)



-----Original Message-----

From: Renato Oliveira <>

To: Iñigo Martinez Lasala <>

Subject: RE: [ADMIN] Migrate postgres to newer hardware

Date: Tue, 30 Mar 2010 15:47:27 +0100



 Hey Iñigo,



 



Thank you very much for your reply.



 



I would love to do just that, but unfortunately I can’t it is not as simple as that.



 



I would love if the application had been built in with this in mind…



 



To give you an idea; the pg_dump takes 15 hours and I attempted a restore yesterday and it took 14 hours and 21 min.



It would not be viable for us and specially I cannot have the system down more than maximum 30 min without the risk of losing data and customers not having alerts.



 



I don’t think I will be able to use PITR to migrate to new servers specially if it is 64 bit and to migrate to another 32 bit is no gain, as we need more memory.



 



As far as can gather there are only two ways:



a)   Slony type



b)   Pg_dump



 



Is that correct ? Do you guys have any other ways?



 



Renato



 



 





  Renato Oliveira

Systems Administrator

e-mail: renato.oliveira@grant.co.uk   Tel: +44 (0)1763 260811

Fax: +44 (0)1763 262410

  Grant Instruments (Cambridge) Ltd

 

Company registered in England, registration number 658133

 

Registered office address:

29 Station Road,

Shepreth,

CAMBS SG8 6GB

UK  

  From: Iñigo Martinez Lasala [mailto:imartinez@vectorsf.com]

Sent:30 March 2010 15:29

To:Renato Oliveira

Cc:pgsql-admin

Subject: Re: [ADMIN] Migrate postgres to newer hardware





 



Hi Renato.



I would follow the ancient method: perform a pg_dump / pg_restore



Yes, you will have to take offline database for a long period.



And yes, it would be a great moment to perform a 8.4 upgrade. Performance is far superior, restore is far faster...

... and yes, it could give you many problems if you don't perform many test in order to address all queries without explicit type conversions before real migration, but I think it's the best moment to deal with a very convenient upgrade. 



We have performed this upgrade last week with a gforge (with only 25GB database) and having also to upgrade to new tsearch2 and everything is running smooth.



-----Original Message-----

From: Renato Oliveira <>

To: pgsql-admin@postgresql.org <>

Subject: [ADMIN] Migrate postgres to newer hardware

Date: Tue, 30 Mar 2010 12:18:36 +0100



Dear All,



 



What would be the easiest and fastest way to migrate Postgres 8.2.24 32 BIT to a new server 64 Bit.



 



The existing server runs on 32 bit architecture and has a database as big as 160GB.



 



We initially thought of using PITR, but as one of the PITR requirements is both machines need to be similar.



This similarity needs to be even in architecture? I think I read something which says “Yes”.



 



If we cannot use PITR what would be the best approach, we can’t have down time I am afraid.



 



Any ideas or suggestions would be very welcome.



 



Thank you very much



 



Best regards



 



Renato



 



 





  Renato Oliveira

Systems Administrator

e-mail: renato.oliveira@grant.co.uk   Tel: +44 (0)1763 260811

Fax: +44 (0)1763 262410

  Grant Instruments (Cambridge) Ltd

 

Company registered in England, registration number 658133

 

Registered office address:

29 Station Road,

Shepreth,

CAMBS SG8 6GB

UK  

 

 

   



P Please consider the environment before printing this email





CONFIDENTIALITY: The information in this e-mail and any attachments is confidential. It is intended only for the named recipients(s). If you are not the named recipient please notify the sender immediately and do not disclose the contents to another person or take copies.  

VIRUSES: The contents of this e-mail or attachment(s) may contain viruses which could damage your own computer system. Whilst Grant Instruments (Cambridge) Ltd has taken every reasonable precaution to minimise this risk, we cannot accept liability for any damage which you sustain as a result of software viruses. You should therefore carry out your own virus checks before opening the attachment(s).  

OpenXML: For information about the OpenXML file format in use within Grant Instruments please visit our





 

   



P Please consider the environment before printing this email





CONFIDENTIALITY: The information in this e-mail and any attachments is confidential. It is intended only for the named recipients(s). If you are not the named recipient please notify the sender immediately and do not disclose the contents to another person or take copies.  

VIRUSES: The contents of this e-mail or attachment(s) may contain viruses which could damage your own computer system. Whilst Grant Instruments (Cambridge) Ltd has taken every reasonable precaution to minimise this risk, we cannot accept liability for any damage which you sustain as a result of software viruses. You should therefore carry out your own virus checks before opening the attachment(s).  

OpenXML: For information about the OpenXML file format in use within Grant Instruments please visit our





 


 
 



P Please consider the environment before printing this email





CONFIDENTIALITY: The information in this e-mail and any attachments is confidential. It is intended only for the named recipients(s). If you are not the named recipient please notify the sender immediately and do not disclose the contents to another person or take copies.
 


VIRUSES: The contents of this e-mail or attachment(s) may contain viruses which could damage your own computer system. Whilst Grant Instruments (Cambridge) Ltd has taken every reasonable precaution to minimise this risk, we cannot accept liability for any damage which you sustain as a result of software viruses. You should therefore carry out your own virus checks before opening the attachment(s).
 


OpenXML: For information about the OpenXML file format in use within Grant Instruments please visit our





--=-tFvshSwyfpy8FmtBKIqY--

Re: Migrate postgres to newer hardware

On Fri, Apr 2, 2010 at 1:58 AM, I=F1igo Martinez Lasala
wrote:
> I've never worked with Bucardo and Londiste, so I cannot give you any hint
> about it.
> With slony it's not necessary to restore all database prior staring sync
> process. You only have to restore your schema but not data. Slony will ke=
ep
> them synced with source server.
>
> Anyway, if you plan to migrate to 8.4 there are some issues with slony. F=
or
> 8.3 and higher, you will go with slony 2.X. For 8.2 with slony 1.X
> I'm not sure if Slony 1.x is compatible with Postgres >=3D 8.3, but I'm s=
ure
> slony 2.x is not backwards compatible.

slony 1.2.20 is definitely compatible with pg 8.4 and 8.5/9.0
according to the release notes. Not sure if 2.x is considered
production ready. It certainly wasn't last fall.

--=20
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin

Re: Migrate postgres to newer hardware

On Fri, 2010-04-02 at 09:58 +0200, Iñigo Martinez Lasala wrote:
> I've never worked with Bucardo and Londiste, so I cannot give you any
> hint about it.
> With slony it's not necessary to restore all database prior staring
> sync process. You only have to restore your schema but not data. Slony
> will keep them synced with source server.
>=20
> Anyway, if you plan to migrate to 8.4 there are some issues with
> slony. For 8.3 and higher, you will go with slony 2.X. For 8.2 with
> slony 1.X
> I'm not sure if Slony 1.x is compatible with Postgres >=3D 8.3, but I'm
> sure slony 2.x is not backwards compatible.

Slony 1.2.17 and higher is compatible with PG 8.4. I'd go with the
latest stable release though.

--=20
Brad Nicholson 416-673-4106
Database Administrator, Afilias Canada Corp.



--=20
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin

Re: Migrate postgres to newer hardware

--_000_7965A9DCF12CC14984420BCC37B1608F25ABF30D34Elzargrantc ou_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

RGVhciBhbGwsDQoNCkkgd291bGQgbG92ZSB0byBoYXZlIHRoaW5ncyBjb3Zl cmVkLCBidXQgSSBo
YXZlIGluaGVyaXRlZCB0aGlzIHNldHVwLg0KSSBhbSBzdXJlIHdlIHdpbGwg aW1wcm92ZSBpdCwg
YnV0IEkgaGF2ZSB0byBtYWtlIHRoZSBtb3N0IHdpdGggd2hhdCBJIGhhdmUg Z290LCBJIGFtIGFm
cmFpZC4NCkkgYW0gZ3JhdGVmdWwgZm9yIGFsbCB0aGUgaGVscCBzbyBmYXIs IEkgcmVhbGx5IGFw
cHJlY2lhdGUgaXQuDQoNClBzIEkgdGhpbmsgdGhlcmUgc2hvdWxkIGJlIGFu IGVhc2llciB3YXks
IG1heWJlIGRvaW5nIGFzIGZvbGxvd3M6DQoxIOKAkyBEdW1wIHRoZSBkYXRh YmFzZSBvbmxpbmUg
d2l0aCBwZ19kdW1wLCB3aGlsZSBwcm9kdWN0aW9uIHNlcnZlciBpcyBzdGls bCBydW5uaW5nDQoy
IOKAkyBSZXN0b3JlIGl0IHRvIHRoZSBuZXcgc2VydmVyLCB3aGlsZSBvbGQg c2VydmVyIGlzIHN0
aWxsIG9ubGluZQ0KMyDigJMgT24gdGhlIG9sZCBzZXJ2ZXIsIHJ1biBhIHF1 ZXJ5IGxvb2tpbmcg
Zm9yIGFsbCB0aGUgbmV3IHRyYW5zYWN0aW9ucyBzaW5jZSB0aGUgbGFzdCBm dWxsIGJhY2t1cC4N
CjQg4oCTIFJ1biBhIHBnX2R1bXAgdG8gZHVtcCBvbmx5IHRoZSBuZXcgdHJh bnNhY3Rpb25zIHNp
bmNlIGxhc3QgYmFja3VwIGFuZCByZXN0b3JlIHRvIHRoZSBuZXcgc2VydmVy IG9yIOKAmGFwcGVu
ZOKAmSB0byB0aGUgbmV3IHNlcnZlci4NCg0KSSB0aGluayB0aGlzIHNob3Vs ZCBiZSBwb3NzaWJs
ZSB0byBkby4NCg0KVGhhbmsgeW91IHZlcnkgbXVjaCBmb3IgYWxsIHlvdXIg c3VwcG9ydCBhbmQg
aGVscCwgcmVhbGx5IGFwcHJlY2lhdGVkLg0KDQpSZW5hdG8NCg0KUmVuYXRv IE9saXZlaXJhDQpT
eXN0ZW1zIEFkbWluaXN0cmF0b3INCmUtbWFpbDogcmVuYXRvLm9saXZlaXJh QGdyYW50LmNvLnVr
DQoNClRlbDogKzQ0ICgwKTE3NjMgMjYwODExDQpGYXg6ICs0NCAoMCkxNzYz IDI2MjQxMA0Kd3d3
LmdyYW50LmNvLnVrPGh0dHA6Ly93d3cuZ3JhbnQuY28udWsvPg0KDQpHcmFu dCBJbnN0cnVtZW50
cyAoQ2FtYnJpZGdlKSBMdGQNCg0KQ29tcGFueSByZWdpc3RlcmVkIGluIEVu Z2xhbmQsIHJlZ2lz
dHJhdGlvbiBudW1iZXIgNjU4MTMzDQoNClJlZ2lzdGVyZWQgb2ZmaWNlIGFk ZHJlc3M6DQoyOSBT
dGF0aW9uIFJvYWQsDQpTaGVwcmV0aCwNCkNBTUJTIFNHOCA2R0INClVLDQoN Cg0KRnJvbTogcGdz
cWwtYWRtaW4tb3duZXJAcG9zdGdyZXNxbC5vcmcgW21haWx0bzpwZ3NxbC1h ZG1pbi1vd25lckBw
b3N0Z3Jlc3FsLm9yZ10gT24gQmVoYWxmIE9mIEnDsWlnbyBNYXJ0aW5leiBM YXNhbGENClNlbnQ6
IDAyIEFwcmlsIDIwMTAgMDg6NDENClRvOiBCcmFkIE5pY2hvbHNvbg0KQ2M6 IHBnc3FsLWFkbWlu
DQpTdWJqZWN0OiBSZTogW0FETUlOXSBNaWdyYXRlIHBvc3RncmVzIHRvIG5l d2VyIGhhcmR3YXJl
DQoNCkkgd291bGQgbmV2ZXIgc2luZyBhIFNMQSBmb3IgSEEgaWYgSSBkb24n dCBoYXZlIHN5c3Rl
bSwgYXQgbGVhc3QsIGZ1bGx5IHJlZHVuZGFudCBpbiBvcmRlciB0byBkZWFs IHdpdGggdGhlc2Ug
aXNzdWVzLg0KU2luZ2xlIHNlcnZlciwgc2luZ2xlIHBvaW50IG9mIGZhaWx1 cmUuDQoNCi0tLS0t
T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBCcmFkIE5pY2hvbHNvbiA8 Ym5pY2hvbHNAY2Eu
YWZpbGlhcy5pbmZvPG1haWx0bzpCcmFkJTIwTmljaG9sc29uJTIwJTNjYm5p Y2hvbHNAY2EuYWZp
bGlhcy5pbmZvJTNlPj4NClRvOiBJw7FpZ28gTWFydGluZXogTGFzYWxhIDxp bWFydGluZXpAdmVj
dG9yc2YuY29tPG1haWx0bzolM2QlM2ZJU08tODg1OS0xJTNmUSUzZkklM2RG MWlnbyUzZiUzZCUy
ME1hcnRpbmV6JTIwTGFzYWxhJTIwJTNjaW1hcnRpbmV6QHZlY3RvcnNmLmNv bSUzZT4+DQpDYzog
UmVuYXRvIE9saXZlaXJhIDxyZW5hdG8ub2xpdmVpcmFAZ3JhbnQuY28udWs8 bWFpbHRvOlJlbmF0
byUyME9saXZlaXJhJTIwJTNjcmVuYXRvLm9saXZlaXJhQGdyYW50LmNvLnVr JTNlPj4sIHBnc3Fs
LWFkbWluIDxwZ3NxbC1hZG1pbkBwb3N0Z3Jlc3FsLm9yZzxtYWlsdG86cGdz cWwtYWRtaW4lMjAl
M2NwZ3NxbC1hZG1pbkBwb3N0Z3Jlc3FsLm9yZyUzZT4+DQpTdWJqZWN0OiBS ZTogW0FETUlOXSBN
aWdyYXRlIHBvc3RncmVzIHRvIG5ld2VyIGhhcmR3YXJlDQpEYXRlOiBUdWUs IDMwIE1hciAyMDEw
IDEwOjM4OjAyIC0wNDAwDQoNCg0KDQpPbiBUdWUsIDIwMTAtMDMtMzAgYXQg MTY6MjkgKzAyMDAs
IEnDsWlnbyBNYXJ0aW5leiBMYXNhbGEgd3JvdGU6DQoNCj4gSGkgUmVuYXRv Lg0KDQo+DQoNCj4g
SSB3b3VsZCBmb2xsb3cgdGhlIGFuY2llbnQgbWV0aG9kOiBwZXJmb3JtIGEg cGdfZHVtcCAvIHBn
X3Jlc3RvcmUNCg0KDQoNClRoaXMgaXMgdGhlIGVhc2llc3QgYXBwcm9hY2gu ICBUaGUgcHJvYmxl
bSBpcyB0aGF0IGEgbG90IG9mIHBlb3BsZSBoYXZlDQoNCmNvbnRyYWN0dWFs IFNMQSdzIHRoYXQg
ZG8gbm90IGFsbG93IHRoZW0gdG8gdGFrZSB0aGVpciBzeXN0ZW1zIGRvd24g bG9uZw0KDQplbm91
Z2ggdG8gZG8gYSBkdW1wIGFuZCByZXN0b3JlIHVwZ3JhZGUuDQoNCg0KDQoN Cg0KDQpQIFBsZWFz
ZSBjb25zaWRlciB0aGUgZW52aXJvbm1lbnQgYmVmb3JlIHByaW50aW5nIHRo aXMgZW1haWwNCkNP
TkZJREVOVElBTElUWTogVGhlIGluZm9ybWF0aW9uIGluIHRoaXMgZS1tYWls IGFuZCBhbnkgYXR0
YWNobWVudHMgaXMgY29uZmlkZW50aWFsLiBJdCBpcyBpbnRlbmRlZCBvbmx5 IGZvciB0aGUgbmFt
ZWQgcmVjaXBpZW50cyhzKS4gSWYgeW91IGFyZSBub3QgdGhlIG5hbWVkIHJl Y2lwaWVudCBwbGVh
c2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5kIGRvIG5vdCBk aXNjbG9zZSB0aGUg
Y29udGVudHMgdG8gYW5vdGhlciBwZXJzb24gb3IgdGFrZSBjb3BpZXMuDQoN ClZJUlVTRVM6IFRo
ZSBjb250ZW50cyBvZiB0aGlzIGUtbWFpbCBvciBhdHRhY2htZW50KHMpIG1h eSBjb250YWluIHZp
cnVzZXMgd2hpY2ggY291bGQgZGFtYWdlIHlvdXIgb3duIGNvbXB1dGVyIHN5 c3RlbS4gV2hpbHN0
IEdyYW50IEluc3RydW1lbnRzIChDYW1icmlkZ2UpIEx0ZCBoYXMgdGFrZW4g ZXZlcnkgcmVhc29u
YWJsZSBwcmVjYXV0aW9uIHRvIG1pbmltaXNlIHRoaXMgcmlzaywgd2UgY2Fu bm90IGFjY2VwdCBs
aWFiaWxpdHkgZm9yIGFueSBkYW1hZ2Ugd2hpY2ggeW91IHN1c3RhaW4gYXMg YSByZXN1bHQgb2Yg
c29mdHdhcmUgdmlydXNlcy4gWW91IHNob3VsZCB0aGVyZWZvcmUgY2Fycnkg b3V0IHlvdXIgb3du
IHZpcnVzIGNoZWNrcyBiZWZvcmUgb3BlbmluZyB0aGUgYXR0YWNobWVudChz KS4NCg0KT3BlblhN
TDogRm9yIGluZm9ybWF0aW9uIGFib3V0IHRoZSBPcGVuWE1MIGZpbGUgZm9y bWF0IGluIHVzZSB3
aXRoaW4gR3JhbnQgSW5zdHJ1bWVudHMgcGxlYXNlIHZpc2l0IG91ciB3ZWJz aXRlPGh0dHA6Ly93
d3cuZ3JhbnQuY28udWsvU3VwcG9ydC9vcGVueG1sLmh0bWw+DQo=

--_000_7965A9DCF12CC14984420BCC37B1608F25ABF30D34Elzargrantc ou_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

77u/PEhUTUwgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1odG1s NDAiIHhtbG5zOmE9
InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOmFjY2VzcyIgeG1s bnM6Yj0idXJuOnNj
aGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6cHVibGlzaGVyIiB4bWxuczpj PSJ1cm46c2NoZW1h
cy1taWNyb3NvZnQtY29tOm9mZmljZTpjb21wb25lbnQ6c3ByZWFkc2hlZXQi IHhtbG5zOkQ9IkRB
VjoiIHhtbG5zOmRpcj0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9z aGFyZXBvaW50L3Nv
YXAvZGlyZWN0b3J5LyIgeG1sbnM6ZHM9Imh0dHA6Ly93d3cudzMub3JnLzIw MDAvMDkveG1sZHNp
ZyMiIHhtbG5zOmRzcD0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9z aGFyZXBvaW50L2Rz
cCIgeG1sbnM6ZHNzaT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9v ZmZpY2UvMjAwNi9k
aWdzaWciIHhtbG5zOmRzc3M9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vb2ZmaWNlLzIw
MDYvZGlnc2lnLXNldHVwIiB4bWxuczpkdD0idXVpZDpDMkY0MTAxMC02NUIz LTExZDEtQTI5Ri0w
MEFBMDBDMTQ4ODIiIHhtbG5zOmVjPSJodHRwOi8vd3d3LnczLm9yZy8yMDAx LzA0L3htbGVuYyMi
IHhtbG5zOmV4MTJtPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2V4 Y2hhbmdlL3NlcnZp
Y2VzLzIwMDYvbWVzc2FnZXMiIHhtbG5zOmV4MTJ0PSJodHRwOi8vc2NoZW1h cy5taWNyb3NvZnQu
Y29tL2V4Y2hhbmdlL3NlcnZpY2VzLzIwMDYvdHlwZXMiIHhtbG5zOmh0bWw9 Imh0dHA6Ly93d3cu
dzMub3JnL1RSL1JFQy1odG1sNDAiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFz Lm1pY3Jvc29mdC5j
b20vb2ZmaWNlLzIwMDQvMTIvb21tbCIgeG1sbnM6bWRzc2k9Imh0dHA6Ly9z Y2hlbWFzLm9wZW54
bWxmb3JtYXRzLm9yZy9wYWNrYWdlLzIwMDYvZGlnaXRhbC1zaWduYXR1cmUi IHhtbG5zOm1yZWxz
PSJodHRwOi8vc2NoZW1hcy5vcGVueG1sZm9ybWF0cy5vcmcvcGFja2FnZS8y MDA2L3JlbGF0aW9u
c2hpcHMiIHhtbG5zOm10PSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29t L3NoYXJlcG9pbnQv
c29hcC9tZWV0aW5ncy8iIHhtbG5zOm12ZXI9Imh0dHA6Ly9zY2hlbWFzLm9w ZW54bWxmb3JtYXRz
Lm9yZy9tYXJrdXAtY29tcGF0aWJpbGl0eS8yMDA2IiB4bWxuczpvPSJ1cm46 c2NoZW1hcy1taWNy
b3NvZnQtY29tOm9mZmljZTpvZmZpY2UiIHhtbG5zOm9hPSJ1cm46c2NoZW1h cy1taWNyb3NvZnQt
Y29tOm9mZmljZTphY3RpdmF0aW9uIiB4bWxuczpvZGM9InVybjpzY2hlbWFz LW1pY3Jvc29mdC1j
b206b2ZmaWNlOm9kYyIgeG1sbnM6b2lzPSJodHRwOi8vc2NoZW1hcy5taWNy b3NvZnQuY29tL3No
YXJlcG9pbnQvc29hcC9vaXMvIiB4bWxuczpwPSJ1cm46c2NoZW1hcy1taWNy b3NvZnQtY29tOm9m
ZmljZTpwb3dlcnBvaW50IiB4bWxuczpwcGRhPSJodHRwOi8vd3d3LnBhc3Nw b3J0LmNvbS9OYW1l
U3BhY2UueHNkIiB4bWxuczpwcHRzbD0iaHR0cDovL3NjaGVtYXMubWljcm9z b2Z0LmNvbS9zaGFy
ZXBvaW50L3NvYXAvU2xpZGVMaWJyYXJ5LyIgeG1sbnM6cT0iaHR0cDovL3Nj aGVtYXMueG1sc29h
cC5vcmcvc29hcC9lbnZlbG9wZS8iIHhtbG5zOlJlcGw9Imh0dHA6Ly9zY2hl bWFzLm1pY3Jvc29m
dC5jb20vcmVwbC8iIHhtbG5zOnJzPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQt Y29tOnJvd3NldCIg
eG1sbnM6cnRjPSJodHRwOi8vbWljcm9zb2Z0LmNvbS9vZmZpY2VuZXQvY29u ZmVyZW5jaW5nIiB4
bWxuczpzPSJ1dWlkOkJEQzZFM0YwLTZEQTMtMTFkMS1BMkEzLTAwQUEwMEMx NDg4MiIgeG1sbnM6
c3A9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC8i IHhtbG5zOnNwcz0i
aHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAv IiB4bWxuczpzcHNs
PSJodHRwOi8vbWljcm9zb2Z0LmNvbS93ZWJzZXJ2aWNlcy9TaGFyZVBvaW50 UG9ydGFsU2VydmVy
L1B1Ymxpc2hlZExpbmtzU2VydmljZSIgeG1sbnM6c3B3cD0iaHR0cDovL21p Y3Jvc29mdC5jb20v
c2hhcmVwb2ludC93ZWJwYXJ0cGFnZXMiIHhtbG5zOnNzPSJ1cm46c2NoZW1h cy1taWNyb3NvZnQt
Y29tOm9mZmljZTpzcHJlYWRzaGVldCIgeG1sbnM6c3Q9IiYjMTsiIHhtbG5z OnN1Yj0iaHR0cDov
L3NjaGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvMjAwMi8x L2FsZXJ0cy8iIHht
bG5zOnVkYz0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9kYXRhL3Vk YyIgeG1sbnM6dWRj
cDJwPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEvdWRjL3Bh cnR0b3BhcnQiIHht
bG5zOnVkY3M9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vZGF0YS91 ZGMvc29hcCIgeG1s
bnM6dWRjeGY9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vZGF0YS91 ZGMveG1sZmlsZSIg
eG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5z Onc9InVybjpzY2hl
bWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOndvcmQiIHhtbG5zOndmPSJodHRw Oi8vc2NoZW1hcy5t
aWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29hcC93b3JrZmxvdy8iIHhtbG5z Ong9InVybjpzY2hl
bWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOmV4Y2VsIiB4bWxuczp4Mj0iaHR0 cDovL3NjaGVtYXMu
bWljcm9zb2Z0LmNvbS9vZmZpY2UvZXhjZWwvMjAwMy94bWwiIHhtbG5zOnhz ZD0iaHR0cDovL3d3
dy53My5vcmcvMjAwMS9YTUxTY2hlbWEiIHhtbG5zOnhzaT0iaHR0cDovL3d3 dy53My5vcmcvMjAw
MS9YTUxTY2hlbWEtaW5zdGFuY2UiIHhtbG5zOlo9InVybjpzY2hlbWFzLW1p Y3Jvc29mdC1jb206
Ij48aGVhZD48TUVUQSBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRm LTgiIGh0dHAtZXF1
aXY9IkNvbnRlbnQtVHlwZSI+DQo8TUVUQSBjb250ZW50PSJ0ZXh0L2h0bWw7 IGNoYXJzZXQ9dXRm
LTgiIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSI+DQoNCjxtZXRhIGNvbnRl bnQ9InRleHQvaHRt
bDsgY2hhcnNldD11dGYtOCIgaHR0cC1lcXVpdj1Db250ZW50LVR5cGU+DQo8 bWV0YSBjb250ZW50
PSJNaWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQgbWVkaXVtKSIgbmFtZT1H ZW5lcmF0b3I+DQo8
c3R5bGU+DQo8IS0tDQogLyogRm9udCBEZWZpbml0aW9ucyAqLw0KIEBmb250 LWZhY2UNCgl7Zm9u
dC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAz IDIgNDt9DQpAZm9u
dC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDEx IDYgNCAzIDUgNCA0
IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0K CXBhbm9zZS0xOjIg
MTEgNiA5IDIgMiA0IDMgMiA0O30NCiAvKiBTdHlsZSBEZWZpbml0aW9ucyAq Lw0KIHAuTXNvTm9y
bWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBj bTsNCgltYXJnaW4t
Ym90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZh bWlseToiVGltZXMg
TmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxp bmsNCgl7bXNvLXN0
eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0 aW9uOnVuZGVybGlu
ZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7 bXNvLXN0eWxlLXBy
aW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30N
CnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxp bms6IkhUTUwgUHJl
Zm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRv bTouMDAwMXB0Ow0K
CWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3 Ijt9DQpzcGFuLkhU
TUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFBy ZWZvcm1hdHRlZCBD
aGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxp bms6IkhUTUwgUHJl
Zm9ybWF0dGVkIjsNCglmb250LWZhbWlseTpDb25zb2xhczt9DQpzcGFuLkVt YWlsU3R5bGUxOQ0K
CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWls eToiQ2FsaWJyaSIs
InNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1 bHQNCgl7bXNvLXN0
eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpA cGFnZSBTZWN0aW9u
MQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcy LjBwdCA3Mi4wcHQg
NzIuMHB0O30NCmRpdi5TZWN0aW9uMQ0KCXtwYWdlOlNlY3Rpb24xO30NCi0t Pg0KPC9zdHlsZT4N
CjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KIDxvOnNoYXBlZGVmYXVsdHMg djpleHQ9ImVkaXQi
IHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lm IGd0ZSBtc28gOV0+
PHhtbD4NCiA8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQogIDxvOmlk bWFwIHY6ZXh0PSJl
ZGl0IiBkYXRhPSIxIiAvPg0KIDwvbzpzaGFwZWxheW91dD48L3htbD48IVtl bmRpZl0tLT4NCjwv
aGVhZD48Qk9EWT4NCjxESVYgU1RZTEU9IkZPTlQtU0laRTogOXB0OyBGT05U LUZBTUlMWTogQ291
cmllciBOZXciPg0KPERJVj4NCjxESVY+PEZPTlQgRkFDRT0iQXJpYWwiIFNJ WkU9IjIiPg0KDQo8
ZGl2IGNsYXNzPVNlY3Rpb24xPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNw YW4gc3R5bGU9J2Zv
bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIjsNCmNvbG9y
OiMxRjQ5N0QnPkRlYXIgYWxsLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0K PHAgY2xhc3M9TXNv
Tm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiJDYWxpYnJp
Iiwic2Fucy1zZXJpZiI7DQpjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48
L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1z aXplOjExLjBwdDtm
b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KY29sb3I6IzFG NDk3RCc+SSB3b3Vs
ZCBsb3ZlIHRvIGhhdmUgdGhpbmdzIGNvdmVyZWQsIGJ1dCBJIGhhdmUgaW5o ZXJpdGVkIHRoaXMN
CnNldHVwLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNv Tm9ybWFsPjxzcGFu
IHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJp
ZiI7DQpjb2xvcjojMUY0OTdEJz5JIGFtIHN1cmUgd2Ugd2lsbCBpbXByb3Zl IGl0LCBidXQgSSBo
YXZlIHRvIG1ha2UgdGhlIG1vc3Qgd2l0aA0Kd2hhdCBJIGhhdmUgZ290LCBJ IGFtIGFmcmFpZC48
bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48 c3BhbiBzdHlsZT0n
Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMt c2VyaWYiOw0KY29s
b3I6IzFGNDk3RCc+SSBhbSBncmF0ZWZ1bCBmb3IgYWxsIHRoZSBoZWxwIHNv IGZhciwgSSByZWFs
bHkgYXBwcmVjaWF0ZSBpdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxw IGNsYXNzPU1zb05v
cm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eToiQ2FsaWJyaSIs
InNhbnMtc2VyaWYiOw0KY29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9w
Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMS4wcHQ7Zm9u
dC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCmNvbG9yOiMxRjQ5 N0QnPlBzIEkgdGhp
bmsgdGhlcmUgc2hvdWxkIGJlIGFuIGVhc2llciB3YXksIG1heWJlIGRvaW5n IGFzDQpmb2xsb3dz
OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFs PjxzcGFuIHN0eWxl
PSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu cy1zZXJpZiI7DQpj
b2xvcjojMUY0OTdEJz4xIOKAkyBEdW1wIHRoZSBkYXRhYmFzZSBvbmxpbmUg d2l0aCBwZ19kdW1w
LCB3aGlsZSBwcm9kdWN0aW9uDQpzZXJ2ZXIgaXMgc3RpbGwgcnVubmluZzxv OnA+PC9vOnA+PC9z
cGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdm b250LXNpemU6MTEu
MHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQpjb2xv cjojMUY0OTdEJz4y
IOKAkyBSZXN0b3JlIGl0IHRvIHRoZSBuZXcgc2VydmVyLCB3aGlsZSBvbGQg c2VydmVyIGlzIHN0
aWxsDQpvbmxpbmUgPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFz cz1Nc29Ob3JtYWw+
PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNh bGlicmkiLCJzYW5z
LXNlcmlmIjsNCmNvbG9yOiMxRjQ5N0QnPjMg4oCTIE9uIHRoZSBvbGQgc2Vy dmVyLCBydW4gYSBx
dWVyeSBsb29raW5nIGZvciBhbGwgdGhlIG5ldw0KdHJhbnNhY3Rpb25zIHNp bmNlIHRoZSBsYXN0
IGZ1bGwgYmFja3VwLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xh c3M9TXNvTm9ybWFs
PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fu
cy1zZXJpZiI7DQpjb2xvcjojMUY0OTdEJz40IOKAkyBSdW4gYSBwZ19kdW1w IHRvIGR1bXAgb25s
eSB0aGUgbmV3IHRyYW5zYWN0aW9ucyBzaW5jZSBsYXN0DQpiYWNrdXAgYW5k IHJlc3RvcmUgdG8g
dGhlIG5ldyBzZXJ2ZXIgb3Ig4oCYYXBwZW5k4oCZIHRvIHRoZSBuZXcgc2Vy dmVyLjxvOnA+PC9v
OnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0 eWxlPSdmb250LXNp
emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 DQpjb2xvcjojMUY0
OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNz PU1zb05vcm1hbD48
c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2Fs aWJyaSIsInNhbnMt
c2VyaWYiOw0KY29sb3I6IzFGNDk3RCc+SSB0aGluayB0aGlzIHNob3VsZCBi ZSBwb3NzaWJsZSB0
byBkby48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05v cm1hbD48c3BhbiBz
dHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIs InNhbnMtc2VyaWYi
Ow0KY29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KDQo8cCBjbGFz
cz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6IkNh
bGlicmkiLCJzYW5zLXNlcmlmIjsNCmNvbG9yOiMxRjQ5N0QnPlRoYW5rIHlv dSB2ZXJ5IG11Y2gg
Zm9yIGFsbCB5b3VyIHN1cHBvcnQgYW5kIGhlbHAsIHJlYWxseQ0KYXBwcmVj aWF0ZWQuPG86cD48
L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4g c3R5bGU9J2ZvbnQt
c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlm IjsNCmNvbG9yOiMx
RjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xh c3M9TXNvTm9ybWFs
PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fu
cy1zZXJpZiI7DQpjb2xvcjojMUY0OTdEJz5SZW5hdG88bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQoN
CjxkaXY+DQoNCjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgRkFDRT0iQXJp YWwiIFNJWkU9IjIi
PjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgRkFDRT0iQXJpYWwi IFNJWkU9IjIiPjxG
T05UIEZBQ0U9IkFyaWFsIiBTSVpFPSIyIj5SZW5hdG8gT2xpdmVpcmE8QlI+ U3lzdGVtcyBBZG1p
bmlzdHJhdG9yPEJSPmUtbWFpbDogcmVuYXRvLm9saXZlaXJhQGdyYW50LmNv LnVrPC9GT05UPjwv
Rk9OVD48Rk9OVCBGQUNFPSJBcmlhbCIgU0laRT0iMiI+PEZPTlQgRkFDRT0i QXJpYWwiIFNJWkU9
IjIiPjwvRk9OVD48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIEZBQ0U9IkFy aWFsIiBTSVpFPSIy
Ij48Rk9OVCBGQUNFPSJBcmlhbCIgU0laRT0iMiI+PC9GT05UPjwvRk9OVD4m bmJzcDs8L0RJVj4N
CjxESVY+PEZPTlQgRkFDRT0iQXJpYWwiIFNJWkU9IjIiPjxGT05UIEZBQ0U9 IkFyaWFsIiBTSVpF
PSIyIj5UZWw6ICs0NCAoMCkxNzYzIDI2MDgxMTxCUj5GYXg6ICs0NCAoMCkx NzYzIDI2MjQxMDxC
Uj48QSBIUkVGPSJodHRwOi8vd3d3LmdyYW50LmNvLnVrLyI+d3d3LmdyYW50 LmNvLnVrPC9BPjwv
Rk9OVD48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIEZBQ0U9IkFyaWFsIiBT SVpFPSIyIj48Rk9O
VCBGQUNFPSJBcmlhbCIgU0laRT0iMiI+PC9GT05UPjwvRk9OVD4mbmJzcDs8 L0RJVj4NCjxESVY+
PEZPTlQgRkFDRT0iQXJpYWwiIFNJWkU9IjIiPjxGT05UIEZBQ0U9IkFyaWFs IiBTSVpFPSIyIj5H
cmFudCBJbnN0cnVtZW50cyAoQ2FtYnJpZGdlKSBMdGQgPEJSPiZuYnNwOzxC Uj5Db21wYW55IHJl
Z2lzdGVyZWQgaW4gRW5nbGFuZCwgcmVnaXN0cmF0aW9uIG51bWJlciA2NTgx MzM8QlI+Jm5ic3A7
PEJSPlJlZ2lzdGVyZWQgb2ZmaWNlIGFkZHJlc3M6PEJSPjI5IFN0YXRpb24g Um9hZCwgPEJSPlNo
ZXByZXRoLCA8QlI+Q0FNQlMgU0c4IDZHQiA8QlI+VUs8L0ZPTlQ+PC9GT05U PjwvRElWPg0KPERJ
Vj48Rk9OVCBGQUNFPSJBcmlhbCIgU0laRT0iMiI+PEZPTlQgRkFDRT0iQXJp YWwiIFNJWkU9IjIi
PjwvRk9OVD48L0ZPTlQ+PEZPTlQgRkFDRT0iQXJpYWwiIFNJWkU9IjIiPjxG T05UIEZBQ0U9IkFy
aWFsIiBTSVpFPSIyIj48L0ZPTlQ+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJ Vj48Rk9OVCBGQUNF
PSJBcmlhbCIgU0laRT0iMiI+PEZPTlQgRkFDRT0iQXJpYWwiIFNJWkU9IjIi PjwvRk9OVD48L0ZP
TlQ+PC9ESVY+DQo8RElWPjxGT05UIEZBQ0U9IkFyaWFsIiBTSVpFPSIyIj48 Rk9OVCBGQUNFPSJB
cmlhbCIgU0laRT0iMiI+PC9GT05UPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxE SVY+PEZPTlQgRkFD
RT0iQXJpYWwiIFNJWkU9IjIiPjxGT05UIEZBQ0U9IkFyaWFsIiBTSVpFPSIy Ij4NCg0KPHAgY2xh
c3M9TXNvTm9ybWFsPjxiPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQt c2l6ZToxMC4wcHQ7
Zm9udC1mYW1pbHk6DQoiVGFob21hIiwic2Fucy1zZXJpZiInPkZyb206PC9z cGFuPjwvYj48c3Bh
biBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Ow0KZm9udC1m YW1pbHk6IlRhaG9t
YSIsInNhbnMtc2VyaWYiJz4gcGdzcWwtYWRtaW4tb3duZXJAcG9zdGdyZXNx bC5vcmcNClttYWls
dG86cGdzcWwtYWRtaW4tb3duZXJAcG9zdGdyZXNxbC5vcmddIDxiPk9uIEJl aGFsZiBPZiA8L2I+
ScOxaWdvIE1hcnRpbmV6DQpMYXNhbGE8YnI+DQo8Yj5TZW50OjwvYj4gMDIg QXByaWwgMjAxMCAw
ODo0MTxicj4NCjxiPlRvOjwvYj4gQnJhZCBOaWNob2xzb248YnI+DQo8Yj5D Yzo8L2I+IHBnc3Fs
LWFkbWluPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbQURNSU5dIE1pZ3Jh dGUgcG9zdGdyZXMg
dG8gbmV3ZXIgaGFyZHdhcmU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjwv ZGl2Pg0KDQo8L2Rp
dj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KDQo8cCBjbGFz
cz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1ib3R0b206MTIuMHB0Jz5JIHdv dWxkIG5ldmVyIHNp
bmcgYSBTTEEgZm9yIEhBDQppZiBJIGRvbid0IGhhdmUgc3lzdGVtLCBhdCBs ZWFzdCwgZnVsbHkg
cmVkdW5kYW50IGluIG9yZGVyIHRvIGRlYWwgd2l0aCB0aGVzZQ0KaXNzdWVz Ljxicj4NClNpbmds
ZSBzZXJ2ZXIsIHNpbmdsZSBwb2ludCBvZiBmYWlsdXJlLjxicj4NCjxicj4N Ci0tLS0tT3JpZ2lu
YWwgTWVzc2FnZS0tLS0tPGJyPg0KPGI+RnJvbTwvYj46IEJyYWQgTmljaG9s c29uICZsdDs8YSBo
cmVmPSJtYWlsdG86QnJhZCUyME5pY2hvbHNvbiUyMCUzY2JuaWNob2xzQGNh LmFmaWxpYXMuaW5m
byUzZSI+Ym5pY2hvbHNAY2EuYWZpbGlhcy5pbmZvPC9hPiZndDs8YnI+DQo8 Yj5UbzwvYj46IEnD
sWlnbyBNYXJ0aW5leiBMYXNhbGEgJmx0OzxhIGhyZWY9Im1haWx0bzolM2Ql M2ZJU08tODg1OS0x
JTNmUSUzZkklM2RGMWlnbyUzZiUzZCUyME1hcnRpbmV6JTIwTGFzYWxhJTIw JTNjaW1hcnRpbmV6
QHZlY3RvcnNmLmNvbSUzZSI+aW1hcnRpbmV6QHZlY3RvcnNmLmNvbTwvYT4m Z3Q7PGJyPg0KPGI+
Q2M8L2I+OiBSZW5hdG8gT2xpdmVpcmEgJmx0OzxhIGhyZWY9Im1haWx0bzpS ZW5hdG8lMjBPbGl2
ZWlyYSUyMCUzY3JlbmF0by5vbGl2ZWlyYUBncmFudC5jby51ayUzZSI+cmVu YXRvLm9saXZlaXJh
QGdyYW50LmNvLnVrPC9hPiZndDssDQpwZ3NxbC1hZG1pbiAmbHQ7PGEgaHJl Zj0ibWFpbHRvOnBn
c3FsLWFkbWluJTIwJTNjcGdzcWwtYWRtaW5AcG9zdGdyZXNxbC5vcmclM2Ui PnBnc3FsLWFkbWlu
QHBvc3RncmVzcWwub3JnPC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0PC9iPjog UmU6IFtBRE1JTl0g
TWlncmF0ZSBwb3N0Z3JlcyB0byBuZXdlciBoYXJkd2FyZTxicj4NCjxiPkRh dGU8L2I+OiBUdWUs
IDMwIE1hciAyMDEwIDEwOjM4OjAyIC0wNDAwPG86cD48L286cD48L3A+DQoN CjxwcmU+PG86cD4m
bmJzcDs8L286cD48L3ByZT48cHJlPk9uIFR1ZSwgMjAxMC0wMy0zMCBhdCAx NjoyOSArMDIwMCwg
ScOxaWdvIE1hcnRpbmV6IExhc2FsYSB3cm90ZTo8bzpwPjwvbzpwPjwvcHJl PjxwcmU+Jmd0OyBI
aSBSZW5hdG8uPG86cD48L286cD48L3ByZT48cHJlPiZndDsgPG86cD48L286 cD48L3ByZT48cHJl
PiZndDsgSSB3b3VsZCBmb2xsb3cgdGhlIGFuY2llbnQgbWV0aG9kOiBwZXJm b3JtIGEgcGdfZHVt
cCAvIHBnX3Jlc3RvcmU8bzpwPjwvbzpwPjwvcHJlPjxwcmU+PG86cD4mbmJz cDs8L286cD48L3By
ZT48cHJlPlRoaXMgaXMgdGhlIGVhc2llc3QgYXBwcm9hY2guJm5ic3A7IFRo ZSBwcm9ibGVtIGlz
IHRoYXQgYSBsb3Qgb2YgcGVvcGxlIGhhdmU8bzpwPjwvbzpwPjwvcHJlPjxw cmU+Y29udHJhY3R1
YWwgU0xBJ3MgdGhhdCBkbyBub3QgYWxsb3cgdGhlbSB0byB0YWtlIHRoZWly IHN5c3RlbXMgZG93
biBsb25nPG86cD48L286cD48L3ByZT48cHJlPmVub3VnaCB0byBkbyBhIGR1 bXAgYW5kIHJlc3Rv
cmUgdXBncmFkZS48bzpwPjwvbzpwPjwvcHJlPjxwcmU+PG86cD4mbmJzcDs8 L286cD48L3ByZT4N
Cg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K DQo8L2Rpdj4NCg0K
PC9GT05UPjwvRk9OVD48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElW PjxGT05UIEZBQ0U9
IkFyaWFsIiBTSVpFPSIyIj48Rk9OVCBGQUNFPSJBcmlhbCIgU0laRT0iMiI+ PC9GT05UPjwvRk9O
VD48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+IDwvRElWPg0KPERJVj4NCjxQ IENMQVNTPSJNc29O
b3JtYWwiPjxFTT48Qj48U1BBTiBMQU5HPSJFTi1VUyIgU1RZTEU9IkZPTlQt U0laRTogMThwdDsg
Q09MT1I6IGdyZWVuOyBGT05ULUZBTUlMWTogV2ViZGluZ3MiPjwvU1BBTj48 L0I+PC9FTT4mbmJz
cDs8L1A+DQo8UCBDTEFTUz0iTXNvTm9ybWFsIj48RU0+PEI+PFNQQU4gTEFO Rz0iRU4tVVMiIFNU
WUxFPSJGT05ULVNJWkU6IDE4cHQ7IENPTE9SOiBncmVlbjsgRk9OVC1GQU1J TFk6IFdlYmRpbmdz
Ij5QPC9TUEFOPjwvQj48L0VNPjxFTT48Qj48U1BBTiBMQU5HPSJFTi1VUyIg U1RZTEU9IkZPTlQt
U0laRTogMTBwdDsgQ09MT1I6IGJsYWNrOyBGT05ULUZBTUlMWTogJ1ZlcmRh bmEnLCdzYW5zLXNl
cmlmJyI+IDwvU1BBTj48L0I+PC9FTT48U1RST05HPjxJPjxTUEFOIFNUWUxF PSJGT05ULVNJWkU6
IDcuNXB0OyBDT0xPUjogZ3JlZW47IEZPTlQtRkFNSUxZOiAnQXJpYWwnLCdz YW5zLXNlcmlmJyI+
UGxlYXNlIGNvbnNpZGVyIHRoZSBlbnZpcm9ubWVudCBiZWZvcmUgcHJpbnRp bmcgdGhpcyBlbWFp
bDwvU1BBTj48L0k+PC9TVFJPTkc+PC9QPjwvRElWPg0KPERJVj48Rk9OVCBG QUNFPSJBcmlhbCIg
U0laRT0iMiI+PFNUUk9ORz5DT05GSURFTlRJQUxJVFk8L1NUUk9ORz46IFRo ZSBpbmZvcm1hdGlv
biBpbiB0aGlzIGUtbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGlzIGNvbmZp ZGVudGlhbC4gSXQg
aXMgaW50ZW5kZWQgb25seSBmb3IgdGhlIG5hbWVkIHJlY2lwaWVudHMocyku IElmIHlvdSBhcmUg
bm90IHRoZSBuYW1lZCByZWNpcGllbnQgcGxlYXNlIG5vdGlmeSB0aGUgc2Vu ZGVyIGltbWVkaWF0
ZWx5IGFuZCBkbyBub3QgZGlzY2xvc2UgdGhlIGNvbnRlbnRzIHRvIGFub3Ro ZXIgcGVyc29uIG9y
IHRha2UgY29waWVzLiA8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIEZBQ0U9 IkFyaWFsIiBTSVpF
PSIyIj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIEZBQ0U9IkFy aWFsIiBTSVpFPSIy
Ij48U1RST05HPjwvU1RST05HPjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQg RkFDRT0iQXJpYWwi
IFNJWkU9IjIiPjxTVFJPTkc+VklSVVNFUzo8L1NUUk9ORz4gVGhlIGNvbnRl bnRzIG9mIHRoaXMg
ZS1tYWlsIG9yIGF0dGFjaG1lbnQocykgbWF5IGNvbnRhaW4gdmlydXNlcyB3 aGljaCBjb3VsZCBk
YW1hZ2UgeW91ciBvd24gY29tcHV0ZXIgc3lzdGVtLiBXaGlsc3QgR3JhbnQg SW5zdHJ1bWVudHMg
KENhbWJyaWRnZSkgTHRkIGhhcyB0YWtlbiBldmVyeSByZWFzb25hYmxlIHBy ZWNhdXRpb24gdG8g
bWluaW1pc2UgdGhpcyByaXNrLCB3ZSBjYW5ub3QgYWNjZXB0IGxpYWJpbGl0 eSBmb3IgYW55IGRh
bWFnZSB3aGljaCB5b3Ugc3VzdGFpbiBhcyBhIHJlc3VsdCBvZiBzb2Z0d2Fy ZSB2aXJ1c2VzLiBZ
b3Ugc2hvdWxkIHRoZXJlZm9yZSBjYXJyeSBvdXQgeW91ciBvd24gdmlydXMg Y2hlY2tzIGJlZm9y
ZSBvcGVuaW5nIHRoZSBhdHRhY2htZW50KHMpLjwvRk9OVD48L0RJVj4NCjxE SVY+Jm5ic3A7PC9E
SVY+DQo8RElWPjxGT05UIEZBQ0U9IkFyaWFsIiBTSVpFPSIyIj48L0ZPTlQ+ PC9ESVY+DQo8RElW
PjxGT05UIEZBQ0U9IkFyaWFsIiBTSVpFPSIyIj48U1RST05HPk9wZW5YTUw8 L1NUUk9ORz46IEZv
ciBpbmZvcm1hdGlvbiBhYm91dCB0aGUgT3BlblhNTCBmaWxlIGZvcm1hdCBp biB1c2Ugd2l0aGlu
IEdyYW50IEluc3RydW1lbnRzIHBsZWFzZSB2aXNpdCBvdXIgPEEgSFJFRj0i aHR0cDovL3d3dy5n
cmFudC5jby51ay9TdXBwb3J0L29wZW54bWwuaHRtbCI+d2Vic2l0ZTwvQT48 L0ZPTlQ+PC9ESVY+
PC9ESVY+PC9CT0RZPjwvSFRNTD4NCg==

--_000_7965A9DCF12CC14984420BCC37B1608F25ABF30D34Elzargrantc ou_--