 | |
#11
 
| |||
| |||
|
Re: Mach11 questions -
09-08-2010
, 07:40 PM
|
On Sep 8, 12:44 am, fv_it <f.ver... (AT) strhold (DOT) it> wrote: I think you should deeper navigate in the documentation (Information Center): for example, take a look at the following page.... http://publib.boulder.ibm.com/infoce...opic/com.ibm.a... There you can find (in the "Hardware and software requirements for SD secondary servers" page) some rules regarding how to configure the disks to use SDS in the correct way. Then, you can simply find some tips on the documentation provided by the "Informix on Campus" portal, such as.... Shared Disk Secondary (SDS) Next evolutionary step of HDR -SDS nodes share disks with the primary -Can have 0 to N SDS nodes How does it work? -Primary transmits the current Log Sequence Number (LSN) as it is flushing logs -SDS instance(s) receives the LSN from the primary and reads the logs from the shared disks -SDS instance(s) applies log changes to its buffer cache - SDS instance(s) re-sync processed LSN to primary Uses -Adjust capacity online as demand changes -Lower data storage costs Similarities with HDR secondary node -Dirty reads allowed on SDS nodes -The primary can failover to any SDS node Differences with HDR secondary node -Only manual failover of primary supported Updates on Secondary -Allows updating activity to be performed from the secondary node -Allows the customers to take better advantage of their investment -Supports a DML operation (insert, update, and delete) on the secondary node. -Uses optimistic concurrency to avoid updating a stale copy of the row. -Works on HDR secondary, RSS nodes, and SDS nodes. - Works with the basic data types, UDTs (those that store data in the server), logged smart BLOBs, and partition BLOBs. -Supports temp tables- both explicit and implicit. -Works with ER. Optimistic Concurrency and Writes on the Secondary -We did not implement a distributed lock manager -Added support for row versioning CREATE TABLE …. WITH VERCOLS ALTER TABLE …. [ADD]/[DROP] VERCOLS -Creates a shadow column consisting of an insert checksum value (ifx_insert_checksum) and update version column (ifx_row_version). -If it is determined that the before image on the secondary is different than the current image on the primary, then the write operation is not allowed and an EVERCONFLICT (-7350) error is returned. -If table does not use VERCOLS, then a before image of the row is used to verify that the update is not being attempted on a stale row. Committed Reads on the Secondary -The secondary node supports ‘Committed Read’ and ‘Last Committed Read’ isolation levels. -This is implemented as a locally committed read, not a globally committed read. -The Read on the secondary node will not return an uncommitted read -However the row could be in the process of being updated The above notices come from the PPT presentation called "IDS_Rep_Avail_Overview", you can find it there: https://www.ibm.com/developerworks/w...ay/IDS101/Home Hope this helps, Francesco This is really good information. However, its very confusing since information on sites indicated all secondary solutions for Mach11 are read-only. |
introduced in v11.50.
You can configure any secondary (HDR, RSS or SDS) to allow updates.
And your question: "-How UPDATE commands are routed if coming through an SDS
node" made me think you understood that.
So, now it seems you can do writes on the SDS as well. Now I have more
Quote:
|
questions! Before I was thinking that the application program would be doing reads on the buffer in the SDS node. Are the updates are being done on the actual database on the shared storage? If so, what is the purpose of the buffer on the SDS nodes. |
node will effectively write to the disk.
The buffer on the secondary nodes has exactly the same role an in the
primary. It's used for caching disk pages for speeding up access times (just
like in any RDBMS system)
Regards.
--
Fernando Nunes
Portugal
http://informix-technology.blogspot.com
My email works... but I don't check it frequently...
#12
| |||
| |||
|
|
And your question: "-How UPDATE commands are routed if coming through an SDS node" made me think you understood that. The updates are transparently sent to the primary node. Only the primary node will effectively write to the disk. The buffer on the secondary nodes has exactly the same role an in the primary. It's used for caching disk pages for speeding up access times (just like in any RDBMS system) Regards. -- Fernando Nunes Portugal |
and SDS) where there is an application processes running on each that
wants to read/write to the database. If the reads on the SDS
retrieves data from its own bufferpool and updates were not allowed
(or so I thought at the time) I was wondering how updates were routed
because I assumed they had to go to the primary. Before V11.50 this
was done manually but the user some how?
Now, you state that UPDATEs are allowed on the SDS but are actually
rerouted through the Primary, so it must really be the same as before
except there is some sort of automatic rerouting.
One thing that is confusing with this reroute to the primary is one of
the slides stated the following:
"Uses optimistic concurrency to avoid updating a stale copy of the
row"
"If it is determined that the before image on the secondary is
different than the current image on the primary, then the write
operation is not allowed and an EVERCONFLICT (-7350) error is
returned"
This leads me to believe that updates are not just rerouted to the
primary...its saying there is a possibility of a "stale" or different
copy on the SDS. If the update is merely rerouted to the primary for
the update wouldnt it just look like any other update to a server
where if another process/thread is updating the row the update request
coming from the SDS would just have wait until that update finishes?
This concept of versioning of each row is interesting...and is
centered around my original question on how READs work on the SDS. If
a READ command comes in to the SDS and the copy in the buffer is stale
is this versioning used to determine this and then what happens? If a
dirty read is not specified and you want the uncommitted version does
it have functionality that can somehow get the updated data from the
database?
I really appreciate your help on this...these concepts are important
for us to determine if Mach11 is right for the new product we want to
design.
#13
| |||
| |||
|
|
And your question: "-How UPDATE commands are routed if coming through an SDS node" made me think you understood that. The updates are transparently sent to the primary node. Only the primary node will effectively write to the disk. The buffer on the secondary nodes has exactly the same role an in the primary. It's used for caching disk pages for speeding up access times (just like in any RDBMS system) Regards. -- Fernando Nunes Portugal |
and SDS) where there is an application processes running on each that
wants to read/write to the database. If the reads on the SDS
retrieves data from its own bufferpool and updates were not allowed
(or so I thought at the time) I was wondering how updates were routed
because I assumed they had to go to the primary. Before V11.50 this
was done manually but the user some how?
Now, you state that UPDATEs are allowed on the SDS but are actually
rerouted through the Primary, so it must really be the same as before
except there is some sort of automatic rerouting.
One thing that is confusing with this reroute to the primary is one of
the slides stated the following:
"Uses optimistic concurrency to avoid updating a stale copy of the
row"
"If it is determined that the before image on the secondary is
different than the current image on the primary, then the write
operation is not allowed and an EVERCONFLICT (-7350) error is
returned"
This leads me to believe that updates are not just rerouted to the
primary...its saying there is a possibility of a "stale" copy on the
SDS. If the update is merely rerouted to the primary for the update
wouldnt it just look like any other update to a server where if
another process/thread is updating the row, the update request
coming from the SDS would just have wait until that update finishes?
This concept of versioning of each row is interesting...and is
centered around my original question on how READs work on the SDS.
But I see in the slides that the reads on the SDS only supports
committed reads so this must mot apply to read operations.
I really appreciate your help on this...these concepts are important
for us to determine if Mach11 is right for the new product we want to
design.
#14
| |||
| |||
|
|
And your question: "-How UPDATE commands are routed if coming through an SDS node" made me think you understood that. The updates are transparently sent to the primary node. Only the primary node will effectively write to the disk. The buffer on the secondary nodes has exactly the same role an in the primary. It's used for caching disk pages for speeding up access times (just like in any RDBMS system) Regards. -- Fernando Nunes Portugal No..I was thinking of the topology where you have two nodes (primary and SDS) where there is an application processes running on each that wants to read/write to the database. If the reads on the SDS retrieves data from its own bufferpool and updates were not allowed (or so I thought at the time) I was wondering how updates were routed because I assumed they had to go to the primary. Before V11.50 this was done manually but the user some how? Now, you state that UPDATEs are allowed on the SDS but are actually rerouted through the Primary, so it must really be the same as before except there is some sort of automatic rerouting. |
reference the primary server:
INSERT INTO database@primary_informix_server:table (....) VALUES (...)
as oposite to
INSERT INTO table (....) VALUES (...).
It had to be done as any other distributed query in Informix (a query where
you reference an external engine)
Quote:
|
One thing that is confusing with this reroute to the primary is one of the slides stated the following: "Uses optimistic concurrency to avoid updating a stale copy of the row" "If it is determined that the before image on the secondary is different than the current image on the primary, then the write operation is not allowed and an EVERCONFLICT (-7350) error is returned" This leads me to believe that updates are not just rerouted to the primary...its saying there is a possibility of a "stale" copy on the SDS. If the update is merely rerouted to the primary for the update wouldnt it just look like any other update to a server where if another process/thread is updating the row, the update request coming from the SDS would just have wait until that update finishes? |
secondary. After that it asks the primary to write the new value(s).
When the primary gets this requests it has to read the data from disk
(direct access since it will not need a query plan) or eventually use the
row image already in it's cache.
Since there is a possibilty that the SDS didn't keep up with the LSN sent by
the primary (there is a parameter to limit this - if exceed the SDS will be
disconnected), the image from the SDS and the primary is compared. If equal
the update is done. If not it raises the error.
The comparison can be optimized if you use VERCOLS.
Quote:
|
This concept of versioning of each row is interesting...and is centered around my original question on how READs work on the SDS. But I see in the slides that the reads on the SDS only supports committed reads so this must mot apply to read operations. |
--
Fernando Nunes
Portugal
http://informix-technology.blogspot.com
My email works... but I don't check it frequently...
#15
| ||||
| ||||
|
|
And your question: "-How UPDATE commands are routed if coming through an SDS node" made me think you understood that. |
Quote:
|
The updates are transparently sent to the primary node. Only the primary node will effectively write to the disk. The buffer on the secondary nodes has exactly the same role an in the primary. It's used for caching disk pages for speeding up access times(just like in any RDBMS system) |
Quote:
|
Regards. |
Quote:
|
-- Fernando Nunes Portugal |
No..I was thinking of the topology where you have two nodes (primary
and SDS) where there is an application processes running on each that
wants to read/write to the database. *If the reads on the SDS
retrieves data from its own bufferpool and updates were not allowed
(or so I thought at the time) I was wondering how updates were routed
because I assumed they had to go to the primary. Before V11.50 this
was done manually but the user some how?
Now, you state that UPDATEs are allowed on the SDS but are actually
rerouted through the Primary, so it must really be the same as before
except there is some sort of automatic rerouting.
Before UPDATABLE_SECONDARY the application code would have to explicitly reference the primary server:
INSERT INTO database@primary_informix_server:table (....) VALUES (...)
as oposite to
INSERT INTO table (....) VALUES (...).
It had to be done as any other distributed query in Informix (a query whereyou reference an external engine)
*
One thing that is confusing with this reroute to the primary is one of
the slides stated the following:
"Uses optimistic concurrency to avoid updating a stale copy of the
row"
"If it is determined that the before image on the secondary is
different than the current image on the primary, then the write
operation is not allowed and an EVERCONFLICT (-7350) error is
returned"
This leads me to believe that updates are not just rerouted to the
primary...its saying there is a possibility of a "stale" copy on the
SDS. *If the update is merely rerouted to the primary for the update
wouldnt it just look like any other update to a server where if
another process/thread is updating the row, the update request
coming from the SDS would just have wait until that update finishes?
An update requires the server to locate the row(s). This is done on the secondary. After that it asks the primary to write the new value(s).
When the primary gets this requests it has to read the data from disk (direct access since it will not need a query plan) or eventually use the rowimage already in it's cache.
Since there is a possibilty that the SDS didn't keep up with the LSN sent by the primary (there is a parameter to limit this - if exceed the SDS will be disconnected), the image from the SDS and the primary is compared. If equal the update is done. If not it raises the error.
The comparison can be optimized if you use VERCOLS.
*
This concept of versioning of each row is interesting...and is
centered around my original question on how READs work on the SDS.
But I see in the slides that the reads on the SDS only supports
committed reads so this must mot apply to read operations.
Can you share those slides?
*
--
Fernando Nunes
Portugal
http://informix-technology.blogspot.com
My email works... but I don't check it frequently...
-----Anexo incorporado-----
_______________________________________________
Informix-list mailing list
Informix-list (AT) iiug (DOT) org
http://www.iiug.org/mailman/listinfo/informix-list
#16
| |||
| |||
|
#17
| |||
| |||
|
|
Fernando thanks so much for your time on this. The slides were in one of the links from the first poster, fv_it: https://www.ibm.com/developerworks/w...ay/IDS101/Home The specific slide I pasted the above is in the IDS_Rep_Avail_Overview presentation. _______________________________________________ Informix-list mailing list Informix-list (AT) iiug (DOT) org http://www.iiug.org/mailman/listinfo/informix-list |
Ok.... The reason why I wanted to see the slides is this paragraph:
"This concept of versioning of each row is interesting...and is
centered around my original question on how READs work on the SDS.
But I see in the slides that the reads on the SDS only supports
committed reads so this must mot apply to read operations."
On slide 14 you can see that dirty reads are also supported (most people
with experience in other technologies don't want to use them).
The whole concept of row versioning is what I called as VERCOLS (which can
also be used without MACH 11 to implement what we call optimistic
concurrency).
But again, it you don't use them, the primary can check that the data that
was located and read on the secondary is up to date and as such can be
changed.
If not it will raise the error like it's stated in slide 18.
I'm not sure if this answers all your questions (I suppose it doesn't
because the subject is complex). If not please send the new questions.
Note that due to the nature of SDS, it's more likely that they are up to
date than an HDR or specially an RSS.
Regards.
--
Fernando Nunes
Portugal
http://informix-technology.blogspot.com
My email works... but I don't check it frequently...
#18
| |||
| |||
|
|
On Thu, Sep 9, 2010 at 8:48 PM, shorti <lbrya... (AT) juno (DOT) com> wrote: Fernando thanks so much for your time on this. *The slides were in one of the links from the first poster, fv_it: https://www.ibm.com/developerworks/w...ay/IDS101/Home The specific slide I pasted the above is in the IDS_Rep_Avail_Overview presentation. _______________________________________________ Informix-list mailing list Informix-l... (AT) iiug (DOT) org http://www.iiug.org/mailman/listinfo/informix-list Ok.... The reason why I wanted to see the slides is this paragraph: "This concept of versioning of each row is interesting...and is centered around my original question on how READs work on the SDS. But I see in the slides that the reads on the SDS only supports committed reads so this must mot apply to read operations." On slide 14 you can see that dirty reads are also supported (most people with experience in other technologies don't want to use them). The whole concept of row versioning is what I called as VERCOLS (which can also be used without MACH 11 to implement what we call optimistic concurrency). But again, it you don't use them, the primary can check that the data that was located and read on the secondary is up to date and as such can be changed. If not it will raise the error like it's stated in slide 18. I'm not sure if this answers all your questions (I suppose it doesn't because the subject is complex). If not please send the new questions. Note that due to the nature of SDS, it's more likely that they are up to date than an HDR or specially an RSS. Regards. -- Fernando Nunes Portugal http://informix-technology.blogspot.com My email works... but I don't check it frequently... |
differently:
"The secondary node supports ‘Committed Read’ and ‘Last Committed
Read’ isolation levels."
"This is implemented as a locally committed read, not a globally
committed read.
The Read on the secondary node will not return an uncommitted read
However the row could be in the process of being updated"
Here it states specifically that the secondary will not return
uncommitted reads. In prior database implementations I have not
hesitated in doing dirty reads as long as it applies to the
situation.
This is not the only item confusing in this presentation...slide 8
also specifically says "Secondary available for Read-only queries" for
HDR but later on the other slide does states that updates are
allowed.
#19
| |||
| |||
|
|
On Sep 9, 1:58 pm, Fernando Nunes <domusonl... (AT) gmail (DOT) com> wrote: On Thu, Sep 9, 2010 at 8:48 PM, shorti <lbrya... (AT) juno (DOT) com> wrote: Fernando thanks so much for your time on this. The slides were in one of the links from the first poster, fv_it: https://www.ibm.com/developerworks/w...ay/IDS101/Home The specific slide I pasted the above is in the IDS_Rep_Avail_Overview presentation. _______________________________________________ Informix-list mailing list Informix-l... (AT) iiug (DOT) org http://www.iiug.org/mailman/listinfo/informix-list Ok.... The reason why I wanted to see the slides is this paragraph: "This concept of versioning of each row is interesting...and is centered around my original question on how READs work on the SDS. But I see in the slides that the reads on the SDS only supports committed reads so this must mot apply to read operations." On slide 14 you can see that dirty reads are also supported (most people with experience in other technologies don't want to use them). The whole concept of row versioning is what I called as VERCOLS (which can also be used without MACH 11 to implement what we call optimistic concurrency). But again, it you don't use them, the primary can check that the data that was located and read on the secondary is up to date and as such can be changed. If not it will raise the error like it's stated in slide 18. I'm not sure if this answers all your questions (I suppose it doesn't because the subject is complex). If not please send the new questions. Note that due to the nature of SDS, it's more likely that they are up to date than an HDR or specially an RSS. Regards. -- Fernando Nunes Portugal http://informix-technology.blogspot.com My email works... but I don't check it frequently... I think the slides are confusing because on slide 19 it says differently: "The secondary node supports ‘Committed Read’ and ‘Last Committed Read’ isolation levels." "This is implemented as a locally committed read, not a globally committed read. The Read on the secondary node will not return an uncommitted read However the row could be in the process of being updated" ... when using committed read isolation level... |
Quote:
|
Here it states specifically that the secondary will not return uncommitted reads. In prior database implementations I have not hesitated in doing dirty reads as long as it applies to the situation. |
assume that a slide that talks about Committed reads means that dirty reads
are not possible.
Quote:
|
This is not the only item confusing in this presentation...slide 8 also specifically says "Secondary available for Read-only queries" for HDR but later on the other slide does states that updates are allowed. |
provide before 11.50.... I think somebody already suggested: You can access
a virtual machine with a complete MACH 11 setup (all nodes on the same
machine). It's a perfect way to make some tests.
Regards.
--
Fernando Nunes
Portugal
http://informix-technology.blogspot.com
My email works... but I don't check it frequently...
#20
| |||
| |||
|
|
Fernando thanks so much for your time on this. The slides were in one of the links from the first poster, fv_it: https://www.ibm.com/developerworks/w...ay/IDS101/Home The specific slide I pasted the above is in the IDS_Rep_Avail_Overview presentation. _______________________________________________ Informix-list mailing list Informix-list (AT) iiug (DOT) org http://www.iiug.org/mailman/listinfo/informix-list |
Quote:
|
Fernando thanks so much for your time on this. The slides were in one of the links from the first poster, fv_it: https://www.ibm.com/developerworks/w...ay/IDS101/Home The specific slide I pasted the above is in the IDS_Rep_Avail_Overview presentation. _______________________________________________ Informix-list mailing list Informix-list (AT) iiug (DOT) org http://www.iiug.org/mailman/listinfo/informix-list |
to use myschemart
 |
« Previous Thread
|
Next Thread »
| Thread Tools | |
| Display Modes | |
Linear Mode
| |
Powered by vBulletin Version 3.5.3
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.