Upgrade procedure.

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

Upgrade procedure.

Vladyslav Bachynskyi
Hi All,

Could someone please advise me on proper upgrade procedure for ATS.

I have 4.0.1 instance installed under:
/opt/trafficserver-4.0.1

I've compiled the new 4.1.1 under:
/opt/trafficserver-4.1.1

I've copied all configs from /opt/trafficserver-4.0.1/etc/trafficserver/* to newly installed 4.1.1, and after I started the new version of ATS I can see in logs that all objects which was HITed before, now are MISSed.
When I switched back to previous version (4.0.1), all objects which was HITed before are HITed now as well.

What I'm doing wrong?

I could not found the upgrade procedure in docs and wiki, please, give me a link, If it's exists.


Thanks,
Reply | Threaded
Open this post in threaded view
|

Re: Upgrade procedure.

Reindl Harald


Am 20.11.2013 08:04, schrieb Vladyslav Bachynskyi:
> Could someone please advise me on proper upgrade procedure for ATS.
>
> I have 4.0.1 instance installed under:
> /opt/trafficserver-4.0.1
>
> I've compiled the new 4.1.1 under:
> /opt/trafficserver-4.1.1

ouch - you should build packages so that you could
do *clean* updates / downgrades

> I've copied all configs from /opt/trafficserver-4.0.1/etc/trafficserver/* to newly installed 4.1.1, and after I
> started the new version of ATS I can see in logs that all objects which was HITed before, now are MISSed.
> When I switched back to previous version (4.0.1), all objects which was HITed before are HITed now as well.
>
> What I'm doing wrong?

look in the logfiles, normally /var/log/trafficserver/

> I could not found the upgrade procedure in docs and wiki, please, give me a link, If it's exists

for 4.0 to 4.1 there is no change needed


