Hi Morgan,
Comments below..
Thanks,
Octave
On 2/6/2017 1:04 PM, Morgan Fainberg wrote:
On Thu, Feb 2, 2017 at 2:28 PM, Octave J. Orgeron
mailto:octave.orge...@oracle.com>> wrote:
That refers to the total length of the row. InnoDB has a limit of
65k and NDB is limited to 14k.
On 02/06/2017 01:28 PM, Octave J. Orgeron wrote:
Hi Mike,
I've had a chance to look through the links you provided. I do think
this is a rather heavy solution that would be more suited if there were
actually significant dialect features to override from MySQL. MySQL and
NDB use the same dialec
On Thu, Feb 2, 2017 at 2:28 PM, Octave J. Orgeron wrote:
> That refers to the total length of the row. InnoDB has a limit of 65k and
> NDB is limited to 14k.
>
> A simple example would be the volumes table in Cinder where the row length
> goes beyond 14k. So in the IF logic block, I change column
Excerpts from Roman Podoliaka's message of 2017-02-03 17:16:36 +0200:
> On Fri, Feb 3, 2017 at 4:41 PM, Mike Bayer wrote:
> > Not sure if people on the list are seeing that we are simultaneously talking
> > about getting rid of Postgresql in the efforts to support only "one
> > database", while at
Hi Mike,
I've had a chance to look through the links you provided. I do think
this is a rather heavy solution that would be more suited if there were
actually significant dialect features to override from MySQL. MySQL and
NDB use the same dialect and the differences really just come down to
o
On 02/03/2017 11:59 AM, Octave J. Orgeron wrote:
Hi Mike,
Comments below..
Thanks,
Octave
On 2/3/2017 7:41 AM, Mike Bayer wrote:
On 02/02/2017 05:28 PM, Octave J. Orgeron wrote:
That refers to the total length of the row. InnoDB has a limit of 65k
and NDB is limited to 14k.
A simple exa
Excerpts from Octave J. Orgeron's message of 2017-02-03 09:54:53 -0700:
> Comments below..
>
> On 2/2/2017 6:22 PM, Doug Hellmann wrote:
> >> Yes, this is major undertaking and major driver for Oracle to setup a
> >> 3rd party CI so that we can automate regression testing against MySQL
> >> Cluste
Comments below..
On 2/3/2017 8:34 AM, Mike Bayer wrote:
On 02/03/2017 10:21 AM, Doug Hellmann wrote:
Excerpts from Mike Bayer's message of 2017-02-03 09:41:11 -0500:
On 02/02/2017 05:28 PM, Octave J. Orgeron wrote:
That refers to the total length of the row. InnoDB has a limit of 65k
and N
Hi Doug,
Comments below..
On 2/3/2017 8:21 AM, Doug Hellmann wrote:
Excerpts from Mike Bayer's message of 2017-02-03 09:41:11 -0500:
On 02/02/2017 05:28 PM, Octave J. Orgeron wrote:
That refers to the total length of the row. InnoDB has a limit of 65k
and NDB is limited to 14k.
A simple exam
Hi Mike,
It might be easier to reduce the size of certain columns today. We have
an enormous amount of wasted space in the tables today. Reducing them
would make things more efficient regardless of the database engine being
used. On the flip side, if we were using SQL Alchemy properly and not
Hi Mike,
Comments below..
Thanks,
Octave
On 2/3/2017 7:41 AM, Mike Bayer wrote:
On 02/02/2017 05:28 PM, Octave J. Orgeron wrote:
That refers to the total length of the row. InnoDB has a limit of 65k
and NDB is limited to 14k.
A simple example would be the volumes table in Cinder where the
Comments below..
On 2/2/2017 6:22 PM, Doug Hellmann wrote:
Yes, this is major undertaking and major driver for Oracle to setup a
3rd party CI so that we can automate regression testing against MySQL
Cluster. On the flip side, it helps solve some of the challenges with
I'm not sure we would want
On 02/03/2017 10:21 AM, Doug Hellmann wrote:
Excerpts from Mike Bayer's message of 2017-02-03 09:41:11 -0500:
On 02/02/2017 05:28 PM, Octave J. Orgeron wrote:
That refers to the total length of the row. InnoDB has a limit of 65k
and NDB is limited to 14k.
A simple example would be the volum
Excerpts from Mike Bayer's message of 2017-02-03 09:41:11 -0500:
>
> On 02/02/2017 05:28 PM, Octave J. Orgeron wrote:
> > That refers to the total length of the row. InnoDB has a limit of 65k
> > and NDB is limited to 14k.
> >
> > A simple example would be the volumes table in Cinder where the row
On Fri, Feb 3, 2017 at 4:41 PM, Mike Bayer wrote:
> Not sure if people on the list are seeing that we are simultaneously talking
> about getting rid of Postgresql in the efforts to support only "one
> database", while at the same time adding one that is in many ways a new
> database.
++
and, FWI
On 02/02/2017 05:28 PM, Octave J. Orgeron wrote:
That refers to the total length of the row. InnoDB has a limit of 65k
and NDB is limited to 14k.
A simple example would be the volumes table in Cinder where the row
length goes beyond 14k. So in the IF logic block, I change columns types
that ar
Excerpts from Octave J. Orgeron's message of 2017-02-02 15:08:14 -0700:
> Comments below..
>
> On 2/2/2017 1:08 PM, Doug Hellmann wrote:
> > Excerpts from Octave J. Orgeron's message of 2017-02-02 12:16:15 -0700:
> >> Hi Doug,
> >>
> >> Comments below..
> >>
> >> Thanks,
> >> Octave
> >>
> >> On 2
That refers to the total length of the row. InnoDB has a limit of 65k
and NDB is limited to 14k.
A simple example would be the volumes table in Cinder where the row
length goes beyond 14k. So in the IF logic block, I change columns types
that are vastly oversized such as status and attach_stat
Comments below..
On 2/2/2017 1:08 PM, Doug Hellmann wrote:
Excerpts from Octave J. Orgeron's message of 2017-02-02 12:16:15 -0700:
Hi Doug,
Comments below..
Thanks,
Octave
On 2/2/2017 11:27 AM, Doug Hellmann wrote:
Excerpts from Octave J. Orgeron's message of 2017-02-02 09:40:23 -0700:
Hi
Hi Doug,
Comments below..
Thanks,
Octave
On 2/2/2017 12:52 PM, Mike Bayer wrote:
On 02/02/2017 02:16 PM, Octave J. Orgeron wrote:
Hi Doug,
Comments below..
Thanks,
Octave
On 2/2/2017 11:27 AM, Doug Hellmann wrote:
It sounds like part of the plan is to use the configuration setting
to co
On 02/02/2017 02:52 PM, Mike Bayer wrote:
But more critically I noticed you referred to altering the names of
columns to suit NDB. How will this be accomplished? Changing a column
name in an openstack application is no longer trivial, because online
upgrades must be supported for applicatio
Excerpts from Octave J. Orgeron's message of 2017-02-02 12:16:15 -0700:
> Hi Doug,
>
> Comments below..
>
> Thanks,
> Octave
>
> On 2/2/2017 11:27 AM, Doug Hellmann wrote:
> > Excerpts from Octave J. Orgeron's message of 2017-02-02 09:40:23 -0700:
> >> Hi Doug,
> >>
> >> One could try to detect
On 02/02/2017 02:16 PM, Octave J. Orgeron wrote:
Hi Doug,
Comments below..
Thanks,
Octave
On 2/2/2017 11:27 AM, Doug Hellmann wrote:
It sounds like part of the plan is to use the configuration setting
to control how the migration scripts create tables. How will that
work? Does each migratio
Hi Doug,
Comments below..
Thanks,
Octave
On 2/2/2017 11:27 AM, Doug Hellmann wrote:
Excerpts from Octave J. Orgeron's message of 2017-02-02 09:40:23 -0700:
Hi Doug,
One could try to detect the default engine. However, in MySQL Cluster,
you can support multiple storage engines. Only NDB is fu
Excerpts from Octave J. Orgeron's message of 2017-02-02 09:40:23 -0700:
> Hi Doug,
>
> One could try to detect the default engine. However, in MySQL Cluster,
> you can support multiple storage engines. Only NDB is fully clustered
> and replicated, so if you accidentally set a table to be InnoDB
Hi Mike,
I've sent out another email that gives some more insight into how this
will work for the other OpenStack services. The hook in the oslo.db
namespace gives a global configuration point for enabling the patches
elsewhere.
Thanks,
Octave
On 2/2/2017 9:24 AM, Mike Bayer wrote:
On 02
Hi Monty,
Thank you for the feedback. I'm excited about getting these patches
upstream as everyone will be able to benefit from them.
Thanks,
Octave
On 2/2/2017 8:25 AM, Monty Taylor wrote:
On 02/01/2017 09:33 PM, Octave J. Orgeron wrote:
Hi Folks,
I'm working on adding support for MySQL C
Hi Doug,
One could try to detect the default engine. However, in MySQL Cluster,
you can support multiple storage engines. Only NDB is fully clustered
and replicated, so if you accidentally set a table to be InnoDB it won't
be replicated . So it makes more sense for the operator to be explicit
On 02/02/2017 10:25 AM, Monty Taylor wrote:
On 02/01/2017 09:33 PM, Octave J. Orgeron wrote:
Hi Folks,
I'm working on adding support for MySQL Cluster to the core OpenStack
services. This will enable the community to benefit from an
active/active, auto-sharding, and scale-out MySQL database.
On 02/01/2017 09:33 PM, Octave J. Orgeron wrote:
> Hi Folks,
>
> I'm working on adding support for MySQL Cluster to the core OpenStack
> services. This will enable the community to benefit from an
> active/active, auto-sharding, and scale-out MySQL database. My approach
> is to have a single confi
Excerpts from Octave J. Orgeron's message of 2017-02-01 20:33:38 -0700:
> Hi Folks,
>
> I'm working on adding support for MySQL Cluster to the core OpenStack
> services. This will enable the community to benefit from an
> active/active, auto-sharding, and scale-out MySQL database. My approach
>
Hi Folks,
I'm working on adding support for MySQL Cluster to the core OpenStack
services. This will enable the community to benefit from an
active/active, auto-sharding, and scale-out MySQL database. My approach
is to have a single configuration setting in each core OpenStack service
in the o
32 matches
Mail list logo
