Hello...
I've been following the recent IPv6 threads with interest. I decided
to test the M in LAMP for IPv6 support (Although it was really a FreeBSD
server not Linux). It seems than only newer versions (5.5 rc) of MySQL
support IPv6 network connections. Worse is that although it will
accept a network connection via IPv6, the grant tables do not work. To
successfully get data out of the database, the grants would have to be
open to the world. After a few google searches, it seems that
PostgreSQL is in a similar situation.
Network operations content:
Will "We're running MySQL and Postgress servers that do not support
IPv6" be a valid reason for rejecting IPv6 addresses from ISPs or
hosting providers?
Have any hosting providers network people talked the the DBA people to
tell them that they might have a problem soon?
With RedHat, CentOS, Ubuntu all shipping databases that will not work
correctly with IPv6, I suspect some people are in for a rude awakening
next year. Furthermore, why would Oracle want to 'fix' MySQL?
It seems to me that for medium to large content providers IPv6 would be
great. Have racks and racks of LAMP servers on IPv6, only a few hosts
and load balancers would need to be dual stack. But if the database
servers must be IPv4 only, then there is zero benefit to add IPv6
anywhere else.
note: by LAMP I really mean Linux/FreeBSD/Solaris , Apache/nginx/etc,
MySQL/PostgressSQL/etc, and php/perl/python/ruby.
And thanks to the FreeBSD people for making 6to4 so easy to setup for
initial IPv6 testing.
First, it's not like the flag day is tomorrow.
And then, I think if you're running SQL over the public Internet,
you have bigger problems than whether or not you're going to be able
to get v4 addressing and transit.
--msa
Network operations content:
Will "We're running MySQL and Postgress servers that do not support
IPv6" be a valid reason for rejecting IPv6 addresses from ISPs or
hosting providers?
Why not have v4 and v6? There's never a reason to reject v6, only the possible need for v4. That being said, MySQL and Postgres often reside close enough to the node that needs them that they should have v4 connectivity (or run v4 over v6 ipsec tunnels).
Have any hosting providers network people talked the the DBA people to
tell them that they might have a problem soon?
Many hosting providers have db on the same server as the web server until they reach a certain size, in which case it is on a private network behind the content servers and not visible from global routing anyways.
With RedHat, CentOS, Ubuntu all shipping databases that will not work
correctly with IPv6, I suspect some people are in for a rude awakening
next year. Furthermore, why would Oracle want to 'fix' MySQL?
I doubt anyone will notice that matters.
It seems to me that for medium to large content providers IPv6 would be
great. Have racks and racks of LAMP servers on IPv6, only a few hosts
and load balancers would need to be dual stack. But if the database
servers must be IPv4 only, then there is zero benefit to add IPv6
anywhere else.
Only need v4 on the private network behind the content hosts. Even geographically distributed applications don't normally make calls across public net directly to a database. If the database itself isn't distributed, one might consider using vpn's to interconnect the sites, but I believe that is a rarity. Perhaps someone with a larger deployment can enlighten us.
Jack
Network operations content:
Will "We're running MySQL and Postgress servers that do not support
IPv6" be a valid reason for rejecting IPv6 addresses from ISPs or
hosting providers?
First, it's not like the flag day is tomorrow.
And then, I think if you're running SQL over the public Internet,
you have bigger problems than whether or not you're going to be able
to get v4 addressing and transit.
patches were available to do it as early as 2005 the work to do it in
and official way was done back in 2008 leading up to the death of
mysql6, it was in 5.5beta...
In a message written on Thu, Oct 21, 2010 at 01:53:49PM -0700, Christopher McCrory wrote:
open to the world. After a few google searches, it seems that
PostgreSQL is in a similar situation.
I don't know when PostgreSQL first supported IPv6, but it works just
fine. I just fired up a stock FreeBSD 8.1 system and built the Postgres
8.4 port with no changes, and viola:
postgresql# netstat -a
Active Internet connections (including servers)
Proto Recv-Q Send-Q Local Address Foreign Address (state)
tcp4 0 0 localhost.postgresql *.* LISTEN
tcp6 0 0 localhost.postgresql *.* LISTEN
$ psql -h ::1
psql (8.4.4)
Type "help" for help.
pgsql=# \l
List of databases
Name | Owner | Encoding | Collation | Ctype | Access privileges
All this is pretty moot point if you run a localized copy of your database
(mysql or postgres) and connect via unix domains sockets.
True. It mostly affects shared/smaller hosting providers who have customers
that want direct access to the database remotely over the public network
(and don't want to use some local admin tool such as phpMyAdmin).
-brandon
In a message written on Thu, Oct 21, 2010 at 01:53:49PM -0700, Christopher
McCrory wrote:
open to the world. After a few google searches, it seems that
PostgreSQL is in a similar situation.
I don't know when PostgreSQL first supported IPv6, but it works just
fine. I just fired up a stock FreeBSD 8.1 system and built the Postgres
8.4 port with no changes, and viola:
All this is pretty moot point if you run a localized copy of your database
(mysql or postgres) and connect via unix domains sockets.
True. It mostly affects shared/smaller hosting providers who have customers
that want direct access to the database remotely over the public network
(and don't want to use some local admin tool such as phpMyAdmin).
linux/unix machines can trivially build ip-tunnels of several flavors.
IMHO you should never, ever make your MySQL accesible over the public
Internet, which renders the issue of MySQL not supporting IPv6 correctly
mostly irrelevant. You could even run your MySQL behind your web backend
using RFC1918 space (something I do recommend).
Moreover, if you need direct access to the engine, you can trivially create
an SSH tunnel (You can even do this in a point-and-click way using the
latest MySQL Workbench). SSH works over IPv6 just fine.
And for the LAMP stack, as long as the "A" fully supports IPv6 (which it
does), we are fine.
Warm regards,
Carlos
Public or not, if someone wants to run IPv6 only, they shouldn't have to have the v4 stack just for the database. Databases must work on the v6 stack.
amen. so isn't that a dba issue and not a netop issue? I subscribe to
postgresql-* lists for my dba fill (:
Hi all,
the replication point is a good one, I did not think about that. However, I
still believe that on the road to v6 adoption, databases are far from being
our most pressing roadblock.
Thanks all!
Carlos