signature.asc (271 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Upgrade procedure.

Vladyslav Bachynskyi

On 20.11.2013 11:24, Reindl Harald wrote:

>
> Am 20.11.2013 08:04, schrieb Vladyslav Bachynskyi:
>> Could someone please advise me on proper upgrade procedure for ATS.
>>
>> I have 4.0.1 instance installed under:
>> /opt/trafficserver-4.0.1
>>
>> I've compiled the new 4.1.1 under:
>> /opt/trafficserver-4.1.1
> ouch - you should build packages so that you could
> do *clean* updates / downgrades
>
>> I've copied all configs from /opt/trafficserver-4.0.1/etc/trafficserver/* to newly installed 4.1.1, and after I
>> started the new version of ATS I can see in logs that all objects which was HITed before, now are MISSed.
>> When I switched back to previous version (4.0.1), all objects which was HITed before are HITed now as well.
>>
>> What I'm doing wrong?
> look in the logfiles, normally /var/log/trafficserver/

Nothing special in logs:

diags.log:

[Nov 19 16:30:36.053] {0x2b499f3be3c0} STATUS: opened
/opt/trafficserver/var/log/trafficserver/diags.log
[Nov 19 16:30:36.054] {0x2b499f3be3c0} NOTE: updated diags config
[Nov 19 16:30:36.059] Server {0x2b499f3be3c0} NOTE: cache clustering
disabled
[Nov 19 16:30:36.059] Server {0x2b499f3be3c0} NOTE: clearing statistics
[Nov 19 16:30:36.075] Server {0x2b499f3be3c0} NOTE: ip_allow.config
updated, reloading
[Nov 19 16:30:36.087] Server {0x2b499f3be3c0} WARNING: configuration
changed: [hostdb.config] : reinitializing database
[Nov 19 16:30:36.087] Server {0x2b499f3be3c0} NOTE: reconfiguring host
database
[Nov 19 16:30:36.173] Server {0x2b499f3be3c0} NOTE: cache clustering
disabled
[Nov 19 16:30:36.175] Server {0x2b499f3be3c0} NOTE: logging
initialized[15], logging_mode = 3
[Nov 19 16:30:36.182] Server {0x2b499f3be3c0} NOTE: loading plugin
'/opt/trafficserver-4.1.1/libexec/trafficserver/stats_over_http.so'
[Nov 19 16:30:36.183] Server {0x2b499f3be3c0} NOTE: loading plugin
'/opt/trafficserver-4.1.1/libexec/trafficserver/cacheurl.so'
[Nov 19 16:30:36.185] Server {0x2b499f3be3c0} NOTE: Rolling interval
adjusted from 0 sec to 300 sec for /var/log/trafficserver/cacheurl.log
[Nov 19 16:30:36.234] Server {0x2b499f3be3c0} NOTE: traffic server running
[Nov 19 16:30:40.033] Server {0x2b49a5514700} NOTE: cache enabled

In the access logs just a usual requests...


>
>> I could not found the upgrade procedure in docs and wiki, please, give me a link, If it's exists
> for 4.0 to 4.1 there is no change needed

So I can just install the new version over previous, and everything
should work fine?
Reply | Threaded
Open this post in threaded view
|

Re: Upgrade procedure.

Reindl Harald


Am 20.11.2013 11:00, schrieb Vladyslav Bachynskyi:

> On 20.11.2013 11:24, Reindl Harald wrote:
>>
>> Am 20.11.2013 08:04, schrieb Vladyslav Bachynskyi:
>>> Could someone please advise me on proper upgrade procedure for ATS.
>>>
>>> I have 4.0.1 instance installed under:
>>> /opt/trafficserver-4.0.1
>>>
>>> I've compiled the new 4.1.1 under:
>>> /opt/trafficserver-4.1.1
>> ouch - you should build packages so that you could
>> do *clean* updates / downgrades
>>
>>> I've copied all configs from /opt/trafficserver-4.0.1/etc/trafficserver/* to newly installed 4.1.1, and after I
>>> started the new version of ATS I can see in logs that all objects which was HITed before, now are MISSed.
>>> When I switched back to previous version (4.0.1), all objects which was HITed before are HITed now as well.
>>>
>>> What I'm doing wrong?
>> look in the logfiles, normally /var/log/trafficserver/
>
> Nothing special in logs:
>
> diags.log:
>
> [Nov 19 16:30:36.053] {0x2b499f3be3c0} STATUS: opened
> /opt/trafficserver/var/log/trafficserver/diags.log
>
>>> I could not found the upgrade procedure in docs and wiki, please, give me a link, If it's exists
>> for 4.0 to 4.1 there is no change needed
>
> So I can just install the new version over previous, and everything
> should work fine?
yes, but that is why i *strongly* recommend to build *packages*
RPM removes obsolete files and you have always a clean install
you should never install compilers on servers and build packages on isolated environment with a restricted user
a plain "make install" is the root of all evil on a server over the long


signature.asc (271 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Upgrade procedure.

Vladyslav Bachynskyi
Anyway, I don't understand why I can't use the same cache when I switch over to newly compiled version?
I've checked the object with cache inspector and found, that the key (not url-key) is different for same object under 4.0.1 and 4.1.1, but "first key" is the same:

ATS 4.0.1
Volume  #1 - store='/dev/sda'
first key       409542BD429764BEE60B0610B8924C4D
key     6BA7E5696E9A9E7A1E05212E5264D3C4
sync_serial     10836
write_serial    388912
header length   2480
fragment type   1
No of Alternates        1

ATS 4.1.1
Volume  #1 - store='/dev/sda'
first key       409542BD429764BEE60B0610B8924C4D
key     34CEA58AC5FBA6D240C484307DE4C315
sync_serial     10837
write_serial    388912
header length   2480 
fragment type   1    
No of Alternates        1


Should I copy anything else but *.config files from previous 4.0.1 to 4.1.1 to make 4.1.1 found cached objects?


On 20.11.2013 12:20, Reindl Harald wrote:

Am 20.11.2013 11:00, schrieb Vladyslav Bachynskyi:
On 20.11.2013 11:24, Reindl Harald wrote:
Am 20.11.2013 08:04, schrieb Vladyslav Bachynskyi:
Could someone please advise me on proper upgrade procedure for ATS.

I have 4.0.1 instance installed under:
/opt/trafficserver-4.0.1

I've compiled the new 4.1.1 under:
/opt/trafficserver-4.1.1
ouch - you should build packages so that you could
do *clean* updates / downgrades

I've copied all configs from /opt/trafficserver-4.0.1/etc/trafficserver/* to newly installed 4.1.1, and after I
started the new version of ATS I can see in logs that all objects which was HITed before, now are MISSed.
When I switched back to previous version (4.0.1), all objects which was HITed before are HITed now as well.

What I'm doing wrong?
look in the logfiles, normally /var/log/trafficserver/
Nothing special in logs:

diags.log:

[Nov 19 16:30:36.053] {0x2b499f3be3c0} STATUS: opened
/opt/trafficserver/var/log/trafficserver/diags.log

I could not found the upgrade procedure in docs and wiki, please, give me a link, If it's exists
for 4.0 to 4.1 there is no change needed
So I can just install the new version over previous, and everything
should work fine?
yes, but that is why i *strongly* recommend to build *packages*
RPM removes obsolete files and you have always a clean install
you should never install compilers on servers and build packages on isolated environment with a restricted user
a plain "make install" is the root of all evil on a server over the long


Reply | Threaded
Open this post in threaded view
|

Re: Upgrade procedure.

Reindl Harald
i don't understand why this matters

so prune the cache, it will refill itself because
it is a cache and no critical data

Am 21.11.2013 10:11, schrieb Vladyslav Bachynskyi:

> Anyway, I don't understand why I can't use the same cache when I switch over to newly compiled version?
> I've checked the object with cache inspector and found, that the key (not url-key) is different for same object
> under 4.0.1 and 4.1.1, but "first key" is the same:
>
> ATS 4.0.1
> Volume  #1 - store='/dev/sda'
> first key       409542BD429764BEE60B0610B8924C4D
> key     6BA7E5696E9A9E7A1E05212E5264D3C4
> sync_serial     10836
> write_serial    388912
> header length   2480
> fragment type   1
> No of Alternates        1
>
> ATS 4.1.1
> Volume  #1 - store='/dev/sda'
> first key       409542BD429764BEE60B0610B8924C4D
> key     34CEA58AC5FBA6D240C484307DE4C315
> sync_serial     10837
> write_serial    388912
> header length   2480
> fragment type   1    
> No of Alternates        1


signature.asc (271 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Upgrade procedure.

Vladyslav Bachynskyi
I have many servers with Terabytes of cache.
My two parent proxies has more than 60Tb of cache (each server). So it's
a critical data for me.

On 21.11.2013 11:24, Reindl Harald wrote:

> i don't understand why this matters
>
> so prune the cache, it will refill itself because
> it is a cache and no critical data
>
> Am 21.11.2013 10:11, schrieb Vladyslav Bachynskyi:
>> Anyway, I don't understand why I can't use the same cache when I switch over to newly compiled version?
>> I've checked the object with cache inspector and found, that the key (not url-key) is different for same object
>> under 4.0.1 and 4.1.1, but "first key" is the same:
>>
>> ATS 4.0.1
>> Volume  #1 - store='/dev/sda'
>> first key       409542BD429764BEE60B0610B8924C4D
>> key     6BA7E5696E9A9E7A1E05212E5264D3C4
>> sync_serial     10836
>> write_serial    388912
>> header length   2480
>> fragment type   1
>> No of Alternates        1
>>
>> ATS 4.1.1
>> Volume  #1 - store='/dev/sda'
>> first key       409542BD429764BEE60B0610B8924C4D
>> key     34CEA58AC5FBA6D240C484307DE4C315
>> sync_serial     10837
>> write_serial    388912
>> header length   2480
>> fragment type   1    
>> No of Alternates        1

Reply | Threaded
Open this post in threaded view
|

Re: Upgrade procedure.

Igor Galić-2
In reply to this post by Vladyslav Bachynskyi

Anyway, I don't understand why I can't use the same cache when I switch over to newly compiled version?
I've checked the object with cache inspector and found, that the key (not url-key) is different for same object under 4.0.1 and 4.1.1, but "first key" is the same:

ATS 4.0.1
Volume  #1 - store='/dev/sda'
first key       409542BD429764BEE60B0610B8924C4D
key     6BA7E5696E9A9E7A1E05212E5264D3C4
sync_serial     10836
write_serial    388912
header length   2480
fragment type   1
No of Alternates        1

ATS 4.1.1
Volume  #1 - store='/dev/sda'
first key       409542BD429764BEE60B0610B8924C4D
key     34CEA58AC5FBA6D240C484307DE4C315
sync_serial     10837
write_serial    388912
header length   2480 
fragment type   1    
No of Alternates        1


Should I copy anything else but *.config files from previous 4.0.1 to 4.1.1 to make 4.1.1 found cached objects?

I would copy the *changes* you made to your .config files.

The issues with the key changing is a little off putting.

Do you have any means of verifying verify that ATS serves
the correct objects from cache when run under 4.1.1?

--
Igor Galić

Tel: +43 (0) 664 886 22 883
Mail: [hidden email]
URL: http://brainsware.org/
GPG: 8716 7A9F 989B ABD5 100F  4008 F266 55D6 2998 1641

Reply | Threaded
Open this post in threaded view
|

Re: Upgrade procedure.

Vladyslav Bachynskyi

On 21.11.2013 11:54, Igor Galić wrote:

Anyway, I don't understand why I can't use the same cache when I switch over to newly compiled version?
I've checked the object with cache inspector and found, that the key (not url-key) is different for same object under 4.0.1 and 4.1.1, but "first key" is the same:

ATS 4.0.1
Volume  #1 - store='/dev/sda'
first key       409542BD429764BEE60B0610B8924C4D
key     6BA7E5696E9A9E7A1E05212E5264D3C4
sync_serial     10836
write_serial    388912
header length   2480
fragment type   1
No of Alternates        1

ATS 4.1.1
Volume  #1 - store='/dev/sda'
first key       409542BD429764BEE60B0610B8924C4D
key     34CEA58AC5FBA6D240C484307DE4C315
sync_serial     10837
write_serial    388912
header length   2480 
fragment type   1    
No of Alternates        1


Should I copy anything else but *.config files from previous 4.0.1 to 4.1.1 to make 4.1.1 found cached objects?

I would copy the *changes* you made to your .config files.

The issues with the key changing is a little off putting.

Do you have any means of verifying verify that ATS serves
the correct objects from cache when run under 4.1.1?

I'm not sure what you mean... When run 4.1.1 all previously cached objects under 4.0.1 are MISS, these objects  downloading from parent, and then they HIT again.


Reply | Threaded
Open this post in threaded view
|

Re: Upgrade procedure.

Igor Galić-2




On 21.11.2013 11:54, Igor Galić wrote:

Anyway, I don't understand why I can't use the same cache when I switch over to newly compiled version?
I've checked the object with cache inspector and found, that the key (not url-key) is different for same object under 4.0.1 and 4.1.1, but "first key" is the same:

ATS 4.0.1
Volume  #1 - store='/dev/sda'
first key       409542BD429764BEE60B0610B8924C4D
key     6BA7E5696E9A9E7A1E05212E5264D3C4
sync_serial     10836
write_serial    388912
header length   2480
fragment type   1
No of Alternates        1

ATS 4.1.1
Volume  #1 - store='/dev/sda'
first key       409542BD429764BEE60B0610B8924C4D
key     34CEA58AC5FBA6D240C484307DE4C315
sync_serial     10837
write_serial    388912
header length   2480 
fragment type   1    
No of Alternates        1


Should I copy anything else but *.config files from previous 4.0.1 to 4.1.1 to make 4.1.1 found cached objects?

I would copy the *changes* you made to your .config files.

The issues with the key changing is a little off putting.

Do you have any means of verifying verify that ATS serves
the correct objects from cache when run under 4.1.1?

I'm not sure what you mean... When run 4.1.1 all previously cached objects under 4.0.1 are MISS, these objects  downloading from parent, and then they HIT again
Well, this is bad. This is especially bad because we advertised this release as 4.x compatible.
I'm very surprised none of our power-users (Yahoo, et al) noticed this.

Currently I'm giving the code a stare-down to see what changed that would prompt the
on-disk cache to become incompatible.

-- i
Igor Galić

Tel: +43 (0) 664 886 22 883
Mail: [hidden email]
URL: http://brainsware.org/
GPG: 8716 7A9F 989B ABD5 100F  4008 F266 55D6 2998 1641

Reply | Threaded
Open this post in threaded view
|

Re: Upgrade procedure.

Leif Hedstrom
On Nov 21, 2013, at 5:06 AM, Igor Galić <[hidden email]> wrote:





On 21.11.2013 11:54, Igor Galić wrote:

Anyway, I don't understand why I can't use the same cache when I switch over to newly compiled version?
I've checked the object with cache inspector and found, that the key (not url-key) is different for same object under 4.0.1 and 4.1.1, but "first key" is the same:

ATS 4.0.1
Volume  #1 - store='/dev/sda'
first key       409542BD429764BEE60B0610B8924C4D
key     6BA7E5696E9A9E7A1E05212E5264D3C4
sync_serial     10836
write_serial    388912
header length   2480
fragment type   1
No of Alternates        1

ATS 4.1.1
Volume  #1 - store='/dev/sda'
first key       409542BD429764BEE60B0610B8924C4D
key     34CEA58AC5FBA6D240C484307DE4C315
sync_serial     10837
write_serial    388912
header length   2480  
fragment type   1     
No of Alternates        1


Should I copy anything else but *.config files from previous 4.0.1 to 4.1.1 to make 4.1.1 found cached objects?

I would copy the *changes* you made to your .config files.

The issues with the key changing is a little off putting.

Do you have any means of verifying verify that ATS serves
the correct objects from cache when run under 4.1.1?

I'm not sure what you mean... When run 4.1.1 all previously cached objects under 4.0.1 are MISS, these objects  downloading from parent, and then they HIT again
Well, this is bad. This is especially bad because we advertised this release as 4.x compatible.
I'm very surprised none of our power-users (Yahoo, et al) noticed this.



I’ve reproduced this. Please file a bug on this issue, I’m trying to track it down right now, but lets get the Jira ticket going.

— Leif

Reply | Threaded
Open this post in threaded view
|

Re: Upgrade procedure.

Igor Galić-2
In reply to this post by Igor Galić-2

Vladyslav,

Can you please comment on the issue I created (TS-2384)?

We'd like to know what platform you're running on, and how,
exactly, you've compiled Apache Traffic Server.

-- i
Igor Galić

Tel: +43 (0) 664 886 22 883
Mail: [hidden email]
URL: http://brainsware.org/
GPG: 8716 7A9F 989B ABD5 100F  4008 F266 55D6 2998 1641