Re: Some more ideas

[Fabricio Mota]

Hi, Peter!
 At first, I would like to accord with you a thing, that is, our
conversation is getting so long, and so rich in terms of hypotheses and new
ideas - for my surprising enjoy - that I am get confusion, and losing
control to link it to spec.
So, lets trigger one conversation per subject?
 Ok, I'll reply it so, and add c.c. to the internals list.
 Regards, and wait just some minutes to the first reply!
 Fabricio

 2005/11/20, Peter B. Volk <peter.benjamin.volk@stripped>:
>
> Hi Fabricio,
>
>  here are a few more Ideas and comments, enjoy :)
>
>  >[Peter:] Sound good you'll probably need to do this to support
> transactions anyway since the remote server will need to be able to do a
> rollback if a connection is broken
>
> >before the transaction was committed. And since there is no such thing as
> a part transaction (some minor part of the complete transaction) you'll need
> to tell the remote
>
> >server when a transaction is committed with the same user connection. Or
> keep the connection alive per transaction and flush the connections after
> COMIT. That should
>
> >reduce the persistent connections (I've had horrible nightmares at work
> with to many persistent connections) and "reduce" the complexity to O(t x
> n^2) (with t is # >transaction) persistent connections at a time.
>
>  >Sorry, but how are you thinking about multiple opened transactions at
> same time?
>
> >I thought about synchronous (blocking) commands, i.e, the user really
> could not do anything more before the response comes from all servers
> involved with the sent
>
> >command. Are you thinking about assynchronous management? (server threads
> working in second plane, while the user execute the next commands?)
>
>  Well asynchronous commands won't work since MySql executes the command
> above the engines. So we only need to serve the top part with the data and
> perform the commands that are given to us by MySql. And this execution is
> not parallel. So there will only be one thread per transaction working on
> the engine. Multiple transactions in terms of multiple users generate
> multiple transaction. But every user only has a max of one transaction
> running. So practically we have multiple transactions running since there
> are always more than one user logged in to the system. So the transaction
> can only be a blocking command thingy.
>
>  >Another problem it makes me think right now (that I haven't thought
> before) is about global deadlocks. It could happen, and a way to manage it
> must be thought...
>
>  Might be mainly solved by the masking idea further down
>
>  >My last idea (that's already in doc) involves to use common remote
> login/password to establish a DDE connection. That is, A connects to B, with
> a login/password already existent in B, known by A when
>
> >the DDE-registering process occurred. Consider also, in a synchronous
> (blocking) approaching, the user never will request anything before a
> previous request to be ended.
>
>  So you mean a general login for server communication....sounds ok for me.
>
>  >The idea to evaluate the performance of remote server for internal
> control is very interesting, but don't you think it could have another label
> with less severity than "DOWN" for slow servers? That's
>
> >because, for example, some very short and very critical operations could
> still be performed with this server.
>
> >Another important thing to consider about it, is that the server
> efficience could seem for one differently than for other. An typical example
> of it is about localized network problems.
>
>  Another state like SLOW seems to be interesting and logical. Mybe the
> state could be broken down to 2 Different states: GLOBALY SLOW and SLOW
> meaning that a GLOBALY SLOW server is visible as a SLOW server to all
> servers and a SLOW server only visible to a minor number of server. But I
> think breaking the state down even more to these 2 sub states might be a
> next increment approach. Also when you run a query against a SLOW server
> MySql could produce a warning for the user. This would make the queries
> better debuggable for the DBAs
>
>  >A thing we still didn't start to think is: how could we control
> data-record statistics internally? Could it be an internal (and invisible)
> column for each LDD table? I wait for ideas...
>
>  I don't exactly know how easy it is to create a hidden column on the
> table. But the Statistics could be kept in a separate hidden table. Hidden
> tables are rather easy to create in MySql and InnoDB does this to keep their
> stats for the transactions. You could use the hidden tables to keep the
> statistics without interfering with an SELECT * FROM.... query (since you
> would need to filter the hidden columns out of the result). For the hidden
> table there are 2 options:
>
>  1. The table keeps stats for each row and for each table. So the hidden
> table would inherit the prim. key (or RID) from the visible table and add
> the columns needed for the stats. This would enable the engine to do
> extremely detailed stat analysis for the optimizations but they would be
> rather large
>
>  2. The table keeps stats for each table and each server. This would
> reduce the size of the hidden table. the table would have the Table_id,
> server_id and the stats columns for the analysis. Also this would reduce the
> num. of tables to 1-> better management of the hidden tables.
>
>  Any other Idea?
>
>  I've been thinking........If you are thinking of implementing a RDD Table
> as a masked InnoDB table then you could do this for LDD tables the same way.
> The only problem that would needed to be solved is the autoinc management
> and the Index management. If you go that way it is only a small step to
> complete fault tolerance because you could adjust the masking to mask ndb
> tables instead of InnoDB tables (should be next increment impl.) and the
> step after that would be to make the selection of the mapped engine user
> defined. So a user (or DBA in the ini file) could decide what underlying
> features he wants to use (MyIsams speed, ndb cluster or InnoDB ACID save
> management). This masking would also speed up the development since the
> "only" thing to implement is the hock into the engines and the management
> above the tables (so the mask management). Also this would reduce the
> management of deadlocks of the queries since this is done by the already
> existing engines or the above MySql stuff. Now I don't have any idea how
> easy it would be to implement such a "Masking engine". I think the MySql
> Internals list would be able to give a bit more information about this.
>
> What do you think?
>
>  Greetings
>
> Peter
>
>


--

Sem mais,

Fabricio Mota
Oda Mae Brown - Aprecie sem moderação.
http://www.odamaebrown.com.br